* Re: 2.6.18-rc5-mm1
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
@ 2006-09-01 9:53 ` Manuel Lauss
2006-09-01 10:44 ` 2.6.18-rc5-mm1 Grant Wilson
` (29 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Manuel Lauss @ 2006-09-01 9:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
I need the following patch to make it build.
__NR_execve is undeclared.
--- a/arch/i386/kernel/sys_i386.c~ 2006-09-01 11:48:45.000000000 +0200
+++ b/arch/i386/kernel/sys_i386.c 2006-09-01 11:48:45.000000000 +0200
@@ -22,6 +22,7 @@
#include <asm/uaccess.h>
#include <asm/ipc.h>
+#include <asm/unistd.h>
/*
* sys_pipe() is the normal C calling standard for creating
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
2006-09-01 9:53 ` 2.6.18-rc5-mm1 Manuel Lauss
@ 2006-09-01 10:44 ` Grant Wilson
2006-09-01 13:50 ` [-mm patch] drivers/md/Kconfig: fix BLOCK dependency Adrian Bunk
2006-09-01 14:15 ` David Howells
2006-09-01 16:00 ` 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error Adrian Bunk
` (28 subsequent siblings)
30 siblings, 2 replies; 138+ messages in thread
From: Grant Wilson @ 2006-09-01 10:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
[snip]
> The CONFIG_BLOCK changes wrecked these.
The CONFIG_BLOCK changes also seem to prevent the selection of any RAID
or LVM drivers...
Cheers,
Grant
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] drivers/md/Kconfig: fix BLOCK dependency
2006-09-01 10:44 ` 2.6.18-rc5-mm1 Grant Wilson
@ 2006-09-01 13:50 ` Adrian Bunk
2006-09-01 14:15 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-01 13:50 UTC (permalink / raw)
To: Grant Wilson, David Howells, Jens Axboe
Cc: Andrew Morton, linux-kernel, dm-devel
On Fri, Sep 01, 2006 at 11:44:29AM +0100, Grant Wilson wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> [snip]
> > The CONFIG_BLOCK changes wrecked these.
>
> The CONFIG_BLOCK changes also seem to prevent the selection of any RAID
> or LVM drivers...
Thanks for the bug report, patch below.
> Cheers,
> Grant
cu
Adrian
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc5-mm1/drivers/md/Kconfig.old 2006-09-01 15:47:10.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/md/Kconfig 2006-09-01 15:47:16.000000000 +0200
@@ -2,7 +2,7 @@
# Block device driver configuration
#
-if CONFIG_BLOCK
+if BLOCK
menu "Multi-device support (RAID and LVM)"
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [-mm patch] drivers/md/Kconfig: fix BLOCK dependency
2006-09-01 10:44 ` 2.6.18-rc5-mm1 Grant Wilson
2006-09-01 13:50 ` [-mm patch] drivers/md/Kconfig: fix BLOCK dependency Adrian Bunk
@ 2006-09-01 14:15 ` David Howells
2006-09-01 14:26 ` Jens Axboe
1 sibling, 1 reply; 138+ messages in thread
From: David Howells @ 2006-09-01 14:15 UTC (permalink / raw)
To: Adrian Bunk
Cc: Grant Wilson, David Howells, Jens Axboe, Andrew Morton,
linux-kernel, dm-devel
Adrian Bunk <bunk@stusta.de> wrote:
> -if CONFIG_BLOCK
> +if BLOCK
Oops.
Acked-By: David Howells <dhowells@redhat.com>
^ permalink raw reply [flat|nested] 138+ messages in thread
* 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
2006-09-01 9:53 ` 2.6.18-rc5-mm1 Manuel Lauss
2006-09-01 10:44 ` 2.6.18-rc5-mm1 Grant Wilson
@ 2006-09-01 16:00 ` Adrian Bunk
2006-09-01 17:13 ` Andrew Morton
2006-09-01 16:40 ` 2.6.18-rc5-mm1 Maciej Rutecki
` (27 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Adrian Bunk @ 2006-09-01 16:00 UTC (permalink / raw)
To: Andrew Morton, Tom Tucker, Steve Wise, Roland Dreier
Cc: linux-kernel, openib-general
On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +amso1100-build-fix.patch
>
> Fix git-infiniband.patch
>...
This causes the following compile error on i386:
<-- snip -->
...
CC drivers/infiniband/hw/amso1100/c2.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c: In function ‘c2_tx_ring_alloc’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c:133: error: implicit declaration of function ‘__raw_writeq’
make[4]: *** [drivers/infiniband/hw/amso1100/c2.o] Error 1
<-- snip -->
There seems to be some confusion regarding whether __raw_writeq() is
considered a platform independent API.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 16:00 ` 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error Adrian Bunk
@ 2006-09-01 17:13 ` Andrew Morton
2006-09-01 17:34 ` Roland Dreier
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-01 17:13 UTC (permalink / raw)
To: Adrian Bunk
Cc: Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general
On Fri, 1 Sep 2006 18:00:23 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm3:
> >...
> > +amso1100-build-fix.patch
> >
> > Fix git-infiniband.patch
> >...
>
> This causes the following compile error on i386:
>
> <-- snip -->
>
> ...
> CC drivers/infiniband/hw/amso1100/c2.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c: In function ‘c2_tx_ring_alloc’:
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.c:133: error: implicit declaration of function ‘__raw_writeq’
> make[4]: *** [drivers/infiniband/hw/amso1100/c2.o] Error 1
>
That would have been me cheerfully deleting stuff because it didn't build
on powerpc.
>
> There seems to be some confusion regarding whether __raw_writeq() is
> considered a platform independent API.
>
It appears to be undocumented and uncommented hence it's not an API
_at all_, is it?
What's __raw_writeq() supposed to do, anyway? On alpha it's writeq()
without an mb(). On parisc it's writeq() only the data is byte-reversed.
On sparc64() it's incomprehensible. On everything else it's writeq().
What a crock.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 17:13 ` Andrew Morton
@ 2006-09-01 17:34 ` Roland Dreier
2006-09-01 18:23 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 17:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general
Andrew> What's __raw_writeq() supposed to do, anyway? On alpha
Andrew> it's writeq() without an mb(). On parisc it's writeq()
Andrew> only the data is byte-reversed. On sparc64() it's
Andrew> incomprehensible. On everything else it's writeq().
My understanding is that __raw_writeq() is like writeq() except not
strongly ordered and without the byte-swap on big-endian
architectures. The __raw_writeX() variants are convenient to avoid
having to write inefficient code like writel(swab32(foo), ...) when
talking to a PCI device that wants big-endian data. Without the raw
variant, you end up with a double swap on big-endian architectures.
sparc64 looks wrong, since __raw_writeq() seems identical to writeq(),
which seems to imply it's going to swab what is stores.
- R.
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 17:34 ` Roland Dreier
@ 2006-09-01 18:23 ` Andrew Morton
2006-09-01 19:53 ` Roland Dreier
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-01 18:23 UTC (permalink / raw)
To: Roland Dreier
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general, David S. Miller
On Fri, 01 Sep 2006 10:34:24 -0700
Roland Dreier <rdreier@cisco.com> wrote:
> Andrew> What's __raw_writeq() supposed to do, anyway? On alpha
> Andrew> it's writeq() without an mb(). On parisc it's writeq()
> Andrew> only the data is byte-reversed. On sparc64() it's
> Andrew> incomprehensible. On everything else it's writeq().
>
> My understanding is that __raw_writeq() is like writeq() except not
> strongly ordered and without the byte-swap on big-endian
> architectures. The __raw_writeX() variants are convenient to avoid
> having to write inefficient code like writel(swab32(foo), ...) when
> talking to a PCI device that wants big-endian data. Without the raw
> variant, you end up with a double swap on big-endian architectures.
>
> sparc64 looks wrong, since __raw_writeq() seems identical to writeq(),
> which seems to imply it's going to swab what is stores.
>
OK. Can we please stop hacking around this in drivers and
a) work out what it's supposed to do
b) document that (Documentation/DocBook/deviceiobook.tmpl or code
comment or whatever)
c) tell arch maintainers?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 18:23 ` Andrew Morton
@ 2006-09-01 19:53 ` Roland Dreier
2006-09-01 20:04 ` Andrew Morton
2006-09-01 20:45 ` [openib-general] " Bryan O'Sullivan
0 siblings, 2 replies; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 19:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general, David S. Miller
Roland> My understanding is that __raw_writeq() is like writeq()
Roland> except not strongly ordered and without the byte-swap on
Roland> big-endian architectures. The __raw_writeX() variants are
Roland> convenient to avoid having to write inefficient code like
Roland> writel(swab32(foo), ...) when talking to a PCI device that
Roland> wants big-endian data. Without the raw variant, you end
Roland> up with a double swap on big-endian architectures.
Oh, I left one other thing out: writeq() and __raw_writeq() shold be
atomic in the sense that no other transactions should be able to get
onto the IO bus in the middle -- so implementing writeq() as two
writel()s in a row is not allowed
Andrew> OK. Can we please stop hacking around this in drivers and
Andrew> a) work out what it's supposed to do
Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
Andrew> or code comment or whatever)
Andrew> c) tell arch maintainers?
Yes, I agree that's a good plan, especially the documentation part.
However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
is legitimate: the driver uses __raw_writeq() when it exists and uses
two __raw_writel()s properly serialized with a device-specific lock to
get exactly the atomicity it needs on 32-bit archs.
It's an open question what drivers that don't actually need atomicity
but just want a convenient way to write 64 bits at time should do.
- R.
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 19:53 ` Roland Dreier
@ 2006-09-01 20:04 ` Andrew Morton
2006-09-01 20:20 ` Tom Tucker
` (2 more replies)
2006-09-01 20:45 ` [openib-general] " Bryan O'Sullivan
1 sibling, 3 replies; 138+ messages in thread
From: Andrew Morton @ 2006-09-01 20:04 UTC (permalink / raw)
To: Roland Dreier
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general, David S. Miller
On Fri, 01 Sep 2006 12:53:47 -0700
Roland Dreier <rdreier@cisco.com> wrote:
> Roland> My understanding is that __raw_writeq() is like writeq()
> Roland> except not strongly ordered and without the byte-swap on
> Roland> big-endian architectures. The __raw_writeX() variants are
> Roland> convenient to avoid having to write inefficient code like
> Roland> writel(swab32(foo), ...) when talking to a PCI device that
> Roland> wants big-endian data. Without the raw variant, you end
> Roland> up with a double swap on big-endian architectures.
>
> Oh, I left one other thing out: writeq() and __raw_writeq() shold be
> atomic in the sense that no other transactions should be able to get
> onto the IO bus in the middle -- so implementing writeq() as two
> writel()s in a row is not allowed
>
> Andrew> OK. Can we please stop hacking around this in drivers and
>
> Andrew> a) work out what it's supposed to do
>
> Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
> Andrew> or code comment or whatever)
>
> Andrew> c) tell arch maintainers?
>
> Yes, I agree that's a good plan, especially the documentation part.
> However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
> is legitimate: the driver uses __raw_writeq() when it exists and uses
> two __raw_writel()s properly serialized with a device-specific lock to
> get exactly the atomicity it needs on 32-bit archs.
No, driver-specific workarounds are not legitimate, sorry.
The driver should simply fail to compile on architectures which do not
implement __raw_writeq().
We can speed up the process by sending helpful emails to architecture
maintainers, but they'll notice either way.
Let's fix it once, and in the correct place.
> It's an open question what drivers that don't actually need atomicity
> but just want a convenient way to write 64 bits at time should do.
Well yeah. We should sort out the design issues before implementing
things ;)
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:04 ` Andrew Morton
@ 2006-09-01 20:20 ` Tom Tucker
2006-09-01 20:43 ` Russell King
2006-09-01 20:51 ` Roland Dreier
2 siblings, 0 replies; 138+ messages in thread
From: Tom Tucker @ 2006-09-01 20:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Roland Dreier, Adrian Bunk, Steve Wise, Roland Dreier,
linux-kernel, openib-general, David S. Miller
So to make sure I understand all this...
The purpose of these services is to provide a platform independent API
for reading and writing 16, 32 and 64b values to MMIO devices. The
rationale for needing these services is that there is currently no
platform independent API for efficiently reading and writing these
values to BE devices on MMIO PCI devices. Examples are the mthca and
amso1100 devices.
Two classes of service are needed, atomic services that are interrupt
safe and services that either don't require atomicity or are called with
a suitable lock already held.
Does the API look something like this?
void mmio_wr_be16(__be16 val, void __iomem *addr);
void mmio_wr_be32(__be32 val, void __iomem *addr);
void mmio_wr_be64(__be64 val, void __iomem *addr);
void mmio_atomic_wr_be16(__be16 val, void __iomem *addr);
void mmio_atomic_wr_be32(__be32 val, void __iomem *addr);
void mmio_atomic_wr_be64(__be64 val, void __iomem *addr);
__be16 mmio_rd_be16(void __iomem *addr);
__be32 mmio_rd_be32(void __iomem *addr);
__be64 mmio_rd_be64(void __iomem *addr);
__be16 mmio_atomic_wr_be16(void __iomem *addr);
__be32 mmio_atomic_wr_be32(void __iomem *addr);
__be64 mmio_atomic_wr_be64(void __iomem *addr);
On Fri, 2006-09-01 at 13:04 -0700, Andrew Morton wrote:
> On Fri, 01 Sep 2006 12:53:47 -0700
> Roland Dreier <rdreier@cisco.com> wrote:
>
> > Roland> My understanding is that __raw_writeq() is like writeq()
> > Roland> except not strongly ordered and without the byte-swap on
> > Roland> big-endian architectures. The __raw_writeX() variants are
> > Roland> convenient to avoid having to write inefficient code like
> > Roland> writel(swab32(foo), ...) when talking to a PCI device that
> > Roland> wants big-endian data. Without the raw variant, you end
> > Roland> up with a double swap on big-endian architectures.
> >
> > Oh, I left one other thing out: writeq() and __raw_writeq() shold be
> > atomic in the sense that no other transactions should be able to get
> > onto the IO bus in the middle -- so implementing writeq() as two
> > writel()s in a row is not allowed
> >
> > Andrew> OK. Can we please stop hacking around this in drivers and
> >
> > Andrew> a) work out what it's supposed to do
> >
> > Andrew> b) document that (Documentation/DocBook/deviceiobook.tmpl
> > Andrew> or code comment or whatever)
> >
> > Andrew> c) tell arch maintainers?
> >
> > Yes, I agree that's a good plan, especially the documentation part.
> > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
> > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > two __raw_writel()s properly serialized with a device-specific lock to
> > get exactly the atomicity it needs on 32-bit archs.
>
> No, driver-specific workarounds are not legitimate, sorry.
>
> The driver should simply fail to compile on architectures which do not
> implement __raw_writeq().
>
> We can speed up the process by sending helpful emails to architecture
> maintainers, but they'll notice either way.
>
> Let's fix it once, and in the correct place.
>
> > It's an open question what drivers that don't actually need atomicity
> > but just want a convenient way to write 64 bits at time should do.
>
> Well yeah. We should sort out the design issues before implementing
> things ;)
>
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:04 ` Andrew Morton
2006-09-01 20:20 ` Tom Tucker
@ 2006-09-01 20:43 ` Russell King
2006-09-01 20:54 ` Roland Dreier
2006-09-01 20:59 ` Andrew Morton
2006-09-01 20:51 ` Roland Dreier
2 siblings, 2 replies; 138+ messages in thread
From: Russell King @ 2006-09-01 20:43 UTC (permalink / raw)
To: Andrew Morton
Cc: Roland Dreier, Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier,
linux-kernel, openib-general, David S. Miller
On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> On Fri, 01 Sep 2006 12:53:47 -0700
> Roland Dreier <rdreier@cisco.com> wrote:
> > Yes, I agree that's a good plan, especially the documentation part.
> > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
> > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > two __raw_writel()s properly serialized with a device-specific lock to
> > get exactly the atomicity it needs on 32-bit archs.
>
> No, driver-specific workarounds are not legitimate, sorry.
>
> The driver should simply fail to compile on architectures which do not
> implement __raw_writeq().
So, what you're basically saying is that on architectures which can _NOT_
implement an atomic __raw_writeq(), certain drivers simply will not be
available?
> We can speed up the process by sending helpful emails to architecture
> maintainers, but they'll notice either way.
I think you're completely wrong in the context of the message you're
replying to - it's talking about an _atomic_ 64-bit write.
Sure, if you want a _non-atomic_ 64-bit write then that's possible,
but many 32-bit architectures can't do a 64-bit atomic IO write and
that isn't something they can "fix".
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
--
VGER BF report: H 5.55112e-17
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:43 ` Russell King
@ 2006-09-01 20:54 ` Roland Dreier
2006-09-01 21:01 ` [openib-general] " Bryan O'Sullivan
2006-09-01 20:59 ` Andrew Morton
1 sibling, 1 reply; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 20:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general, David S. Miller
Russell> Sure, if you want a _non-atomic_ 64-bit write then that's
Russell> possible, but many 32-bit architectures can't do a 64-bit
Russell> atomic IO write and that isn't something they can "fix".
I agree completely. And going one step further: if an architecture
cannot implement a 64-bit write atomically, then the precise
serialization that is required is device-specific knowledge that
belongs in the device driver.
(For example, in the mthca case, the only serialization required is
that no writes go to the same page of MMIO space between the two
32-bit halves of the 64-bit write)
- R.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:54 ` Roland Dreier
@ 2006-09-01 21:01 ` Bryan O'Sullivan
0 siblings, 0 replies; 138+ messages in thread
From: Bryan O'Sullivan @ 2006-09-01 21:01 UTC (permalink / raw)
To: Roland Dreier
Cc: Andrew Morton, linux-kernel, openib-general, Adrian Bunk,
David S. Miller
On Fri, 2006-09-01 at 13:54 -0700, Roland Dreier wrote:
> I agree completely. And going one step further: if an architecture
> cannot implement a 64-bit write atomically, then the precise
> serialization that is required is device-specific knowledge that
> belongs in the device driver.
Absolutely.
<b
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:43 ` Russell King
2006-09-01 20:54 ` Roland Dreier
@ 2006-09-01 20:59 ` Andrew Morton
2006-09-01 21:05 ` Roland Dreier
1 sibling, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-01 20:59 UTC (permalink / raw)
To: Russell King
Cc: Roland Dreier, Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier,
linux-kernel, openib-general, David S. Miller
On Fri, 1 Sep 2006 21:43:43 +0100
Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Fri, Sep 01, 2006 at 01:04:44PM -0700, Andrew Morton wrote:
> > On Fri, 01 Sep 2006 12:53:47 -0700
> > Roland Dreier <rdreier@cisco.com> wrote:
> > > Yes, I agree that's a good plan, especially the documentation part.
> > > However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
> > > is legitimate: the driver uses __raw_writeq() when it exists and uses
> > > two __raw_writel()s properly serialized with a device-specific lock to
> > > get exactly the atomicity it needs on 32-bit archs.
> >
> > No, driver-specific workarounds are not legitimate, sorry.
> >
> > The driver should simply fail to compile on architectures which do not
> > implement __raw_writeq().
>
> So, what you're basically saying is that on architectures which can _NOT_
> implement an atomic __raw_writeq(), certain drivers simply will not be
> available?
If the driver *requires* an atomic __raw_writeq(), then yes. The driver
cannot work correctly on that machine.
If, however, there is some way in which we can make the hardware work on
that machine (say, with other locking) then we got the __raw_writeq()
interface design (whatever that is) wrong.
IOW, the best way of tackling this is to work out what we're trying to do,
design an interface, then implement it.
Doing funny workarounds within individual drivers isn't the way to address
this. In fact it's an indication that something is wrong.
> > We can speed up the process by sending helpful emails to architecture
> > maintainers, but they'll notice either way.
>
> I think you're completely wrong in the context of the message you're
> replying to - it's talking about an _atomic_ 64-bit write.
>
> Sure, if you want a _non-atomic_ 64-bit write then that's possible,
> but many 32-bit architectures can't do a 64-bit atomic IO write and
> that isn't something they can "fix".
If the hardware/driver absolutely requires that the 64-bit write be atomic
on-the-bus then sure, the fix is to disable that driver on that
architecture in Kconfig.
If, however, the atomicity requirement is a software thing (we need to be
atomic against other CPU reads and writes) then that can be solved with
locking, and we can design APIs for this which can be implemented
efficiently on all architectures.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:59 ` Andrew Morton
@ 2006-09-01 21:05 ` Roland Dreier
2006-09-01 21:26 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 21:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Russell King, Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier,
linux-kernel, openib-general, David S. Miller
Andrew> If the hardware/driver absolutely requires that the 64-bit
Andrew> write be atomic on-the-bus then sure, the fix is to
Andrew> disable that driver on that architecture in Kconfig.
Andrew> If, however, the atomicity requirement is a software thing
Andrew> (we need to be atomic against other CPU reads and writes)
Andrew> then that can be solved with locking, and we can design
Andrew> APIs for this which can be implemented efficiently on all
Andrew> architectures.
It seems that there are cases of both. ipath needs actual 64-bit bus
transactions to work properly. mthca needs to make sure that if
doorbell writes are split into two 32-bit halves, then no other writes
go to the same MMIO page in between the halves.
What do you think the API would look like? Something along the lines
of mthca_doorbell.h, where we have macros for
DECLARE_WRITEQ_LOCK()
INIT_WRITEQ_LOCK()
GET_WRITEQ_LOCK()
which get stubbed out on architectures where writeq is already atomic,
and then pass the lock into writeq()?
But then you probably need some Kconfig symbol to say if writeq() is
really atomic or just software atomic (for ipath et al to depend on).
- R.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 21:05 ` Roland Dreier
@ 2006-09-01 21:26 ` Andrew Morton
2006-09-01 22:42 ` Roland Dreier
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-01 21:26 UTC (permalink / raw)
To: Roland Dreier
Cc: Russell King, Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier,
linux-kernel, openib-general, David S. Miller
On Fri, 01 Sep 2006 14:05:36 -0700
Roland Dreier <rdreier@cisco.com> wrote:
> Andrew> If the hardware/driver absolutely requires that the 64-bit
> Andrew> write be atomic on-the-bus then sure, the fix is to
> Andrew> disable that driver on that architecture in Kconfig.
>
> Andrew> If, however, the atomicity requirement is a software thing
> Andrew> (we need to be atomic against other CPU reads and writes)
> Andrew> then that can be solved with locking, and we can design
> Andrew> APIs for this which can be implemented efficiently on all
> Andrew> architectures.
>
> It seems that there are cases of both. ipath needs actual 64-bit bus
> transactions to work properly.
If we define __raw_writeq() to be 64-bit-atomic-on-the-bus then an
appropriate solution for ipath would be to call __raw_writeq() directly.
If the arch cannot implement __raw_write() then build error -> Kconfig fix.
> mthca needs to make sure that if
> doorbell writes are split into two 32-bit halves, then no other writes
> go to the same MMIO page in between the halves.
>
> What do you think the API would look like? Something along the lines
> of mthca_doorbell.h, where we have macros for
>
> DECLARE_WRITEQ_LOCK()
> INIT_WRITEQ_LOCK()
> GET_WRITEQ_LOCK()
>
> which get stubbed out on architectures where writeq is already atomic,
> and then pass the lock into writeq()?
>
> But then you probably need some Kconfig symbol to say if writeq() is
> really atomic or just software atomic (for ipath et al to depend on).
>
It depends on how many other devices have (or are expected to have)
mthca-like requirements. If the answer is "very few, maybe none" then
perhaps we don't need to go designing generic interfaces to support such
things.
As for interfaces, umm, something like
#ifdef CONFIG_ARCH_HAS_64BIT_ATOMIC_MMIO_WRITES
struct be64_port {
void __iomem *addr;
};
static inline void atomic_be64_mmio_write(u64 v, struct be64_port *port)
{
__raw_writeq(v, port->addr);
}
#define be64_port_init(port, addr)
port->addr = addr;
#define be64_port_init_external_locking(port, addr, lockp)
be64_port_init(port, addr)
#else
struct be64_port {
void __iomem *addr;
spinlock_t lock;
spinlock_t *lockp;
};
static inline void atomic_be64_mmio_write(u64 v, struct be64_port *port)
{
unsigned long flags;
spin_lock_irqsave(port->lockp, flags);
__raw_writel(...);
__raw_writel(...);
spin_unlock_irqrestore(port->lockp, flags);
}
#define be64_port_init(port, addr)
spin_lock_init(&port->lock);
port->lockp = &port->lock;
port->addr = addr;
#define be64_port_init_external_locking(port, addr, lockp)
port->lockp = lockp;
port->addr = addr;
#endif
perhaps?
btw, 32-bit mthca_write64() is downright scary from an endianness POV. I
guess it's right, but I wouldn't label it "obviously correct" ;)
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 21:26 ` Andrew Morton
@ 2006-09-01 22:42 ` Roland Dreier
0 siblings, 0 replies; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 22:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Russell King, Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier,
linux-kernel, openib-general, David S. Miller
Andrew> It depends on how many other devices have (or are expected
Andrew> to have) mthca-like requirements. If the answer is "very
Andrew> few, maybe none" then perhaps we don't need to go
Andrew> designing generic interfaces to support such things.
I actually don't know of any others -- not that I'm an expert on the
range of devices that exist...
What's your feeling about drivers like amso1100, which don't
particularly care about atomicity, but just want to write a 64-bit
quantity conveniently? Should we require writeq()/__raw_writeq() for
all archs, and then define CONFIG_ARCH_HAS_64BIT_ATOMIC_MMIO_WRITES as
appropriate?
I see stuff like this is drivers/dma/ioatdma.c:
#if (BITS_PER_LONG == 64)
ioatdma_chan_write64(ioat_chan, IOAT_CHAINADDR_OFFSET, desc->phys);
#else
ioatdma_chan_write32(ioat_chan,
IOAT_CHAINADDR_OFFSET_LOW,
(u32) desc->phys);
ioatdma_chan_write32(ioat_chan, IOAT_CHAINADDR_OFFSET_HIGH, 0);
#endif
and drivers/char/hpet.c:
#ifndef readq
static inline unsigned long long readq(void __iomem *addr)
{
return readl(addr) | (((unsigned long long)readl(addr + 4)) << 32LL);
}
#endif
#ifndef writeq
static inline void writeq(unsigned long long v, void __iomem *addr)
{
writel(v & 0xffffffff, addr);
writel(v >> 32, addr + 4);
}
#endif
and so on...
- R.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:04 ` Andrew Morton
2006-09-01 20:20 ` Tom Tucker
2006-09-01 20:43 ` Russell King
@ 2006-09-01 20:51 ` Roland Dreier
2006-09-01 21:03 ` Andrew Morton
2 siblings, 1 reply; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 20:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general, David S. Miller
Andrew> No, driver-specific workarounds are not legitimate, sorry.
Andrew> The driver should simply fail to compile on architectures
Andrew> which do not implement __raw_writeq().
But how should i386 (say) implement __raw_writeq()? As two
__raw_writel()s protected by a spinlock (that serializes all IO
transactions)? That seems rather ugly.
- R.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:51 ` Roland Dreier
@ 2006-09-01 21:03 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2006-09-01 21:03 UTC (permalink / raw)
To: Roland Dreier
Cc: Adrian Bunk, Tom Tucker, Steve Wise, Roland Dreier, linux-kernel,
openib-general, David S. Miller
On Fri, 01 Sep 2006 13:51:32 -0700
Roland Dreier <rdreier@cisco.com> wrote:
> Andrew> No, driver-specific workarounds are not legitimate, sorry.
>
> Andrew> The driver should simply fail to compile on architectures
> Andrew> which do not implement __raw_writeq().
>
> But how should i386 (say) implement __raw_writeq()? As two
> __raw_writel()s protected by a spinlock (that serializes all IO
> transactions)? That seems rather ugly.
>
If it's a choice between "ugly" and "doesn't work on x86", we'll take
"ugly" ;)
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 19:53 ` Roland Dreier
2006-09-01 20:04 ` Andrew Morton
@ 2006-09-01 20:45 ` Bryan O'Sullivan
2006-09-01 20:59 ` Roland Dreier
1 sibling, 1 reply; 138+ messages in thread
From: Bryan O'Sullivan @ 2006-09-01 20:45 UTC (permalink / raw)
To: Roland Dreier
Cc: Andrew Morton, linux-kernel, openib-general, Adrian Bunk,
David S. Miller
On Fri, 2006-09-01 at 12:53 -0700, Roland Dreier wrote:
> Yes, I agree that's a good plan, especially the documentation part.
> However I would argue that what's in drivers/infiniband/hw/mthca/mthca_doorbell.h
> is legitimate: the driver uses __raw_writeq() when it exists and uses
> two __raw_writel()s properly serialized with a device-specific lock to
> get exactly the atomicity it needs on 32-bit archs.
On the off chance that you might be arguing that mthca_write64 could be
a candidate drop-in for writeq on 32-bit arches:
That approach might work on mthca hardware, but it's not safe in
general. The ipath driver requires a proper writeq(), for example,
because the hardware will quite legitimately treat 32-bit writes to some
registers as separate accesses, and screw things up royally.
You get atomicity from the perspective of software with this approach,
but you can do exciting and bad things to hardware.
<b
--
VGER BF report: H 3.23386e-12
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:45 ` [openib-general] " Bryan O'Sullivan
@ 2006-09-01 20:59 ` Roland Dreier
2006-09-01 21:03 ` Bryan O'Sullivan
0 siblings, 1 reply; 138+ messages in thread
From: Roland Dreier @ 2006-09-01 20:59 UTC (permalink / raw)
To: Bryan O'Sullivan
Cc: Andrew Morton, linux-kernel, openib-general, Adrian Bunk,
David S. Miller
Roland> Yes, I agree that's a good plan, especially the
Roland> documentation part. However I would argue that what's in
Roland> drivers/infiniband/hw/mthca/mthca_doorbell.h is
Roland> legitimate: the driver uses __raw_writeq() when it exists
Roland> and uses two __raw_writel()s properly serialized with a
Roland> device-specific lock to get exactly the atomicity it needs
Roland> on 32-bit archs.
Bryan> On the off chance that you might be arguing that
Bryan> mthca_write64 could be a candidate drop-in for writeq on
Bryan> 32-bit arches:
No, quite the opposite. I'm arguing that the wrappers in mthca do
legitimately belong in a device driver, since they encapsulate
device-specific knowledge about what serialization suffices when an
atomic __raw_writeq() is not available.
Bryan> That approach might work on mthca hardware, but it's not
Bryan> safe in general. The ipath driver requires a proper
Bryan> writeq(), for example, because the hardware will quite
Bryan> legitimately treat 32-bit writes to some registers as
Bryan> separate accesses, and screw things up royally.
Yes, that's an unfortunate feature of the ipath hardware that
apparently makes it impossible to drive on a generic 32-bit architecture.
So perhaps writeq()/__raw_writeq() need to be defined to generate a
single bus cycle to the extent that makes sense. Which would mean
that it's not possible to implement on all architectures.
- R.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [openib-general] 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
2006-09-01 20:59 ` Roland Dreier
@ 2006-09-01 21:03 ` Bryan O'Sullivan
0 siblings, 0 replies; 138+ messages in thread
From: Bryan O'Sullivan @ 2006-09-01 21:03 UTC (permalink / raw)
To: Roland Dreier
Cc: Andrew Morton, linux-kernel, openib-general, Adrian Bunk,
David S. Miller
On Fri, 2006-09-01 at 13:59 -0700, Roland Dreier wrote:
> No, quite the opposite. I'm arguing that the wrappers in mthca do
> legitimately belong in a device driver, since they encapsulate
> device-specific knowledge about what serialization suffices when an
> atomic __raw_writeq() is not available.
Yes, I figured that out from some later messages. I think we're
violently in agreement, in that case.
<b
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-09-01 16:00 ` 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error Adrian Bunk
@ 2006-09-01 16:40 ` Maciej Rutecki
2006-09-05 16:16 ` 2.6.18-rc5-mm1 Bjorn Helgaas
2006-09-01 19:58 ` [-mm patch] fs/reiser4/: possible cleanups Adrian Bunk
` (26 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Maciej Rutecki @ 2006-09-01 16:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-acpi
[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>
ACPI error (similar like in 2.6.18-rc4-mm3):
[ 23.790140] ACPI Error (utglobal-0125): Unknown exception code:
0xFFFFFFEA [20060707]
[ 23.790318] [<c0221ba9>] acpi_format_exception+0x9f/0xa9
[ 23.790445] [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
[ 23.790554] [<c021b3ac>] acpi_walk_resources+0x103/0x10d
[ 23.790661] [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
[ 23.790774] [<c022900f>] acpi_motherboard_add+0x1f/0x2c
[ 23.790880] [<c0228154>] acpi_bus_driver_init+0x2c/0x78
[ 23.790987] [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
[ 23.791094] [<c038a8da>] acpi_motherboard_init+0xa/0xf5
[ 23.791205] [<c01002b0>] init+0x70/0x280
[ 23.791309] [<c0102db2>] ret_from_fork+0x6/0x14
[ 23.791420] [<c0100240>] init+0x0/0x280
[ 23.791520] [<c0100240>] init+0x0/0x280
[ 23.791621] [<c0103997>] kernel_thread_helper+0x7/0x10
[ 23.791728] =======================
[ 23.791844] ACPI Error (utglobal-0125): Unknown exception code:
0xFFFFFFEA [20060707]
[ 23.792004] [<c0221ba9>] acpi_format_exception+0x9f/0xa9
[ 23.792112] [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
[ 23.792218] [<c021b3ac>] acpi_walk_resources+0x103/0x10d
[ 23.792325] [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
[ 23.792432] [<c022900f>] acpi_motherboard_add+0x1f/0x2c
[ 23.792538] [<c0228154>] acpi_bus_driver_init+0x2c/0x78
[ 23.792644] [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
[ 23.792751] [<c038a8e4>] acpi_motherboard_init+0x14/0xf5
[ 23.792857] [<c01002b0>] init+0x70/0x280
[ 23.792959] [<c0102db2>] ret_from_fork+0x6/0x14
[ 23.793062] [<c0100240>] init+0x0/0x280
[ 23.793162] [<c0100240>] init+0x0/0x280
[ 23.793262] [<c0103997>] kernel_thread_helper+0x7/0x10
[ 23.793367] =======================
Also when I try:
echo standby > /sys/power/state,
I got this message on display:
Sep 1 18:03:02 maciek kernel: [ 189.192822] Stopping tasks:
==========================|
Sep 1 18:03:02 maciek kernel: [ 189.465008] Suspending console(s)
Sep 1 18:03:02 maciek kernel: [ 191.466946] Suspending device vcsa9
But display don't want go standby.
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
[-- Attachment #1.2: config-2.6.18-rc5-mm1.gz --]
[-- Type: application/x-gzip, Size: 14631 bytes --]
[-- Attachment #1.3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9641 bytes --]
[-- Attachment #1.4: lsmod_output.txt.gz --]
[-- Type: application/x-gzip, Size: 810 bytes --]
[-- Attachment #1.5: syslog.txt.gz --]
[-- Type: application/x-gzip, Size: 2546 bytes --]
[-- Attachment #1.6: ver_linux.txt.gz --]
[-- Type: application/x-gzip, Size: 650 bytes --]
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1
2006-09-01 16:40 ` 2.6.18-rc5-mm1 Maciej Rutecki
@ 2006-09-05 16:16 ` Bjorn Helgaas
2006-09-06 16:55 ` 2.6.18-rc5-mm1 Maciej Rutecki
0 siblings, 1 reply; 138+ messages in thread
From: Bjorn Helgaas @ 2006-09-05 16:16 UTC (permalink / raw)
To: Maciej Rutecki; +Cc: Andrew Morton, linux-kernel, linux-acpi
On Friday 01 September 2006 10:40, Maciej Rutecki wrote:
> ACPI error (similar like in 2.6.18-rc4-mm3):
>
> [ 23.790140] ACPI Error (utglobal-0125): Unknown exception code:
> 0xFFFFFFEA [20060707]
> [ 23.790318] [<c0221ba9>] acpi_format_exception+0x9f/0xa9
> [ 23.790445] [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
> [ 23.790554] [<c021b3ac>] acpi_walk_resources+0x103/0x10d
> [ 23.790661] [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
> [ 23.790774] [<c022900f>] acpi_motherboard_add+0x1f/0x2c
> [ 23.790880] [<c0228154>] acpi_bus_driver_init+0x2c/0x78
> [ 23.790987] [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
> [ 23.791094] [<c038a8da>] acpi_motherboard_init+0xa/0xf5
> [ 23.791205] [<c01002b0>] init+0x70/0x280
> [ 23.791309] [<c0102db2>] ret_from_fork+0x6/0x14
> [ 23.791420] [<c0100240>] init+0x0/0x280
> [ 23.791520] [<c0100240>] init+0x0/0x280
> [ 23.791621] [<c0103997>] kernel_thread_helper+0x7/0x10
This ACPI "unknown exception code" problem is the same one reported here:
http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
Basically, we just need to revert this:
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
The above patch happened to fix a hot-add memory problem, but it was
the wrong fix, and we're working out a better one.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-05 16:16 ` 2.6.18-rc5-mm1 Bjorn Helgaas
@ 2006-09-06 16:55 ` Maciej Rutecki
2006-09-07 3:08 ` 2.6.18-rc5-mm1 Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Maciej Rutecki @ 2006-09-06 16:55 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Andrew Morton, linux-kernel, linux-acpi
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
Bjorn Helgaas napisał(a):
>
> This ACPI "unknown exception code" problem is the same one reported here:
> http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
>
> Basically, we just need to revert this:
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
>
Thanks it works.
--
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-06 16:55 ` 2.6.18-rc5-mm1 Maciej Rutecki
@ 2006-09-07 3:08 ` Andrew Morton
2006-09-07 17:33 ` 2.6.18-rc5-mm1 keith mannthey
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-07 3:08 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Bjorn Helgaas, linux-kernel, linux-acpi, Keith Mannthey,
KAMEZAWA Hiroyuki
On Wed, 06 Sep 2006 18:55:11 +0200
Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> Bjorn Helgaas napisał(a):
> >
> > This ACPI "unknown exception code" problem is the same one reported here:
> > http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> >
> > Basically, we just need to revert this:
> > http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> >
> Thanks it works.
>
So... should I drop that patch?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-07 3:08 ` 2.6.18-rc5-mm1 Andrew Morton
@ 2006-09-07 17:33 ` keith mannthey
0 siblings, 0 replies; 138+ messages in thread
From: keith mannthey @ 2006-09-07 17:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Maciej Rutecki, Bjorn Helgaas, lkml, linux acpi,
KAMEZAWA Hiroyuki
On Wed, 2006-09-06 at 20:08 -0700, Andrew Morton wrote:
> On Wed, 06 Sep 2006 18:55:11 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
>
> > Bjorn Helgaas napisał(a):
> > >
> > > This ACPI "unknown exception code" problem is the same one reported here:
> > > http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > >
> > > Basically, we just need to revert this:
> > > http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > >
> > Thanks it works.
> >
>
> So... should I drop that patch?
Yes please drop this patch.
I dislike breaking my boxes functionality without a consensus for the
right fix is but it appears to be breaking others. The discussion about
what the right fix is ongoing with no definitive direction. At a minimum
this patch will need to be updated.
Thanks,
Keith
^ permalink raw reply [flat|nested] 138+ messages in thread
* [-mm patch] fs/reiser4/: possible cleanups
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-09-01 16:40 ` 2.6.18-rc5-mm1 Maciej Rutecki
@ 2006-09-01 19:58 ` Adrian Bunk
2006-09-01 23:13 ` 2.6.18-rc5-mm1 (IDE resume regression) Rafael J. Wysocki
` (25 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-01 19:58 UTC (permalink / raw)
To: Andrew Morton, reiserfs-dev; +Cc: linux-kernel
This patch contains the following possible cleanups:
- make the following needlessly global function static:
- plugin/file/file.c: hint_validate()
- #if 0 the following unused global function:
- jnode.c: page_detach_jnode()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/reiser4/jnode.c | 2 ++
fs/reiser4/jnode.h | 3 ---
fs/reiser4/plugin/file/file.c | 4 +++-
fs/reiser4/plugin/file/file.h | 2 --
4 files changed, 5 insertions(+), 6 deletions(-)
--- linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.h.old 2006-09-01 20:54:04.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.h 2006-09-01 20:54:09.000000000 +0200
@@ -157,8 +157,6 @@
void reiser4_set_hint(hint_t *, const reiser4_key *, znode_lock_mode);
int hint_is_set(const hint_t *);
void reiser4_unset_hint(hint_t *);
-int hint_validate(hint_t *, const reiser4_key *, int check_key,
- znode_lock_mode);
void hint_init_zero(hint_t *);
int reiser4_update_file_size(struct inode *, reiser4_key *, int update_sd);
--- linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.c.old 2006-09-01 20:54:17.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/plugin/file/file.c 2006-09-01 20:55:08.000000000 +0200
@@ -26,6 +26,8 @@
static int unpack(struct file *file, struct inode *inode, int forever);
static void drop_access(unix_file_info_t *);
+static int hint_validate(hint_t * hint, const reiser4_key * key, int check_key,
+ znode_lock_mode lock_mode);
/* get unix file plugin specific portion of inode */
unix_file_info_t *unix_file_inode_data(const struct inode *inode)
@@ -747,7 +749,7 @@
}
#endif
-int
+static int
hint_validate(hint_t * hint, const reiser4_key * key, int check_key,
znode_lock_mode lock_mode)
{
--- linux-2.6.18-rc5-mm1/fs/reiser4/jnode.h.old 2006-09-01 20:55:19.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/jnode.h 2006-09-01 20:55:27.000000000 +0200
@@ -486,9 +486,6 @@
return atomic_read(&node->d_count) > 0;
}
-extern void page_detach_jnode(struct page *page,
- struct address_space *mapping,
- unsigned long index) NONNULL;
extern void page_clear_jnode(struct page *page, jnode * node) NONNULL;
static inline void jnode_set_reloc(jnode * node)
--- linux-2.6.18-rc5-mm1/fs/reiser4/jnode.c.old 2006-09-01 20:55:33.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/reiser4/jnode.c 2006-09-01 20:55:47.000000000 +0200
@@ -697,6 +697,7 @@
page_cache_release(page);
}
+#if 0
/* it is only used in one place to handle error */
void
page_detach_jnode(struct page *page, struct address_space *mapping,
@@ -716,6 +717,7 @@
}
unlock_page(page);
}
+#endif /* 0 */
/* return @node page locked.
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1 (IDE resume regression)
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (4 preceding siblings ...)
2006-09-01 19:58 ` [-mm patch] fs/reiser4/: possible cleanups Adrian Bunk
@ 2006-09-01 23:13 ` Rafael J. Wysocki
2006-09-02 0:08 ` Andrew Morton
2006-09-02 1:00 ` 2.6.18-rc5-mm1 Matthias Hentges
` (24 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Rafael J. Wysocki @ 2006-09-01 23:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Jens Axboe
On Friday 01 September 2006 10:58, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>
>
> - CONFIG_BLOCK=n is bust due to
> writeback_congestion_end()/blk_congestion_end() snafu. We'll fix it later.
I need the appended patch to prevent my box from crashing during suspend to
disk (in the resume-during-suspend phase).
Apparently, the pointer returned by to_ide_driver() in generic_ide_resume()
is completely bogous, although it's nonzero, and a NULL pointer dereference
occurs when drv->resume is evaluated (100% of the time on my box).
---
drivers/ide/ide.c | 9 +--------
1 files changed, 1 insertion(+), 8 deletions(-)
Index: linux-2.6.18-rc5-mm1/drivers/ide/ide.c
===================================================================
--- linux-2.6.18-rc5-mm1.orig/drivers/ide/ide.c
+++ linux-2.6.18-rc5-mm1/drivers/ide/ide.c
@@ -1235,11 +1235,9 @@ static int generic_ide_suspend(struct de
static int generic_ide_resume(struct device *dev)
{
ide_drive_t *drive = dev->driver_data;
- ide_driver_t *drv = to_ide_driver(dev->driver);
struct request rq;
struct request_pm_state rqpm;
ide_task_t args;
- int err;
memset(&rq, 0, sizeof(rq));
memset(&rqpm, 0, sizeof(rqpm));
@@ -1250,12 +1248,7 @@ static int generic_ide_resume(struct dev
rqpm.pm_step = ide_pm_state_start_resume;
rqpm.pm_state = PM_EVENT_ON;
- err = ide_do_drive_cmd(drive, &rq, ide_head_wait);
-
- if (err == 0 && drv->resume)
- drv->resume(drive);
-
- return err;
+ return ide_do_drive_cmd(drive, &rq, ide_head_wait);
}
int generic_ide_ioctl(ide_drive_t *drive, struct file *file, struct block_device *bdev,
--
VGER BF report: H 0.0771048
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1 (IDE resume regression)
2006-09-01 23:13 ` 2.6.18-rc5-mm1 (IDE resume regression) Rafael J. Wysocki
@ 2006-09-02 0:08 ` Andrew Morton
0 siblings, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2006-09-02 0:08 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, Jens Axboe, Lee Trager, Alan Cox
On Sat, 2 Sep 2006 01:13:23 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Friday 01 September 2006 10:58, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> >
> >
> > - CONFIG_BLOCK=n is bust due to
> > writeback_congestion_end()/blk_congestion_end() snafu. We'll fix it later.
>
> I need the appended patch to prevent my box from crashing during suspend to
> disk (in the resume-during-suspend phase).
>
> Apparently, the pointer returned by to_ide_driver() in generic_ide_resume()
> is completely bogous, although it's nonzero, and a NULL pointer dereference
> occurs when drv->resume is evaluated (100% of the time on my box).
>
OK, thanks. That's ide-hpa-resume-fix.patch
> Index: linux-2.6.18-rc5-mm1/drivers/ide/ide.c
> ===================================================================
> --- linux-2.6.18-rc5-mm1.orig/drivers/ide/ide.c
> +++ linux-2.6.18-rc5-mm1/drivers/ide/ide.c
> @@ -1235,11 +1235,9 @@ static int generic_ide_suspend(struct de
> static int generic_ide_resume(struct device *dev)
> {
> ide_drive_t *drive = dev->driver_data;
> - ide_driver_t *drv = to_ide_driver(dev->driver);
> struct request rq;
> struct request_pm_state rqpm;
> ide_task_t args;
> - int err;
>
> memset(&rq, 0, sizeof(rq));
> memset(&rqpm, 0, sizeof(rqpm));
> @@ -1250,12 +1248,7 @@ static int generic_ide_resume(struct dev
> rqpm.pm_step = ide_pm_state_start_resume;
> rqpm.pm_state = PM_EVENT_ON;
>
> - err = ide_do_drive_cmd(drive, &rq, ide_head_wait);
> -
> - if (err == 0 && drv->resume)
> - drv->resume(drive);
> -
> - return err;
> + return ide_do_drive_cmd(drive, &rq, ide_head_wait);
> }
>
> int generic_ide_ioctl(ide_drive_t *drive, struct file *file, struct block_device *bdev,
And the above reverts most of it. It looks like we'll need to
have another go at that one. I'll drop it.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (5 preceding siblings ...)
2006-09-01 23:13 ` 2.6.18-rc5-mm1 (IDE resume regression) Rafael J. Wysocki
@ 2006-09-02 1:00 ` Matthias Hentges
2006-09-02 1:30 ` 2.6.18-rc5-mm1 Andrew Morton
2006-09-02 1:06 ` 2.6.18-rc5-mm1 Grant Coady
` (23 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Matthias Hentges @ 2006-09-02 1:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1969 bytes --]
Hi,
2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
attached.
This did not happen in 2.6.18-rc4-mm3.
BUG: unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000 [#1]
4K_STACKS SMP
last sysfs file:
Modules linked in:
CPU: 0
EIP: 0060:[<00000000>] Not tainted VLI
EFLAGS: 00010087 (2.6.18-rc5-mm1 #1)
EIP is at rest_init+0x3feffd78/0x20
eax: 000000da ebx: c04d5f78 ecx: c04d5f94 edx: c04d2f00
esi: 000000da edi: 00000000 ebp: c04d2f00 esp: c0516ffc
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
Stack: c0105027
Call Trace:
[<c0105027>] do_IRQ+0x8a/0xac
[<c01035a6>] common_interrupt+0x1a/0x20
[<c0101a72>] mwait_idle_with_hints+0x36/0x3b
[<c0101a83>] mwait_idle+0xc/0x1b
[<c0101a26>] cpu_idle+0x5e/0x74
[<c04db6fa>] start_kernel+0x363/0x36a
=======================
Code: Bad EIP value.
EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
<0>Kernel panic - not syncing: Fatal exception in interrupt
BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
[<c010ca45>] smp_call_function+0x54/0xff
[<c011a270>] printk+0x12/0x16
[<c010cb03>] smp_send_stop+0x13/0x1c
[<c0119480>] panic+0x49/0xd3
[<c010410c>] die+0x273/0x28a
[<c01126d4>] do_page_fault+0x40d/0x4db
[<c01122c7>] do_page_fault+0x0/0x4db
[<c03d1231>] error_code+0x39/0x40
[<c013007b>] free_module+0x89/0xc3
[<c0105027>] do_IRQ+0x8a/0xac
[<c01035a6>] common_interrupt+0x1a/0x20
[<c0101a72>] mwait_idle_with_hints+0x36/0x3b
[<c0101a83>] mwait_idle+0xc/0x1b
[<c0101a26>] cpu_idle+0x5e/0x74
[<c04db6fa>] start_kernel+0x363/0x36a
=======================
--
Matthias 'CoreDump' Hentges
Webmaster of hentges.net and OpenZaurus developer.
You can reach me in #openzaurus on Freenode.
My OS: Debian SID. Geek by Nature, Linux by Choice
[-- Attachment #1.2: dmesg.txt.gz --]
[-- Type: application/x-gzip, Size: 5023 bytes --]
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1
2006-09-02 1:00 ` 2.6.18-rc5-mm1 Matthias Hentges
@ 2006-09-02 1:30 ` Andrew Morton
[not found] ` <44F93EB3.8050500@goop.org>
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-02 1:30 UTC (permalink / raw)
To: Matthias Hentges; +Cc: linux-kernel, linux-acpi, Venkatesh Pallipadi
On Sat, 02 Sep 2006 03:00:47 +0200
Matthias Hentges <oe@hentges.net> wrote:
> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
> attached.
> This did not happen in 2.6.18-rc4-mm3.
>
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000 [#1]
> 4K_STACKS SMP
> last sysfs file:
> Modules linked in:
> CPU: 0
> EIP: 0060:[<00000000>] Not tainted VLI
> EFLAGS: 00010087 (2.6.18-rc5-mm1 #1)
> EIP is at rest_init+0x3feffd78/0x20
> eax: 000000da ebx: c04d5f78 ecx: c04d5f94 edx: c04d2f00
> esi: 000000da edi: 00000000 ebp: c04d2f00 esp: c0516ffc
> ds: 007b es: 007b ss: 0068
> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
> Stack: c0105027
> Call Trace:
> [<c0105027>] do_IRQ+0x8a/0xac
> [<c01035a6>] common_interrupt+0x1a/0x20
> [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> [<c0101a83>] mwait_idle+0xc/0x1b
> [<c0101a26>] cpu_idle+0x5e/0x74
> [<c04db6fa>] start_kernel+0x363/0x36a
> =======================
> Code: Bad EIP value.
> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
> <0>Kernel panic - not syncing: Fatal exception in interrupt
> BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
> [<c010ca45>] smp_call_function+0x54/0xff
> [<c011a270>] printk+0x12/0x16
> [<c010cb03>] smp_send_stop+0x13/0x1c
> [<c0119480>] panic+0x49/0xd3
> [<c010410c>] die+0x273/0x28a
> [<c01126d4>] do_page_fault+0x40d/0x4db
> [<c01122c7>] do_page_fault+0x0/0x4db
> [<c03d1231>] error_code+0x39/0x40
> [<c013007b>] free_module+0x89/0xc3
> [<c0105027>] do_IRQ+0x8a/0xac
> [<c01035a6>] common_interrupt+0x1a/0x20
> [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> [<c0101a83>] mwait_idle+0xc/0x1b
> [<c0101a26>] cpu_idle+0x5e/0x74
> [<c04db6fa>] start_kernel+0x363/0x36a
> =======================
OK, thanks. That'll be acpi-mwait-c-state-fixes.patch. I've uploaded the
below revert patch to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
diff -puN arch/i386/kernel/acpi/cstate.c~revert-acpi-mwait-c-state-fixes arch/i386/kernel/acpi/cstate.c
--- a/arch/i386/kernel/acpi/cstate.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/i386/kernel/acpi/cstate.c
@@ -10,7 +10,6 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/acpi.h>
-#include <linux/cpu.h>
#include <acpi/processor.h>
#include <asm/acpi.h>
@@ -42,124 +41,5 @@ void acpi_processor_power_init_bm_check(
flags->bm_check = 1;
}
}
-EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
-
-/* The code below handles cstate entry with monitor-mwait pair on Intel*/
-
-struct cstate_entry_s {
- struct {
- unsigned int eax;
- unsigned int ecx;
- } states[ACPI_PROCESSOR_MAX_POWER];
-};
-static struct cstate_entry_s *cpu_cstate_entry; /* per CPU ptr */
-
-static short mwait_supported[ACPI_PROCESSOR_MAX_POWER];
-
-#define MWAIT_SUBSTATE_MASK (0xf)
-#define MWAIT_SUBSTATE_SIZE (4)
-
-#define CPUID_MWAIT_LEAF (5)
-#define CPUID5_ECX_EXTENSIONS_SUPPORTED (0x1)
-#define CPUID5_ECX_INTERRUPT_BREAK (0x2)
-
-#define MWAIT_ECX_INTERRUPT_BREAK (0x1)
-
-#define NATIVE_CSTATE_BEYOND_HALT (2)
-
-int acpi_processor_ffh_cstate_probe(unsigned int cpu,
- struct acpi_processor_cx *cx, struct acpi_power_register *reg)
-{
- struct cstate_entry_s *percpu_entry;
- struct cpuinfo_x86 *c = cpu_data + cpu;
-
- cpumask_t saved_mask;
- int retval;
- unsigned int eax, ebx, ecx, edx;
- unsigned int edx_part;
- unsigned int cstate_type; /* C-state type and not ACPI C-state type */
- unsigned int num_cstate_subtype;
-
- if (!cpu_cstate_entry || c->cpuid_level < CPUID_MWAIT_LEAF )
- return -1;
-
- if (reg->bit_offset != NATIVE_CSTATE_BEYOND_HALT)
- return -1;
-
- percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
- percpu_entry->states[cx->index].eax = 0;
- percpu_entry->states[cx->index].ecx = 0;
-
- /* Make sure we are running on right CPU */
- saved_mask = current->cpus_allowed;
- retval = set_cpus_allowed(current, cpumask_of_cpu(cpu));
- if (retval)
- return -1;
-
- cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx);
-
- /* Check whether this particular cx_type (in CST) is supported or not */
- cstate_type = (cx->address >> MWAIT_SUBSTATE_SIZE) + 1;
- edx_part = edx >> (cstate_type * MWAIT_SUBSTATE_SIZE);
- num_cstate_subtype = edx_part & MWAIT_SUBSTATE_MASK;
-
- retval = 0;
- if (num_cstate_subtype < (cx->address & MWAIT_SUBSTATE_MASK)) {
- retval = -1;
- goto out;
- }
- /* mwait ecx extensions INTERRUPT_BREAK should be supported for C2/C3 */
- if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
- !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) {
- retval = -1;
- goto out;
- }
- percpu_entry->states[cx->index].ecx = MWAIT_ECX_INTERRUPT_BREAK;
-
- /* Use the hint in CST */
- percpu_entry->states[cx->index].eax = cx->address;
-
- if (!mwait_supported[cstate_type]) {
- mwait_supported[cstate_type] = 1;
- printk(KERN_DEBUG "Monitor-Mwait will be used to enter C-%d "
- "state\n", cx->type);
- }
-
-out:
- set_cpus_allowed(current, saved_mask);
- return retval;
-}
-EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_probe);
-
-void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)
-{
- unsigned int cpu = smp_processor_id();
- struct cstate_entry_s *percpu_entry;
-
- percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
- mwait_idle_with_hints(percpu_entry->states[cx->index].eax,
- percpu_entry->states[cx->index].ecx);
-}
-EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_enter);
-
-static int __init ffh_cstate_init(void)
-{
- struct cpuinfo_x86 *c = &boot_cpu_data;
- if (c->x86_vendor != X86_VENDOR_INTEL)
- return -1;
-
- cpu_cstate_entry = alloc_percpu(struct cstate_entry_s);
- return 0;
-}
-
-static void __exit ffh_cstate_exit(void)
-{
- if (cpu_cstate_entry) {
- free_percpu(cpu_cstate_entry);
- cpu_cstate_entry = NULL;
- }
-}
-
-arch_initcall(ffh_cstate_init);
-__exitcall(ffh_cstate_exit);
+EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
diff -puN arch/i386/kernel/process.c~revert-acpi-mwait-c-state-fixes arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/i386/kernel/process.c
@@ -236,28 +236,20 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
* We execute MONITOR against need_resched and enter optimized wait state
* through MWAIT. Whenever someone changes need_resched, we would be woken
* up from MWAIT (without an IPI).
- *
- * New with Core Duo processors, MWAIT can take some hints based on CPU
- * capability.
*/
-void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+static void mwait_idle(void)
{
- if (!need_resched()) {
+ local_irq_enable();
+
+ while (!need_resched()) {
__monitor((void *)¤t_thread_info()->flags, 0, 0);
smp_mb();
- if (!need_resched())
- __mwait(eax, ecx);
+ if (need_resched())
+ break;
+ __mwait(0, 0);
}
}
-/* Default MONITOR/MWAIT with no hints, used for default C1 state */
-static void mwait_idle(void)
-{
- local_irq_enable();
- while (!need_resched())
- mwait_idle_with_hints(0, 0);
-}
-
void __devinit select_idle_routine(const struct cpuinfo_x86 *c)
{
if (cpu_has(c, X86_FEATURE_MWAIT)) {
diff -puN arch/x86_64/kernel/process.c~revert-acpi-mwait-c-state-fixes arch/x86_64/kernel/process.c
--- a/arch/x86_64/kernel/process.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/x86_64/kernel/process.c
@@ -235,28 +235,20 @@ void cpu_idle (void)
* We execute MONITOR against need_resched and enter optimized wait state
* through MWAIT. Whenever someone changes need_resched, we would be woken
* up from MWAIT (without an IPI).
- *
- * New with Core Duo processors, MWAIT can take some hints based on CPU
- * capability.
*/
-void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+static void mwait_idle(void)
{
- if (!need_resched()) {
+ local_irq_enable();
+
+ while (!need_resched()) {
__monitor((void *)¤t_thread_info()->flags, 0, 0);
smp_mb();
- if (!need_resched())
- __mwait(eax, ecx);
+ if (need_resched())
+ break;
+ __mwait(0, 0);
}
}
-/* Default MONITOR/MWAIT with no hints, used for default C1 state */
-static void mwait_idle(void)
-{
- local_irq_enable();
- while (!need_resched())
- mwait_idle_with_hints(0,0);
-}
-
void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
{
static int printed;
diff -puN drivers/acpi/processor_idle.c~revert-acpi-mwait-c-state-fixes drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~revert-acpi-mwait-c-state-fixes
+++ a/drivers/acpi/processor_idle.c
@@ -219,23 +219,6 @@ static void acpi_safe_halt(void)
static atomic_t c3_cpu_count;
-/* Common C-state entry for C2, C3, .. */
-static void acpi_cstate_enter(struct acpi_processor_cx *cstate)
-{
- if (cstate->space_id == ACPI_CSTATE_FFH) {
- /* Call into architectural FFH based C-state */
- acpi_processor_ffh_cstate_enter(cstate);
- } else {
- int unused;
- /* IO port based C-state */
- inb(cstate->address);
- /* Dummy wait op - must do something useless after P_LVL2 read
- because chipsets cannot guarantee that STPCLK# signal
- gets asserted in time to freeze execution properly. */
- unused = inl(acpi_fadt.xpm_tmr_blk.address);
- }
-}
-
static void acpi_processor_idle(void)
{
struct acpi_processor *pr = NULL;
@@ -378,7 +361,11 @@ static void acpi_processor_idle(void)
/* Get start time (ticks) */
t1 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Invoke C2 */
- acpi_cstate_enter(cx);
+ inb(cx->address);
+ /* Dummy wait op - must do something useless after P_LVL2 read
+ because chipsets cannot guarantee that STPCLK# signal
+ gets asserted in time to freeze execution properly. */
+ t2 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Get end time (ticks) */
t2 = inl(acpi_fadt.xpm_tmr_blk.address);
@@ -414,7 +401,9 @@ static void acpi_processor_idle(void)
/* Get start time (ticks) */
t1 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Invoke C3 */
- acpi_cstate_enter(cx);
+ inb(cx->address);
+ /* Dummy wait op (see above) */
+ t2 = inl(acpi_fadt.xpm_tmr_blk.address);
/* Get end time (ticks) */
t2 = inl(acpi_fadt.xpm_tmr_blk.address);
if (pr->flags.bm_check) {
@@ -639,16 +628,20 @@ static int acpi_processor_get_power_info
return 0;
}
-static int acpi_processor_get_power_info_default(struct acpi_processor *pr)
+static int acpi_processor_get_power_info_default_c1(struct acpi_processor *pr)
{
- if (!pr->power.states[ACPI_STATE_C1].valid) {
- /* set the first C-State to C1 */
- /* all processors need to support C1 */
- pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
- pr->power.states[ACPI_STATE_C1].valid = 1;
- }
- /* the C0 state only exists as a filler in our array */
+
+ /* Zero initialize all the C-states info. */
+ memset(pr->power.states, 0, sizeof(pr->power.states));
+
+ /* set the first C-State to C1 */
+ pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
+
+ /* the C0 state only exists as a filler in our array,
+ * and all processors need to support C1 */
pr->power.states[ACPI_STATE_C0].valid = 1;
+ pr->power.states[ACPI_STATE_C1].valid = 1;
+
return 0;
}
@@ -665,7 +658,12 @@ static int acpi_processor_get_power_info
if (nocst)
return -ENODEV;
- current_count = 0;
+ current_count = 1;
+
+ /* Zero initialize C2 onwards and prepare for fresh CST lookup */
+ for (i = 2; i < ACPI_PROCESSOR_MAX_POWER; i++)
+ memset(&(pr->power.states[i]), 0,
+ sizeof(struct acpi_processor_cx));
status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);
if (ACPI_FAILURE(status)) {
@@ -720,39 +718,22 @@ static int acpi_processor_get_power_info
(reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE))
continue;
+ cx.address = (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) ?
+ 0 : reg->address;
+
/* There should be an easy way to extract an integer... */
obj = (union acpi_object *)&(element->package.elements[1]);
if (obj->type != ACPI_TYPE_INTEGER)
continue;
cx.type = obj->integer.value;
- /*
- * Some buggy BIOSes won't list C1 in _CST -
- * Let acpi_processor_get_power_info_default() handle them later
- */
- if (i == 1 && cx.type != ACPI_STATE_C1)
- current_count++;
- cx.address = reg->address;
- cx.index = current_count + 1;
+ if ((cx.type != ACPI_STATE_C1) &&
+ (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO))
+ continue;
- cx.space_id = ACPI_CSTATE_SYSTEMIO;
- if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
- if (acpi_processor_ffh_cstate_probe
- (pr->id, &cx, reg) == 0) {
- cx.space_id = ACPI_CSTATE_FFH;
- } else if (cx.type != ACPI_STATE_C1) {
- /*
- * C1 is a special case where FIXED_HARDWARE
- * can be handled in non-MWAIT way as well.
- * In that case, save this _CST entry info.
- * That is, we retain space_id of SYSTEM_IO for
- * halt based C1.
- * Otherwise, ignore this info and continue.
- */
- continue;
- }
- }
+ if ((cx.type < ACPI_STATE_C2) || (cx.type > ACPI_STATE_C3))
+ continue;
obj = (union acpi_object *)&(element->package.elements[2]);
if (obj->type != ACPI_TYPE_INTEGER)
@@ -957,18 +938,12 @@ static int acpi_processor_get_power_info
/* NOTE: the idle thread may not be running while calling
* this function */
- /* Zero initialize all the C-states info. */
- memset(pr->power.states, 0, sizeof(pr->power.states));
-
+ /* Adding C1 state */
+ acpi_processor_get_power_info_default_c1(pr);
result = acpi_processor_get_power_info_cst(pr);
if (result == -ENODEV)
acpi_processor_get_power_info_fadt(pr);
- if (result)
- return result;
-
- acpi_processor_get_power_info_default(pr);
-
pr->power.count = acpi_processor_power_verify(pr);
/*
diff -puN include/acpi/pdc_intel.h~revert-acpi-mwait-c-state-fixes include/acpi/pdc_intel.h
--- a/include/acpi/pdc_intel.h~revert-acpi-mwait-c-state-fixes
+++ a/include/acpi/pdc_intel.h
@@ -13,7 +13,6 @@
#define ACPI_PDC_SMP_C_SWCOORD (0x0040)
#define ACPI_PDC_SMP_T_SWCOORD (0x0080)
#define ACPI_PDC_C_C1_FFH (0x0100)
-#define ACPI_PDC_C_C2C3_FFH (0x0200)
#define ACPI_PDC_EST_CAPABILITY_SMP (ACPI_PDC_SMP_C1PT | \
ACPI_PDC_C_C1_HALT | \
@@ -24,10 +23,8 @@
ACPI_PDC_SMP_P_SWCOORD | \
ACPI_PDC_P_FFH)
-#define ACPI_PDC_C_CAPABILITY_SMP (ACPI_PDC_SMP_C2C3 | \
- ACPI_PDC_SMP_C1PT | \
- ACPI_PDC_C_C1_HALT | \
- ACPI_PDC_C_C1_FFH | \
- ACPI_PDC_C_C2C3_FFH)
+#define ACPI_PDC_C_CAPABILITY_SMP (ACPI_PDC_SMP_C2C3 | \
+ ACPI_PDC_SMP_C1PT | \
+ ACPI_PDC_C_C1_HALT)
#endif /* __PDC_INTEL_H__ */
diff -puN include/acpi/processor.h~revert-acpi-mwait-c-state-fixes include/acpi/processor.h
--- a/include/acpi/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/acpi/processor.h
@@ -29,9 +29,6 @@
#define DOMAIN_COORD_TYPE_SW_ANY 0xfd
#define DOMAIN_COORD_TYPE_HW_ALL 0xfe
-#define ACPI_CSTATE_SYSTEMIO (0)
-#define ACPI_CSTATE_FFH (1)
-
/* Power Management */
struct acpi_processor_cx;
@@ -61,8 +58,6 @@ struct acpi_processor_cx {
u8 valid;
u8 type;
u32 address;
- u8 space_id;
- u8 index;
u32 latency;
u32 latency_ticks;
u32 power;
@@ -211,9 +206,6 @@ void arch_acpi_processor_init_pdc(struct
#ifdef ARCH_HAS_POWER_INIT
void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
unsigned int cpu);
-int acpi_processor_ffh_cstate_probe(unsigned int cpu,
- struct acpi_processor_cx *cx, struct acpi_power_register *reg);
-void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cstate);
#else
static inline void acpi_processor_power_init_bm_check(struct
acpi_processor_flags
@@ -222,16 +214,6 @@ static inline void acpi_processor_power_
flags->bm_check = 1;
return;
}
-static inline int acpi_processor_ffh_cstate_probe(unsigned int cpu,
- struct acpi_processor_cx *cx, struct acpi_power_register *reg)
-{
- return -1;
-}
-static inline void acpi_processor_ffh_cstate_enter(
- struct acpi_processor_cx *cstate)
-{
- return;
-}
#endif
/* in processor_perflib.c */
diff -puN include/asm-i386/processor.h~revert-acpi-mwait-c-state-fixes include/asm-i386/processor.h
--- a/include/asm-i386/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/asm-i386/processor.h
@@ -306,8 +306,6 @@ static inline void __mwait(unsigned long
: :"a" (eax), "c" (ecx));
}
-extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
-
/* from system description table in BIOS. Mostly for MCA use, but
others may find it useful. */
extern unsigned int machine_id;
diff -puN include/asm-x86_64/processor.h~revert-acpi-mwait-c-state-fixes include/asm-x86_64/processor.h
--- a/include/asm-x86_64/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/asm-x86_64/processor.h
@@ -475,8 +475,6 @@ static inline void __mwait(unsigned long
: :"a" (eax), "c" (ecx));
}
-extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
-
#define stack_current() \
({ \
struct thread_info *ti; \
_
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (6 preceding siblings ...)
2006-09-02 1:00 ` 2.6.18-rc5-mm1 Matthias Hentges
@ 2006-09-02 1:06 ` Grant Coady
2006-09-02 1:12 ` 2.6.18-rc5-mm1 Dmitry Torokhov
2006-09-02 1:39 ` 2.6.18-rc5-mm1 Andrew Morton
2006-09-02 9:05 ` 2.6.18-rc5-mm1 Philippe Gramoullé
` (22 subsequent siblings)
30 siblings, 2 replies; 138+ messages in thread
From: Grant Coady @ 2006-09-02 1:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, dmitry.torokhov
On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
...
>- See the `hot-fixes' directory for any important updates to this patchset.
>
Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
Repeating message, hand copied:
atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access
hardware directly.
Thing is, I've been getting this similar message once in dmesg for ages:
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.14.7a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.15.7a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.16.27a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.16.28a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.17.11a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program, like XFree86, might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.18-rc3-mm2a.gz>:
<no mention>
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.18-rc4a.gz>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/dmesg-2.6.18-rc5-git4b>:
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directly.
<http://bugsplatter.mine.nu/test/boxen/sempro/> for more info on hardware
This is MSI KM4M-V <http://tinyurl.com/64cfd> AMD Sempron SktA 32-bit CPU, I
don't see the error on Intel CPU boxen, nor on an AMD K6-2/500 CPU (2.6.15.6)
Grant.
--
VGER BF report: U 0.480374
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1
2006-09-02 1:06 ` 2.6.18-rc5-mm1 Grant Coady
@ 2006-09-02 1:12 ` Dmitry Torokhov
2006-09-02 1:33 ` 2.6.18-rc5-mm1 Dmitry Torokhov
2006-09-02 2:10 ` 2.6.18-rc5-mm1 Grant Coady
2006-09-02 1:39 ` 2.6.18-rc5-mm1 Andrew Morton
1 sibling, 2 replies; 138+ messages in thread
From: Dmitry Torokhov @ 2006-09-02 1:12 UTC (permalink / raw)
To: Grant Coady; +Cc: Andrew Morton, linux-kernel
On Friday 01 September 2006 21:06, Grant Coady wrote:
> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> ...
> >- See the `hot-fixes' directory for any important updates to this patchset.
> >
> Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
>
> Repeating message, hand copied:
> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access
> hardware directly.
>
Please try booting with i8042.panicblink=0 to see the real oops (important
data). We should probably disable blinking if X is not active...
--
Dmitry
--
VGER BF report: H 2.32592e-14
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-02 1:12 ` 2.6.18-rc5-mm1 Dmitry Torokhov
@ 2006-09-02 1:33 ` Dmitry Torokhov
2006-09-02 2:10 ` 2.6.18-rc5-mm1 Grant Coady
1 sibling, 0 replies; 138+ messages in thread
From: Dmitry Torokhov @ 2006-09-02 1:33 UTC (permalink / raw)
To: Grant Coady; +Cc: Andrew Morton, linux-kernel
On Friday 01 September 2006 21:12, Dmitry Torokhov wrote:
> On Friday 01 September 2006 21:06, Grant Coady wrote:
> > On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> >
> > >
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> > ...
> > >- See the `hot-fixes' directory for any important updates to this patchset.
> > >
> > Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
> >
> > Repeating message, hand copied:
> > atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access
> > hardware directly.
> >
>
> Please try booting with i8042.panicblink=0 to see the real oops (important
> data).
.. or try the patch below.
--
Dmitry
Input: i8042 - disable keyboard port when panicking and blinking
This should get rid of "spurious ACK" messages from atkbd driver
during panic.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---
drivers/input/serio/i8042.c | 7 +++++++
1 files changed, 7 insertions(+)
Index: work/drivers/input/serio/i8042.c
===================================================================
--- work.orig/drivers/input/serio/i8042.c
+++ work/drivers/input/serio/i8042.c
@@ -836,9 +836,16 @@ static long i8042_panic_blink(long count
*/
if (!i8042_blink_frequency)
return 0;
+
if (count - last_blink < i8042_blink_frequency)
return 0;
+ /*
+ * Disable keyboard port so ATKBD won't fill logs with
+ * "spurious ACK" messages
+ */
+ i8042_ports[I8042_KBD_PORT_NO].exists = 0;
+
led ^= 0x01 | 0x04;
while (i8042_read_status() & I8042_STR_IBF)
DELAY;
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-02 1:12 ` 2.6.18-rc5-mm1 Dmitry Torokhov
2006-09-02 1:33 ` 2.6.18-rc5-mm1 Dmitry Torokhov
@ 2006-09-02 2:10 ` Grant Coady
1 sibling, 0 replies; 138+ messages in thread
From: Grant Coady @ 2006-09-02 2:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel
On Fri, 1 Sep 2006 21:12:18 -0400, Dmitry Torokhov <dtor@insightbb.com> wrote:
>On Friday 01 September 2006 21:06, Grant Coady wrote:
>> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>>
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>> ...
>> >- See the `hot-fixes' directory for any important updates to this patchset.
>> >
>> Okay, I applied hotfixes and it crashed on boot, keyboard LEDs flashing:
>>
>> Repeating message, hand copied:
>> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access
>> hardware directly.
>>
>
>Please try booting with i8042.panicblink=0 to see the real oops (important
>data). We should probably disable blinking if X is not active...
Please, yes ;) I always boot to CLI console, run linux boxen
mostly headless...
Now it say:
VFS: Cannot open root device "803" or unknown-block(8,3)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS Unable to mount root fs on unknown-block(8,3)
_
What next? (CC akpm removed 'cos bounced)
Grant.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-02 1:06 ` 2.6.18-rc5-mm1 Grant Coady
2006-09-02 1:12 ` 2.6.18-rc5-mm1 Dmitry Torokhov
@ 2006-09-02 1:39 ` Andrew Morton
2006-09-02 3:51 ` 2.6.18-rc5-mm1 Grant Coady
1 sibling, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-02 1:39 UTC (permalink / raw)
To: Grant Coady; +Cc: linux-kernel, dmitry.torokhov
On Sat, 02 Sep 2006 11:06:15 +1000
Grant Coady <gcoady.lk@gmail.com> wrote:
> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> >
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> ...
> >- See the `hot-fixes' directory for any important updates to this patchset.
> >
> Okay, I applied hotfixes and it crashed on boot,
There's another hotfix there now:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/revert-acpi-mwait-c-state-fixes.patch
If that doesn't prevent the crash, please try to get a trace out of it
somehow?
> keyboard LEDs flashing: Repeating message, hand copied:
> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access
Yes, one of my machine does that when it crashes too. It makes the crash
information scroll off the screen in about half a second, which isn't very
kernel-developer-friendly.
--
VGER BF report: H 2.94209e-15
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-02 1:39 ` 2.6.18-rc5-mm1 Andrew Morton
@ 2006-09-02 3:51 ` Grant Coady
2006-09-02 20:20 ` 2.6.18-rc5-mm1 Grant Coady
0 siblings, 1 reply; 138+ messages in thread
From: Grant Coady @ 2006-09-02 3:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, dmitry.torokhov
On Fri, 1 Sep 2006 18:39:27 -0700, Andrew Morton <akpm@osdl.org> wrote:
>On Sat, 02 Sep 2006 11:06:15 +1000
>Grant Coady <gcoady.lk@gmail.com> wrote:
>
>> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>>
>> >
>> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>> ...
>> >- See the `hot-fixes' directory for any important updates to this patchset.
>> >
>> Okay, I applied hotfixes and it crashed on boot,
>
>There's another hotfix there now:
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/revert-acpi-mwait-c-state-fixes.patch
>
>If that doesn't prevent the crash, please try to get a trace out of it
>somehow?
>
>> keyboard LEDs flashing: Repeating message, hand copied:
>> atkbd.c: Spurious ACK in isa0060/serio0. Some program might be trying access
>
>Yes, one of my machine does that when it crashes too. It makes the crash
>information scroll off the screen in about half a second, which isn't very
>kernel-developer-friendly.
Dmitry's patch stopped the LEDs but gave VFS no root device error, make no
sense to me so I start over...
Apply 2.6.18-rc5-mm1, then:
File: drivers-md-kconfig-fix-block-dependency.patch
File: provide-kernel_execve-on-all-architectures-fix-2.patch
File: provide-kernel_execve-on-all-architectures-fix-3.patch
File: revert-acpi-mwait-c-state-fixes.patch
File: revert-ide-hpa-resume-fix.patch
Falls over, looping, after a VFS no root message :(
Apply Dmitry's patch...
Okay, we're not doing the silly looping:
Error is same as previously reported.
A couple blank menu screens in other areas, make oldconfig doesn't :(
WTF happened to SATA support? Where's it hiding now? Found it...
Okay, boots --> Needs Dmitry's non-looping patch so errors don't scroll off
screen. Problem was SATA moved to new window and `make oldconfig` didn't ;)
Grant.
--
VGER BF report: H 6.04481e-06
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-02 3:51 ` 2.6.18-rc5-mm1 Grant Coady
@ 2006-09-02 20:20 ` Grant Coady
2006-09-02 20:38 ` "VGER BF report:.." ? Matti Aarnio
0 siblings, 1 reply; 138+ messages in thread
From: Grant Coady @ 2006-09-02 20:20 UTC (permalink / raw)
To: Grant Coady; +Cc: Andrew Morton, linux-kernel, dmitry.torokhov
On Sat, 02 Sep 2006 13:51:04 +1000, Grant Coady <gcoady.lk@gmail.com> wrote:
>--
>VGER BF report: H 6.04481e-06
^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem
can add a sane sprintf? The boggle minds ;)
Grant.
--
VGER BF report: H 0.00423726
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: "VGER BF report:.." ?
2006-09-02 20:20 ` 2.6.18-rc5-mm1 Grant Coady
@ 2006-09-02 20:38 ` Matti Aarnio
2006-09-03 15:06 ` Jan Engelhardt
0 siblings, 1 reply; 138+ messages in thread
From: Matti Aarnio @ 2006-09-02 20:38 UTC (permalink / raw)
To: Grant Coady; +Cc: linux-kernel
On Sun, Sep 03, 2006 at 06:20:01AM +1000, Grant Coady wrote:
> On Sat, 02 Sep 2006 13:51:04 +1000, Grant Coady <gcoady.lk@gmail.com> wrote:
> >--
> >VGER BF report: H 6.04481e-06
> ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem
> can add a sane sprintf? The boggle minds ;)
>
> Grant.
> --
> VGER BF report: H 0.00423726
That is "bogofilter -T" giving that result.
Presently it is there to debug things and to see what leaked
(unrecognized) spams got.. But my intention is to remove it
quite soon -- say, on monday.
/Matti Aarnio -- one of <postmaster@vger.kernel.org>
--
VGER BF report: U 0.5
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: "VGER BF report:.." ?
2006-09-02 20:38 ` "VGER BF report:.." ? Matti Aarnio
@ 2006-09-03 15:06 ` Jan Engelhardt
2006-09-03 19:59 ` Grant Coady
0 siblings, 1 reply; 138+ messages in thread
From: Jan Engelhardt @ 2006-09-03 15:06 UTC (permalink / raw)
To: Matti Aarnio; +Cc: Grant Coady, linux-kernel
>> >--
>> >VGER BF report: H 6.04481e-06
>> ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem
>> can add a sane sprintf? The boggle minds ;)
Sane? That's just sprintf("%e") - simple, is not it?
If you are not scientifically gifted, 6.04481 * 10^-6 may be more readable
to you ;-)
>VGER BF report: U 0.5
Hm, what's "H" (ham?) and "U" standing for?
Jan Engelhardt
--
--
VGER BF report: U 0.499957
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: "VGER BF report:.." ?
2006-09-03 15:06 ` Jan Engelhardt
@ 2006-09-03 19:59 ` Grant Coady
0 siblings, 0 replies; 138+ messages in thread
From: Grant Coady @ 2006-09-03 19:59 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Matti Aarnio, linux-kernel
On Sun, 3 Sep 2006 17:06:27 +0200 (MEST), Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
>
>>> >--
>>> >VGER BF report: H 6.04481e-06
>>> ^^^^^^^^^^^^^--> perhaps whoever is adding this info-gem
>>> can add a sane sprintf? The boggle minds ;)
>
>Sane? That's just sprintf("%e") - simple, is not it?
Not my point. The value could be rounded to 2 or three digit value for
display, perhaps a 2 digit percentage? The example may as well be zero.
Grant.
--
VGER BF report: H 0.126501
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (7 preceding siblings ...)
2006-09-02 1:06 ` 2.6.18-rc5-mm1 Grant Coady
@ 2006-09-02 9:05 ` Philippe Gramoullé
2006-09-02 11:40 ` 2.6.18-rc5-mm1 Stefan Richter
2006-09-03 9:09 ` [2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA Mike Galbraith
` (21 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Philippe Gramoullé @ 2006-09-02 9:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hello Andrew,
On Fri, 1 Sep 2006 01:58:18 -0700
Andrew Morton <akpm@osdl.org> wrote:
| ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
2.6.18-rc5-mm1 doesn't build whereas 2.6.18-rc5 does.
p4:/usr/src/linux-2.6.17# make bzImage
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
CC arch/i386/kernel/sys_i386.o
arch/i386/kernel/sys_i386.c: In function 'kernel_execve':
arch/i386/kernel/sys_i386.c:262: error: '__NR_execve' undeclared (first use in this function)
arch/i386/kernel/sys_i386.c:262: error: (Each undeclared identifier is reported only once
arch/i386/kernel/sys_i386.c:262: error: for each function it appears in.)
make[1]: *** [arch/i386/kernel/sys_i386.o] Error 1
make: *** [arch/i386/kernel] Error 2
P4 x86
Thanks,
Philippe
--
VGER BF report: H 1.56412e-06
^ permalink raw reply [flat|nested] 138+ messages in thread* [2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (8 preceding siblings ...)
2006-09-02 9:05 ` 2.6.18-rc5-mm1 Philippe Gramoullé
@ 2006-09-03 9:09 ` Mike Galbraith
2006-09-05 16:18 ` Bjorn Helgaas
2006-09-03 17:25 ` 2.6.18-rc5-mm1: sysfs_init() related compile error Adrian Bunk
` (20 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Mike Galbraith @ 2006-09-03 9:09 UTC (permalink / raw)
To: LKML; +Cc: linux-acpi
Greetings,
My single P4/HT box tossed the below on boot.
-Mike
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
[<c1004089>] dump_trace+0x1d7/0x206
[<c10040d2>] show_trace_log_lvl+0x1a/0x30
[<c100484c>] show_trace+0x12/0x14
[<c100496d>] dump_stack+0x19/0x1b
[<c1229702>] acpi_format_exception+0xa2/0xaf
[<c1226824>] acpi_ut_status_exit+0x2b/0x58
[<c1222cbc>] acpi_walk_resources+0xfd/0x109
[<c12393ca>] acpi_motherboard_add+0x22/0x32
[<c123848e>] acpi_bus_driver_init+0x2a/0x7a
[<c123892c>] acpi_bus_register_driver+0x8b/0xfb
[<c15ebd20>] acpi_motherboard_init+0xd/0xf9
[<c10003b1>] init+0x108/0x300
[<c1003c93>] kernel_thread_helper+0x7/0x14
=======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
[<c1004089>] dump_trace+0x1d7/0x206
[<c10040d2>] show_trace_log_lvl+0x1a/0x30
[<c100484c>] show_trace+0x12/0x14
[<c100496d>] dump_stack+0x19/0x1b
[<c1229702>] acpi_format_exception+0xa2/0xaf
[<c1226824>] acpi_ut_status_exit+0x2b/0x58
[<c1222cbc>] acpi_walk_resources+0xfd/0x109
[<c12393ca>] acpi_motherboard_add+0x22/0x32
[<c123848e>] acpi_bus_driver_init+0x2a/0x7a
[<c123892c>] acpi_bus_register_driver+0x8b/0xfb
[<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
[<c10003b1>] init+0x108/0x300
[<c1003c93>] kernel_thread_helper+0x7/0x14
=======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
[<c1004089>] dump_trace+0x1d7/0x206
[<c10040d2>] show_trace_log_lvl+0x1a/0x30
[<c100484c>] show_trace+0x12/0x14
[<c100496d>] dump_stack+0x19/0x1b
[<c1229702>] acpi_format_exception+0xa2/0xaf
[<c1226824>] acpi_ut_status_exit+0x2b/0x58
[<c1222cbc>] acpi_walk_resources+0xfd/0x109
[<c12393ca>] acpi_motherboard_add+0x22/0x32
[<c123848e>] acpi_bus_driver_init+0x2a/0x7a
[<c123892c>] acpi_bus_register_driver+0x8b/0xfb
[<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
[<c10003b1>] init+0x108/0x300
[<c1003c93>] kernel_thread_helper+0x7/0x14
=======================
--
VGER BF report: H 0.00749888
^ permalink raw reply [flat|nested] 138+ messages in thread* 2.6.18-rc5-mm1: sysfs_init() related compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (9 preceding siblings ...)
2006-09-03 9:09 ` [2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA Mike Galbraith
@ 2006-09-03 17:25 ` Adrian Bunk
2006-09-03 22:17 ` 2.6.18-rc5-mm1: MMU=n " Adrian Bunk
` (19 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-03 17:25 UTC (permalink / raw)
To: Andrew Morton, Jens Axboe, David Howells, Greg Kroah-Hartman; +Cc: linux-kernel
I'm getting the following compile error on h8300:
<-- snip -->
...
CC arch/h8300/kernel/asm-offsets.s
In file included from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/kobject.h:22,
from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sysdev.h:24,
from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1605,
from /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/h8300/kernel/asm-offsets.c:12:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sysfs.h:210: error: redefinition of 'sysfs_init'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sysfs.h:136: error: previous definition of 'sysfs_init' was here
make[2]: *** [arch/h8300/kernel/asm-offsets.s] Error 1
<-- snip -->
The problem is a merge conflict since both git-block.patch and
gregkh-driver-sysfs-add-proper-sysfs_init-prototype.patch added
sysfs_init() prototypes and CONFIG_SYSFS=n dummmies to sysfs.h .
The git-block.patch version lacks the __must_check annotation.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
VGER BF report: H 0.332312
^ permalink raw reply [flat|nested] 138+ messages in thread* 2.6.18-rc5-mm1: MMU=n compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (10 preceding siblings ...)
2006-09-03 17:25 ` 2.6.18-rc5-mm1: sysfs_init() related compile error Adrian Bunk
@ 2006-09-03 22:17 ` Adrian Bunk
2006-09-04 7:44 ` Peter Zijlstra
2006-09-03 23:34 ` Lost DVD-RW [Was Re: 2.6.18-rc5-mm1] J.A. Magallón
` (18 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Adrian Bunk @ 2006-09-03 22:17 UTC (permalink / raw)
To: Andrew Morton, Peter Zijlstra; +Cc: linux-kernel, Hugh Dickins
mm-tracking-shared-dirty-pages.patch breaks CONFIG_MMU=n architectures:
<-- snip -->
...
CC mm/page-writeback.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c: In function 'test_clear_page_dirty':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c:867: error: implicit declaration of function 'page_mkclean'
make[2]: *** [mm/page-writeback.o] Error 1
<-- snip -->
cu
Adrian
BTW: @Andrew:
The Cc: line in mm-tracking-shared-dirty-pages.patch is busted.
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
VGER BF report: H 0.00135769
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: MMU=n compile error
2006-09-03 22:17 ` 2.6.18-rc5-mm1: MMU=n " Adrian Bunk
@ 2006-09-04 7:44 ` Peter Zijlstra
2006-09-04 15:44 ` Adrian Bunk
0 siblings, 1 reply; 138+ messages in thread
From: Peter Zijlstra @ 2006-09-04 7:44 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, Hugh Dickins
On Mon, 2006-09-04 at 00:17 +0200, Adrian Bunk wrote:
> mm-tracking-shared-dirty-pages.patch breaks CONFIG_MMU=n architectures:
>
> <-- snip -->
>
> ....
> CC mm/page-writeback.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c: In function 'test_clear_page_dirty':
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c:867: error: implicit declaration of function 'page_mkclean'
> make[2]: *** [mm/page-writeback.o] Error 1
This might fix it, but I don't have a cross compiler for any nommu arch,
nor an emulator so I can't test. - Will try to build me a toolchain but
this could take some time.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
include/linux/rmap.h | 2 ++
1 file changed, 2 insertions(+)
Index: linux-mm/include/linux/rmap.h
===================================================================
--- linux-mm.orig/include/linux/rmap.h 2006-09-04 08:31:57.000000000 +0200
+++ linux-mm/include/linux/rmap.h 2006-09-04 08:33:44.000000000 +0200
@@ -120,6 +120,8 @@ int page_mkclean(struct page *);
#define page_referenced(page,l) TestClearPageReferenced(page)
#define try_to_unmap(page, refs) SWAP_FAIL
+#define page_mkclean(page) (0)
+
#endif /* CONFIG_MMU */
/*
--
VGER BF report: H 0.393012
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: MMU=n compile error
2006-09-04 7:44 ` Peter Zijlstra
@ 2006-09-04 15:44 ` Adrian Bunk
0 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 15:44 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Andrew Morton, linux-kernel, Hugh Dickins
On Mon, Sep 04, 2006 at 09:44:32AM +0200, Peter Zijlstra wrote:
> On Mon, 2006-09-04 at 00:17 +0200, Adrian Bunk wrote:
> > mm-tracking-shared-dirty-pages.patch breaks CONFIG_MMU=n architectures:
> >
> > <-- snip -->
> >
> > ....
> > CC mm/page-writeback.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c: In function 'test_clear_page_dirty':
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/page-writeback.c:867: error: implicit declaration of function 'page_mkclean'
> > make[2]: *** [mm/page-writeback.o] Error 1
>
> This might fix it, but I don't have a cross compiler for any nommu arch,
> nor an emulator so I can't test. - Will try to build me a toolchain but
> this could take some time.
>...
Thanks, I can confirm this fixes the compilation.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 138+ messages in thread
* Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (11 preceding siblings ...)
2006-09-03 22:17 ` 2.6.18-rc5-mm1: MMU=n " Adrian Bunk
@ 2006-09-03 23:34 ` J.A. Magallón
2006-09-04 1:12 ` Andrew Morton
2006-09-04 11:41 ` 2.6.18-rc5-mm1: is_init() parisc compile error Adrian Bunk
` (17 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: J.A. Magallón @ 2006-09-03 23:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>
Err, my burner got lost this summer ;).
This is really not a bug of _this_ kernel, because I noticed it dissapeared
with the previous release also, just before going on vacation... But as it
did not come back with this relase, I report it here.
Last kernel that I have tried that worked was 2.6.18-rc2-mm1. With this
relase, it is gone still. dmesg for both kernels is below.
The only thing I hace noticed is the different IRQ assignment between
them.
Any ideas ? TIA.
dmesg for rc2-mm1:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac6
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 14
scsi0 : ata_piix
ata1.00: ATAPI, max UDMA/33
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.00: configured for UDMA/33
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.01: ATAPI, max UDMA/33
ata2.00: configured for UDMA/100
ata2.01: configured for UDMA/33
Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111
Type: CD-ROM ANSI SCSI revision: 05
Vendor: IOMEGA Model: ZIP 250 Rev: 51.G
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3120022A Rev: 3.06
Type: Direct-Access ANSI SCSI revision: 05
Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004
Type: CD-ROM ANSI SCSI revision: 05
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
...
dmesg for rc5-mm1:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : ata_piix
ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.01: ATAPI, max UDMA/33
ata2.00: configured for UDMA/100
ata2.01: configured for UDMA/33
scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5
sd 0:0:1:0: Attached scsi removable disk sda
scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
scsi 1:0:1:0: CD-ROM TOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:1:0: Attached scsi CD-ROM sr0
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam08 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #1 SMP PREEMPT
--
VGER BF report: U 0.5
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-03 23:34 ` Lost DVD-RW [Was Re: 2.6.18-rc5-mm1] J.A. Magallón
@ 2006-09-04 1:12 ` Andrew Morton
2006-09-04 2:42 ` Tejun Heo
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-04 1:12 UTC (permalink / raw)
To: "J.A. =?ISO-8859-1?B?TWFnYWxs824i?= <jamagallon
Cc: linux-kernel, Alan Cox, Jeff Garzik, Tejun Heo
On Mon, 4 Sep 2006 01:34:43 +0200
"J.A. Magallón" <jamagallon@ono.com> wrote:
> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> >
>
> Err, my burner got lost this summer ;).
> This is really not a bug of _this_ kernel, because I noticed it dissapeared
> with the previous release also, just before going on vacation... But as it
> did not come back with this relase, I report it here.
>
> Last kernel that I have tried that worked was 2.6.18-rc2-mm1. With this
> relase, it is gone still. dmesg for both kernels is below.
> The only thing I hace noticed is the different IRQ assignment between
> them.
>
> Any ideas ? TIA.
>
> dmesg for rc2-mm1:
>
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00ac6
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 14
> scsi0 : ata_piix
> ata1.00: ATAPI, max UDMA/33
> ata1.01: ATAPI, max MWDMA0, CDB intr
> ata1.00: configured for UDMA/33
> ata1.01: configured for PIO3
> scsi1 : ata_piix
> ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
> ata2.00: ata2: dev 0 multi count 16
> ata2.01: ATAPI, max UDMA/33
> ata2.00: configured for UDMA/100
> ata2.01: configured for UDMA/33
> Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111
> Type: CD-ROM ANSI SCSI revision: 05
> Vendor: IOMEGA Model: ZIP 250 Rev: 51.G
> Type: Direct-Access ANSI SCSI revision: 05
> Vendor: ATA Model: ST3120022A Rev: 3.06
> Type: Direct-Access ANSI SCSI revision: 05
> Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004
> Type: CD-ROM ANSI SCSI revision: 05
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
> ...
>
> dmesg for rc5-mm1:
>
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00ac7
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> scsi0 : ata_piix
> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
> ata1.01: ATAPI, max MWDMA0, CDB intr
> ata1.01: configured for PIO3
> scsi1 : ata_piix
> ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
> ata2.00: ata2: dev 0 multi count 16
> ata2.01: ATAPI, max UDMA/33
> ata2.00: configured for UDMA/100
> ata2.01: configured for UDMA/33
> scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5
> sd 0:0:1:0: Attached scsi removable disk sda
> scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5
> SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: drive cache: write back
> SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
> sdb: Write Protect is off
> sdb: Mode Sense: 00 3a 00 00
> SCSI device sdb: drive cache: write back
> sdb: sdb1
> sd 1:0:0:0: Attached scsi disk sdb
> scsi 1:0:1:0: CD-ROM TOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
> sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
> sr 1:0:1:0: Attached scsi CD-ROM sr0
> ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
> ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
> ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
>
Please, try to cc the relevant developers on bug reports.
Thanks.
--
VGER BF report: H 0
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-04 1:12 ` Andrew Morton
@ 2006-09-04 2:42 ` Tejun Heo
2006-09-04 22:26 ` J.A. Magallón
0 siblings, 1 reply; 138+ messages in thread
From: Tejun Heo @ 2006-09-04 2:42 UTC (permalink / raw)
To: jamagallon; +Cc: Andrew Morton, linux-kernel, Alan Cox, Jeff Garzik
[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]
Andrew Morton wrote:
> On Mon, 4 Sep 2006 01:34:43 +0200
> "J.A. Magallón" <jamagallon@ono.com> wrote:
>
>> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
>>>
>> Err, my burner got lost this summer ;).
>> This is really not a bug of _this_ kernel, because I noticed it dissapeared
>> with the previous release also, just before going on vacation... But as it
>> did not come back with this relase, I report it here.
>>
>> Last kernel that I have tried that worked was 2.6.18-rc2-mm1. With this
>> relase, it is gone still. dmesg for both kernels is below.
>> The only thing I hace noticed is the different IRQ assignment between
>> them.
>>
>> Any ideas ? TIA.
>>
>> dmesg for rc2-mm1:
>> scsi0 : ata_piix
>> ata1.00: ATAPI, max UDMA/33
>> ata1.01: ATAPI, max MWDMA0, CDB intr
>> ata1.00: configured for UDMA/33
>> ata1.01: configured for PIO3
>> Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111
>> Type: CD-ROM ANSI SCSI revision: 05
>> Vendor: IOMEGA Model: ZIP 250 Rev: 51.G
>> Type: Direct-Access ANSI SCSI revision: 05
>>
>> dmesg for rc5-mm1:
>> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
Hmmm... Strange.
The related code hasn't changed much between rc2-mm1 and rc5-mm1. We're
talking about 2.6.18-rc2-mm1 and 2.6.18-rc5-mm1, right?
Can you try the attached patch and report what the kernel says?
--
tejun
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 544 bytes --]
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 1c93154..af2fc6f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1276,6 +1276,8 @@ int ata_dev_read_id(struct ata_device *d
swap_buf_le16(id, ATA_ID_WORDS);
/* sanity check */
+ ata_dev_printk(dev, KERN_INFO, "XXX class=%d is_ata=%d is_cfa=%d\n",
+ class, ata_id_is_ata(id), ata_id_is_cfa(id));
if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
rc = -EINVAL;
reason = "device reports illegal type";
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-04 2:42 ` Tejun Heo
@ 2006-09-04 22:26 ` J.A. Magallón
2006-09-07 9:34 ` Tejun Heo
0 siblings, 1 reply; 138+ messages in thread
From: J.A. Magallón @ 2006-09-04 22:26 UTC (permalink / raw)
To: Tejun Heo; +Cc: Andrew Morton, linux-kernel, Alan Cox, Jeff Garzik
On Mon, 04 Sep 2006 04:42:35 +0200, Tejun Heo <htejun@gmail.com> wrote:
> Andrew Morton wrote:
> > On Mon, 4 Sep 2006 01:34:43 +0200
> > "J.A. Magallón" <jamagallon@ono.com> wrote:
> >
> >> On Fri, 1 Sep 2006 01:58:18 -0700, Andrew Morton <akpm@osdl.org> wrote:
> >>
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> >>>
> >> Err, my burner got lost this summer ;).
...
> >> dmesg for rc2-mm1:
> >> scsi0 : ata_piix
> >> ata1.00: ATAPI, max UDMA/33
> >> ata1.01: ATAPI, max MWDMA0, CDB intr
> >> ata1.00: configured for UDMA/33
> >> ata1.01: configured for PIO3
> >> Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111
> >> Type: CD-ROM ANSI SCSI revision: 05
> >> Vendor: IOMEGA Model: ZIP 250 Rev: 51.G
> >> Type: Direct-Access ANSI SCSI revision: 05
> >>
> >> dmesg for rc5-mm1:
> >> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
>
> Hmmm... Strange.
>
> The related code hasn't changed much between rc2-mm1 and rc5-mm1. We're
> talking about 2.6.18-rc2-mm1 and 2.6.18-rc5-mm1, right?
>
> Can you try the attached patch and report what the kernel says?
>
>
Here it is:
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : ata_piix
ata1.00: XXX class=3 is_ata=0 is_cfa=1
ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
ata1.01: XXX class=3 is_ata=0 is_cfa=0
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.01: XXX class=3 is_ata=0 is_cfa=0
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: XXX class=1 is_ata=1 is_cfa=0
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.01: XXX class=3 is_ata=0 is_cfa=0
ata2.01: ATAPI, max UDMA/33
ata2.00: XXX class=1 is_ata=1 is_cfa=0
ata2.00: configured for UDMA/100
ata2.01: XXX class=3 is_ata=0 is_cfa=0
ata2.01: configured for UDMA/33
scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5
sd 0:0:1:0: Attached scsi removable disk sda
scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
scsi 1:0:1:0: CD-ROM TOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:1:0: Attached scsi CD-ROM sr0
ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ]
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16
ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16
scsi2 : ata_piix
ata3.00: XXX class=1 is_ata=1 is_cfa=0
ata3.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48
ata3.00: ata3: dev 0 multi count 16
ata3.00: XXX class=1 is_ata=1 is_cfa=0
ata3.00: configured for UDMA/133
scsi3 : ata_piix
ATA: abnormal status 0x7F on port 0xC807
scsi 2:0:0:0: Direct-Access ATA ST3200822AS 3.01 PQ: 0 ANSI: 5
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2 sdc3
sd 2:0:0:0: Attached scsi disk sdc
sata_promise 0000:03:04.0: version 1.04
ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 23 (level, low) -> IRQ 17
sata_promise PATA port found
ata5: SATA max UDMA/133 cmd 0xF8802200 ctl 0xF8802238 bmdma 0x0 irq 17
ata6: SATA max UDMA/133 cmd 0xF8802280 ctl 0xF88022B8 bmdma 0x0 irq 17
ata7: PATA max UDMA/133 cmd 0xF8802300 ctl 0xF8802338 bmdma 0x0 irq 17
scsi4 : sata_promise
ata5: SATA link down (SStatus 0 SControl 0)
scsi5 : sata_promise
ata6: SATA link down (SStatus 0 SControl 300)
scsi6 : sata_promise
ATA: abnormal status 0x7F on port 0xF880231C
ata7: disabling port
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam08 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #2 SMP PREEMPT
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-04 22:26 ` J.A. Magallón
@ 2006-09-07 9:34 ` Tejun Heo
2006-09-07 11:13 ` J.A. Magallón
2006-09-09 14:46 ` Lost DVD-RW [Was Re: 2.6.18-rc5-mm1] Alan Cox
0 siblings, 2 replies; 138+ messages in thread
From: Tejun Heo @ 2006-09-07 9:34 UTC (permalink / raw)
To: "J.A. Magallón"
Cc: Andrew Morton, linux-kernel, Alan Cox, Jeff Garzik
[-- Attachment #1: Type: text/plain, Size: 3226 bytes --]
J.A. Magallón wrote:
> libata version 2.00 loaded.
> ata_piix 0000:00:1f.1: version 2.00ac7
> ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:1f.1 to 64
> ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> scsi0 : ata_piix
> ata1.00: XXX class=3 is_ata=0 is_cfa=1
> ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
Magallón, does the attached patch fix the problem?
Alan, it seems that 0x848a indicates CFA device iff the ID data is from
IDENTIFY DEVICE. When the command is IDENTIFY PACKET DEVICE, 0x848a
seems to indicate a valid ATAPI device.
From ATA8-ACS, 7.17 is IDENTIFY DEVICE.
> 7.17.7.1 Word 0: General configuration
>
> Devices that conform to this standard shall clear bit 15 to zero. If
> bit 7 is set to one, the device is a removable media device. Bit 6 is
> obsolete.
>
> If bit 2 is set to one it indicates that the content of the IDENTIFY
> DEVICE data is incomplete. This will occur if the device supports the
> Power-up in Standby feature set and required data is contained on the
> device media. In this case the content of at least word 0 and word 2
> shall be valid.
>
> Devices supporting the CFA feature set shall place the value 848Ah in
^^^^^
> word 0. In this case, the above definitions for the bits in word 0
> are not valid.
And, 7.18 is on IDENTIFY PACKET DEVICE.
> 7.18.6.2 Word 0: General configuration
>
> Bits (15:14) of word 0 indicate the type of device. Bit 15 shall be
> set to one and bit 14 shall be cleared to zeroto indicate the device
> implements the PACKET Command feature set.
>
> Bits (12:8) of word 0 indicate the command packet set implemented by
> the device. This value follows the peripheral device type value as
> defined in SCSI Primary Commands, ANSI INCITS 301:1997.
>
> Bit 7 if set to one indicates that the device has removable media.
>
> Bits (6:5) of word 0 indicate the DRQ response time when a PACKET
> command is received. A value of 00b indicates a maximum time of 3 ms
> from receipt of PACKET to the setting of DRQ to one. A value of 10b
> indicates a maximum time of 50 μs from the receipt of PACKET to the
> setting of DRQ to one. The value 11b is reserved.
>
> If bit 2 is set to one it indicates that the content of the IDENTIFY
> DEVICE data is incomplete. This will occur if the device supports the
> Power-up in Standby feature set and required data is contained on the
> device media. In this case the content of at least word 0 and word 2
> shall be valid.
>
> Bits (1:0) of word 0 indicate the packet size the device supports. A
> value of 00b indicates that a 12-byte packet is supported; a value of
> 01b indicates a 16 byte packet. The values 10b and 11b are reserved.
So, when the output is from IDENTIFY PACKET DEVICE, 0x848a doesn't have
any special meaning. It indicates a valid write-once, removable media,
ATAPI device with 16bytes CDB.
The attached patch makes sanity checking logic in ata_dev_read_id()
check for CFA only if IDENTIFY DEVICE is used.
Thanks.
--
tejun
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 702 bytes --]
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 73dd6c8..427b73a 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -1256,10 +1256,15 @@ int ata_dev_read_id(struct ata_device *d
swap_buf_le16(id, ATA_ID_WORDS);
/* sanity check */
- if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
- rc = -EINVAL;
- reason = "device reports illegal type";
- goto err_out;
+ rc = -EINVAL;
+ reason = "device reports illegal type";
+
+ if (class == ATA_DEV_ATA) {
+ if (!ata_id_is_ata(id) && !ata_id_is_cfa(id))
+ goto err_out;
+ } else {
+ if (ata_id_is_ata(id))
+ goto err_out;
}
if (post_reset && class == ATA_DEV_ATA) {
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-07 9:34 ` Tejun Heo
@ 2006-09-07 11:13 ` J.A. Magallón
2006-09-07 11:32 ` [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device Tejun Heo
2006-09-09 14:46 ` Lost DVD-RW [Was Re: 2.6.18-rc5-mm1] Alan Cox
1 sibling, 1 reply; 138+ messages in thread
From: J.A. Magallón @ 2006-09-07 11:13 UTC (permalink / raw)
To: Tejun Heo; +Cc: Andrew Morton, linux-kernel, Alan Cox, Jeff Garzik
On Thu, 07 Sep 2006 11:34:39 +0200, Tejun Heo <htejun@gmail.com> wrote:
> J.A. Magallón wrote:
> > libata version 2.00 loaded.
> > ata_piix 0000:00:1f.1: version 2.00ac7
> > ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
> > PCI: Setting latency timer of device 0000:00:1f.1 to 64
> > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
> > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
> > scsi0 : ata_piix
> > ata1.00: XXX class=3 is_ata=0 is_cfa=1
> > ata1.00: failed to IDENTIFY (device reports illegal type, err_mask=0x0)
>
> Magallón, does the attached patch fix the problem?
>
Yes, my burner is back :)
libata version 2.00 loaded.
ata_piix 0000:00:1f.1: version 2.00ac7
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1f.1 to 64
ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi0 : ata_piix
ata1.00: ATAPI, max UDMA/33
ata1.01: ATAPI, max MWDMA0, CDB intr
ata1.00: configured for UDMA/33
ata1.01: configured for PIO3
scsi1 : ata_piix
ata2.00: ATA-6, max UDMA/100, 234441648 sectors: LBA48
ata2.00: ata2: dev 0 multi count 16
ata2.01: ATAPI, max UDMA/33
ata2.00: configured for UDMA/100
ata2.01: configured for UDMA/33
scsi 0:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-4120B A111 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 0:0:0:0: Attached scsi CD-ROM sr0
scsi 0:0:1:0: Direct-Access IOMEGA ZIP 250 51.G PQ: 0 ANSI: 5
sd 0:0:1:0: Attached scsi removable disk sda
scsi 1:0:0:0: Direct-Access ATA ST3120022A 3.06 PQ: 0 ANSI: 5
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1
sd 1:0:0:0: Attached scsi disk sdb
scsi 1:0:1:0: CD-ROM TOSHIBA DVD-ROM SD-M1712 1004 PQ: 0 ANSI: 5
sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray
sr 1:0:1:0: Attached scsi CD-ROM sr1
Thanks !!
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam08 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #4 SMP PREEMPT
^ permalink raw reply [flat|nested] 138+ messages in thread* [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device
2006-09-07 11:13 ` J.A. Magallón
@ 2006-09-07 11:32 ` Tejun Heo
2006-09-07 20:27 ` Andrew Morton
0 siblings, 1 reply; 138+ messages in thread
From: Tejun Heo @ 2006-09-07 11:32 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, linux-kernel, Alan Cox, J.A. Magallon
0x848a in ID word 0 indicates CFA device iff the ID data is obtained
from IDENTIFY DEVICE. For ATAPI devices, 0x848a in ID work 0
indicates valid ATAPI device. Fix sanity check in ata_dev_read_id()
such that ATAPI devices reporting 0x848a in ID word 0 is not handled
as error.
The problem is identified by J.A. Magallon with HL-DT-ST DVDRAM
GSA-4120B.
Signed-off-by: Tejun Helo <htejun@gmail.com>
Cc: J.A. Magallon <jamagallon@ono.com>
---
Jeff, this is a regression and thus should go into .19.
diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 73dd6c8..427b73a 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -1256,10 +1256,15 @@ int ata_dev_read_id(struct ata_device *d
swap_buf_le16(id, ATA_ID_WORDS);
/* sanity check */
- if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
- rc = -EINVAL;
- reason = "device reports illegal type";
- goto err_out;
+ rc = -EINVAL;
+ reason = "device reports illegal type";
+
+ if (class == ATA_DEV_ATA) {
+ if (!ata_id_is_ata(id) && !ata_id_is_cfa(id))
+ goto err_out;
+ } else {
+ if (ata_id_is_ata(id))
+ goto err_out;
}
if (post_reset && class == ATA_DEV_ATA) {
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device
2006-09-07 11:32 ` [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device Tejun Heo
@ 2006-09-07 20:27 ` Andrew Morton
2006-09-07 21:03 ` Jeff Garzik
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-07 20:27 UTC (permalink / raw)
To: Tejun Heo; +Cc: Jeff Garzik, linux-kernel, Alan Cox, J.A. Magallon
On Thu, 7 Sep 2006 20:32:24 +0900
Tejun Heo <htejun@gmail.com> wrote:
> 0x848a in ID word 0 indicates CFA device iff the ID data is obtained
> from IDENTIFY DEVICE. For ATAPI devices, 0x848a in ID work 0
> indicates valid ATAPI device. Fix sanity check in ata_dev_read_id()
> such that ATAPI devices reporting 0x848a in ID word 0 is not handled
> as error.
>
> The problem is identified by J.A. Magallon with HL-DT-ST DVDRAM
> GSA-4120B.
>
> Signed-off-by: Tejun Helo <htejun@gmail.com>
> Cc: J.A. Magallon <jamagallon@ono.com>
> ---
> Jeff, this is a regression and thus should go into .19.
You mean 2.6.18, yes?
> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> index 73dd6c8..427b73a 100644
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -1256,10 +1256,15 @@ int ata_dev_read_id(struct ata_device *d
> swap_buf_le16(id, ATA_ID_WORDS);
>
> /* sanity check */
> - if ((class == ATA_DEV_ATA) != (ata_id_is_ata(id) | ata_id_is_cfa(id))) {
> - rc = -EINVAL;
> - reason = "device reports illegal type";
> - goto err_out;
> + rc = -EINVAL;
> + reason = "device reports illegal type";
> +
> + if (class == ATA_DEV_ATA) {
> + if (!ata_id_is_ata(id) && !ata_id_is_cfa(id))
> + goto err_out;
> + } else {
> + if (ata_id_is_ata(id))
> + goto err_out;
> }
>
> if (post_reset && class == ATA_DEV_ATA) {
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device
2006-09-07 20:27 ` Andrew Morton
@ 2006-09-07 21:03 ` Jeff Garzik
2006-09-08 7:56 ` Tejun Heo
0 siblings, 1 reply; 138+ messages in thread
From: Jeff Garzik @ 2006-09-07 21:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: Tejun Heo, linux-kernel, Alan Cox, J.A. Magallon
Andrew Morton wrote:
> On Thu, 7 Sep 2006 20:32:24 +0900
> Tejun Heo <htejun@gmail.com> wrote:
>
>> 0x848a in ID word 0 indicates CFA device iff the ID data is obtained
>> from IDENTIFY DEVICE. For ATAPI devices, 0x848a in ID work 0
>> indicates valid ATAPI device. Fix sanity check in ata_dev_read_id()
>> such that ATAPI devices reporting 0x848a in ID word 0 is not handled
>> as error.
>>
>> The problem is identified by J.A. Magallon with HL-DT-ST DVDRAM
>> GSA-4120B.
>>
>> Signed-off-by: Tejun Helo <htejun@gmail.com>
>> Cc: J.A. Magallon <jamagallon@ono.com>
>> ---
>> Jeff, this is a regression and thus should go into .19.
>
> You mean 2.6.18, yes?
Actually, it looks like it should indeed be 2.6.19 (libata #upstream),
not 2.6.18 (libata #upstream-fixes). Alan's "add compactflash support"
patch isn't in 2.6.18-rc.
So, this should -not- be sent for 2.6.18.
Jeff
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH libata-dev#upstream-fixes] libata: ignore CFA signature while sanity-checking an ATAPI device
2006-09-07 21:03 ` Jeff Garzik
@ 2006-09-08 7:56 ` Tejun Heo
0 siblings, 0 replies; 138+ messages in thread
From: Tejun Heo @ 2006-09-08 7:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, linux-kernel, Alan Cox, J.A. Magallon
Jeff Garzik wrote:
> Andrew Morton wrote:
>> You mean 2.6.18, yes?
>
> Actually, it looks like it should indeed be 2.6.19 (libata #upstream),
> not 2.6.18 (libata #upstream-fixes). Alan's "add compactflash support"
> patch isn't in 2.6.18-rc.
>
> So, this should -not- be sent for 2.6.18.
Hello,
Yes, I meant .18. Jeff, this should be fixed before 2.6.18 is released.
It's not the question of whether CFA support is implemented or not.
We're sanity-checking in 2.6.18-rcX anyway and it's the sanity checking
which is causing problem. What seems to have happened is...
1. CFA support is implemented
2. CFA check was added (backported) to upstream-fixes, but it was incorrect.
So, we need to do one of two things.
* apply this patch to 2.6.18-rcX
* remove ata_id_is_cfa() check altogether
--
tejun
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: Lost DVD-RW [Was Re: 2.6.18-rc5-mm1]
2006-09-07 9:34 ` Tejun Heo
2006-09-07 11:13 ` J.A. Magallón
@ 2006-09-09 14:46 ` Alan Cox
1 sibling, 0 replies; 138+ messages in thread
From: Alan Cox @ 2006-09-09 14:46 UTC (permalink / raw)
To: Tejun Heo
Cc: "J.A. Magallón", Andrew Morton, linux-kernel,
Jeff Garzik
Ar Iau, 2006-09-07 am 11:34 +0200, ysgrifennodd Tejun Heo:
> Alan, it seems that 0x848a indicates CFA device iff the ID data is from
> IDENTIFY DEVICE. When the command is IDENTIFY PACKET DEVICE, 0x848a
> seems to indicate a valid ATAPI device.
Apparently so - thats a detail I didn't know about.
Acked-by: Alan Cox <alan@redhat.com>
Alan
^ permalink raw reply [flat|nested] 138+ messages in thread
* 2.6.18-rc5-mm1: is_init() parisc compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (12 preceding siblings ...)
2006-09-03 23:34 ` Lost DVD-RW [Was Re: 2.6.18-rc5-mm1] J.A. Magallón
@ 2006-09-04 11:41 ` Adrian Bunk
2006-09-04 13:48 ` [parisc-linux] " Matthew Wilcox
2006-09-04 17:03 ` [-mm patch] drivers/infiniband/hw/amso1100/: possible cleanups Adrian Bunk
` (16 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 11:41 UTC (permalink / raw)
To: Andrew Morton, Sukadev Bhattiprolu, ebiederm; +Cc: linux-kernel, parisc-linux
pidspace-is_init.patch causes the following compile error on parisc:
<-- snip -->
...
CC arch/parisc/kernel/module.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76: error: conflicting types for 'is_init'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090: error: previous definition of 'is_init' was here
make[2]: *** [arch/parisc/kernel/module.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
VGER BF report: H 2.76804e-05
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [parisc-linux] 2.6.18-rc5-mm1: is_init() parisc compile error
2006-09-04 11:41 ` 2.6.18-rc5-mm1: is_init() parisc compile error Adrian Bunk
@ 2006-09-04 13:48 ` Matthew Wilcox
2006-09-04 18:24 ` [PATCH] Fix conflict with the is_init identifier on parisc Eric W. Biederman
0 siblings, 1 reply; 138+ messages in thread
From: Matthew Wilcox @ 2006-09-04 13:48 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Sukadev Bhattiprolu, ebiederm, linux-kernel,
parisc-linux
On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
> pidspace-is_init.patch causes the following compile error on parisc:
>
> <-- snip -->
>
> ...
> CC arch/parisc/kernel/module.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76: error: conflicting types for 'is_init'
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090: error: previous definition of 'is_init' was here
> make[2]: *** [arch/parisc/kernel/module.o] Error 1
>
> <-- snip -->
Looks like ia64 calls the same function in_init(). I'm tempted to
change parisc to have the same name.
^ permalink raw reply [flat|nested] 138+ messages in thread
* [PATCH] Fix conflict with the is_init identifier on parisc
2006-09-04 13:48 ` [parisc-linux] " Matthew Wilcox
@ 2006-09-04 18:24 ` Eric W. Biederman
2006-09-04 18:41 ` Adrian Bunk
2006-09-04 19:18 ` Andrew Morton
0 siblings, 2 replies; 138+ messages in thread
From: Eric W. Biederman @ 2006-09-04 18:24 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Adrian Bunk, Andrew Morton, Sukadev Bhattiprolu, linux-kernel,
parisc-linux
Matthew Wilcox <matthew@wil.cx> writes:
> On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
>> pidspace-is_init.patch causes the following compile error on parisc:
>>
>> <-- snip -->
>>
>> ...
>> CC arch/parisc/kernel/module.o
>>
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76:
> error: conflicting types for 'is_init'
>> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090:
> error: previous definition of 'is_init' was here
>> make[2]: *** [arch/parisc/kernel/module.o] Error 1
>>
>> <-- snip -->
>
> Looks like ia64 calls the same function in_init(). I'm tempted to
> change parisc to have the same name.
How does the following patch look?
Since I don't have a parisc compiler so I haven't compile tested it.
But it is a simple substitute and replace and I can't see any problems
by inspection so it should work.
----
This appears to be the only usage of is_init in the kernel
besides the usage in sched.h. On ia64 the same function is
called in_init. So to remove the conflict and make the kernel
more consistent rename is_init is_core is_local and is_local_section
to in_init in_core in_local and in_local_section respectively.
Thanks to Adrian Bunk who spotted this, and to Matthew Wilcox
who suggested this fix.
Singed-off-by: Eric Biederman <ebiederm@xmission.com>
---
arch/parisc/kernel/module.c | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index aee3118..f50b982 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -27,7 +27,7 @@
* - SEGREL32 handling
* We are not doing SEGREL32 handling correctly. According to the ABI, we
* should do a value offset, like this:
- * if (is_init(me, (void *)val))
+ * if (in_init(me, (void *)val))
* val -= (uint32_t)me->module_init;
* else
* val -= (uint32_t)me->module_core;
@@ -72,27 +72,27 @@ #define MAX_GOTS 1023
/* three functions to determine where in the module core
* or init pieces the location is */
-static inline int is_init(struct module *me, void *loc)
+static inline int in_init(struct module *me, void *loc)
{
return (loc >= me->module_init &&
loc <= (me->module_init + me->init_size));
}
-static inline int is_core(struct module *me, void *loc)
+static inline int in_core(struct module *me, void *loc)
{
return (loc >= me->module_core &&
loc <= (me->module_core + me->core_size));
}
-static inline int is_local(struct module *me, void *loc)
+static inline int in_local(struct module *me, void *loc)
{
- return is_init(me, loc) || is_core(me, loc);
+ return in_init(me, loc) || in_core(me, loc);
}
-static inline int is_local_section(struct module *me, void *loc, void *dot)
+static inline int in_local_section(struct module *me, void *loc, void *dot)
{
- return (is_init(me, loc) && is_init(me, dot)) ||
- (is_core(me, loc) && is_core(me, dot));
+ return (in_init(me, loc) && in_init(me, dot)) ||
+ (in_core(me, loc) && in_core(me, dot));
}
@@ -566,14 +566,14 @@ #endif
break;
case R_PARISC_PCREL17F:
/* 17-bit PC relative address */
- val = get_stub(me, val, addend, ELF_STUB_GOT, is_init(me, loc));
+ val = get_stub(me, val, addend, ELF_STUB_GOT, in_init(me, loc));
val = (val - dot - 8)/4;
CHECK_RELOC(val, 17)
*loc = (*loc & ~0x1f1ffd) | reassemble_17(val);
break;
case R_PARISC_PCREL22F:
/* 22-bit PC relative address; only defined for pa20 */
- val = get_stub(me, val, addend, ELF_STUB_GOT, is_init(me, loc));
+ val = get_stub(me, val, addend, ELF_STUB_GOT, in_init(me, loc));
DEBUGP("STUB FOR %s loc %lx+%lx at %lx\n",
strtab + sym->st_name, (unsigned long)loc, addend,
val)
@@ -670,9 +670,9 @@ #endif
strtab + sym->st_name,
loc, val);
/* can we reach it locally? */
- if(!is_local_section(me, (void *)val, (void *)dot)) {
+ if(!in_local_section(me, (void *)val, (void *)dot)) {
- if (is_local(me, (void *)val))
+ if (in_local(me, (void *)val))
/* this is the case where the
* symbol is local to the
* module, but in a different
@@ -680,14 +680,14 @@ #endif
* in case it's more than 22
* bits away */
val = get_stub(me, val, addend, ELF_STUB_DIRECT,
- is_init(me, loc));
+ in_init(me, loc));
else if (strncmp(strtab + sym->st_name, "$$", 2)
== 0)
val = get_stub(me, val, addend, ELF_STUB_MILLI,
- is_init(me, loc));
+ in_init(me, loc));
else
val = get_stub(me, val, addend, ELF_STUB_GOT,
- is_init(me, loc));
+ in_init(me, loc));
}
DEBUGP("STUB FOR %s loc %lx, val %lx+%lx at %lx\n",
strtab + sym->st_name, loc, sym->st_value,
@@ -720,7 +720,7 @@ #endif
break;
case R_PARISC_FPTR64:
/* 64-bit function address */
- if(is_local(me, (void *)(val + addend))) {
+ if(in_local(me, (void *)(val + addend))) {
*loc64 = get_fdesc(me, val+addend);
DEBUGP("FDESC for %s at %p points to %lx\n",
strtab + sym->st_name, *loc64,
--
1.4.2.rc3.g7e18e-dirty
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [PATCH] Fix conflict with the is_init identifier on parisc
2006-09-04 18:24 ` [PATCH] Fix conflict with the is_init identifier on parisc Eric W. Biederman
@ 2006-09-04 18:41 ` Adrian Bunk
2006-09-04 19:18 ` Andrew Morton
1 sibling, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 18:41 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Matthew Wilcox, Andrew Morton, Sukadev Bhattiprolu, linux-kernel,
parisc-linux
On Mon, Sep 04, 2006 at 12:24:27PM -0600, Eric W. Biederman wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
>
> > On Mon, Sep 04, 2006 at 01:41:30PM +0200, Adrian Bunk wrote:
> >> pidspace-is_init.patch causes the following compile error on parisc:
> >>
> >> <-- snip -->
> >>
> >> ...
> >> CC arch/parisc/kernel/module.o
> >>
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/parisc/kernel/module.c:76:
> > error: conflicting types for 'is_init'
> >> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/include/linux/sched.h:1090:
> > error: previous definition of 'is_init' was here
> >> make[2]: *** [arch/parisc/kernel/module.o] Error 1
> >>
> >> <-- snip -->
> >
> > Looks like ia64 calls the same function in_init(). I'm tempted to
> > change parisc to have the same name.
>
> How does the following patch look?
> Since I don't have a parisc compiler so I haven't compile tested it.
> But it is a simple substitute and replace and I can't see any problems
> by inspection so it should work.
>...
Thanks, I can confirm it fixes the compilation.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] Fix conflict with the is_init identifier on parisc
2006-09-04 18:24 ` [PATCH] Fix conflict with the is_init identifier on parisc Eric W. Biederman
2006-09-04 18:41 ` Adrian Bunk
@ 2006-09-04 19:18 ` Andrew Morton
1 sibling, 0 replies; 138+ messages in thread
From: Andrew Morton @ 2006-09-04 19:18 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Matthew Wilcox, Adrian Bunk, Sukadev Bhattiprolu, linux-kernel,
parisc-linux
On Mon, 04 Sep 2006 12:24:27 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Singed-off-by: Eric Biederman <ebiederm@xmission.com>
ouch! One for the hot-fixes directory, I assume.
^ permalink raw reply [flat|nested] 138+ messages in thread
* [-mm patch] drivers/infiniband/hw/amso1100/: possible cleanups
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (13 preceding siblings ...)
2006-09-04 11:41 ` 2.6.18-rc5-mm1: is_init() parisc compile error Adrian Bunk
@ 2006-09-04 17:03 ` Adrian Bunk
2006-09-04 17:03 ` [-mm patch] make fs/lockd/host.c:nlm_lookup_host() static Adrian Bunk
` (15 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 17:03 UTC (permalink / raw)
To: Andrew Morton, Tom Tucker, Steve Wise, Roland Dreier
Cc: linux-kernel, openib-general
On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> git-infiniband.patch
>...
> git trees.
>...
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- c2_ae.c: to_qp_state_str()
- c2_cq.c: c2_cq_get()
- c2_cq.c: c2_cq_put()
- c2_qp.c: to_ib_state()
- c2_qp.c: to_ib_state_str()
- c2_rnic.c: c2_rnic_query()
- #if 0 the following unused global function:
- c2_mq.c: c2_mq_count()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/infiniband/hw/amso1100/c2.h | 1 -
drivers/infiniband/hw/amso1100/c2_ae.c | 2 +-
drivers/infiniband/hw/amso1100/c2_cq.c | 4 ++--
drivers/infiniband/hw/amso1100/c2_mq.c | 3 ++-
drivers/infiniband/hw/amso1100/c2_mq.h | 1 -
drivers/infiniband/hw/amso1100/c2_qp.c | 4 ++--
drivers/infiniband/hw/amso1100/c2_rnic.c | 3 +--
7 files changed, 8 insertions(+), 10 deletions(-)
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_ae.c.old 2006-09-01 21:02:16.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_ae.c 2006-09-01 21:02:23.000000000 +0200
@@ -125,7 +125,7 @@
return event_str[event];
}
-const char *to_qp_state_str(int state)
+static const char *to_qp_state_str(int state)
{
switch (state) {
case C2_QP_STATE_IDLE:
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_cq.c.old 2006-09-01 21:02:45.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_cq.c 2006-09-01 21:03:06.000000000 +0200
@@ -41,7 +41,7 @@
#define C2_CQ_MSG_SIZE ((sizeof(struct c2wr_ce) + 32-1) & ~(32-1))
-struct c2_cq *c2_cq_get(struct c2_dev *c2dev, int cqn)
+static struct c2_cq *c2_cq_get(struct c2_dev *c2dev, int cqn)
{
struct c2_cq *cq;
unsigned long flags;
@@ -57,7 +57,7 @@
return cq;
}
-void c2_cq_put(struct c2_cq *cq)
+static void c2_cq_put(struct c2_cq *cq)
{
if (atomic_dec_and_test(&cq->refcount))
wake_up(&cq->wait);
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.h.old 2006-09-01 21:03:23.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.h 2006-09-01 21:03:30.000000000 +0200
@@ -98,7 +98,6 @@
extern void c2_mq_produce(struct c2_mq *q);
extern void *c2_mq_consume(struct c2_mq *q);
extern void c2_mq_free(struct c2_mq *q);
-extern u32 c2_mq_count(struct c2_mq *q);
extern void c2_mq_req_init(struct c2_mq *q, u32 index, u32 q_size, u32 msg_size,
u8 __iomem *pool_start, u16 __iomem *peer, u32 type);
extern void c2_mq_rep_init(struct c2_mq *q, u32 index, u32 q_size, u32 msg_size,
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.c.old 2006-09-01 21:03:37.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_mq.c 2006-09-01 21:03:49.000000000 +0200
@@ -121,7 +121,7 @@
}
}
-
+#if 0
u32 c2_mq_count(struct c2_mq *q)
{
s32 count;
@@ -138,6 +138,7 @@
return (u32) count;
}
+#endif /* 0 */
void c2_mq_req_init(struct c2_mq *q, u32 index, u32 q_size, u32 msg_size,
u8 __iomem *pool_start, u16 __iomem *peer, u32 type)
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_qp.c.old 2006-09-01 21:04:06.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_qp.c 2006-09-01 21:04:22.000000000 +0200
@@ -75,7 +75,7 @@
}
}
-int to_ib_state(enum c2_qp_state c2_state)
+static int to_ib_state(enum c2_qp_state c2_state)
{
switch (c2_state) {
case C2_QP_STATE_IDLE:
@@ -95,7 +95,7 @@
}
}
-const char *to_ib_state_str(int ib_state)
+static const char *to_ib_state_str(int ib_state)
{
static const char *state_str[] = {
"IB_QPS_RESET",
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.h.old 2006-09-01 21:04:49.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2.h 2006-09-01 21:04:54.000000000 +0200
@@ -485,7 +485,6 @@
extern int c2_rnic_init(struct c2_dev *c2dev);
extern void c2_rnic_term(struct c2_dev *c2dev);
extern void c2_rnic_interrupt(struct c2_dev *c2dev);
-extern int c2_rnic_query(struct c2_dev *c2dev, struct ib_device_attr *props);
extern int c2_del_addr(struct c2_dev *c2dev, u32 inaddr, u32 inmask);
extern int c2_add_addr(struct c2_dev *c2dev, u32 inaddr, u32 inmask);
--- linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_rnic.c.old 2006-09-01 21:05:03.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/infiniband/hw/amso1100/c2_rnic.c 2006-09-01 21:05:17.000000000 +0200
@@ -118,8 +118,7 @@
/*
* Query the adapter
*/
-int c2_rnic_query(struct c2_dev *c2dev,
- struct ib_device_attr *props)
+static int c2_rnic_query(struct c2_dev *c2dev, struct ib_device_attr *props)
{
struct c2_vq_req *vq_req;
struct c2wr_rnic_query_req wr;
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] make fs/lockd/host.c:nlm_lookup_host() static
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (14 preceding siblings ...)
2006-09-04 17:03 ` [-mm patch] drivers/infiniband/hw/amso1100/: possible cleanups Adrian Bunk
@ 2006-09-04 17:03 ` Adrian Bunk
2006-09-04 17:04 ` 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error Adrian Bunk
` (14 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 17:03 UTC (permalink / raw)
To: Andrew Morton, Olaf Kirch, Neil Brown; +Cc: linux-kernel, nfs
On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +knfsd-hide-use-of-lockds-h_monitored-flag.patch
> +knfsd-consolidate-common-code-for-statd-lockd-notification.patch
> +knfsd-when-looking-up-a-lockd-host-pass-hostname-length.patch
> +knfsd-lockd-introduce-nsm_handle.patch
> +knfsd-misc-minor-fixes-indentation-changes.patch
> +knfsd-lockd-make-nlm_host_rebooted-use-the-nsm_handle.patch
> +knfsd-lockd-make-the-nsm-upcalls-use-the-nsm_handle.patch
> +knfsd-lockd-make-the-hash-chains-use-a-hlist_node.patch
> +knfsd-lockd-change-list-of-blocked-list-to-list_node.patch
> +knfsd-change-nlm_file-to-use-a-hlist.patch
> +knfsd-lockd-make-nlm_traverse_-more-flexible.patch
> +knfsd-lockd-add-nlm_destroy_host.patch
> +knfsd-simplify-nlmsvc_invalidate_all.patch
> +knfsd-lockd-optionally-use-hostnames-for-identifying-peers.patch
> +knfsd-make-nlmclnt_next_cookie-smp-safe.patch
> +knfsd-match-granted_res-replies-using-cookies.patch
> +knfsd-export-nsm_local_state-to-user-space-via-sysctl.patch
> +knfsd-lockd-fix-use-of-h_nextrebind.patch
> +knfsd-register-all-rpc-programs-with-portmapper-by-default.patch
>
> nfsd updates.
>...
nlm_lookup_host() can now become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
fs/lockd/host.c | 48 ++++++++++++++++++------------------
include/linux/lockd/lockd.h | 1
2 files changed, 24 insertions(+), 25 deletions(-)
--- linux-2.6.18-rc5-mm1/include/linux/lockd/lockd.h.old 2006-09-01 20:57:28.000000000 +0200
+++ linux-2.6.18-rc5-mm1/include/linux/lockd/lockd.h 2006-09-01 20:57:34.000000000 +0200
@@ -164,7 +164,6 @@
*/
struct nlm_host * nlmclnt_lookup_host(const struct sockaddr_in *, int, int, const char *, int);
struct nlm_host * nlmsvc_lookup_host(struct svc_rqst *, const char *, int);
-struct nlm_host * nlm_lookup_host(int server, const struct sockaddr_in *, int, int, const char *, int);
struct rpc_clnt * nlm_bind_host(struct nlm_host *);
void nlm_rebind_host(struct nlm_host *);
struct nlm_host * nlm_get_host(struct nlm_host *);
--- linux-2.6.18-rc5-mm1/fs/lockd/host.c.old 2006-09-01 20:57:42.000000000 +0200
+++ linux-2.6.18-rc5-mm1/fs/lockd/host.c 2006-09-01 20:58:25.000000000 +0200
@@ -38,32 +38,9 @@
const char *, int, int);
/*
- * Find an NLM server handle in the cache. If there is none, create it.
- */
-struct nlm_host *
-nlmclnt_lookup_host(const struct sockaddr_in *sin, int proto, int version,
- const char *hostname, int hostname_len)
-{
- return nlm_lookup_host(0, sin, proto, version,
- hostname, hostname_len);
-}
-
-/*
- * Find an NLM client handle in the cache. If there is none, create it.
- */
-struct nlm_host *
-nlmsvc_lookup_host(struct svc_rqst *rqstp,
- const char *hostname, int hostname_len)
-{
- return nlm_lookup_host(1, &rqstp->rq_addr,
- rqstp->rq_prot, rqstp->rq_vers,
- hostname, hostname_len);
-}
-
-/*
* Common host lookup routine for server & client
*/
-struct nlm_host *
+static struct nlm_host *
nlm_lookup_host(int server, const struct sockaddr_in *sin,
int proto, int version,
const char *hostname,
@@ -165,6 +142,29 @@
}
/*
+ * Find an NLM server handle in the cache. If there is none, create it.
+ */
+struct nlm_host *
+nlmclnt_lookup_host(const struct sockaddr_in *sin, int proto, int version,
+ const char *hostname, int hostname_len)
+{
+ return nlm_lookup_host(0, sin, proto, version,
+ hostname, hostname_len);
+}
+
+/*
+ * Find an NLM client handle in the cache. If there is none, create it.
+ */
+struct nlm_host *
+nlmsvc_lookup_host(struct svc_rqst *rqstp,
+ const char *hostname, int hostname_len)
+{
+ return nlm_lookup_host(1, &rqstp->rq_addr,
+ rqstp->rq_prot, rqstp->rq_vers,
+ hostname, hostname_len);
+}
+
+/*
* Destroy a host
*/
static void
^ permalink raw reply [flat|nested] 138+ messages in thread* 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (15 preceding siblings ...)
2006-09-04 17:03 ` [-mm patch] make fs/lockd/host.c:nlm_lookup_host() static Adrian Bunk
@ 2006-09-04 17:04 ` Adrian Bunk
2006-09-04 19:04 ` Andrew Morton
2006-09-04 17:04 ` [-mm patch] fix kernel_execve() related compile errors Adrian Bunk
` (13 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 17:04 UTC (permalink / raw)
To: Andrew Morton, Greg Banks; +Cc: linux-kernel
cpumask-add-highest_possible_node_id.patch causes the following compile
error with CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n
(and CONFIG_SUNRPC=y):
<-- snip -->
...
LD vmlinux
net/built-in.o: In function `svc_create_pooled':
(.text+0x675fc): undefined reference to `highest_possible_node_id'
net/built-in.o: In function `svc_create_pooled':
(.text+0x675fc): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `highest_possible_node_id'
make[1]: *** [vmlinux] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error
2006-09-04 17:04 ` 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error Adrian Bunk
@ 2006-09-04 19:04 ` Andrew Morton
2006-09-04 19:24 ` Adrian Bunk
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-04 19:04 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Greg Banks, linux-kernel
On Mon, 4 Sep 2006 19:04:11 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> cpumask-add-highest_possible_node_id.patch causes the following compile
> error with CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n
> (and CONFIG_SUNRPC=y):
>
> <-- snip -->
>
> ...
> LD vmlinux
> net/built-in.o: In function `svc_create_pooled':
> (.text+0x675fc): undefined reference to `highest_possible_node_id'
> net/built-in.o: In function `svc_create_pooled':
> (.text+0x675fc): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `highest_possible_node_id'
> make[1]: *** [vmlinux] Error 1
On m32r?
If so, could it be a binutils or m32r bug?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error
2006-09-04 19:04 ` Andrew Morton
@ 2006-09-04 19:24 ` Adrian Bunk
0 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 19:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: Greg Banks, linux-kernel
On Mon, Sep 04, 2006 at 12:04:30PM -0700, Andrew Morton wrote:
> On Mon, 4 Sep 2006 19:04:11 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > cpumask-add-highest_possible_node_id.patch causes the following compile
> > error with CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n
> > (and CONFIG_SUNRPC=y):
> >
> > <-- snip -->
> >
> > ...
> > LD vmlinux
> > net/built-in.o: In function `svc_create_pooled':
> > (.text+0x675fc): undefined reference to `highest_possible_node_id'
> > net/built-in.o: In function `svc_create_pooled':
> > (.text+0x675fc): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `highest_possible_node_id'
> > make[1]: *** [vmlinux] Error 1
>
> On m32r?
>
> If so, could it be a binutils or m32r bug?
No, it is a kernel bug (don't be confused by the second message, the
first one describes the bug).
The problem is simple:
- net/sunrpc/svc.c uses highest_possible_node_id()
- include/linux/nodemask.h says highest_possible_node_id() is
out-of-line #if MAX_NUMNODES > 1
- the out-of-line highest_possible_node_id() is in lib/cpumask.c
- lib/Makefile: lib-$(CONFIG_SMP) += cpumask.o
CONFIG_ARCH_DISCONTIGMEM_ENABLE=y, CONFIG_SMP=n, CONFIG_SUNRPC=y
-> highest_possible_node_id() is used in net/sunrpc/svc.c
CONFIG_NODES_SHIFT defined and > 0
-> include/linux/numa.h: MAX_NUMNODES > 1
-> compile error
The bug is not present on architectures where ARCH_DISCONTIGMEM_ENABLE
depends on NUMA (but m32r isn't the only affected architecture).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 138+ messages in thread
* [-mm patch] fix kernel_execve() related compile errors
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (16 preceding siblings ...)
2006-09-04 17:04 ` 2.6.18-rc5-mm1: ARCH_DISCONTIGMEM_ENABLE=y, SMP=n compile error Adrian Bunk
@ 2006-09-04 17:04 ` Adrian Bunk
2006-09-04 17:04 ` [-mm patch] lib/ioremap.c must #include <linux/mm.h> Adrian Bunk
` (12 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 17:04 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann; +Cc: linux-kernel
On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +rename-the-provided-execve-functions-to-kernel_execve.patch
>...
> kernel syscalls cleanup
>...
This patch fixes some typos causing compile errors.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/arm/kernel/sys_arm.c | 2 +-
arch/arm26/kernel/sys_arm.c | 2 +-
arch/parisc/kernel/process.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.18-rc5-mm1/arch/arm/kernel/sys_arm.c.old 2006-09-03 23:32:16.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/arm/kernel/sys_arm.c 2006-09-03 23:32:24.000000000 +0200
@@ -279,7 +279,7 @@
return error;
}
-int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
+int kernel_execve(const char *filename, char *const argv[], char *const envp[])
{
struct pt_regs regs;
int ret;
--- linux-2.6.18-rc5-mm1/arch/arm26/kernel/sys_arm.c.old 2006-09-03 23:32:31.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/arm26/kernel/sys_arm.c 2006-09-03 23:32:37.000000000 +0200
@@ -283,7 +283,7 @@
}
/* FIXME - see if this is correct for arm26 */
-int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
+int kernel_execve(const char *filename, char *const argv[], char *const envp[])
{
struct pt_regs regs;
int ret;
--- linux-2.6.18-rc5-mm1/arch/parisc/kernel/process.c.old 2006-09-03 23:32:45.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/parisc/kernel/process.c 2006-09-03 23:32:50.000000000 +0200
@@ -370,7 +370,7 @@
extern int __execve(const char *filename, char *const argv[],
char *const envp[], struct task_struct *task);
-int kernel_execve(const char *filename, char *const argv[], char *const envp[]);
+int kernel_execve(const char *filename, char *const argv[], char *const envp[])
{
return __execve(filename, argv, envp, current);
}
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] lib/ioremap.c must #include <linux/mm.h>
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (17 preceding siblings ...)
2006-09-04 17:04 ` [-mm patch] fix kernel_execve() related compile errors Adrian Bunk
@ 2006-09-04 17:04 ` Adrian Bunk
2006-09-04 18:41 ` [-mm patch] mm/memory_hotplug.c must #include <linux/cpuset.h> Adrian Bunk
` (11 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 17:04 UTC (permalink / raw)
To: Andrew Morton, Haavard Skinnemoen; +Cc: linux-kernel
generic-ioremap_page_range-implementation.patch causes the following
compile error with -Werror-implicit-function-declaration on ia64:
<-- snip -->
CC lib/ioremap.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c: In function 'ioremap_pte_range':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:21: error: implicit declaration of function 'pte_alloc_kernel'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:21: warning: assignment makes pointer from integer without a cast
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c: In function 'ioremap_pmd_range':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:39: error: implicit declaration of function 'pmd_alloc'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:39: warning: assignment makes pointer from integer without a cast
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c: In function 'ioremap_pud_range':
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:57: error: implicit declaration of function 'pud_alloc'
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/lib/ioremap.c:57: warning: assignment makes pointer from integer without a cast
make[2]: *** [lib/ioremap.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc5-mm1/lib/ioremap.c.old 2006-09-04 02:01:22.000000000 +0200
+++ linux-2.6.18-rc5-mm1/lib/ioremap.c 2006-09-04 02:01:32.000000000 +0200
@@ -7,6 +7,7 @@
*/
#include <linux/io.h>
#include <linux/vmalloc.h>
+#include <linux/mm.h>
#include <asm/cacheflush.h>
#include <asm/pgtable.h>
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] mm/memory_hotplug.c must #include <linux/cpuset.h>
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (18 preceding siblings ...)
2006-09-04 17:04 ` [-mm patch] lib/ioremap.c must #include <linux/mm.h> Adrian Bunk
@ 2006-09-04 18:41 ` Adrian Bunk
2006-09-04 22:17 ` [-mm patch] arch/m68knommu/kernel/sys_m68k.c must #include <asm/unistd.h> Adrian Bunk
` (10 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 18:41 UTC (permalink / raw)
To: Andrew Morton, Paul Jackson; +Cc: linux-kernel
This patch fixes the following compile error:
<-- snip -->
...
CC mm/memory_hotplug.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/memory_hotplug.c: In function ‘add_memory’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/mm/memory_hotplug.c:286: error: implicit declaration of function ‘cpuset_track_online_nodes’
make[2]: *** [mm/memory_hotplug.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc5-mm1/mm/memory_hotplug.c.old 2006-09-04 20:23:30.000000000 +0200
+++ linux-2.6.18-rc5-mm1/mm/memory_hotplug.c 2006-09-04 20:23:48.000000000 +0200
@@ -22,6 +22,7 @@
#include <linux/highmem.h>
#include <linux/vmalloc.h>
#include <linux/ioport.h>
+#include <linux/cpuset.h>
#include <asm/tlbflush.h>
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] arch/m68knommu/kernel/sys_m68k.c must #include <asm/unistd.h>
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (19 preceding siblings ...)
2006-09-04 18:41 ` [-mm patch] mm/memory_hotplug.c must #include <linux/cpuset.h> Adrian Bunk
@ 2006-09-04 22:17 ` Adrian Bunk
2006-09-05 13:03 ` lockdep oddity Heiko Carstens
` (9 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-04 22:17 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann; +Cc: linux-kernel, gerg
On Fri, Sep 01, 2006 at 01:58:18AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm3:
>...
> +provide-kernel_execve-on-all-architectures.patch
>...
> kernel syscalls cleanup
>...
This patch fixes the following compile error on m68knommu:
<-- snip -->
...
CC arch/m68knommu/kernel/sys_m68k.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c:215: error: '__NR_execve' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c:215: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c:215: error: for each function it appears in.)
make[2]: *** [arch/m68knommu/kernel/sys_m68k.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c.old 2006-09-05 00:16:11.000000000 +0200
+++ linux-2.6.18-rc5-mm1/arch/m68knommu/kernel/sys_m68k.c 2006-09-05 00:16:25.000000000 +0200
@@ -26,6 +26,7 @@
#include <asm/traps.h>
#include <asm/ipc.h>
#include <asm/cacheflush.h>
+#include <asm/unistd.h>
/*
* sys_pipe() is the normal C calling standard for creating
^ permalink raw reply [flat|nested] 138+ messages in thread* lockdep oddity
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (20 preceding siblings ...)
2006-09-04 22:17 ` [-mm patch] arch/m68knommu/kernel/sys_m68k.c must #include <asm/unistd.h> Adrian Bunk
@ 2006-09-05 13:03 ` Heiko Carstens
2006-09-05 18:12 ` Ingo Molnar
2006-09-05 20:07 ` Daniel Walker
2006-09-05 13:25 ` 2.6.18-rc5-mm1: {dis,en}able_irq_lockdep_irqrestore compile error Adrian Bunk
` (8 subsequent siblings)
30 siblings, 2 replies; 138+ messages in thread
From: Heiko Carstens @ 2006-09-05 13:03 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Ingo Molnar, Arjan van de Ven, Daniel Walker,
Hua Zhong
The lock validator gives me this (latest -mm and 2.6.18-rc6):
=====================================
[ BUG: bad unlock balance detected! ]
-------------------------------------
swapper/0 is trying to release lock (resource_lock) at:
[<0000000000042842>] request_resource+0x52/0x88
but there are no more locks to release!
The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c don't contain
any of the *_acquire calls, while all of the _unlock functions contain a
*_release call. Hence I get immediately unbalanced locks.
CONFIG_PREEMPT,
CONFIG_SMP,
!CONFIG_PROVE_LOCKING,
CONFIG_DEBUG_LOCK_ALLOC,
and
CONFIG_LOCKDEP
will generate this code.
Found this will debugging some random memory corruptions that happen when
CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
Switching both off or having only one of them on seems to work.
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: lockdep oddity
2006-09-05 13:03 ` lockdep oddity Heiko Carstens
@ 2006-09-05 18:12 ` Ingo Molnar
2006-09-05 18:57 ` Hua Zhong
` (2 more replies)
2006-09-05 20:07 ` Daniel Walker
1 sibling, 3 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-05 18:12 UTC (permalink / raw)
To: Heiko Carstens
Cc: Andrew Morton, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> The lock validator gives me this (latest -mm and 2.6.18-rc6):
>
> =====================================
> [ BUG: bad unlock balance detected! ]
> -------------------------------------
> swapper/0 is trying to release lock (resource_lock) at:
> [<0000000000042842>] request_resource+0x52/0x88
> but there are no more locks to release!
>
> The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c don't
> contain any of the *_acquire calls, while all of the _unlock functions
> contain a *_release call. Hence I get immediately unbalanced locks.
hmmm ... that sounds like a bug. Weird - i recently ran
PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
> Found this will debugging some random memory corruptions that happen
> when CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> Switching both off or having only one of them on seems to work.
previously i had some weirdnesses with PROFILE_LIKELY too, they were
caused by it generating cross-calls from within lockdep. Do the
corruptions go away if you remove all likely() and unlikely() markings
from kernel/lockdep.c?
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread* RE: lockdep oddity
2006-09-05 18:12 ` Ingo Molnar
@ 2006-09-05 18:57 ` Hua Zhong
2006-09-05 18:52 ` Ingo Molnar
2006-09-05 19:08 ` Ingo Molnar
2006-09-06 7:20 ` Heiko Carstens
2 siblings, 1 reply; 138+ messages in thread
From: Hua Zhong @ 2006-09-05 18:57 UTC (permalink / raw)
To: 'Ingo Molnar', 'Heiko Carstens'
Cc: 'Andrew Morton', linux-kernel, 'Arjan van de Ven',
'Daniel Walker'
Maybe we should define raw __likely/__unlikely which behave the same way as the vanilla and use them in places like spinlocks to
avoid these weird problems.
> * Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > The lock validator gives me this (latest -mm and 2.6.18-rc6):
> >
> > =====================================
> > [ BUG: bad unlock balance detected! ]
> > -------------------------------------
> > swapper/0 is trying to release lock (resource_lock) at:
> > [<0000000000042842>] request_resource+0x52/0x88 but there
> are no more
> > locks to release!
> >
> > The reason is that the BUILD_LOCK_OPS macros in
> kernel/lockdep.c don't
> > contain any of the *_acquire calls, while all of the
> _unlock functions
> > contain a *_release call. Hence I get immediately unbalanced locks.
>
> hmmm ... that sounds like a bug. Weird - i recently ran
> PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
>
> > Found this will debugging some random memory corruptions
> that happen
> > when CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
>
> previously i had some weirdnesses with PROFILE_LIKELY too,
> they were caused by it generating cross-calls from within
> lockdep. Do the corruptions go away if you remove all
> likely() and unlikely() markings from kernel/lockdep.c?
>
> Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-05 18:12 ` Ingo Molnar
2006-09-05 18:57 ` Hua Zhong
@ 2006-09-05 19:08 ` Ingo Molnar
2006-09-05 19:37 ` Ingo Molnar
2006-09-06 7:20 ` Heiko Carstens
2 siblings, 1 reply; 138+ messages in thread
From: Ingo Molnar @ 2006-09-05 19:08 UTC (permalink / raw)
To: Heiko Carstens
Cc: Andrew Morton, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
* Ingo Molnar <mingo@elte.hu> wrote:
> > The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c
> > don't contain any of the *_acquire calls, while all of the _unlock
> > functions contain a *_release call. Hence I get immediately
> > unbalanced locks.
>
> hmmm ... that sounds like a bug. Weird - i recently ran
> PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
ok, the reason i didnt find this problem is because this is fixed in my
tree, but i didnt realize that it's a fix also for upstream ...
The patch below is what is in my tree, but that needs separation from
other changes. I'll distill a patch for upstream.
Ingo
NOT-Signed-off-by: Ingo Molnar <mingo@elte.hu>
Index: linux/kernel/spinlock.c
===================================================================
--- linux.orig/kernel/spinlock.c
+++ linux/kernel/spinlock.c
@@ -20,14 +20,14 @@
* Generic declaration of the raw read_trylock() function,
* architectures are supposed to optimize this:
*/
-int __lockfunc generic__raw_read_trylock(raw_rwlock_t *lock)
+int __lockfunc generic_raw_read_trylock(raw_rwlock_t *lock)
{
- __raw_read_lock(lock);
+ _raw_read_lock(lock);
return 1;
}
-EXPORT_SYMBOL(generic__raw_read_trylock);
+EXPORT_SYMBOL(generic_raw_read_trylock);
-int __lockfunc _spin_trylock(spinlock_t *lock)
+int __lockfunc __spin_trylock(raw_spinlock_t *lock)
{
preempt_disable();
if (_raw_spin_trylock(lock)) {
@@ -38,9 +38,46 @@ int __lockfunc _spin_trylock(spinlock_t
preempt_enable();
return 0;
}
-EXPORT_SYMBOL(_spin_trylock);
+EXPORT_SYMBOL(__spin_trylock);
+
+int __lockfunc __spin_trylock_irq(raw_spinlock_t *lock)
+{
+ local_irq_disable();
+ preempt_disable();
+
+ if (_raw_spin_trylock(lock)) {
+ spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
+ return 1;
+ }
+
+ __preempt_enable_no_resched();
+ local_irq_enable();
+ preempt_check_resched();
+
+ return 0;
+}
+EXPORT_SYMBOL(__spin_trylock_irq);
-int __lockfunc _read_trylock(rwlock_t *lock)
+int __lockfunc __spin_trylock_irqsave(raw_spinlock_t *lock,
+ unsigned long *flags)
+{
+ local_irq_save(*flags);
+ preempt_disable();
+
+ if (_raw_spin_trylock(lock)) {
+ spin_acquire(&lock->dep_map, 0, 1, _RET_IP_);
+ return 1;
+ }
+
+ __preempt_enable_no_resched();
+ local_irq_restore(*flags);
+ preempt_check_resched();
+
+ return 0;
+}
+EXPORT_SYMBOL(__spin_trylock_irqsave);
+
+int __lockfunc __read_trylock(raw_rwlock_t *lock)
{
preempt_disable();
if (_raw_read_trylock(lock)) {
@@ -51,9 +88,9 @@ int __lockfunc _read_trylock(rwlock_t *l
preempt_enable();
return 0;
}
-EXPORT_SYMBOL(_read_trylock);
+EXPORT_SYMBOL(__read_trylock);
-int __lockfunc _write_trylock(rwlock_t *lock)
+int __lockfunc __write_trylock(raw_rwlock_t *lock)
{
preempt_disable();
if (_raw_write_trylock(lock)) {
@@ -64,7 +101,7 @@ int __lockfunc _write_trylock(rwlock_t *
preempt_enable();
return 0;
}
-EXPORT_SYMBOL(_write_trylock);
+EXPORT_SYMBOL(__write_trylock);
/*
* If lockdep is enabled then we use the non-preemption spin-ops
@@ -72,17 +109,17 @@ EXPORT_SYMBOL(_write_trylock);
* not re-enabled during lock-acquire (which the preempt-spin-ops do):
*/
#if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
- defined(CONFIG_PROVE_LOCKING)
+ defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_PREEMPT_RT)
-void __lockfunc _read_lock(rwlock_t *lock)
+void __lockfunc __read_lock(raw_rwlock_t *lock)
{
preempt_disable();
rwlock_acquire_read(&lock->dep_map, 0, 0, _RET_IP_);
_raw_read_lock(lock);
}
-EXPORT_SYMBOL(_read_lock);
+EXPORT_SYMBOL(__read_lock);
-unsigned long __lockfunc _spin_lock_irqsave(spinlock_t *lock)
+unsigned long __lockfunc __spin_lock_irqsave(raw_spinlock_t *lock)
{
unsigned long flags;
@@ -101,27 +138,27 @@ unsigned long __lockfunc _spin_lock_irqs
#endif
return flags;
}
-EXPORT_SYMBOL(_spin_lock_irqsave);
+EXPORT_SYMBOL(__spin_lock_irqsave);
-void __lockfunc _spin_lock_irq(spinlock_t *lock)
+void __lockfunc __spin_lock_irq(raw_spinlock_t *lock)
{
local_irq_disable();
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
_raw_spin_lock(lock);
}
-EXPORT_SYMBOL(_spin_lock_irq);
+EXPORT_SYMBOL(__spin_lock_irq);
-void __lockfunc _spin_lock_bh(spinlock_t *lock)
+void __lockfunc __spin_lock_bh(raw_spinlock_t *lock)
{
local_bh_disable();
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
_raw_spin_lock(lock);
}
-EXPORT_SYMBOL(_spin_lock_bh);
+EXPORT_SYMBOL(__spin_lock_bh);
-unsigned long __lockfunc _read_lock_irqsave(rwlock_t *lock)
+unsigned long __lockfunc __read_lock_irqsave(raw_rwlock_t *lock)
{
unsigned long flags;
@@ -131,27 +168,27 @@ unsigned long __lockfunc _read_lock_irqs
_raw_read_lock(lock);
return flags;
}
-EXPORT_SYMBOL(_read_lock_irqsave);
+EXPORT_SYMBOL(__read_lock_irqsave);
-void __lockfunc _read_lock_irq(rwlock_t *lock)
+void __lockfunc __read_lock_irq(raw_rwlock_t *lock)
{
local_irq_disable();
preempt_disable();
rwlock_acquire_read(&lock->dep_map, 0, 0, _RET_IP_);
_raw_read_lock(lock);
}
-EXPORT_SYMBOL(_read_lock_irq);
+EXPORT_SYMBOL(__read_lock_irq);
-void __lockfunc _read_lock_bh(rwlock_t *lock)
+void __lockfunc __read_lock_bh(raw_rwlock_t *lock)
{
local_bh_disable();
preempt_disable();
rwlock_acquire_read(&lock->dep_map, 0, 0, _RET_IP_);
_raw_read_lock(lock);
}
-EXPORT_SYMBOL(_read_lock_bh);
+EXPORT_SYMBOL(__read_lock_bh);
-unsigned long __lockfunc _write_lock_irqsave(rwlock_t *lock)
+unsigned long __lockfunc __write_lock_irqsave(raw_rwlock_t *lock)
{
unsigned long flags;
@@ -161,43 +198,43 @@ unsigned long __lockfunc _write_lock_irq
_raw_write_lock(lock);
return flags;
}
-EXPORT_SYMBOL(_write_lock_irqsave);
+EXPORT_SYMBOL(__write_lock_irqsave);
-void __lockfunc _write_lock_irq(rwlock_t *lock)
+void __lockfunc __write_lock_irq(raw_rwlock_t *lock)
{
local_irq_disable();
preempt_disable();
rwlock_acquire(&lock->dep_map, 0, 0, _RET_IP_);
_raw_write_lock(lock);
}
-EXPORT_SYMBOL(_write_lock_irq);
+EXPORT_SYMBOL(__write_lock_irq);
-void __lockfunc _write_lock_bh(rwlock_t *lock)
+void __lockfunc __write_lock_bh(raw_rwlock_t *lock)
{
local_bh_disable();
preempt_disable();
rwlock_acquire(&lock->dep_map, 0, 0, _RET_IP_);
_raw_write_lock(lock);
}
-EXPORT_SYMBOL(_write_lock_bh);
+EXPORT_SYMBOL(__write_lock_bh);
-void __lockfunc _spin_lock(spinlock_t *lock)
+void __lockfunc __spin_lock(raw_spinlock_t *lock)
{
preempt_disable();
spin_acquire(&lock->dep_map, 0, 0, _RET_IP_);
_raw_spin_lock(lock);
}
-EXPORT_SYMBOL(_spin_lock);
+EXPORT_SYMBOL(__spin_lock);
-void __lockfunc _write_lock(rwlock_t *lock)
+void __lockfunc __write_lock(raw_rwlock_t *lock)
{
preempt_disable();
rwlock_acquire(&lock->dep_map, 0, 0, _RET_IP_);
_raw_write_lock(lock);
}
-EXPORT_SYMBOL(_write_lock);
+EXPORT_SYMBOL(__write_lock);
#else /* CONFIG_PREEMPT: */
@@ -210,7 +247,7 @@ EXPORT_SYMBOL(_write_lock);
*/
#define BUILD_LOCK_OPS(op, locktype) \
-void __lockfunc _##op##_lock(locktype##_t *lock) \
+void __lockfunc __##op##_lock(locktype##_t *lock) \
{ \
for (;;) { \
preempt_disable(); \
@@ -220,15 +257,16 @@ void __lockfunc _##op##_lock(locktype##_
\
if (!(lock)->break_lock) \
(lock)->break_lock = 1; \
- while (!op##_can_lock(lock) && (lock)->break_lock) \
+ while (!__raw_##op##_can_lock(&(lock)->raw_lock) && \
+ (lock)->break_lock) \
cpu_relax(); \
} \
(lock)->break_lock = 0; \
} \
\
-EXPORT_SYMBOL(_##op##_lock); \
+EXPORT_SYMBOL(__##op##_lock); \
\
-unsigned long __lockfunc _##op##_lock_irqsave(locktype##_t *lock) \
+unsigned long __lockfunc __##op##_lock_irqsave(locktype##_t *lock) \
{ \
unsigned long flags; \
\
@@ -242,23 +280,24 @@ unsigned long __lockfunc _##op##_lock_ir
\
if (!(lock)->break_lock) \
(lock)->break_lock = 1; \
- while (!op##_can_lock(lock) && (lock)->break_lock) \
+ while (!__raw_##op##_can_lock(&(lock)->raw_lock) && \
+ (lock)->break_lock) \
cpu_relax(); \
} \
(lock)->break_lock = 0; \
return flags; \
} \
\
-EXPORT_SYMBOL(_##op##_lock_irqsave); \
+EXPORT_SYMBOL(__##op##_lock_irqsave); \
\
-void __lockfunc _##op##_lock_irq(locktype##_t *lock) \
+void __lockfunc __##op##_lock_irq(locktype##_t *lock) \
{ \
- _##op##_lock_irqsave(lock); \
+ __##op##_lock_irqsave(lock); \
} \
\
-EXPORT_SYMBOL(_##op##_lock_irq); \
+EXPORT_SYMBOL(__##op##_lock_irq); \
\
-void __lockfunc _##op##_lock_bh(locktype##_t *lock) \
+void __lockfunc __##op##_lock_bh(locktype##_t *lock) \
{ \
unsigned long flags; \
\
@@ -267,147 +306,161 @@ void __lockfunc _##op##_lock_bh(locktype
/* irq-disabling. We use the generic preemption-aware */ \
/* function: */ \
/**/ \
- flags = _##op##_lock_irqsave(lock); \
+ flags = __##op##_lock_irqsave(lock); \
local_bh_disable(); \
local_irq_restore(flags); \
} \
\
-EXPORT_SYMBOL(_##op##_lock_bh)
+EXPORT_SYMBOL(__##op##_lock_bh)
/*
* Build preemption-friendly versions of the following
* lock-spinning functions:
*
- * _[spin|read|write]_lock()
- * _[spin|read|write]_lock_irq()
- * _[spin|read|write]_lock_irqsave()
- * _[spin|read|write]_lock_bh()
+ * __[spin|read|write]_lock()
+ * __[spin|read|write]_lock_irq()
+ * __[spin|read|write]_lock_irqsave()
+ * __[spin|read|write]_lock_bh()
*/
-BUILD_LOCK_OPS(spin, spinlock);
-BUILD_LOCK_OPS(read, rwlock);
-BUILD_LOCK_OPS(write, rwlock);
+BUILD_LOCK_OPS(spin, raw_spinlock);
+BUILD_LOCK_OPS(read, raw_rwlock);
+BUILD_LOCK_OPS(write, raw_rwlock);
#endif /* CONFIG_PREEMPT */
#ifdef CONFIG_DEBUG_LOCK_ALLOC
-void __lockfunc _spin_lock_nested(spinlock_t *lock, int subclass)
+void __lockfunc __spin_lock_nested(raw_spinlock_t *lock, int subclass)
{
preempt_disable();
spin_acquire(&lock->dep_map, subclass, 0, _RET_IP_);
_raw_spin_lock(lock);
}
-EXPORT_SYMBOL(_spin_lock_nested);
+EXPORT_SYMBOL(__spin_lock_nested);
#endif
-void __lockfunc _spin_unlock(spinlock_t *lock)
+void __lockfunc __spin_unlock(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
_raw_spin_unlock(lock);
preempt_enable();
}
-EXPORT_SYMBOL(_spin_unlock);
+EXPORT_SYMBOL(__spin_unlock);
-void __lockfunc _write_unlock(rwlock_t *lock)
+void __lockfunc __spin_unlock_no_resched(raw_spinlock_t *lock)
+{
+ spin_release(&lock->dep_map, 1, _RET_IP_);
+ _raw_spin_unlock(lock);
+ __preempt_enable_no_resched();
+}
+/* not exported */
+
+void __lockfunc __write_unlock(raw_rwlock_t *lock)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_write_unlock(lock);
preempt_enable();
}
-EXPORT_SYMBOL(_write_unlock);
+EXPORT_SYMBOL(__write_unlock);
-void __lockfunc _read_unlock(rwlock_t *lock)
+void __lockfunc __read_unlock(raw_rwlock_t *lock)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_read_unlock(lock);
preempt_enable();
}
-EXPORT_SYMBOL(_read_unlock);
+EXPORT_SYMBOL(__read_unlock);
-void __lockfunc _spin_unlock_irqrestore(spinlock_t *lock, unsigned long flags)
+void __lockfunc __spin_unlock_irqrestore(raw_spinlock_t *lock, unsigned long flags)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
_raw_spin_unlock(lock);
+ __preempt_enable_no_resched();
local_irq_restore(flags);
- preempt_enable();
+ preempt_check_resched();
}
-EXPORT_SYMBOL(_spin_unlock_irqrestore);
+EXPORT_SYMBOL(__spin_unlock_irqrestore);
-void __lockfunc _spin_unlock_irq(spinlock_t *lock)
+void __lockfunc __spin_unlock_irq(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
_raw_spin_unlock(lock);
+ __preempt_enable_no_resched();
local_irq_enable();
- preempt_enable();
+ preempt_check_resched();
}
-EXPORT_SYMBOL(_spin_unlock_irq);
+EXPORT_SYMBOL(__spin_unlock_irq);
-void __lockfunc _spin_unlock_bh(spinlock_t *lock)
+void __lockfunc __spin_unlock_bh(raw_spinlock_t *lock)
{
spin_release(&lock->dep_map, 1, _RET_IP_);
_raw_spin_unlock(lock);
- preempt_enable_no_resched();
+ __preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
}
-EXPORT_SYMBOL(_spin_unlock_bh);
+EXPORT_SYMBOL(__spin_unlock_bh);
-void __lockfunc _read_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
+void __lockfunc __read_unlock_irqrestore(raw_rwlock_t *lock, unsigned long flags)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_read_unlock(lock);
+ __preempt_enable_no_resched();
local_irq_restore(flags);
- preempt_enable();
+ preempt_check_resched();
}
-EXPORT_SYMBOL(_read_unlock_irqrestore);
+EXPORT_SYMBOL(__read_unlock_irqrestore);
-void __lockfunc _read_unlock_irq(rwlock_t *lock)
+void __lockfunc __read_unlock_irq(raw_rwlock_t *lock)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_read_unlock(lock);
+ __preempt_enable_no_resched();
local_irq_enable();
- preempt_enable();
+ preempt_check_resched();
}
-EXPORT_SYMBOL(_read_unlock_irq);
+EXPORT_SYMBOL(__read_unlock_irq);
-void __lockfunc _read_unlock_bh(rwlock_t *lock)
+void __lockfunc __read_unlock_bh(raw_rwlock_t *lock)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_read_unlock(lock);
- preempt_enable_no_resched();
+ __preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
}
-EXPORT_SYMBOL(_read_unlock_bh);
+EXPORT_SYMBOL(__read_unlock_bh);
-void __lockfunc _write_unlock_irqrestore(rwlock_t *lock, unsigned long flags)
+void __lockfunc __write_unlock_irqrestore(raw_rwlock_t *lock, unsigned long flags)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_write_unlock(lock);
+ __preempt_enable_no_resched();
local_irq_restore(flags);
- preempt_enable();
+ preempt_check_resched();
}
-EXPORT_SYMBOL(_write_unlock_irqrestore);
+EXPORT_SYMBOL(__write_unlock_irqrestore);
-void __lockfunc _write_unlock_irq(rwlock_t *lock)
+void __lockfunc __write_unlock_irq(raw_rwlock_t *lock)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_write_unlock(lock);
+ __preempt_enable_no_resched();
local_irq_enable();
- preempt_enable();
+ preempt_check_resched();
}
-EXPORT_SYMBOL(_write_unlock_irq);
+EXPORT_SYMBOL(__write_unlock_irq);
-void __lockfunc _write_unlock_bh(rwlock_t *lock)
+void __lockfunc __write_unlock_bh(raw_rwlock_t *lock)
{
rwlock_release(&lock->dep_map, 1, _RET_IP_);
_raw_write_unlock(lock);
- preempt_enable_no_resched();
+ __preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
}
-EXPORT_SYMBOL(_write_unlock_bh);
+EXPORT_SYMBOL(__write_unlock_bh);
-int __lockfunc _spin_trylock_bh(spinlock_t *lock)
+int __lockfunc __spin_trylock_bh(raw_spinlock_t *lock)
{
local_bh_disable();
preempt_disable();
@@ -416,13 +469,13 @@ int __lockfunc _spin_trylock_bh(spinlock
return 1;
}
- preempt_enable_no_resched();
+ __preempt_enable_no_resched();
local_bh_enable_ip((unsigned long)__builtin_return_address(0));
return 0;
}
-EXPORT_SYMBOL(_spin_trylock_bh);
+EXPORT_SYMBOL(__spin_trylock_bh);
-int in_lock_functions(unsigned long addr)
+int in_lock_functions(unsigned long addr)
{
/* Linker adds these: start and end of __lockfunc functions */
extern char __lock_text_start[], __lock_text_end[];
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: lockdep oddity
2006-09-05 19:08 ` Ingo Molnar
@ 2006-09-05 19:37 ` Ingo Molnar
2006-09-06 6:54 ` Heiko Carstens
0 siblings, 1 reply; 138+ messages in thread
From: Ingo Molnar @ 2006-09-05 19:37 UTC (permalink / raw)
To: Heiko Carstens
Cc: Andrew Morton, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
* Ingo Molnar <mingo@elte.hu> wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
>
> > > The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c
> > > don't contain any of the *_acquire calls, while all of the _unlock
> > > functions contain a *_release call. Hence I get immediately
> > > unbalanced locks.
> >
> > hmmm ... that sounds like a bug. Weird - i recently ran
> > PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
>
> ok, the reason i didnt find this problem is because this is fixed in
> my tree, but i didnt realize that it's a fix also for upstream ...
actually ... it works fine in the upstream kernel due to this:
* If lockdep is enabled then we use the non-preemption spin-ops
* even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
* not re-enabled during lock-acquire (which the preempt-spin-ops do):
*/
#if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
defined(CONFIG_DEBUG_LOCK_ALLOC)
so i'm wondering, how did you you manage to get into the
BUILD_LOCK_OPS() branch?
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: lockdep oddity
2006-09-05 19:37 ` Ingo Molnar
@ 2006-09-06 6:54 ` Heiko Carstens
2006-09-06 10:05 ` Ingo Molnar
0 siblings, 1 reply; 138+ messages in thread
From: Heiko Carstens @ 2006-09-06 6:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
> > > > The reason is that the BUILD_LOCK_OPS macros in kernel/lockdep.c
> > > > don't contain any of the *_acquire calls, while all of the _unlock
> > > > functions contain a *_release call. Hence I get immediately
> > > > unbalanced locks.
> > >
> > > hmmm ... that sounds like a bug. Weird - i recently ran
> > > PREEMPT+SMP+LOCKDEP kernels and didnt notice this.
> >
> > ok, the reason i didnt find this problem is because this is fixed in
> > my tree, but i didnt realize that it's a fix also for upstream ...
>
> actually ... it works fine in the upstream kernel due to this:
>
> * If lockdep is enabled then we use the non-preemption spin-ops
> * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
> * not re-enabled during lock-acquire (which the preempt-spin-ops do):
> */
> #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
> defined(CONFIG_DEBUG_LOCK_ALLOC)
>
> so i'm wondering, how did you you manage to get into the
> BUILD_LOCK_OPS() branch?
That seems to be code that isn't upstream. 2.6.18-rc5-mm1 as well as
Linus' current git tree have this:
/*
* If lockdep is enabled then we use the non-preemption spin-ops
* even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
* not re-enabled during lock-acquire (which the preempt-spin-ops do):
*/
#if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
defined(CONFIG_PROVE_LOCKING)
And yes, using CONFIG_DEBUG_LOCK_ALLOC instead of CONFIG_PROVE_LOCKING fixes
this for me :)
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: lockdep oddity
2006-09-06 6:54 ` Heiko Carstens
@ 2006-09-06 10:05 ` Ingo Molnar
0 siblings, 0 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-06 10:05 UTC (permalink / raw)
To: Heiko Carstens
Cc: Andrew Morton, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> That seems to be code that isn't upstream. 2.6.18-rc5-mm1 as well as
> Linus' current git tree have this:
>
> /*
> * If lockdep is enabled then we use the non-preemption spin-ops
> * even on CONFIG_PREEMPT, because lockdep assumes that interrupts are
> * not re-enabled during lock-acquire (which the preempt-spin-ops do):
> */
> #if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
> defined(CONFIG_PROVE_LOCKING)
>
> And yes, using CONFIG_DEBUG_LOCK_ALLOC instead of CONFIG_PROVE_LOCKING
> fixes this for me :)
indeed, this is a very recent fix from Jarek Poplawski - not yet in
Linus' tree but already in Andrew's.
Ingo
---------->
From: Jarek Poplawski <jarkao2@o2.pl>
With
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not set
spin_unlock_irqrestore() goes through lockdep but spin_lock_irqsave() doesn't.
Apparently, bad things happen.
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
kernel/spinlock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/spinlock.c~lockdep-ifdef-fix kernel/spinlock.c
--- a/kernel/spinlock.c~lockdep-ifdef-fix
+++ a/kernel/spinlock.c
@@ -72,7 +72,7 @@ EXPORT_SYMBOL(_write_trylock);
* not re-enabled during lock-acquire (which the preempt-spin-ops do):
*/
#if !defined(CONFIG_PREEMPT) || !defined(CONFIG_SMP) || \
- defined(CONFIG_PROVE_LOCKING)
+ defined(CONFIG_DEBUG_LOCK_ALLOC)
void __lockfunc _read_lock(rwlock_t *lock)
{
_
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-05 18:12 ` Ingo Molnar
2006-09-05 18:57 ` Hua Zhong
2006-09-05 19:08 ` Ingo Molnar
@ 2006-09-06 7:20 ` Heiko Carstens
2006-09-06 7:47 ` Andrew Morton
2 siblings, 1 reply; 138+ messages in thread
From: Heiko Carstens @ 2006-09-06 7:20 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
> > Found this will debugging some random memory corruptions that happen
> > when CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
>
> previously i had some weirdnesses with PROFILE_LIKELY too, they were
> caused by it generating cross-calls from within lockdep. Do the
> corruptions go away if you remove all likely() and unlikely() markings
> from kernel/lockdep.c?
No, unfortunately that doesn't help. I'm also wondering why the profile
patch contains this:
+ if (ret)
+ likeliness->count[1]++;
+ else
+ likeliness->count[0]++;
This isn't smp safe. Is that on purpose or a bug?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-06 7:20 ` Heiko Carstens
@ 2006-09-06 7:47 ` Andrew Morton
2006-09-06 8:01 ` Heiko Carstens
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-06 7:47 UTC (permalink / raw)
To: Heiko Carstens
Cc: Ingo Molnar, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
On Wed, 6 Sep 2006 09:20:43 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> I'm also wondering why the profile
> patch contains this:
>
> + if (ret)
> + likeliness->count[1]++;
> + else
> + likeliness->count[0]++;
>
> This isn't smp safe. Is that on purpose or a bug?
Purposeful. This is called from all contexts, including NMI.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-06 7:47 ` Andrew Morton
@ 2006-09-06 8:01 ` Heiko Carstens
2006-09-06 8:23 ` Hua Zhong
0 siblings, 1 reply; 138+ messages in thread
From: Heiko Carstens @ 2006-09-06 8:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Ingo Molnar, linux-kernel, Arjan van de Ven, Daniel Walker,
Hua Zhong
On Wed, Sep 06, 2006 at 12:47:24AM -0700, Andrew Morton wrote:
> On Wed, 6 Sep 2006 09:20:43 +0200
> Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> > I'm also wondering why the profile
> > patch contains this:
> >
> > + if (ret)
> > + likeliness->count[1]++;
> > + else
> > + likeliness->count[0]++;
> >
> > This isn't smp safe. Is that on purpose or a bug?
>
> Purposeful. This is called from all contexts, including NMI.
Why not use atomic_inc then? Or is there some architecture dependent
limitation that it can't be done in every context?
^ permalink raw reply [flat|nested] 138+ messages in thread
* RE: lockdep oddity
2006-09-06 8:01 ` Heiko Carstens
@ 2006-09-06 8:23 ` Hua Zhong
2006-09-06 8:40 ` Ingo Molnar
0 siblings, 1 reply; 138+ messages in thread
From: Hua Zhong @ 2006-09-06 8:23 UTC (permalink / raw)
To: 'Heiko Carstens', 'Andrew Morton'
Cc: 'Ingo Molnar', linux-kernel, 'Arjan van de Ven',
'Daniel Walker'
We are just trading accuracy for speed here.
> On Wed, Sep 06, 2006 at 12:47:24AM -0700, Andrew Morton wrote:
> > On Wed, 6 Sep 2006 09:20:43 +0200
> > Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> >
> > > I'm also wondering why the profile
> > > patch contains this:
> > >
> > > + if (ret)
> > > + likeliness->count[1]++;
> > > + else
> > > + likeliness->count[0]++;
> > >
> > > This isn't smp safe. Is that on purpose or a bug?
> >
> > Purposeful. This is called from all contexts, including NMI.
>
> Why not use atomic_inc then? Or is there some architecture
> dependent limitation that it can't be done in every context?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-06 8:23 ` Hua Zhong
@ 2006-09-06 8:40 ` Ingo Molnar
2006-09-06 14:19 ` Daniel Walker
0 siblings, 1 reply; 138+ messages in thread
From: Ingo Molnar @ 2006-09-06 8:40 UTC (permalink / raw)
To: Hua Zhong
Cc: 'Heiko Carstens', 'Andrew Morton', linux-kernel,
'Arjan van de Ven', 'Daniel Walker'
* Hua Zhong <hzhong@gmail.com> wrote:
> We are just trading accuracy for speed here.
no, we are trading _both_ accuracy and speed here! a global 'likeliness'
pointer for commonly executed codepaths is causing global cacheline
ping-pongs - which is as bad as it gets.
the right approach, which incidentally would also be perfectly accurate,
is to store an alloc_percpu()-ed pointer at the call site, not the
counter itself.
the current code needs more work before it can go upstream i think.
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-06 8:40 ` Ingo Molnar
@ 2006-09-06 14:19 ` Daniel Walker
2006-09-06 14:29 ` Heiko Carstens
0 siblings, 1 reply; 138+ messages in thread
From: Daniel Walker @ 2006-09-06 14:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Hua Zhong, 'Heiko Carstens', 'Andrew Morton',
linux-kernel, 'Arjan van de Ven'
On Wed, 2006-09-06 at 10:40 +0200, Ingo Molnar wrote:
> * Hua Zhong <hzhong@gmail.com> wrote:
>
> > We are just trading accuracy for speed here.
>
> no, we are trading _both_ accuracy and speed here! a global 'likeliness'
> pointer for commonly executed codepaths is causing global cacheline
> ping-pongs - which is as bad as it gets.
Up stream or no, would be better for it to again be light weight.
> the right approach, which incidentally would also be perfectly accurate,
> is to store an alloc_percpu()-ed pointer at the call site, not the
> counter itself.
I don't think it could be done via the macro. If it were called during
run time it would have to be special alloc_percpu() that didn't call
back into the profiling code (which almost everything does do).
> the current code needs more work before it can go upstream i think.
It was never really planned to go upstream. It's ultimately a debugging
feature that's really only needed in -mm ..
Daniel
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-06 14:19 ` Daniel Walker
@ 2006-09-06 14:29 ` Heiko Carstens
2006-09-06 14:34 ` Daniel Walker
0 siblings, 1 reply; 138+ messages in thread
From: Heiko Carstens @ 2006-09-06 14:29 UTC (permalink / raw)
To: Daniel Walker
Cc: Ingo Molnar, Hua Zhong, 'Andrew Morton', linux-kernel,
'Arjan van de Ven'
On Wed, Sep 06, 2006 at 07:19:19AM -0700, Daniel Walker wrote:
> > the current code needs more work before it can go upstream i think.
>
> It was never really planned to go upstream. It's ultimately a debugging
> feature that's really only needed in -mm ..
And I thought the -mm tree was supposed to contain only code that will
go upstream sooner or later (unless it gets dropped for some reason).
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-06 14:29 ` Heiko Carstens
@ 2006-09-06 14:34 ` Daniel Walker
0 siblings, 0 replies; 138+ messages in thread
From: Daniel Walker @ 2006-09-06 14:34 UTC (permalink / raw)
To: Heiko Carstens
Cc: Ingo Molnar, Hua Zhong, 'Andrew Morton', linux-kernel,
'Arjan van de Ven'
On Wed, 2006-09-06 at 16:29 +0200, Heiko Carstens wrote:
> On Wed, Sep 06, 2006 at 07:19:19AM -0700, Daniel Walker wrote:
> > > the current code needs more work before it can go upstream i think.
> >
> > It was never really planned to go upstream. It's ultimately a debugging
> > feature that's really only needed in -mm ..
>
> And I thought the -mm tree was supposed to contain only code that will
> go upstream sooner or later (unless it gets dropped for some reason).
Nope .. There are other -mm only patches.
Daniel
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-05 13:03 ` lockdep oddity Heiko Carstens
2006-09-05 18:12 ` Ingo Molnar
@ 2006-09-05 20:07 ` Daniel Walker
2006-09-06 7:18 ` Heiko Carstens
2006-09-06 11:58 ` Heiko Carstens
1 sibling, 2 replies; 138+ messages in thread
From: Daniel Walker @ 2006-09-05 20:07 UTC (permalink / raw)
To: Heiko Carstens
Cc: Andrew Morton, linux-kernel, Ingo Molnar, Arjan van de Ven,
Hua Zhong
On Tue, 2006-09-05 at 15:03 +0200, Heiko Carstens wrote:
>
> Found this will debugging some random memory corruptions that happen when
> CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> Switching both off or having only one of them on seems to work.
There's potential for a some issues in current -mm , given the config
above. If you us the generic atomic operations
(asm-generic/bitops/atomic.h) for test_and_set_bit(). It eventually
calls into trace_hardirqs_off() and then back into likely profiling.
What architecture are you running this on?
Daniel
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-05 20:07 ` Daniel Walker
@ 2006-09-06 7:18 ` Heiko Carstens
2006-09-06 11:58 ` Heiko Carstens
1 sibling, 0 replies; 138+ messages in thread
From: Heiko Carstens @ 2006-09-06 7:18 UTC (permalink / raw)
To: Daniel Walker
Cc: Andrew Morton, linux-kernel, Ingo Molnar, Arjan van de Ven,
Hua Zhong
On Tue, Sep 05, 2006 at 01:07:47PM -0700, Daniel Walker wrote:
> On Tue, 2006-09-05 at 15:03 +0200, Heiko Carstens wrote:
> > Found this will debugging some random memory corruptions that happen when
> > CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
>
> There's potential for a some issues in current -mm , given the config
> above. If you us the generic atomic operations
> (asm-generic/bitops/atomic.h) for test_and_set_bit(). It eventually
> calls into trace_hardirqs_off() and then back into likely profiling.
>
> What architecture are you running this on?
This was s390. We have our own bitops and trace_hardirqs_off() won't
be called for test_and_set_bit(). Must be something different.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: lockdep oddity
2006-09-05 20:07 ` Daniel Walker
2006-09-06 7:18 ` Heiko Carstens
@ 2006-09-06 11:58 ` Heiko Carstens
1 sibling, 0 replies; 138+ messages in thread
From: Heiko Carstens @ 2006-09-06 11:58 UTC (permalink / raw)
To: Daniel Walker
Cc: Andrew Morton, linux-kernel, Ingo Molnar, Arjan van de Ven,
Hua Zhong
> > Found this will debugging some random memory corruptions that happen when
> > CONFIG_PROVE_LOCKING and CONFIG_PROFILE_LIKELY are both on.
> > Switching both off or having only one of them on seems to work.
> There's potential for a some issues in current -mm , given the config
> above. If you us the generic atomic operations
> (asm-generic/bitops/atomic.h) for test_and_set_bit(). It eventually
> calls into trace_hardirqs_off() and then back into likely profiling.
Your patch has this in it too:
/*
* We check for constant values with __builtin_constant_p() since
* it's not interesting to profile them, and there is a compiler
* bug in gcc 3.x which blows up during constant evalution when
* CONFIG_PROFILE_LIKELY is turned on.
*/
#define likely(x) (__builtin_constant_p(x) ? (!!(x)) : __check_likely((x), 1))
#define unlikely(x) (__builtin_constant_p(x) ? (!!(x)) : __check_likely((x), 0))
Could you define "blows up"? My reading of the text above is: "this code
below makes sure it does work with gcc 3.x as well".
Now I used gcc 3.4.1 and get random memory corruptions while with gcc 4.1.1
everything seems to be ok....
^ permalink raw reply [flat|nested] 138+ messages in thread
* 2.6.18-rc5-mm1: {dis,en}able_irq_lockdep_irqrestore compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (21 preceding siblings ...)
2006-09-05 13:03 ` lockdep oddity Heiko Carstens
@ 2006-09-05 13:25 ` Adrian Bunk
2006-09-05 15:21 ` [PATCH] FRV: Fix " David Howells
` (7 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-05 13:25 UTC (permalink / raw)
To: Andrew Morton, Arjan van de Ven
Cc: linux-kernel, Ingo Molnar, Jeff Garzik, netdev, David Howells
lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch causes
the following compile error on frv:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o: In function `ei_start_xmit':
8390.c:(.text+0x241c8): undefined reference to `disable_irq_nosync_lockdep_irqsave'
8390.c:(.text+0x242a0): undefined reference to `enable_irq_lockdep_irqrestore'
8390.c:(.text+0x2440c): undefined reference to `enable_irq_lockdep_irqrestore'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 138+ messages in thread* [PATCH] FRV: Fix {dis,en}able_irq_lockdep_irqrestore compile error
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (22 preceding siblings ...)
2006-09-05 13:25 ` 2.6.18-rc5-mm1: {dis,en}able_irq_lockdep_irqrestore compile error Adrian Bunk
@ 2006-09-05 15:21 ` David Howells
2006-09-06 12:50 ` Ingo Molnar
2006-09-05 15:27 ` [PATCH] NOMMU: Move the fallback arch_vma_name() to a sensible place David Howells
` (6 subsequent siblings)
30 siblings, 1 reply; 138+ messages in thread
From: David Howells @ 2006-09-05 15:21 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Arjan van de Ven, linux-kernel, Ingo Molnar,
Jeff Garzik, netdev, David Howells
Fix the lack of certain non-LOCKDEP stub functions in linux/interrupt.h and
also provide FRV with LOCKDEP variants.
This is to be applied to -mm kernel since not all of the functions added exist
in the main kernel.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 frv-irq-lockdep-2618rc5mm1.diff
include/asm-frv/irq.h | 43 +++++++++++++++++++++++++++++++++++++++++++
include/linux/interrupt.h | 2 ++
2 files changed, 45 insertions(+)
diff -urp ../kernels/linux-2.6.18-rc5-mm1/include/asm-frv/irq.h linux-2.6.18-rc5-mm1-frv/include/asm-frv/irq.h
--- ../kernels/linux-2.6.18-rc5-mm1/include/asm-frv/irq.h 2006-09-04 18:02:48.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/include/asm-frv/irq.h 2006-09-05 15:59:08.000000000 +0100
@@ -39,5 +39,48 @@ extern void disable_irq_nosync(unsigned
extern void disable_irq(unsigned int irq);
extern void enable_irq(unsigned int irq);
+#ifdef CONFIG_LOCKDEP
+/*
+ * Special lockdep variants of irq disabling/enabling.
+ * These should be used for locking constructs that
+ * know that a particular irq context which is disabled,
+ * and which is the only irq-context user of a lock,
+ * that it's safe to take the lock in the irq-disabled
+ * section without disabling hardirqs.
+ *
+ * On !CONFIG_LOCKDEP they are equivalent to the normal
+ * irq disable/enable methods.
+ */
+static inline void disable_irq_nosync_lockdep(unsigned int irq)
+{
+ disable_irq_nosync(irq);
+ local_irq_disable();
+}
+
+static inline void disable_irq_nosync_lockdep_irqsave(unsigned int irq, unsigned long *flags)
+{
+ disable_irq_nosync(irq);
+ local_irq_save(*flags);
+}
+
+static inline void disable_irq_lockdep(unsigned int irq)
+{
+ disable_irq(irq);
+ local_irq_disable();
+}
+
+static inline void enable_irq_lockdep(unsigned int irq)
+{
+ local_irq_enable();
+ enable_irq(irq);
+}
+
+static inline void enable_irq_lockdep_irqrestore(unsigned int irq, unsigned long *flags)
+{
+ local_irq_restore(*flags);
+ enable_irq(irq);
+}
+#endif /* CONFIG_LOCKDEP */
+
#endif /* _ASM_IRQ_H_ */
diff -urp ../kernels/linux-2.6.18-rc5-mm1/include/linux/interrupt.h linux-2.6.18-rc5-mm1-frv/include/linux/interrupt.h
--- ../kernels/linux-2.6.18-rc5-mm1/include/linux/interrupt.h 2006-09-04 18:03:31.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/include/linux/interrupt.h 2006-09-05 15:58:53.000000000 +0100
@@ -178,6 +178,8 @@ static inline int disable_irq_wake(unsig
# define disable_irq_nosync_lockdep(irq) disable_irq_nosync(irq)
# define disable_irq_lockdep(irq) disable_irq(irq)
# define enable_irq_lockdep(irq) enable_irq(irq)
+# define disable_irq_nosync_lockdep_irqsave(irq, flags) disable_irq_nosync(irq)
+# define enable_irq_lockdep_irqrestore(irq, flags) enable_irq(irq)
# endif
#endif /* CONFIG_GENERIC_HARDIRQS */
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: Fix {dis,en}able_irq_lockdep_irqrestore compile error
2006-09-05 15:21 ` [PATCH] FRV: Fix " David Howells
@ 2006-09-06 12:50 ` Ingo Molnar
0 siblings, 0 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-06 12:50 UTC (permalink / raw)
To: David Howells
Cc: Adrian Bunk, Andrew Morton, Arjan van de Ven, linux-kernel,
Jeff Garzik, netdev
* David Howells <dhowells@redhat.com> wrote:
> Fix the lack of certain non-LOCKDEP stub functions in
> linux/interrupt.h and also provide FRV with LOCKDEP variants.
>
> This is to be applied to -mm kernel since not all of the functions
> added exist in the main kernel.
>
> Signed-Off-By: David Howells <dhowells@redhat.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread
* [PATCH] NOMMU: Move the fallback arch_vma_name() to a sensible place
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (23 preceding siblings ...)
2006-09-05 15:21 ` [PATCH] FRV: Fix " David Howells
@ 2006-09-05 15:27 ` David Howells
2006-09-05 15:29 ` [PATCH] NOMMU: Provide page_mkclean() for NOMMU David Howells
` (5 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: David Howells @ 2006-09-05 15:27 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Arjan van de Ven, linux-kernel, Ingo Molnar,
Jeff Garzik, netdev, David Howells
Move the fallback arch_vma_name() to a sensible place (kernel/signal.c).
Currently it's in fs/proc/task_mmu.c, a file that is dependent on both
CONFIG_PROC_FS and CONFIG_MMU being enabled, but it's used from kernel/signal.c
from where it is called unconditionally.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 nommu-arch_vma_name-2618rc5mm1.diff
fs/proc/task_mmu.c | 5 -----
kernel/signal.c | 5 +++++
2 files changed, 5 insertions(+), 5 deletions(-)
diff -urp ../kernels/linux-2.6.18-rc5-mm1/fs/proc/task_mmu.c linux-2.6.18-rc5-mm1-frv/fs/proc/task_mmu.c
--- ../kernels/linux-2.6.18-rc5-mm1/fs/proc/task_mmu.c 2006-09-04 18:02:43.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/fs/proc/task_mmu.c 2006-09-05 15:49:18.000000000 +0100
@@ -122,11 +122,6 @@ struct mem_size_stats
unsigned long private_dirty;
};
-__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma)
-{
- return NULL;
-}
-
static int show_map_internal(struct seq_file *m, void *v, struct mem_size_stats *mss)
{
struct proc_maps_private *priv = m->private;
diff -urp ../kernels/linux-2.6.18-rc5-mm1/kernel/signal.c linux-2.6.18-rc5-mm1-frv/kernel/signal.c
--- ../kernels/linux-2.6.18-rc5-mm1/kernel/signal.c 2006-09-04 18:03:32.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/kernel/signal.c 2006-09-05 15:49:19.000000000 +0100
@@ -773,6 +773,11 @@ static void pad_len_spaces(int len)
printk("%*c", len, ' ');
}
+__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma)
+{
+ return NULL;
+}
+
static int print_vma(struct vm_area_struct *vma)
{
struct mm_struct *mm = vma->vm_mm;
^ permalink raw reply [flat|nested] 138+ messages in thread* [PATCH] NOMMU: Provide page_mkclean() for NOMMU
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (24 preceding siblings ...)
2006-09-05 15:27 ` [PATCH] NOMMU: Move the fallback arch_vma_name() to a sensible place David Howells
@ 2006-09-05 15:29 ` David Howells
2006-09-05 15:31 ` [PATCH] NOMMU: Make lib/ioremap.c conditional David Howells
` (4 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: David Howells @ 2006-09-05 15:29 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Arjan van de Ven, linux-kernel, Ingo Molnar,
Jeff Garzik, netdev, David Howells
Provide a page_mkclean() implementation for NOMMU. This doesn't do anything
except return successfully as there are no PTEs for it to play with.
This is only relevant to the -mm kernels.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 nommu-page_mkclean-2618rc5mm1.diff
include/linux/rmap.h | 6 ++++++
1 file changed, 6 insertions(+)
diff -urp ../kernels/linux-2.6.18-rc5-mm1/include/linux/rmap.h linux-2.6.18-rc5-mm1-frv/include/linux/rmap.h
--- ../kernels/linux-2.6.18-rc5-mm1/include/linux/rmap.h 2006-09-04 18:03:32.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/include/linux/rmap.h 2006-09-05 15:34:35.000000000 +0100
@@ -120,6 +120,12 @@ int page_mkclean(struct page *);
#define page_referenced(page,l) TestClearPageReferenced(page)
#define try_to_unmap(page, refs) SWAP_FAIL
+static inline int page_mkclean(struct page *page)
+{
+ return 0;
+}
+
+
#endif /* CONFIG_MMU */
/*
^ permalink raw reply [flat|nested] 138+ messages in thread* [PATCH] NOMMU: Make lib/ioremap.c conditional
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (25 preceding siblings ...)
2006-09-05 15:29 ` [PATCH] NOMMU: Provide page_mkclean() for NOMMU David Howells
@ 2006-09-05 15:31 ` David Howells
2006-09-05 15:35 ` [PATCH] FRV: do_gettimeofday() should no longer use tickadj David Howells
` (3 subsequent siblings)
30 siblings, 0 replies; 138+ messages in thread
From: David Howells @ 2006-09-05 15:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Arjan van de Ven, linux-kernel, Ingo Molnar,
Jeff Garzik, netdev, David Howells
Make lib/ioremap.c conditional on !CONFIG_MMU. It plays with PTEs which don't
exist under NOMMU conditions.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 nommu-ioremap-2618rc5mm1.diff
lib/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -urp ../kernels/linux-2.6.18-rc5-mm1/lib/Makefile linux-2.6.18-rc5-mm1-frv/lib/Makefile
--- ../kernels/linux-2.6.18-rc5-mm1/lib/Makefile 2006-09-04 18:03:32.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/lib/Makefile 2006-09-05 16:01:38.000000000 +0100
@@ -5,8 +5,9 @@
lib-y := ctype.o string.o vsprintf.o cmdline.o \
bust_spinlocks.o rbtree.o radix-tree.o dump_stack.o \
idr.o div64.o int_sqrt.o bitmap.o extable.o prio_tree.o \
- sha1.o ioremap.o
+ sha1.o
+lib-$(CONFIG_MMU) += ioremap.o
lib-$(CONFIG_SMP) += cpumask.o
lib-y += kobject.o kref.o kobject_uevent.o klist.o
^ permalink raw reply [flat|nested] 138+ messages in thread* [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (26 preceding siblings ...)
2006-09-05 15:31 ` [PATCH] NOMMU: Make lib/ioremap.c conditional David Howells
@ 2006-09-05 15:35 ` David Howells
2006-09-06 1:46 ` john stultz
2006-09-06 9:27 ` David Howells
2006-09-05 16:00 ` 2.6.18-rc5-mm1 dependency on curses devel still there Steve Fox
` (2 subsequent siblings)
30 siblings, 2 replies; 138+ messages in thread
From: David Howells @ 2006-09-05 15:35 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Arjan van de Ven, linux-kernel, Ingo Molnar,
Jeff Garzik, netdev, David Howells
Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
instead.
This patch also provides a placeholder macro for getting hardware timer data to
be filled in when such is available.
Signed-Off-By: David Howells <dhowells@redhat.com>
---
warthog>diffstat -p1 frv-tickadj-2618rc5mm1.diff
arch/frv/kernel/time.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff -urp ../kernels/linux-2.6.18-rc5-mm1/arch/frv/kernel/time.c linux-2.6.18-rc5-mm1-frv/arch/frv/kernel/time.c
--- ../kernels/linux-2.6.18-rc5-mm1/arch/frv/kernel/time.c 2006-09-04 18:03:14.000000000 +0100
+++ linux-2.6.18-rc5-mm1-frv/arch/frv/kernel/time.c 2006-09-05 15:44:42.000000000 +0100
@@ -31,6 +31,9 @@
#define TICK_SIZE (tick_nsec / 1000)
+/* H/W clock data if we can get it (in microseconds) */
+#define FRV_HW_CLOCK_DATA (0)
+
unsigned long __nongprelbss __clkin_clock_speed_HZ;
unsigned long __nongprelbss __ext_bus_clock_speed_HZ;
unsigned long __nongprelbss __res_bus_clock_speed_HZ;
@@ -148,23 +151,10 @@ void do_gettimeofday(struct timeval *tv)
{
unsigned long seq;
unsigned long usec, sec;
- unsigned long max_ntp_tick;
do {
seq = read_seqbegin(&xtime_lock);
-
- usec = 0;
-
- /*
- * If time_adjust is negative then NTP is slowing the clock
- * so make sure not to go into next possible interval.
- * Better to lose some accuracy than have time go backwards..
- */
- if (unlikely(time_adjust < 0)) {
- max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
- usec = min(usec, max_ntp_tick);
- }
-
+ usec = FRV_HW_CLOCK_DATA;
sec = xtime.tv_sec;
usec += (xtime.tv_nsec / 1000);
} while (read_seqretry(&xtime_lock, seq));
@@ -195,7 +185,7 @@ int do_settimeofday(struct timespec *tv)
* wall time. Discover what correction gettimeofday() would have
* made, and then undo it!
*/
- nsec -= 0 * NSEC_PER_USEC;
+ nsec -= FRV_HW_CLOCK_DATA * NSEC_PER_USEC;
wtm_sec = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-05 15:35 ` [PATCH] FRV: do_gettimeofday() should no longer use tickadj David Howells
@ 2006-09-06 1:46 ` john stultz
2006-09-06 9:27 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: john stultz @ 2006-09-06 1:46 UTC (permalink / raw)
To: David Howells
Cc: Adrian Bunk, Andrew Morton, Arjan van de Ven, linux-kernel,
Ingo Molnar, Jeff Garzik, netdev
On Tue, 2006-09-05 at 16:35 +0100, David Howells wrote:
> Stop do_gettimeofday() on FRV from using tickadj, and model it after ARM
> instead.
>
> This patch also provides a placeholder macro for getting hardware timer data to
> be filled in when such is available.
>From this patch it looks like the FRV arch could be trivially converted
to GENERIC_TIME.
Would you consider the following, totally untested patch?
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Kconfig | 4 ++
kernel/time.c | 81 ----------------------------------------------------------
2 files changed, 4 insertions(+), 81 deletions(-)
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 95a3892..a601a17 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -29,6 +29,10 @@ config GENERIC_HARDIRQS
bool
default n
+config GENERIC_TIME
+ bool
+ default y
+
config TIME_LOW_RES
bool
default y
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
index d5b64e1..68a77fe 100644
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -32,8 +32,6 @@
#define TICK_SIZE (tick_nsec / 1000)
-extern unsigned long wall_jiffies;
-
unsigned long __nongprelbss __clkin_clock_speed_HZ;
unsigned long __nongprelbss __ext_bus_clock_speed_HZ;
unsigned long __nongprelbss __res_bus_clock_speed_HZ;
@@ -145,85 +143,6 @@ void time_init(void)
}
/*
- * This version of gettimeofday has near microsecond resolution.
- */
-void do_gettimeofday(struct timeval *tv)
-{
- unsigned long seq;
- unsigned long usec, sec;
- unsigned long max_ntp_tick;
-
- do {
- unsigned long lost;
-
- seq = read_seqbegin(&xtime_lock);
-
- usec = 0;
- lost = jiffies - wall_jiffies;
-
- /*
- * If time_adjust is negative then NTP is slowing the clock
- * so make sure not to go into next possible interval.
- * Better to lose some accuracy than have time go backwards..
- */
- if (unlikely(time_adjust < 0)) {
- max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
- usec = min(usec, max_ntp_tick);
-
- if (lost)
- usec += lost * max_ntp_tick;
- }
- else if (unlikely(lost))
- usec += lost * (USEC_PER_SEC / HZ);
-
- sec = xtime.tv_sec;
- usec += (xtime.tv_nsec / 1000);
- } while (read_seqretry(&xtime_lock, seq));
-
- while (usec >= 1000000) {
- usec -= 1000000;
- sec++;
- }
-
- tv->tv_sec = sec;
- tv->tv_usec = usec;
-}
-
-EXPORT_SYMBOL(do_gettimeofday);
-
-int do_settimeofday(struct timespec *tv)
-{
- time_t wtm_sec, sec = tv->tv_sec;
- long wtm_nsec, nsec = tv->tv_nsec;
-
- if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
- return -EINVAL;
-
- write_seqlock_irq(&xtime_lock);
- /*
- * This is revolting. We need to set "xtime" correctly. However, the
- * value in this location is the value at the most recent update of
- * wall time. Discover what correction gettimeofday() would have
- * made, and then undo it!
- */
- nsec -= 0 * NSEC_PER_USEC;
- nsec -= (jiffies - wall_jiffies) * TICK_NSEC;
-
- wtm_sec = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
- wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
-
- set_normalized_timespec(&xtime, sec, nsec);
- set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
-
- ntp_clear();
- write_sequnlock_irq(&xtime_lock);
- clock_was_set();
- return 0;
-}
-
-EXPORT_SYMBOL(do_settimeofday);
-
-/*
* Scheduler clock - returns current time in nanosec units.
*/
unsigned long long sched_clock(void)
^ permalink raw reply related [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-05 15:35 ` [PATCH] FRV: do_gettimeofday() should no longer use tickadj David Howells
2006-09-06 1:46 ` john stultz
@ 2006-09-06 9:27 ` David Howells
2006-09-06 9:43 ` Ingo Molnar
2006-09-06 12:30 ` David Howells
1 sibling, 2 replies; 138+ messages in thread
From: David Howells @ 2006-09-06 9:27 UTC (permalink / raw)
To: john stultz
Cc: David Howells, Adrian Bunk, Andrew Morton, Arjan van de Ven,
linux-kernel, Ingo Molnar, Jeff Garzik, netdev
john stultz <johnstul@us.ibm.com> wrote:
> From this patch it looks like the FRV arch could be trivially converted
> to GENERIC_TIME.
>
> Would you consider the following, totally untested patch?
It certainly looks interesting. I'll have to study the clocksource stuff -
some FRV CPUs have an effective TSC.
David
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 9:27 ` David Howells
@ 2006-09-06 9:43 ` Ingo Molnar
2006-09-06 12:30 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-06 9:43 UTC (permalink / raw)
To: David Howells
Cc: john stultz, Adrian Bunk, Andrew Morton, Arjan van de Ven,
linux-kernel, Jeff Garzik, netdev
* David Howells <dhowells@redhat.com> wrote:
> john stultz <johnstul@us.ibm.com> wrote:
>
> > From this patch it looks like the FRV arch could be trivially
> > converted to GENERIC_TIME.
> >
> > Would you consider the following, totally untested patch?
>
> It certainly looks interesting. I'll have to study the clocksource
> stuff - some FRV CPUs have an effective TSC.
btw., would be nice to convert it to genirq (and irqchips) too =B-) That
would solve the kind of disable_irq_lockdep() breakage that was reported
recently.
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 9:27 ` David Howells
2006-09-06 9:43 ` Ingo Molnar
@ 2006-09-06 12:30 ` David Howells
2006-09-06 12:56 ` Ingo Molnar
2006-09-06 14:46 ` David Howells
1 sibling, 2 replies; 138+ messages in thread
From: David Howells @ 2006-09-06 12:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Howells, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev
Ingo Molnar <mingo@elte.hu> wrote:
> btw., would be nice to convert it to genirq (and irqchips) too =B-) That
> would solve the kind of disable_irq_lockdep() breakage that was reported
> recently.
I can think of reasons for not using that stuff also.
(1) Passing "struct pt_regs *regs" around is a complete waste of resources on
FRV. It's in GR28 at all times and can thus be accessed directly.
(2) All the little operations functions cause unnecessary jumping, jumps that
icache lookahead can't predict because they're register-indirect.
(3) ACK'ing and controlling interrupts has to be done by groups.
(4) No account is taken of interrupt priority.
(5) The FRV CPU doesn't tell me which IRQ source fired. Much of the code
I've got is stuff to try and work it out. I could just blindly poll all
the sources attached to a particular interrupt level, but that seems
somehow less efficient.
David
BTW, have you looked at my patch to fix lockdep yet?
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 12:30 ` David Howells
@ 2006-09-06 12:56 ` Ingo Molnar
2006-09-06 14:46 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-06 12:56 UTC (permalink / raw)
To: David Howells
Cc: john stultz, Adrian Bunk, Andrew Morton, Arjan van de Ven,
linux-kernel, Jeff Garzik, netdev, Thomas Gleixner,
Benjamin Herrenschmidt
* David Howells <dhowells@redhat.com> wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > btw., would be nice to convert it to genirq (and irqchips) too =B-) That
> > would solve the kind of disable_irq_lockdep() breakage that was reported
> > recently.
>
> I can think of reasons for not using that stuff also.
>
> (1) Passing "struct pt_regs *regs" around is a complete waste of
> resources on FRV. It's in GR28 at all times and can thus be
> accessed directly.
we'll get rid of that pt_regs thing centrally, from all drivers at once
- there's upstream buy-in for that already, and Thomas already generated
a test-patch for that a few months ago. But it's not a big issue right
now.
> (2) All the little operations functions cause unnecessary jumping,
> jumps that icache lookahead can't predict because they're
> register-indirect.
this shouldnt be a big issue either - we use indirect jumps all around
the kernel. CPUs are either smart enough to predict it, or they simply
dont have that high penalties. (and if they have high penalties but dont
optimize for it then genirq will be the last of their worries. The VFS
and the MM is full of function pointers.)
> (3) ACK'ing and controlling interrupts has to be done by groups.
please be more specific, how is this not possible via genirq?
> (4) No account is taken of interrupt priority.
hm, i'm not sure what you mean - could you be more specific?
> (5) The FRV CPU doesn't tell me which IRQ source fired. Much of the
> code I've got is stuff to try and work it out. I could just
> blindly poll all the sources attached to a particular interrupt
> level, but that seemssomehow less efficient.
but ... somehow the current FRV code does figure out which IRQ source
fired, right? How is that a hindrance for a genirq/irqchips based
design?
> BTW, have you looked at my patch to fix lockdep yet?
oops, i missed it - just acked it. (This problem too was a side-effect
of FRV having its own IRQ layer.)
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 12:30 ` David Howells
2006-09-06 12:56 ` Ingo Molnar
@ 2006-09-06 14:46 ` David Howells
2006-09-06 23:01 ` Benjamin Herrenschmidt
` (3 more replies)
1 sibling, 4 replies; 138+ messages in thread
From: David Howells @ 2006-09-06 14:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Howells, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner, Benjamin Herrenschmidt
Ingo Molnar <mingo@elte.hu> wrote:
> we'll get rid of that pt_regs thing centrally, from all drivers at once
> - there's upstream buy-in for that already, and Thomas already generated
> a test-patch for that a few months ago. But it's not a big issue right
> now.
Yay! Can you give me a pointer to the patch?
> this shouldnt be a big issue either - we use indirect jumps all around
> the kernel.
Yes, I know. I'm sometimes concerned at just how fast indirect jumps (and even
direct calls) are proliferating. Look at the read syscall path for something
like ext3 these days: it's like a pile of spaghetti. That seems particularly
true of direct-IO where it seems to weave in and out of core code and the
filesystem as it goes down. I'm also concerned about stack usage.
> CPUs are either smart enough to predict it
I was told a while back (2002?) not to use indirect pointers for some stuff
because CPUs _couldn't_ predict it. Maybe this has changed in modern CPUs.
> > (3) ACK'ing and controlling interrupts has to be done by groups.
>
> please be more specific,
Under some circumstances I can work out which sources have triggered which
interrupts (there are various off-CPU FPGAs which implement auxiliary PICs that
do announce their sources), but the aux-PIC channels are grouped together upon
delivery to the CPU PIC, so some of the ACK'ing has to be done at the group
level.
> how is this not possible via genirq?
How is it possible with genirq?
Unless I tie all the grouped sources together into one virtual IRQ line, this
doesn't appear to be possible. But doing that I might then also have a mixed
set of "flow" types in any particular IRQ.
> > (4) No account is taken of interrupt priority.
>
> hm, i'm not sure what you mean - could you be more specific?
The FRV CPU, like many others, supports interrupt prioritisation. A particular
interrupt level is set in the PSR, and any interrupt of a higher priority can
interrupt. do_IRQ() can then do the interrupt processing in the interrupt
level of the interrupt that invoked it, thus permitting higher priority
interrupts to still happen.
> but ... somehow the current FRV code does figure out which IRQ source
> fired, right?
Not always; sometimes it has to fall back to polling the drivers unfortunately.
Btw why are we using IRQ_INPROGRESS, IRQ_DISABLED, IRQ_PENDING and friends?
They would appear unnecessary.
David
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 14:46 ` David Howells
@ 2006-09-06 23:01 ` Benjamin Herrenschmidt
2006-09-07 9:55 ` David Howells
` (2 subsequent siblings)
3 siblings, 0 replies; 138+ messages in thread
From: Benjamin Herrenschmidt @ 2006-09-06 23:01 UTC (permalink / raw)
To: David Howells
Cc: Ingo Molnar, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner
> Under some circumstances I can work out which sources have triggered which
> interrupts (there are various off-CPU FPGAs which implement auxiliary PICs that
> do announce their sources), but the aux-PIC channels are grouped together upon
> delivery to the CPU PIC, so some of the ACK'ing has to be done at the group
> level.
>
> > how is this not possible via genirq?
>
> How is it possible with genirq?
Well, genirq gives you more flexibility than the current mecanism so ...
If I understand correctly, you need to do scray stuff to figure out your
toplevel irq, which shound't be a problem with either mecanisms...
Now, if you have funky cascades, then you can always group them into a
virtual irq cascade line and have a special chained flow handler that
does all the "figuring out" off those... it's up to you.
In general, I found genirq allowed me to do more fancy stuff, and end up
with actually less hooks and indirect function calls on the path to a
given irq than before as you can use tailored flow handlers that do just
the right thing.
Ben.
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 14:46 ` David Howells
2006-09-06 23:01 ` Benjamin Herrenschmidt
@ 2006-09-07 9:55 ` David Howells
2006-09-07 10:26 ` Ingo Molnar
` (4 more replies)
2006-09-09 5:46 ` Ingo Molnar
2006-09-11 10:46 ` David Howells
3 siblings, 5 replies; 138+ messages in thread
From: David Howells @ 2006-09-07 9:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: David Howells, Ingo Molnar, john stultz, Adrian Bunk,
Andrew Morton, Arjan van de Ven, linux-kernel, Jeff Garzik,
netdev, Thomas Gleixner
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Well, genirq gives you more flexibility than the current mecanism so ...
No, it doesn't because the FRV arch contains its own mechanism and I can do
what ever I like in it.
genirq's flexibility comes at a price. Count the number of hooks in struct
irq_chip and struct irq_desc together.
> If I understand correctly, you need to do scray stuff to figure out your
> toplevel irq, which shound't be a problem with either mecanisms...
Yeah. I can't actually find out what source caused top-level IRQs. I have to
guess from looking at the IRQ priority and poking around in the hardware. I
got bitten that way too: at one point, I was peeking at the interrupt flag in
the serial regs, only to realise this was causing the driver to go wrong
because it cleared the interrupt requested flag in UART.
Obviously I'd rather not use IRQ priorisation to help multiplex irqs, but
unless I want a large polling set...
> Now, if you have funky cascades, then you can always group them into a
> virtual irq cascade line and have a special chained flow handler that
> does all the "figuring out" off those... it's up to you.
You make it sound so easy, but it's not obvious how to do this, apart from
installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
having those call back into __do_IRQ(). Chaining isn't mentioned in
genericirq.tmpl.
> In general, I found genirq allowed me to do more fancy stuff, and end up
> with actually less hooks and indirect function calls on the path to a
> given irq than before as you can use tailored flow handlers that do just
> the right thing.
My code in the FRV arch has fewer indirection calls than the genirq code
simply because it doesn't require tables of operations. I can trace through
it with gdb and see them.
I built all the stuff that genirq does in indirections directly into the
handlers. It certainly has fewer hooks.
I attempted to convert it over to use genirq, and I came up with some numbers:
The difference in kernel sizes:
text data bss dec hex filename
1993023 77912 166964 2237899 2225cb vmlinux [with genirq]
1986511 76016 167908 2230435 2208a3 vmlinux [without genirq]
The genirq subdir all wraps up into this:
10908 3272 12 14192 3770 kernel/irq/built-in.o
1548 64 4 1616 650 arch/frv/kernel/irq.o
---------------------------------------------------------------------
12456 3336 16 15808 3dc0 total
My FRV-specific IRQ handling wraps up into these:
480 488 0 968 3c8 arch/frv/kernel/irq-mb93091.o
4688 16 520 5224 1468 arch/frv/kernel/irq.o
1576 1152 16 2744 ab8 arch/frv/kernel/irq-routing.o
---------------------------------------------------------------------
6744 1656 536 8936 22e8 total
There's a difference in BSS size in the main kernel that I can't account for,
but basically genirq uses 6.3KB more code and 1.8KB more initialised data, but
0.9KB less BSS. Overall, about 7.2KB more memory. I can shrink the BSS usage
in the FRV specific version by reducing the amount of space in the IRQ sources
table.
So, again, why _should_ I use the generic IRQ stuff? It's bigger and very
probably slower than what I already have.
David
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-07 9:55 ` David Howells
@ 2006-09-07 10:26 ` Ingo Molnar
2006-09-07 13:34 ` David Howells
` (3 subsequent siblings)
4 siblings, 0 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-07 10:26 UTC (permalink / raw)
To: David Howells
Cc: Benjamin Herrenschmidt, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner
* David Howells <dhowells@redhat.com> wrote:
> The genirq subdir all wraps up into this:
>
> 10908 3272 12 14192 3770 kernel/irq/built-in.o
> 1548 64 4 1616 650 arch/frv/kernel/irq.o
> ---------------------------------------------------------------------
> 12456 3336 16 15808 3dc0 total
hm, could you take a look at why that difference happens? Do you make
use of __do_IRQ()? Do you make use of all the various flow handlers that
are offered in handle.c? Could you #ifdef out all the functions that are
unused? The kernel build process doesnt remove them and i havent (yet)
put them into a library.
Could you please send us the patch that genirq-ifies FRV?
> So, again, why _should_ I use the generic IRQ stuff? [...]
To have shared code between architectures? To make generic API updates
easier for all of us? To have less cruft in interrupt.h? To not having
to add last-minute patches to v2.6.18 because some arch defines its own
IRQ prototypes and a difficult generic feature like irqtrace breaks? To
get new IRQ subsystem features for free like preemptible irqs, irqpoll
or SHIRQ debugging?
the same "why should we share code" argument could be made for the VFS
too. Sharing code has a (small) price most of the time, but it's also
very much worth it. I think the size increases you are seeing are
artificial and most of it is not caused by the indirections. If they
were caused by the indirections i'd probably agree with you.
if your argument were true every arch should run its whole Linux kernel
in arch/frv, with zero sharing with anyone else. There's always a lot of
'unnecessary' stuff all around the kernel that is just a hindrance for
FRV. In reality what makes us stronger is to work together. I dont for a
minute say that we should overdo code sharing - if it's not possible
then it must not be forced, but just the pure fact of "more
indirections" or "what does this bring me _now_" isnt a good enough
reason i believe - it simply makes _future_ changes easier.
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-07 9:55 ` David Howells
2006-09-07 10:26 ` Ingo Molnar
@ 2006-09-07 13:34 ` David Howells
2006-09-07 22:53 ` Benjamin Herrenschmidt
` (2 subsequent siblings)
4 siblings, 0 replies; 138+ messages in thread
From: David Howells @ 2006-09-07 13:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Howells, Benjamin Herrenschmidt, john stultz, Adrian Bunk,
Andrew Morton, Arjan van de Ven, linux-kernel, Jeff Garzik,
netdev, Thomas Gleixner
Ingo Molnar <mingo@elte.hu> wrote:
> > So, again, why _should_ I use the generic IRQ stuff? [...]
>
> To have shared code between architectures?
That's reasonable as far as it goes, the algorithms are similar per-arch, but
the PICs are quite ofter quite different. My FRV board here has three very
different ones, none of them compatible with anything else as far as I know.
> To make generic API updates easier for all of us?
That's reasonable.
> To have less cruft in interrupt.h?
That's specious. The whole point of having arch-specific code is to support
arch-specific stuff.
> To not having to add last-minute patches to v2.6.18 because some arch
> defines its own IRQ prototypes and a difficult generic feature like irqtrace
> breaks?
Specious again. If whoever it was made the changes got them right in the
first place, then it wouldn't have required a last minute patch for the
LOCKDEP=n case now would it?
If you're going to insist on the genirq stuff being used, than you should take
CONFIG_GENERIC_HARDIRQS away and force everyone else to move to what you've
decided they should use, right?
> To get new IRQ subsystem features for free like preemptible irqs, irqpoll or
> SHIRQ debugging?
That's reasonable, but you don't get necessarily get features for "free" when
you add up the cost of having support there for them. The features appear for
the subscribed arches automatically, and so do the costs.
> hm, could you take a look at why that difference happens? Do you make
> use of __do_IRQ()?
I did say I used it. In fact, as far as I can tell, I have to use it
recursively. There doesn't seem to be any other way in that's correct.
> Do you make use of all the various flow handlers that are offered in
> handle.c?
Some of them.
> Could you #ifdef out all the functions that are unused? The kernel build
> process doesnt remove them and i havent (yet) put them into a library.
I could get away with commenting out:
no_action()
set_irq_wake()
can_request_irq()
set_irq_type()
set_irq_data()
set_irq_chip_data()
handle_simple_irq()
handle_fasteio_irq()
bits of handle_irq_name() corresponding to the previous two
This results in a small shrinkage of text and a slight increase in the amount
of data used:
text data bss dec hex filename
1993023 77908 166964 2237895 2225c7 vmlinux [before]
1991407 77912 166964 2236283 221f7b vmlinux [after]
---------------------------------------
1616 -4 0 1612
The increase in data size is slightly puzzling, but may have something to do
with there being fewer strings in handle_irq_name(). The text decrease is
about 12% of the unmodified total:
text data bss dec hex filename
10908 3272 12 14192 3770 kernel/irq/built-in.o
1548 64 4 1616 650 arch/frv/kernel/irq.o
744 192 0 936 3a8 arch/frv/kernel/irq-mb93091.o
---------------------------------------
13200 3528 16 16744 total
> the same "why should we share code" argument could be made for the VFS too.
That argument doesn't really follow. We only have one interrupt system in the
kernel, but we have lots of different filesystems.
> Sharing code has a (small) price most of the time, but it's also very much
> worth it. I think the size increases you are seeing are artificial
Artificial in what manner? I haven't added extra code to genirq to make it
look bad or anything like that.
> and most of it is not caused by the indirections. If they were caused by the
> indirections i'd probably agree with you.
I think most of the size increase is due to the core genirq function set being
large, not the indirections themselves. There aren't many indirections
implemented in the core set.
The indirected functions exist in the arch code for the most part, and where
they are implemented they are generally very small. In FRV's case, one lot in
arch/frv/kernel/irq.c for the CPU and one lot in arch/frv/kernel/irq-mb93091.c
or similar for the on-motherboard FPGA.
> if your argument were true every arch should run its whole Linux kernel
> in arch/frv, with zero sharing with anyone else.
Not really. eCos manages this more efficiently than Linux, with generally
fewer indirections through the use of macros and inline functions.
At some point you do have to draw a line and do common stuff. The VFS is
definitely in the common region. It has little need of arch-specific stuff in
there, and that that it does is quite readily encapsulated in inline functions
where it has little effect on the space. I'm not entirely convinced that this
applies to interrupt handling though. That is at the basic level very
arch-dependent.
> There's always a lot of 'unnecessary' stuff all around the kernel that is
> just a hindrance for FRV.
Or any other platform, embedded or otherwise, that doesn't want it. A lot of
it I can disable - the block layer now, for instance - but some of it I can't
(like interrupt handling).
> In reality what makes us stronger is to work together. I dont for a minute
> say that we should overdo code sharing
So who defines what is "overdone"? You seem to have decided that you do.
> - if it's not possible then it must not be forced, but just the pure fact of
> "more indirections" or "what does this bring me _now_" isnt a good enough
> reason i believe - it simply makes _future_ changes easier.
And makes the kernel larger and slower and makes it consume more stack space
and less easy for the compiler to optimise.
David
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-07 9:55 ` David Howells
2006-09-07 10:26 ` Ingo Molnar
2006-09-07 13:34 ` David Howells
@ 2006-09-07 22:53 ` Benjamin Herrenschmidt
2006-09-08 10:25 ` David Howells
2006-09-08 12:29 ` David Howells
4 siblings, 0 replies; 138+ messages in thread
From: Benjamin Herrenschmidt @ 2006-09-07 22:53 UTC (permalink / raw)
To: David Howells
Cc: Ingo Molnar, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner
On Thu, 2006-09-07 at 10:55 +0100, David Howells wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Well, genirq gives you more flexibility than the current mecanism so ...
>
> No, it doesn't because the FRV arch contains its own mechanism and I can do
> what ever I like in it.
But genirq allows you to have your own flow handlers... Which does mean
do whatever you like as well
> genirq's flexibility comes at a price. Count the number of hooks in struct
> irq_chip and struct irq_desc together.
You do not have to implement them all. Some of them are specific to a
given flow. For example, on XICS or MPIC, I only call eoi(), that is a
single hook, using the fasteoi handler. That's actually less than with
the previous generic code.
> > If I understand correctly, you need to do scray stuff to figure out your
> > toplevel irq, which shound't be a problem with either mecanisms...
>
> Yeah. I can't actually find out what source caused top-level IRQs. I have to
> guess from looking at the IRQ priority and poking around in the hardware. I
> got bitten that way too: at one point, I was peeking at the interrupt flag in
> the serial regs, only to realise this was causing the driver to go wrong
> because it cleared the interrupt requested flag in UART.
>
> Obviously I'd rather not use IRQ priorisation to help multiplex irqs, but
> unless I want a large polling set...
But neither the old mecanism nor genirq changes nor does anything in the
way of discovering what the toplevel irq is ... They only intervene
after you have found it...
> > Now, if you have funky cascades, then you can always group them into a
> > virtual irq cascade line and have a special chained flow handler that
> > does all the "figuring out" off those... it's up to you.
>
> You make it sound so easy, but it's not obvious how to do this, apart from
> installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
> having those call back into __do_IRQ(). Chaining isn't mentioned in
> genericirq.tmpl.
No, you do a chain handler. Look at how I do it in
arch/powerpc/platform/pseries/setup.c for example. It's actually
trivial. You install a special flow handler (which means that there is
very little overhead, almost none, from the toplevel irq to the chained
irq). You can _also_ if you want just install an IRQ handler for the
cascaded controller and call generic_handle_irq (rather than __do_IRQ)
from it, but that has more overhead. A chained handler completely
relaces the flow handler for the cascade, and thus, if you don't need
all of the nits and bits of the other flow handlers for your cascade,
you can speed things up by hooking at that level.
> My code in the FRV arch has fewer indirection calls than the genirq code
> simply because it doesn't require tables of operations. I can trace through
> it with gdb and see them.
>
> I built all the stuff that genirq does in indirections directly into the
> handlers. It certainly has fewer hooks.
genirq allows you to do just that by using custom handlers.
> I attempted to convert it over to use genirq, and I came up with some numbers:
>
> The difference in kernel sizes:
>
> text data bss dec hex filename
> 1993023 77912 166964 2237899 2225cb vmlinux [with genirq]
> 1986511 76016 167908 2230435 2208a3 vmlinux [without genirq]
>
> The genirq subdir all wraps up into this:
>
> 10908 3272 12 14192 3770 kernel/irq/built-in.o
> 1548 64 4 1616 650 arch/frv/kernel/irq.o
> ---------------------------------------------------------------------
> 12456 3336 16 15808 3dc0 total
>
> My FRV-specific IRQ handling wraps up into these:
>
> 480 488 0 968 3c8 arch/frv/kernel/irq-mb93091.o
> 4688 16 520 5224 1468 arch/frv/kernel/irq.o
> 1576 1152 16 2744 ab8 arch/frv/kernel/irq-routing.o
> ---------------------------------------------------------------------
> 6744 1656 536 8936 22e8 total
>
> There's a difference in BSS size in the main kernel that I can't account for,
> but basically genirq uses 6.3KB more code and 1.8KB more initialised data, but
> 0.9KB less BSS. Overall, about 7.2KB more memory. I can shrink the BSS usage
> in the FRV specific version by reducing the amount of space in the IRQ sources
> table.
>
> So, again, why _should_ I use the generic IRQ stuff? It's bigger and very
> probably slower than what I already have.
Well, I would have to look precisely at how you did the port to
genirq... But in my case, it's definitely not slower, especially when
cascaded controllers are involved.
Ben.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-07 9:55 ` David Howells
` (2 preceding siblings ...)
2006-09-07 22:53 ` Benjamin Herrenschmidt
@ 2006-09-08 10:25 ` David Howells
2006-09-08 11:05 ` Benjamin Herrenschmidt
2006-09-08 12:24 ` David Howells
2006-09-08 12:29 ` David Howells
4 siblings, 2 replies; 138+ messages in thread
From: David Howells @ 2006-09-08 10:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: David Howells, Ingo Molnar, john stultz, Adrian Bunk,
Andrew Morton, Arjan van de Ven, linux-kernel, Jeff Garzik,
netdev, Thomas Gleixner
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> No, you do a chain handler. Look at how I do it in
> arch/powerpc/platform/pseries/setup.c for example. It's actually
> trivial. You install a special flow handler (which means that there is
> very little overhead, almost none, from the toplevel irq to the chained
> irq). You can _also_ if you want just install an IRQ handler for the
> cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> from it, but that has more overhead. A chained handler completely
> relaces the flow handler for the cascade, and thus, if you don't need
> all of the nits and bits of the other flow handlers for your cascade,
> you can speed things up by hooking at that level.
Please update Documentation/DocBook/genericirq.tmpl. That doesn't mention it.
David
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-08 10:25 ` David Howells
@ 2006-09-08 11:05 ` Benjamin Herrenschmidt
2006-09-08 12:24 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: Benjamin Herrenschmidt @ 2006-09-08 11:05 UTC (permalink / raw)
To: David Howells
Cc: Ingo Molnar, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner
On Fri, 2006-09-08 at 11:25 +0100, David Howells wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > No, you do a chain handler. Look at how I do it in
> > arch/powerpc/platform/pseries/setup.c for example. It's actually
> > trivial. You install a special flow handler (which means that there is
> > very little overhead, almost none, from the toplevel irq to the chained
> > irq). You can _also_ if you want just install an IRQ handler for the
> > cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> > from it, but that has more overhead. A chained handler completely
> > relaces the flow handler for the cascade, and thus, if you don't need
> > all of the nits and bits of the other flow handlers for your cascade,
> > you can speed things up by hooking at that level.
>
> Please update Documentation/DocBook/genericirq.tmpl. That doesn't mention it.
I must admit I haven't read the documentation :) I looked at the
code/patches when genirq was posted and did my powerpc implementation
based on my understanding of the code and discussions with Thomas and
Ingo. I'll have a look at the doc next week and see if I can improve it.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-08 10:25 ` David Howells
2006-09-08 11:05 ` Benjamin Herrenschmidt
@ 2006-09-08 12:24 ` David Howells
1 sibling, 0 replies; 138+ messages in thread
From: David Howells @ 2006-09-08 12:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: David Howells, Ingo Molnar, john stultz, Adrian Bunk,
Andrew Morton, Arjan van de Ven, linux-kernel, Jeff Garzik,
netdev, Thomas Gleixner
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Please update Documentation/DocBook/genericirq.tmpl. That doesn't mention it.
>
> I must admit I haven't read the documentation :) I looked at the
> code/patches when genirq was posted and did my powerpc implementation
> based on my understanding of the code and discussions with Thomas and
> Ingo. I'll have a look at the doc next week and see if I can improve it.
While you're at it, you should also encomment pseries_8259_cascade() which is
what I suspect you're referring to in the powerpc sources.
David
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-07 9:55 ` David Howells
` (3 preceding siblings ...)
2006-09-08 10:25 ` David Howells
@ 2006-09-08 12:29 ` David Howells
2006-09-11 4:06 ` Benjamin Herrenschmidt
4 siblings, 1 reply; 138+ messages in thread
From: David Howells @ 2006-09-08 12:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: David Howells, Ingo Molnar, john stultz, Adrian Bunk,
Andrew Morton, Arjan van de Ven, linux-kernel, Jeff Garzik,
netdev, Thomas Gleixner
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > Now, if you have funky cascades, then you can always group them into a
> > > virtual irq cascade line and have a special chained flow handler that
> > > does all the "figuring out" off those... it's up to you.
> >
> > You make it sound so easy, but it's not obvious how to do this, apart from
> > installing interrupt handlers for the auxiliary PIC interrupts on the CPU and
> > having those call back into __do_IRQ(). Chaining isn't mentioned in
> > genericirq.tmpl.
>
> No, you do a chain handler. Look at how I do it in
> arch/powerpc/platform/pseries/setup.c for example. It's actually
> trivial. You install a special flow handler (which means that there is
> very little overhead, almost none, from the toplevel irq to the chained
> irq). You can _also_ if you want just install an IRQ handler for the
> cascaded controller and call generic_handle_irq (rather than __do_IRQ)
> from it, but that has more overhead. A chained handler completely
> relaces the flow handler for the cascade, and thus, if you don't need
> all of the nits and bits of the other flow handlers for your cascade,
> you can speed things up by hooking at that level.
But funky cascading using chained flow handlers doesn't work if the cascade
must share an IRQ with some other device, right?
David
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-08 12:29 ` David Howells
@ 2006-09-11 4:06 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 138+ messages in thread
From: Benjamin Herrenschmidt @ 2006-09-11 4:06 UTC (permalink / raw)
To: David Howells
Cc: Ingo Molnar, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner
> But funky cascading using chained flow handlers doesn't work if the cascade
> must share an IRQ with some other device, right?
Indeed. Best way there is then to have a normal action handler like you
do and have it call generic_handle_irq() on the cascaded interrupts.
Ben.
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 14:46 ` David Howells
2006-09-06 23:01 ` Benjamin Herrenschmidt
2006-09-07 9:55 ` David Howells
@ 2006-09-09 5:46 ` Ingo Molnar
2006-09-11 10:46 ` David Howells
3 siblings, 0 replies; 138+ messages in thread
From: Ingo Molnar @ 2006-09-09 5:46 UTC (permalink / raw)
To: David Howells
Cc: john stultz, Adrian Bunk, Andrew Morton, Arjan van de Ven,
linux-kernel, Jeff Garzik, netdev, Thomas Gleixner,
Benjamin Herrenschmidt
* David Howells <dhowells@redhat.com> wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
>
> > we'll get rid of that pt_regs thing centrally, from all drivers at once
> > - there's upstream buy-in for that already, and Thomas already generated
> > a test-patch for that a few months ago. But it's not a big issue right
> > now.
>
> Yay! Can you give me a pointer to the patch?
i cannot find Thomas' recent 2.6 one (Thomas, do you have a link to
it?), but i did one 5 years ago:
http://people.redhat.com/mingo/irq-rewrite-patches/irq-cleanup-2.4.15-B1.bz2
in general it's a large but otherwise pretty dumb patch.
> > this shouldnt be a big issue either - we use indirect jumps all around
> > the kernel.
>
> Yes, I know. I'm sometimes concerned at just how fast indirect jumps
> (and even direct calls) are proliferating. Look at the read syscall
> path for something like ext3 these days: it's like a pile of
> spaghetti. That seems particularly true of direct-IO where it seems
> to weave in and out of core code and the filesystem as it goes down.
> I'm also concerned about stack usage.
yeah - but unless you can suggest some low-maintainance-overhead
solution, not much can be done i suspect: being a few cycles slower is a
lot less of a problem than being less flexible in the design. In general
CPUs do optimize this quite well, but it is true that not every CPU
does.
> > CPUs are either smart enough to predict it
>
> I was told a while back (2002?) not to use indirect pointers for some
> stuff because CPUs _couldn't_ predict it. Maybe this has changed in
> modern CPUs.
indirect pointers are very common both in OSs and in applications,
especially in C++ based ones, where lots of execution goes off dynamic
objects which have function pointers associated to them. So _lots_ of
effort goes into branch prediction on the hardware side - and yes,
modern CPUs do quite well with indirect pointers too.
The worst-case scenario is when the indirect branch flip-flops between
multiple destination addresses - but that shouldnt be an issue for
genirq because most systems have _one_ preferred way of handling
interrupts that the majority of interrupt traffic uses. (for example on
i686 it's level-triggered PCI irqs)
But even if there's multiple destinations from the indirect jump, newest
CPUs (such as Core 2) can actually store _multiple_ branch history
targets and can prefetch all of them at once (if there's idle capacity
left).
(And i wouldnt be surprised if some modern CPUs already stored the
indirection register's index in the BHT, and used that for the
prediction. Most indirect calls happen off registers, and if the
compiler loads the register early enough (which it typically does) then
the branch target value is available to the CPU. Other context
information can be included in a BHT too.)
Also, in general, if something is arguably a smart thing to do in an OS
(and more design flexibility via function pointers is a smart thing for
which there is no viable alternative), we can expect CPUs to get
gradually better at handling them.
> > > (4) No account is taken of interrupt priority.
> >
> > hm, i'm not sure what you mean - could you be more specific?
>
> The FRV CPU, like many others, supports interrupt prioritisation. A
> particular interrupt level is set in the PSR, and any interrupt of a
> higher priority can interrupt. do_IRQ() can then do the interrupt
> processing in the interrupt level of the interrupt that invoked it,
> thus permitting higher priority interrupts to still happen.
ah, ok. For PREEMPT_HARDIRQS we thought about possibly utilizing
hw-level IRQ prioritization too - but it's quite inflexible in most IRQ
controller designs: the prioritization is rarely integrated with the CPU
and is often attached to the ACK/EOI-ing of the IRQ line (and an
unACK-ed IRQ can have side-effects).
So the thing we chose for PREEMPT_HARDIRQS was to do the prioritization
at the OS/scheduler level. And OS level handling of this is what we need
anyway: IRQ handlers are just the first, often tiny portion in a
critical workload that a system must perform. (we have softirqs,
signals, tasks, etc.) Nevertheless the door is open to utilize hw
capabilities of IRQ prioritization - we 'only' need standard driver and
/sys APIs to make use of them.
Ingo
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [PATCH] FRV: do_gettimeofday() should no longer use tickadj
2006-09-06 14:46 ` David Howells
` (2 preceding siblings ...)
2006-09-09 5:46 ` Ingo Molnar
@ 2006-09-11 10:46 ` David Howells
3 siblings, 0 replies; 138+ messages in thread
From: David Howells @ 2006-09-11 10:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Howells, john stultz, Adrian Bunk, Andrew Morton,
Arjan van de Ven, linux-kernel, Jeff Garzik, netdev,
Thomas Gleixner, Benjamin Herrenschmidt
Ingo Molnar <mingo@elte.hu> wrote:
> i cannot find Thomas' recent 2.6 one (Thomas, do you have a link to
> it?), but i did one 5 years ago:
>
> http://people.redhat.com/mingo/irq-rewrite-patches/irq-cleanup-2.4.15-B1.bz2
>
> in general it's a large but otherwise pretty dumb patch.
I wrote my own patch to test this last Friday. I found that removing all the
regs pointer passing from the interrupt code reduced interrupt entry with a
warm cache by 1 cpu cycle out of 87, and interrupt exit by 19 cycles out of 99.
I can't tell from that exactly how many instructions/memory accesses have been
removed since the FRV permits two instructions to be executed in one cycle
under some circumstances, and two registers to be stored/loaded in one
instruction.
But the main gain in the exit path has to be due to recovery of the clobbered
regs parameter due to a call inside a loop, possibly in handle_IRQ_event().
I'd expect i386 to do better in cycle reduction because it has fewer registers
and so getting one back should gain more.
David
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: 2.6.18-rc5-mm1 dependency on curses devel still there
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (27 preceding siblings ...)
2006-09-05 15:35 ` [PATCH] FRV: do_gettimeofday() should no longer use tickadj David Howells
@ 2006-09-05 16:00 ` Steve Fox
2006-09-06 23:06 ` [-mm patch] ATA_JMICRON: remove the superfluous ATA dependency Adrian Bunk
2006-09-06 23:07 ` [-mm patch] ACPI_SONY shouldn't default m Adrian Bunk
30 siblings, 0 replies; 138+ messages in thread
From: Steve Fox @ 2006-09-05 16:00 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-kernel-announce
On Fri, 01 Sep 2006 01:58:18 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
The dependency on having curses installed reported by Andy Whitcroft for
2.6.18-rc4-mm1 is still there. I've included the prior discussion below.
Could this patch be reverted or fixed to not build things which use
curses? Thanks.
Andy Whitcroft wrote:
> Andy Whitcroft wrote:
> > Andrew Morton wrote:
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm1/
> >>
> >
> >> git-lxdialog.patch
> >
> > This tree seems to change the Makefile dependancies in the kconfig
> > subdirectory such that a plain compile of the kernel leads to an attempt
> > to build the menuconfig targets. This in turn adds a new dependancy on
> > the curses development libraries.
> >
> > 08/15/06-05:23:09 building kernel - make -j4 vmlinux
> > HOSTCC scripts/kconfig/lxdialog/checklist.o
> > In file included from scripts/kconfig/lxdialog/checklist.c:24:
> > scripts/kconfig/lxdialog/dialog.h:31:20: error: curses.h:
> > No such file or directory
> >
> > This seems to come from this rather innocent sounding change in that tree:
> >
> > commit 9238251dddc15b52656e70b74dffe56193d01215
> > Author: Sam Ravnborg <sam@mars.ravnborg.org>
> > Date: Mon Jul 24 21:40:46 2006 +0200
> >
> > kconfig/lxdialog: refactor color support
> >
>
> Ok, reading the patch as if its git output isn't a good plan. The
> changeset appears to be this one:
>
> commit 49140e7b29bb1fcc195efef3e1c54c144dd2eff7
> Author: Sam Ravnborg <sam@mars.ravnborg.org>
> Date: Thu Jul 27 22:10:27 2006 +0200
>
> kconfig/menuconfig: lxdialog is now built-in
>
>
> > which also seems to change the Makefile about, specifically bringing the
> > sub Makefile into the top level one.
> >
> > [...]
> > - $(Q)$(MAKE) $(build)=scripts/kconfig/lxdialog
> > [...]
> > +# lxdialog stuff
> > +check-lxdialog := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
> > [...]
> >
> > Sam?
> >
> > -apw
Andy Whitcroft wrote:
> Sam Ravnborg wrote:
> > On Wed, Aug 16, 2006 at 10:41:59AM +0100, Andy Whitcroft wrote:
> >> This tree seems to change the Makefile dependancies in the kconfig
> >> subdirectory such that a plain compile of the kernel leads to an attempt
> >> to build the menuconfig targets. This in turn adds a new dependancy on
> >> the curses development libraries.
> > What I see is that "make defconfig" builds _all_ *config targets -
> > strange...
>
> Well it could be trying to build them all for me too, but as I don't
> have curses development libraries it would fail at that point. I don't
> think we want it to build the ones its not using. Thats daft :).
--
Steve Fox
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] ATA_JMICRON: remove the superfluous ATA dependency
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (28 preceding siblings ...)
2006-09-05 16:00 ` 2.6.18-rc5-mm1 dependency on curses devel still there Steve Fox
@ 2006-09-06 23:06 ` Adrian Bunk
2006-09-06 23:07 ` [-mm patch] ACPI_SONY shouldn't default m Adrian Bunk
30 siblings, 0 replies; 138+ messages in thread
From: Adrian Bunk @ 2006-09-06 23:06 UTC (permalink / raw)
To: Andrew Morton, Alan Cox; +Cc: linux-kernel, jgarzik, linux-ide
The dependency on ATA is no longer required since this option is now
inside an "if ATA" block.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc5-mm1/drivers/ata/Kconfig.old 2006-09-07 00:39:33.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/ata/Kconfig 2006-09-07 00:39:55.000000000 +0200
@@ -309,7 +309,7 @@
config ATA_JMICRON
tristate "JMicron non-AHCI support (Experimental)"
- depends on ATA && PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL
help
This option enables support for Jmicron ATA controllers
ports running in non-AHCI mode. Where possible you should
^ permalink raw reply [flat|nested] 138+ messages in thread* [-mm patch] ACPI_SONY shouldn't default m
2006-09-01 8:58 2.6.18-rc5-mm1 Andrew Morton
` (29 preceding siblings ...)
2006-09-06 23:06 ` [-mm patch] ATA_JMICRON: remove the superfluous ATA dependency Adrian Bunk
@ 2006-09-06 23:07 ` Adrian Bunk
2006-09-07 3:30 ` Andrew Morton
30 siblings, 1 reply; 138+ messages in thread
From: Adrian Bunk @ 2006-09-06 23:07 UTC (permalink / raw)
To: Andrew Morton, Bjorn Helgaas, Stelian Pop; +Cc: linux-kernel, linux-acpi
Drivers should default to n.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old 2006-09-07 00:49:37.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig 2006-09-07 00:50:01.000000000 +0200
@@ -251,7 +251,6 @@
config ACPI_SONY
tristate "Sony Laptop Extras"
depends on X86 && ACPI
- default m
---help---
This mini-driver drives the ACPI SNC device present in the
ACPI BIOS of the Sony Vaio laptops.
^ permalink raw reply [flat|nested] 138+ messages in thread* Re: [-mm patch] ACPI_SONY shouldn't default m
2006-09-06 23:07 ` [-mm patch] ACPI_SONY shouldn't default m Adrian Bunk
@ 2006-09-07 3:30 ` Andrew Morton
2006-09-07 4:41 ` Randy.Dunlap
0 siblings, 1 reply; 138+ messages in thread
From: Andrew Morton @ 2006-09-07 3:30 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Bjorn Helgaas, Stelian Pop, linux-kernel, linux-acpi
On Thu, 7 Sep 2006 01:07:00 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> Drivers should default to n.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old 2006-09-07 00:49:37.000000000 +0200
> +++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig 2006-09-07 00:50:01.000000000 +0200
> @@ -251,7 +251,6 @@
> config ACPI_SONY
> tristate "Sony Laptop Extras"
> depends on X86 && ACPI
> - default m
Not this one - I need it on my Vaio and I get sick of the option vanishing.
Make it depend on CONFIG_AKPM?
^ permalink raw reply [flat|nested] 138+ messages in thread
* Re: [-mm patch] ACPI_SONY shouldn't default m
2006-09-07 3:30 ` Andrew Morton
@ 2006-09-07 4:41 ` Randy.Dunlap
0 siblings, 0 replies; 138+ messages in thread
From: Randy.Dunlap @ 2006-09-07 4:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Bjorn Helgaas, Stelian Pop, linux-kernel, linux-acpi
On Wed, 6 Sep 2006 20:30:03 -0700 Andrew Morton wrote:
> On Thu, 7 Sep 2006 01:07:00 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > Drivers should default to n.
> >
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> > --- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old 2006-09-07 00:49:37.000000000 +0200
> > +++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig 2006-09-07 00:50:01.000000000 +0200
> > @@ -251,7 +251,6 @@
> > config ACPI_SONY
> > tristate "Sony Laptop Extras"
> > depends on X86 && ACPI
> > - default m
>
> Not this one - I need it on my Vaio and I get sick of the option vanishing.
> Make it depend on CONFIG_AKPM?
I'll ack that one. :)
otherwise I also agree with Adrian's patch...
---
~Randy
^ permalink raw reply [flat|nested] 138+ messages in thread