On Tue, Feb 19, 2008 at 09:50:55PM -0800, Greg KH wrote:
> What's the best way to constantly follow this tree? I had cloned it
> a while ago, but now if I 'git pull' it wants to merge things, which
> isn't right.
I would guess:
$ git remote add linux-next
On Tue, Feb 19, 2008 at 09:50:55PM -0800, Greg KH wrote:
What's the best way to constantly follow this tree? I had cloned it
a while ago, but now if I 'git pull' it wants to merge things, which
isn't right.
I would guess:
$ git remote add linux-next
On Thu, Jan 31, 2008 at 07:55:43PM +0200, Adrian Bunk wrote:
> Who was talking about laptops?
If laptops are mostly MP these days, then 'desktops' and 'servers'
certainly are --- so pretty much everyone needs CPU hotplug.
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, Jan 31, 2008 at 07:14:36PM +0200, Adrian Bunk wrote:
> > cpuhotplug is required for suspend/resume.
>
> Not on UP computers.
those are less and less common now, most modern laptops are dual core
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Thu, Jan 31, 2008 at 07:14:36PM +0200, Adrian Bunk wrote:
cpuhotplug is required for suspend/resume.
Not on UP computers.
those are less and less common now, most modern laptops are dual core
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Thu, Jan 31, 2008 at 07:55:43PM +0200, Adrian Bunk wrote:
Who was talking about laptops?
If laptops are mostly MP these days, then 'desktops' and 'servers'
certainly are --- so pretty much everyone needs CPU hotplug.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote:
> Looks like the readdir is in the bowels of the btree code when
> filldir gets called here, there are probably locks on several
> buffers in the btree at this point. This will only show up for large
> directories I bet.
I see it for
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote:
Looks like the readdir is in the bowels of the btree code when
filldir gets called here, there are probably locks on several
buffers in the btree at this point. This will only show up for large
directories I bet.
I see it for
On Sun, Nov 25, 2007 at 04:30:14PM +, Christoph Hellwig wrote:
> The current readdir implementation deadlocks on a btree buffers
> locks because nfsd calls back into ->lookup from the filldir
> callback. The only short-term fix for this is to revert to the old
> inefficient double-buffering
On Sun, Nov 25, 2007 at 04:30:14PM +, Christoph Hellwig wrote:
The current readdir implementation deadlocks on a btree buffers
locks because nfsd calls back into -lookup from the filldir
callback. The only short-term fix for this is to revert to the old
inefficient double-buffering
On Fri, Nov 16, 2007 at 09:19:32AM -0500, Trond Myklebust wrote:
> Very funny, but disabling XFS on the client won't help.
Oops, I meant it for NFSD... and I'm somewhat serious. I'm not
saying it's a good long term solution, but a potentially safer
short-term workaround.
-
To unsubscribe from
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote:
> OK, I'll try this. I hope this can be fixed somehow before 2.6.24...
Well, one simple nasty idea would be something like:
diff --git a/fs/Kconfig b/fs/Kconfig
index 429a002..da231fd 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote:
OK, I'll try this. I hope this can be fixed somehow before 2.6.24...
Well, one simple nasty idea would be something like:
diff --git a/fs/Kconfig b/fs/Kconfig
index 429a002..da231fd 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@
On Fri, Nov 16, 2007 at 09:19:32AM -0500, Trond Myklebust wrote:
Very funny, but disabling XFS on the client won't help.
Oops, I meant it for NFSD... and I'm somewhat serious. I'm not
saying it's a good long term solution, but a potentially safer
short-term workaround.
-
To unsubscribe from
On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote:
> [] mutex_lock_nested+0xcc/0x2c0
> [] do_lookup+0xa4/0x190
> [] __link_path_walk+0x749/0xd10
> [] link_path_walk+0x44/0xc0
> [] path_walk+0x18/0x20
> [] do_path_lookup+0x78/0x1c0
> [] __user_walk_fd+0x38/0x60
> []
On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote:
[c040914c] mutex_lock_nested+0xcc/0x2c0
[c016dc64] do_lookup+0xa4/0x190
[c016f6f9] __link_path_walk+0x749/0xd10
[c016fd04] link_path_walk+0x44/0xc0
[c016fd98] path_walk+0x18/0x20
[c016ff98] do_path_lookup+0x78/0x1c0
On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote:
> With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
> see a hang when accessing some NFS exported XFS filesystems. Local
> access to these filesystems ahead of time works without problems.
>
> This
On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote:
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
see a hang when accessing some NFS exported XFS filesystems. Local
access to these filesystems ahead of time works without problems.
This does not occur
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
see a hang when accessing some NFS exported XFS filesystems. Local
access to these filesystems ahead of time works without problems.
This does not occur with 2.6.23.1. The filesystem does not appear to
be corrupt.
The call
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
see a hang when accessing some NFS exported XFS filesystems. Local
access to these filesystems ahead of time works without problems.
This does not occur with 2.6.23.1. The filesystem does not appear to
be corrupt.
The call
> (to make it easier for people to click)
actually, it's not a tarball either... am I seeing something stale or
perhaps the result of slow 'kernel.org replication?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Mon, Sep 24, 2007 at 09:31:48AM -0700, Greg KH wrote:
> A tarball of the patches can be found at:
> kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.22.8-rc1.gz
^^^
s/testing/review/
On Mon, Sep 24, 2007 at 09:31:48AM -0700, Greg KH wrote:
A tarball of the patches can be found at:
kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.22.8-rc1.gz
^^^
s/testing/review/
(to make it easier for people to click)
actually, it's not a tarball either... am I seeing something stale or
perhaps the result of slow 'kernel.org replication?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Thu, Sep 13, 2007 at 10:17:27PM +0200, Oleg Verych wrote:
> That particular one-line `ALTARCH := i386' of course can be matched
> simpler, because there's only *one* (as written above) whitespace and no
> make's assignment variations,
The goal is to extract the RHS from ALTARCH := ...
>
On Thu, Sep 13, 2007 at 08:34:00PM +0200, Sam Ravnborg wrote:
> A few. Please address them and resubmit with full changelog and
> proper attribution (if possible) and a signed-of-by.
sure
> I would strongly prefer the name "build-pkg".
right
> The prefix -pkg is just to use the magic in
On Thu, Sep 13, 2007 at 08:34:00PM +0200, Sam Ravnborg wrote:
A few. Please address them and resubmit with full changelog and
proper attribution (if possible) and a signed-of-by.
sure
I would strongly prefer the name build-pkg.
right
The prefix -pkg is just to use the magic in top-level
On Thu, Sep 13, 2007 at 10:17:27PM +0200, Oleg Verych wrote:
That particular one-line `ALTARCH := i386' of course can be matched
simpler, because there's only *one* (as written above) whitespace and no
make's assignment variations,
The goal is to extract the RHS from ALTARCH := ...
Also,
This is a somewhat rough first-pass at making a 'minimal tree'
installation target. This installs a partial source-tree which you
can use to build external modules against. It feels pretty unclean
but I'm not aware of a much better way to do some of this.
This patch works for me, even when
This is a somewhat rough first-pass at making a 'minimal tree'
installation target. This installs a partial source-tree which you
can use to build external modules against. It feels pretty unclean
but I'm not aware of a much better way to do some of this.
This patch works for me, even when
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> Are there any architectures still requiring a gcc < 4.0 ?
Yes, sadly in some places (embedded) there are people with older
compiler who want newer kernels.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
Are there any architectures still requiring a gcc 4.0 ?
Yes, sadly in some places (embedded) there are people with older
compiler who want newer kernels.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
> +typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
^
> + __u32 blocksize; /* filesystem (data) block size */
[...]
> + __u32 dirblocksize; /* directory
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
+typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
^
+ __u32 blocksize; /* filesystem (data) block size */
[...]
+ __u32 dirblocksize; /* directory block
MODPOST seems to be spewing bogus warnings. It's not clear how best
to fix it so perhaps we should silence it for now?
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 113dc77..bd6fe7b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -872,6 +872,10 @@ static void
Does this look correct?
diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 9a55807..7bd7cb9 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0,
Does this look correct?
diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 9a55807..7bd7cb9 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0,
MODPOST seems to be spewing bogus warnings. It's not clear how best
to fix it so perhaps we should silence it for now?
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 113dc77..bd6fe7b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -872,6 +872,10 @@ static void
On Wed, May 09, 2007 at 12:24:32AM +0200, Andi Kleen wrote:
> Somehow yes. But i'm not going to add a useless syscall just to
> shut it up.
It turns out this has come up in other places. Sam has a suggestion
on how to silence this per-arch so I'll post a patch once that change
is in.
-
To
On Wed, May 09, 2007 at 12:13:48AM +0200, Andi Kleen wrote:
> Nope. There already is a getcpu vsyscall. This is not needed.
The kbuild magic that checks for missing syscalls needs to be taught
about this then I take it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Tue, May 08, 2007 at 11:37:26AM -0700, Chris Wedgwood wrote:
> +#define __NR_getcpu 280
I see something was merged just now that uses 280. Should I resubmit
this using 281 & 282?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Wed, May 09, 2007 at 12:03:19AM +0400, Alexey Dobriyan wrote:
> For one, size_t should be printed with %zu.
thanks, i wasn't aware of this
> For two, this is already fixed in mainline.
this was against mainline that wasn't more than an hour old when i
sent the patch
-
To unsubscribe from
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
net/sunrpc/sched.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 4a53e94..60df3c1 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -764,7 +764,7 @
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
include/asm-x86_64/unistd.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index 26e23e0..aa7d4bf 100644
--- a/include/asm-x86_64/unistd.h
+++ b/inclu
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
drivers/base/dd.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED]
---
drivers/base/dd.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19 +207,6
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED]
---
net/sunrpc/sched.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 4a53e94..60df3c1 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -764,7 +764,7 @@ void
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED]
---
include/asm-x86_64/unistd.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index 26e23e0..aa7d4bf 100644
--- a/include/asm-x86_64/unistd.h
+++ b/include/asm
On Wed, May 09, 2007 at 12:03:19AM +0400, Alexey Dobriyan wrote:
For one, size_t should be printed with %zu.
thanks, i wasn't aware of this
For two, this is already fixed in mainline.
this was against mainline that wasn't more than an hour old when i
sent the patch
-
To unsubscribe from this
On Tue, May 08, 2007 at 11:37:26AM -0700, Chris Wedgwood wrote:
+#define __NR_getcpu 280
I see something was merged just now that uses 280. Should I resubmit
this using 281 282?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Wed, May 09, 2007 at 12:13:48AM +0200, Andi Kleen wrote:
Nope. There already is a getcpu vsyscall. This is not needed.
The kbuild magic that checks for missing syscalls needs to be taught
about this then I take it?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Wed, May 09, 2007 at 12:24:32AM +0200, Andi Kleen wrote:
Somehow yes. But i'm not going to add a useless syscall just to
shut it up.
It turns out this has come up in other places. Sam has a suggestion
on how to silence this per-arch so I'll post a patch once that change
is in.
-
To
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote:
> On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:
> IIRC, the argument for FA_ALLOCATE changing file size is that
> posix_fallocate() is supposed to change the file size.
But it's not posix_fallocate; it's
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote:
On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:
IIRC, the argument for FA_ALLOCATE changing file size is that
posix_fallocate() is supposed to change the file size.
But it's not posix_fallocate; it's something more
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:
> For FA_ALLOCATE, it's supposed to change the file size if we
> allocate past EOF, right?
I would argue no. Use truncate for that.
> For FA_DEALLOCATE, does it change the filesize at all?
Same as above.
> Or does
> it just punch
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:
For FA_ALLOCATE, it's supposed to change the file size if we
allocate past EOF, right?
I would argue no. Use truncate for that.
For FA_DEALLOCATE, does it change the filesize at all?
Same as above.
Or does
it just punch a
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote:
> If one insists to have fd at first argument, what is wrong with
> having u32 arguments only?
Well, I was one of those who objected as it seems *UGLY* to me.
> It's not that this syscall comes even close to what can be
>
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote:
If one insists to have fd at first argument, what is wrong with
having u32 arguments only?
Well, I was one of those who objected as it seems *UGLY* to me.
It's not that this syscall comes even close to what can be
considered
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch
>
> It sounded this was specific to Ingo.
I'm not sure, it sounds a bit like
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch
It sounded this was specific to Ingo.
I'm not sure, it sounds a bit like
On Mon, Apr 02, 2007 at 12:04:56PM -0700, Tom Strader wrote:
> I have seen quite a few posts regarding unable to open an initial
> console, but my system seems to have the necessary things in place
> so I come looking for help.
your rootfs/initramfs/initrd is missing a valid working /dev/console
On Mon, Apr 02, 2007 at 12:04:56PM -0700, Tom Strader wrote:
I have seen quite a few posts regarding unable to open an initial
console, but my system seems to have the necessary things in place
so I come looking for help.
your rootfs/initramfs/initrd is missing a valid working /dev/console
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote:
>int fallocate(int fd, loff_t offset, loff_t len, int mode)
Right now there are only two possible values for mode --- it's not
clear what additional values there will be in the future.
How about two syscalls? If we decide later
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote:
int fallocate(int fd, loff_t offset, loff_t len, int mode)
Right now there are only two possible values for mode --- it's not
clear what additional values there will be in the future.
How about two syscalls? If we decide later
I hate to comment at this late stage, especially on something that I
think is really a great idea (I did similar more complex, sys_blkalloc
with even more arguments time ago --- I'm glad given how complex this
thread has become I didn't post them now).
In the past there wasn't that much incentive
I hate to comment at this late stage, especially on something that I
think is really a great idea (I did similar more complex, sys_blkalloc
with even more arguments time ago --- I'm glad given how complex this
thread has become I didn't post them now).
In the past there wasn't that much incentive
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> This patch allows for ibm-acpi to coexist (with diminished
> functionality) with other drivers like ACPI_BAY.
Given the ACP_IBM_BAY implementation is more complete (or seems to be,
please comment if that isn't the
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
code to fail to initialize so all the IBM ACPI functionality is
missing. The simplest fix is to just make sure the Kconfig magic
disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
Signed-off-by: Chris Wedgwood <[EMAIL PROTEC
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
code to fail to initialize so all the IBM ACPI functionality is
missing. The simplest fix is to just make sure the Kconfig magic
disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
Signed-off-by: Chris Wedgwood [EMAIL PROTECTED
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
This patch allows for ibm-acpi to coexist (with diminished
functionality) with other drivers like ACPI_BAY.
Given the ACP_IBM_BAY implementation is more complete (or seems to be,
please comment if that isn't the case)
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote:
> Not only has it only been on Nvidia chipsets but we have only seen
> reports on the Nvidia CK804 SATA controller.
People have reported problems with other controllers. I have one here
I can test given a day or so.
I don't think it's
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote:
> I just tried again and while using iommu=soft does avoid the
> corruption problem, as with previous kernels with 2.6.20-rc5 using
> iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
i would file a separate bug about that,
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote:
I just tried again and while using iommu=soft does avoid the
corruption problem, as with previous kernels with 2.6.20-rc5 using
iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
i would file a separate bug about that,
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote:
Not only has it only been on Nvidia chipsets but we have only seen
reports on the Nvidia CK804 SATA controller.
People have reported problems with other controllers. I have one here
I can test given a day or so.
I don't think it's SATA
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote:
> Do you (someone) have (maintain) a list of affected systems,
> including motherboard type and possibly version, BIOS version and
> CPU type? A similar list of unaffected systems with 4GB+ RAM could
> be useful, too.
All I know
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> I agree,... it seems drastic, but this is the only really secure
> solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
> >If one use iommu=soft the sata_nv will continue to use the new code
> >for the ADMA, right?
>
> Right, that shouldn't affect it.
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
If one use iommu=soft the sata_nv will continue to use the new code
for the ADMA, right?
Right, that shouldn't affect it.
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote:
Do you (someone) have (maintain) a list of affected systems,
including motherboard type and possibly version, BIOS version and
CPU type? A similar list of unaffected systems with 4GB+ RAM could
be useful, too.
All I know is
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
> Please don't use that name, it strikes me as much more confusing
> than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> convey what it means, either.
Calling internal symbols _INTERNAL is confusing?
>
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote:
> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
disruptive (though we could
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
> I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> done properly (and I think we use it fairly well).
>
> I think we _can_ do things where we give clear hints to people that
> "we think this is such an internal
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote:
> - error in the Opteron (memory controller)
> - error in the Nvidia chipsets
> - error in the kernel
My guess without further information would be that some, but not all
BIOSes are doing some work to avoid this.
Does
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote:
- error in the Opteron (memory controller)
- error in the Nvidia chipsets
- error in the kernel
My guess without further information would be that some, but not all
BIOSes are doing some work to avoid this.
Does anyone
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
done properly (and I think we use it fairly well).
I think we _can_ do things where we give clear hints to people that
we think this is such an internal Linux
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote:
Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
disruptive (though we could support
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
Please don't use that name, it strikes me as much more confusing
than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
convey what it means, either.
Calling internal symbols _INTERNAL is confusing?
On Wed, Dec 13, 2006 at 08:18:21PM +0100, Christoph Anton Mitterer wrote:
> booting with iommu=soft => works fine
> booting with iommu=noagp => DOESN'T solve the error
> booting with iommu=off => the system doesn't even boot and panics
> When I set IOMMU to disabled in the BIOS the error is not
On Wed, Dec 13, 2006 at 08:20:59PM +0100, Christoph Anton Mitterer wrote:
> Did anyone made any test under Windows? I cannot set there
> iommu=soft, can I?
Windows never uses the hardware iommu, so it's always doing the
equivalent on iommu=soft
-
To unsubscribe from this list: send the line
On Wed, Dec 13, 2006 at 08:20:59PM +0100, Christoph Anton Mitterer wrote:
Did anyone made any test under Windows? I cannot set there
iommu=soft, can I?
Windows never uses the hardware iommu, so it's always doing the
equivalent on iommu=soft
-
To unsubscribe from this list: send the line
On Wed, Dec 13, 2006 at 08:18:21PM +0100, Christoph Anton Mitterer wrote:
booting with iommu=soft = works fine
booting with iommu=noagp = DOESN'T solve the error
booting with iommu=off = the system doesn't even boot and panics
When I set IOMMU to disabled in the BIOS the error is not solved-
On Mon, Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote:
> We could not reproduce the data corruption anymore if we boot the
> machines with the kernel parameter "iommu=soft" i.e. if we use
> software bounce buffering instead of the hw-iommu. (As mentioned
> before, booting with mem=2g
On Mon, Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote:
We could not reproduce the data corruption anymore if we boot the
machines with the kernel parameter iommu=soft i.e. if we use
software bounce buffering instead of the hw-iommu. (As mentioned
before, booting with mem=2g works
On Wed, Dec 06, 2006 at 12:11:38PM +0100, Christian wrote:
> I copied a massive amount of data (more than 500GB) several times
> between the HDDs and ran md5sum each time, but it found no errors.
It might be a known problem that your BIOS addresses already, or maybe
it's restricted to some
On Wed, Dec 06, 2006 at 12:11:38PM +0100, Christian wrote:
I copied a massive amount of data (more than 500GB) several times
between the HDDs and ran md5sum each time, but it found no errors.
It might be a known problem that your BIOS addresses already, or maybe
it's restricted to some
On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote:
> I found a severe bug mainly by fortune because it occurs very
> rarely. My test looks like the following: I have about 30GB of
> testing data on my harddisk,... I repeat verifying sha512 sums on
> these files and check
On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote:
I found a severe bug mainly by fortune because it occurs very
rarely. My test looks like the following: I have about 30GB of
testing data on my harddisk,... I repeat verifying sha512 sums on
these files and check if
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
> 4Kb kernel stacks are the future on i386, and it seems the problems
> it initially caused are now sorted out.
Not entirely.
XFS when mixed with raid/lvm/nfs still blows up. It's probably not
alone in this respect but worse than
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
4Kb kernel stacks are the future on i386, and it seems the problems
it initially caused are now sorted out.
Not entirely.
XFS when mixed with raid/lvm/nfs still blows up. It's probably not
alone in this respect but worse than
1 - 100 of 363 matches
Mail list logo
