Andrew Morton writes:
Plus, we can get in a situation where take a cache-cold, known-zero page
from the pte quicklist when there is a cache-hot, non-zero page sitting in
the page allocator. I suspect that zeroing the cache-hot page would take a
similar amount of time to a single miss agains
David Miller writes:
> I ported this to sparc64 as per the patch below, tested on
> UP SunBlade1500 and 24 cpu Niagara T1000.
Did you see any performance improvement? We used to have quicklists
on ppc, but I remain to be convinced that they actually help.
Also, I didn't understand why we have
David Miller writes:
I ported this to sparc64 as per the patch below, tested on
UP SunBlade1500 and 24 cpu Niagara T1000.
Did you see any performance improvement? We used to have quicklists
on ppc, but I remain to be convinced that they actually help.
Also, I didn't understand why we have to
Bill Huey (hui) writes:
> The places that need to be reverted to raw spinlocks are generally either
> acquired by function calls that allocate the spinlock at a terminal of the
> kernel's lock graph or isolated from other callers completely (parts of the
> timer for logic for instance). It's all
Sergei Shtylyov writes:
> I've floowed up to my patch with such explanation. In the context of
> an-rt
> patch itself, it was just too clear, hence I didn't go into explanations in
> the patch itself. :-)
Well, it might be clear, to you, now, with the context in your head.
But if such a
Sergei Shtylyov writes:
> As I said, this was intended for the -rt patch, hence the question was
> for
> Ingo. I CC'ed the list just to keep people here in a loop.
OK, fair enough, but I still think the patch description was
inadequate. In the -rt context, I would at least expect to see
Sergei Shtylyov writes:
> I've already sent a patch fixing this one (along with many others) a
> month
> ago:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031164.html
>
> I wonder iof it was ever considered... :-/
The entire patch description was just this:
> Convert
Sergei Shtylyov writes:
I've already sent a patch fixing this one (along with many others) a
month
ago:
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031164.html
I wonder iof it was ever considered... :-/
The entire patch description was just this:
Convert the
Sergei Shtylyov writes:
As I said, this was intended for the -rt patch, hence the question was
for
Ingo. I CC'ed the list just to keep people here in a loop.
OK, fair enough, but I still think the patch description was
inadequate. In the -rt context, I would at least expect to see some
Sergei Shtylyov writes:
I've floowed up to my patch with such explanation. In the context of
an-rt
patch itself, it was just too clear, hence I didn't go into explanations in
the patch itself. :-)
Well, it might be clear, to you, now, with the context in your head.
But if such a patch
Bill Huey (hui) writes:
The places that need to be reverted to raw spinlocks are generally either
acquired by function calls that allocate the spinlock at a terminal of the
kernel's lock graph or isolated from other callers completely (parts of the
timer for logic for instance). It's all
Linus Torvalds writes:
> The point being that in the guests, hotunplug is almost useless (for
> bigger ranges), and we're much better off just telling the virtualization
> hosts on a per-page level whether we care about a page or not, than to
> worry about fragmentation.
We don't have that
Linus Torvalds writes:
The point being that in the guests, hotunplug is almost useless (for
bigger ranges), and we're much better off just telling the virtualization
hosts on a per-page level whether we care about a page or not, than to
worry about fragmentation.
We don't have that luxury
Gerd Hoffmann writes:
> This patch fixes the console selection code to *not* consider a boot
> console a full-featured one, so the first non-boot console registering
> will become the default console instead. This way the unregister call
> for the boot console in the register_console() function
Gerd Hoffmann writes:
This patch fixes the console selection code to *not* consider a boot
console a full-featured one, so the first non-boot console registering
will become the default console instead. This way the unregister call
for the boot console in the register_console() function
Ingo Molnar writes:
> add include/linux/syslet.h which contains the user-space API/ABI
> declarations. Add the new header to include/linux/Kbuild as well.
> +struct syslet_uatom {
> + unsigned long flags;
> + unsigned long nr;
> +
Ingo Molnar writes:
add include/linux/syslet.h which contains the user-space API/ABI
declarations. Add the new header to include/linux/Kbuild as well.
+struct syslet_uatom {
+ unsigned long flags;
+ unsigned long nr;
+ long
Andrew Morton writes:
> This is all fairly unpleasant.
>
> What architecture is preventing us from using DIE_NMI_POST on all
> architectures which support ipmi? ia64?
>
> It would be better to simply require that all ipmi-using architectures
> implement notify_die(DIE_NMI_POST, ...).
We're
Andrew Morton writes:
This is all fairly unpleasant.
What architecture is preventing us from using DIE_NMI_POST on all
architectures which support ipmi? ia64?
It would be better to simply require that all ipmi-using architectures
implement notify_die(DIE_NMI_POST, ...).
We're starting
Andi Kleen writes:
> Just to avoid spreading misinformation: modulo some new broken hardware
> (which we always try to work around when found) i386/x86-64 gettimeofday
> is monotonic. AFAIK on the currently known hardware it should be generally
> ok.
>
> However ntpd can always screw you up,
Andi Kleen writes:
Just to avoid spreading misinformation: modulo some new broken hardware
(which we always try to work around when found) i386/x86-64 gettimeofday
is monotonic. AFAIK on the currently known hardware it should be generally
ok.
However ntpd can always screw you up, but
Andrew Morton writes:
> Once a subsystem has a subsystem tree (git or quilt) I basically never
> merge anything which belongs to that tree. It's always
>
> originator->mm->subsystemtree->Linus
>
> If the subsystem tree maintainer wants to tell me "I can't be bothered
> setting up a git
Commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7 breaks the build on
64-bit powerpc because we no longer get the -m64 flag passed to gcc.
There is code in arch/powerpc/Makefile which adds (or used to add)
-m64 to AS, LD and CC if we are running on a 64-bit machine (which I
am) and have a biarch
Commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7 breaks the build on
64-bit powerpc because we no longer get the -m64 flag passed to gcc.
There is code in arch/powerpc/Makefile which adds (or used to add)
-m64 to AS, LD and CC if we are running on a 64-bit machine (which I
am) and have a biarch
Andrew Morton writes:
Once a subsystem has a subsystem tree (git or quilt) I basically never
merge anything which belongs to that tree. It's always
originator-mm-subsystemtree-Linus
If the subsystem tree maintainer wants to tell me I can't be bothered
setting up a git pull for
Mathieu Desnoyers writes:
> * Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote:
> > On Mon, 2007-02-05 at 09:29 -0500, Mathieu Desnoyers wrote:
> > > Missing include in include/asm-powerpc/prom.h
> > >
> > > include/asm-powerpc/prom.h needs to include asm/irq.h because it uses
> > >
Carl Love writes:
> This is the first update to the patch previously posted by Maynard
> Johnson as "PATCH 4/4. Add support to OProfile for profiling CELL".
Is it really necessary to keep posting all these messages to three
lists? Wouldn't cbe-oss-dev be sufficient?
Paul.
-
To unsubscribe
Carl Love writes:
This is the first update to the patch previously posted by Maynard
Johnson as PATCH 4/4. Add support to OProfile for profiling CELL.
Is it really necessary to keep posting all these messages to three
lists? Wouldn't cbe-oss-dev be sufficient?
Paul.
-
To unsubscribe from
Mathieu Desnoyers writes:
* Benjamin Herrenschmidt ([EMAIL PROTECTED]) wrote:
On Mon, 2007-02-05 at 09:29 -0500, Mathieu Desnoyers wrote:
Missing include in include/asm-powerpc/prom.h
include/asm-powerpc/prom.h needs to include asm/irq.h because it uses
irq_of_parse_and_map and
Michael Ellerman writes:
> You can read config space, but it's not clear to me if the HV is allowed
> to filter it and hide things. It's also possible that the device
It appears that the HV does not prevent us from reading or writing any
config space registers for functions that are assigned to
Benjamin Herrenschmidt writes:
> > I'd hate to hit a different Hypervisor that did something close but
> > not quite the same and have the code fail then. So definitely
> > avoiding touching pci config space at all in the calls seems to make a
> > lot of sense. This includes avoiding
Benjamin Herrenschmidt writes:
I'd hate to hit a different Hypervisor that did something close but
not quite the same and have the code fail then. So definitely
avoiding touching pci config space at all in the calls seems to make a
lot of sense. This includes avoiding
Michael Ellerman writes:
You can read config space, but it's not clear to me if the HV is allowed
to filter it and hide things. It's also possible that the device
It appears that the HV does not prevent us from reading or writing any
config space registers for functions that are assigned to
Eric W. Biederman writes:
> @@ -693,15 +664,14 @@ int pci_enable_msi(struct pci_dev* dev)
> if (!pos)
> return -EINVAL;
>
> - WARN_ON(!msi_lookup_irq(dev, PCI_CAP_ID_MSI));
> + WARN_ON(!!dev->msi_enabled);
Minor nit: what's wrong with just WARN_ON(dev->msi_enabled)
Eric W. Biederman writes:
@@ -693,15 +664,14 @@ int pci_enable_msi(struct pci_dev* dev)
if (!pos)
return -EINVAL;
- WARN_ON(!msi_lookup_irq(dev, PCI_CAP_ID_MSI));
+ WARN_ON(!!dev-msi_enabled);
Minor nit: what's wrong with just WARN_ON(dev-msi_enabled) ?
Also
Mathieu Desnoyers writes:
> +static __inline__ int local_dec_if_positive(local_t *l)
> +{
> + int t;
> +
> + __asm__ __volatile__(
> +"1: lwarx %0,0,%1 # local_dec_if_positive\n\
> + addic. %0,%0,-1\n\
> + blt-2f\n"
> + PPC405_ERR77(0,%1)
> +"stwcx.
Mathieu Desnoyers writes:
+static __inline__ int local_dec_if_positive(local_t *l)
+{
+ int t;
+
+ __asm__ __volatile__(
+1: lwarx %0,0,%1 # local_dec_if_positive\n\
+ addic. %0,%0,-1\n\
+ blt-2f\n
+ PPC405_ERR77(0,%1)
+stwcx. %0,0,%1\n\
+
Mariusz Kozlowski writes:
> This patch removes redundant argument check for of_node_get().
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> arch/powerpc/sysdev/cpm2_pic.c |4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff -upr
Robert P. J. Day writes:
> Clean up some PowerPC source files to use the canonical alignment
> macros from kernel.h, and add an ALIGN_DOWN() macro to kernel.h for
> symmetry.
[snip]
> and, no, i didn't test-compile this as i don't have a PPC
> cross-compiler at the moment. sorry.
Yeah. I
Robert P. J. Day writes:
Clean up some PowerPC source files to use the canonical alignment
macros from kernel.h, and add an ALIGN_DOWN() macro to kernel.h for
symmetry.
[snip]
and, no, i didn't test-compile this as i don't have a PPC
cross-compiler at the moment. sorry.
Yeah. I
Mariusz Kozlowski writes:
This patch removes redundant argument check for of_node_get().
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
arch/powerpc/sysdev/cpm2_pic.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -upr
Roman Zippel writes:
> Well, there are still patches umerged for over a year, they probably still
> apply mostly.
Please rebase and repost them, if you want them to go in.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Akinobu Mita writes:
> Use is_init() rather than hard coded pid comparison.
What's the context of this patch? Why is this a good thing to do?
Doing a git grep -w is_init on Linus' current git tree reveals an
is_init() in arch/parisc/kernel/module.c, which looks to be something
different, but
Akinobu Mita writes:
Use is_init() rather than hard coded pid comparison.
What's the context of this patch? Why is this a good thing to do?
Doing a git grep -w is_init on Linus' current git tree reveals an
is_init() in arch/parisc/kernel/module.c, which looks to be something
different, but no
Roman Zippel writes:
Well, there are still patches umerged for over a year, they probably still
apply mostly.
Please rebase and repost them, if you want them to go in.
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Linus Torvalds writes:
>
>
> On Tue, 19 Dec 2006, Paul Mackerras wrote:
> >
> > There is in fact a pretty substantial non-technical difference between
> > static and dynamic linking. If I create a binary by static linking
> > and I include some library, and I
Linus Torvalds writes:
> "Derivation" has nothing to do with "linking". Either it's derived or it
> is not, and "linking" simply doesn't matter. It doesn't matter whether
> it's static or dynamic. That's a detail that simply doesn't have anythign
> at all to do with "derivative work".
There
Junio C Hamano writes:
> Excuse me, but are you two discussing "ld"? ;-)
Oops. Yes. :)
Paul.
-
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
Junio C Hamano writes:
Excuse me, but are you two discussing ld? ;-)
Oops. Yes. :)
Paul.
-
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
Linus Torvalds writes:
Derivation has nothing to do with linking. Either it's derived or it
is not, and linking simply doesn't matter. It doesn't matter whether
it's static or dynamic. That's a detail that simply doesn't have anythign
at all to do with derivative work.
There is in fact a
Linus Torvalds writes:
On Tue, 19 Dec 2006, Paul Mackerras wrote:
There is in fact a pretty substantial non-technical difference between
static and dynamic linking. If I create a binary by static linking
and I include some library, and I distribute that binary to someone
else
Linus Torvalds writes:
> Why do people think that using "ln" is _any_ different from using
> "mkisofs". Both create one file that contains multiple pieces. What's the
> difference - really?
The difference - really - at least for static linking - is that "ln"
makes modifications to each piece
Linus Torvalds writes:
Why do people think that using ln is _any_ different from using
mkisofs. Both create one file that contains multiple pieces. What's the
difference - really?
The difference - really - at least for static linking - is that ln
makes modifications to each piece to make
Mike Kravetz writes:
> Thanks for the debug work! Just curious if you really need
> CONFIG_NODES_SPAN_OTHER_NODES defined for your platform? Can you get
> those types of memory layouts? If not, an easy/immediate fix for you
> might be to simply turn off the option.
We really need
Mike Kravetz writes:
Thanks for the debug work! Just curious if you really need
CONFIG_NODES_SPAN_OTHER_NODES defined for your platform? Can you get
those types of memory layouts? If not, an easy/immediate fix for you
might be to simply turn off the option.
We really need
Russell King writes:
> Why can't we just use atomic_t for this?
On 64-bit platforms, atomic_t tends to be 4 bytes, whereas bitops work
on arrays of unsigned long, i.e. multiples of 8 bytes. We could
use atomic_long_t for this, however.
Paul.
-
To unsubscribe from this list: send the line
Russell King writes:
Why can't we just use atomic_t for this?
On 64-bit platforms, atomic_t tends to be 4 bytes, whereas bitops work
on arrays of unsigned long, i.e. multiples of 8 bytes. We could
use atomic_long_t for this, however.
Paul.
-
To unsubscribe from this list: send the line
Linus Torvalds writes:
> On Mon, 11 Dec 2006, Olaf Hering wrote:
> >
> > arch/powerpc/boot/wrapper:156:version=`${CROSS}strings "$kernel" | grep
> > '^Linux version [-0-9.]' | \
>
> This is also obviously broken (and really sad), but actually ends up being
> better than what
Linus Torvalds writes:
On Mon, 11 Dec 2006, Olaf Hering wrote:
arch/powerpc/boot/wrapper:156:version=`${CROSS}strings $kernel | grep
'^Linux version [-0-9.]' | \
This is also obviously broken (and really sad), but actually ends up being
better than what get_kernel_version
Andrew Morton writes:
> ppc-m48t35-add-missing-bracket.patch
> powerpc-replace-kmallocmemset-with-kzalloc.patch
These are already in Linus' tree.
> Am holding onto these until the powerpc git tree gets un-messied up.
It should be fine now. Linus has pulled it, so there are currently no
Andrew Morton writes:
ppc-m48t35-add-missing-bracket.patch
powerpc-replace-kmallocmemset-with-kzalloc.patch
These are already in Linus' tree.
Am holding onto these until the powerpc git tree gets un-messied up.
It should be fine now. Linus has pulled it, so there are currently no
changes
Adrian Bunk writes:
> This patch changes the EMBEDDED6xx dependencies to the equivalent
> dependency that seems to have been intended.
Nack - CONFIG_EMBEDDED6xx is going away entirely, soon.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Adrian Bunk writes:
This patch changes the EMBEDDED6xx dependencies to the equivalent
dependency that seems to have been intended.
Nack - CONFIG_EMBEDDED6xx is going away entirely, soon.
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Andi Kleen writes:
> On Friday 17 November 2006 23:59, Vivek Goyal wrote:
>
> > + * Copyright (c) 2006-2007 Vivek Goyal ([EMAIL PROTECTED])
>
> Normally it's not ok to take sole copyright on code that you mostly copied ...
Is this a case where the original had no copyright notice? If so,
Andi Kleen writes:
On Friday 17 November 2006 23:59, Vivek Goyal wrote:
+ * Copyright (c) 2006-2007 Vivek Goyal ([EMAIL PROTECTED])
Normally it's not ok to take sole copyright on code that you mostly copied ...
Is this a case where the original had no copyright notice? If so,
what do
)
>
>
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
]
Acked-by: Paul Mackerras [EMAIL PROTECTED]
Matt,
My concern about this series of patches is that it will make it harder
to keep the kernel zlib in sync with the upstream zlib.
Are you signing up to track the upstream zlib and apply any changes
made there to the kernel version, for the forseeable future?
Paul.
Matt,
My concern about this series of patches is that it will make it harder
to keep the kernel zlib in sync with the upstream zlib.
Are you signing up to track the upstream zlib and apply any changes
made there to the kernel version, for the forseeable future?
Paul.
Grant Grundler writes:
> I would argue it more obvious. People looking at the code
> are immediately going to realize it was a deliberate choice to
> not use a spinlock.
It achieves exactly the same effect as spin_lock/spin_unlock, just
more verbosely. :)
> > and it precludes the sorts of
Grant Grundler writes:
I would argue it more obvious. People looking at the code
are immediately going to realize it was a deliberate choice to
not use a spinlock.
It achieves exactly the same effect as spin_lock/spin_unlock, just
more verbosely. :)
and it precludes the sorts of
Grant Grundler writes:
> Ok this is good example - I see what the problem is.
> You could use the following sequence too then:
> pci_block_user_cfg_access
> pci_save_state
> block_ucfg_access = 1
> mb()
> while (spin_is_locked(_lock))
Mark Bellon writes:
> Simply put the existing code has a fixed reservation (claim) address and
> once the kernel plus initrd image are large enough to pass this address
> all sorts of bad things occur. The fix is the dynamically establish the
> first claim address above the loaded kernel plus
Mark Bellon writes:
Simply put the existing code has a fixed reservation (claim) address and
once the kernel plus initrd image are large enough to pass this address
all sorts of bad things occur. The fix is the dynamically establish the
first claim address above the loaded kernel plus
Grant Grundler writes:
Ok this is good example - I see what the problem is.
You could use the following sequence too then:
pci_block_user_cfg_access
pci_save_state
block_ucfg_access = 1
mb()
while (spin_is_locked(pci_lock))
to do on logically-partitioned pSeries
systems.
Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]>
---
drivers/pci/pci.h |1 -
drivers/pci/probe.c | 50 +-
include/linux/pci.h |3 +++
3 files changed, 36 insertions(+), 18 deletions(-)
to do on logically-partitioned pSeries
systems.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
drivers/pci/pci.h |1 -
drivers/pci/probe.c | 50 +-
include/linux/pci.h |3 +++
3 files changed, 36 insertions(+), 18 deletions(-)
diff -urN
Grant Grundler writes:
> On Fri, Sep 02, 2005 at 06:56:35PM -0500, Brian King wrote:
> > Andrew Morton wrote:
> > >Brian King <[EMAIL PROTECTED]> wrote:
> > >
> > >>+void pci_block_user_cfg_access(struct pci_dev *dev)
> > >>+{
> > >>+ unsigned long flags;
> > >>+
> > >>+ pci_save_state(dev);
> >
Grant Grundler writes:
On Fri, Sep 02, 2005 at 06:56:35PM -0500, Brian King wrote:
Andrew Morton wrote:
Brian King [EMAIL PROTECTED] wrote:
+void pci_block_user_cfg_access(struct pci_dev *dev)
+{
+ unsigned long flags;
+
+ pci_save_state(dev);
+ spin_lock_irqsave(pci_lock,
Linas Vepstas writes:
> > One way to clean this up would be to make rpaphp the driver for the
> > EADS bridges (from the pci code's point of view).
>
> I guess I don't understand what that means. Are you suggesting moving
> pSeries_pci.c into the rpaphp code directory?
No, not at all. :)
Marcelo Tosatti writes:
> The memory map structure which contains device configuration/registers
> is _always_ directly mapped with pte's (the 8xx is a chip with builtin
> UART/network/etc functionality).
>
> I don't think there is a need to use read/write acessors.
Generally on PowerPC you
Linas Vepstas writes:
> Actually, no. There are three issues:
> 1) hotplug routines are called from within kernel. GregKH has stated on
>multiple occasions that doing this is wrong/bad/evil. This includes
>calling hot-unplug.
>
> 2) As a result, the code to call hot-unplug is a bit
Linas Vepstas writes:
Actually, no. There are three issues:
1) hotplug routines are called from within kernel. GregKH has stated on
multiple occasions that doing this is wrong/bad/evil. This includes
calling hot-unplug.
2) As a result, the code to call hot-unplug is a bit messy. In
Marcelo Tosatti writes:
The memory map structure which contains device configuration/registers
is _always_ directly mapped with pte's (the 8xx is a chip with builtin
UART/network/etc functionality).
I don't think there is a need to use read/write acessors.
Generally on PowerPC you need to
Linas Vepstas writes:
One way to clean this up would be to make rpaphp the driver for the
EADS bridges (from the pci code's point of view).
I guess I don't understand what that means. Are you suggesting moving
pSeries_pci.c into the rpaphp code directory?
No, not at all. :)
I'm
Russell King writes:
> Have you looked at how serial_core handles this kind of problem in
> its open and close methods? I put some comments in there because
> of the issue, after thinking about it fairly carefully.
Yes, albeit briefly; the problem in con_open is much simpler because
we never
get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called. Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.
Could this go into 2.6.1
and then
con_close on a different fd clears tty-driver_data, because
tty-count is incremented before con_open is called. Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.
Could this go into 2.6.13 please?
Signed-off-by: Paul Mackerras [EMAIL PROTECTED
Russell King writes:
Have you looked at how serial_core handles this kind of problem in
its open and close methods? I put some comments in there because
of the issue, after thinking about it fairly carefully.
Yes, albeit briefly; the problem in con_open is much simpler because
we never need
Benjamin Herrenschmidt writes:
> Ok, so what is the problem then ? Why do we have to wait at all ? Why
> not just unplug/replug right away ?
We'd have to be absolutely certain that the driver could not possibly
take another interrupt or try to access the device on behalf of the
old instance of
Benjamin Herrenschmidt writes:
Ok, so what is the problem then ? Why do we have to wait at all ? Why
not just unplug/replug right away ?
We'd have to be absolutely certain that the driver could not possibly
take another interrupt or try to access the device on behalf of the
old instance of the
Paul Jackson writes:
> ... however ... question for Paul M. ... what version of gcc did this fail
> on?
The gcc-4.0.2 in Debian/ppc sid, which is biarch.
> I finally got my crosstools setup working for me again, and building
> a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail.
Linas Vepstas writes:
> The meta-issue that I'd like to reach consensus on first is whether
> there should be any hot-plug recovery attempted at all. Removing
> hot-plug-recovery support will make many of the issues you raise
> to be moot.
Yes, this probably the thorniest issue we have.
My
I wrote:
> Linas Vepstas writes:
>
> In this patch at least, your mailer seems to have blanked out lines
> that match ^[-+]$. Could you send them to me again with a different
> mailer or put them on a web or ftp site somewhere?
I got 3 copies of each of these mails, one directly, one through
Linas Vepstas writes:
The meta-issue that I'd like to reach consensus on first is whether
there should be any hot-plug recovery attempted at all. Removing
hot-plug-recovery support will make many of the issues you raise
to be moot.
Yes, this probably the thorniest issue we have.
My
Paul Jackson writes:
... however ... question for Paul M. ... what version of gcc did this fail
on?
The gcc-4.0.2 in Debian/ppc sid, which is biarch.
I finally got my crosstools setup working for me again, and building
a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail. That
I wrote:
Linas Vepstas writes:
In this patch at least, your mailer seems to have blanked out lines
that match ^[-+]$. Could you send them to me again with a different
mailer or put them on a web or ftp site somewhere?
I got 3 copies of each of these mails, one directly, one through
Al Viro writes:
> ppc SMP is supported only for 6xx/POWER3/POWER4 - i.e. ones that have
> PPC_STD_MMU. Dependency fixed.
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Paul Mackerras <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line &
Linas Vepstas writes:
In this patch at least, your mailer seems to have blanked out lines
that match ^[-+]$. Could you send them to me again with a different
mailer or put them on a web or ftp site somewhere?
Thanks,
Paul.
-
To unsubscribe from this list: send the line "unsubscribe
Linas Vepstas writes:
In this patch at least, your mailer seems to have blanked out lines
that match ^[-+]$. Could you send them to me again with a different
mailer or put them on a web or ftp site somewhere?
Thanks,
Paul.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
701 - 800 of 1180 matches
Mail list logo
