Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
> > In any case, doing PAGE_KERNEL_NOCACHE for DMA memory is incorrect on > > many architectures. So at this stage, there's no much option but ifdef I > > suspect for now until this is fixed properly. > > Ok. But, i am not sure whether Greg will agree to this. If, Ok, is the > following patch i sent earlier Ok ? > > http://lkml.org/lkml/2009/6/5/462, Not really. You probably want to use a constant (call it MY_DMA_MAP_PGPROT), and in a header, you have a bunch of ifdef's that set it to PAGE_KERNEL, PAGE_KERNEL_NOCACHE or PAGE_KERNEL_NC depending on what's needed. Today, you can pretty much assume that - x86*, sparc*, ia64*, alpha, ... needs PAGE_KERNEL - powerpc needs PAGE_KERNEL if !CONFIG_NOT_COHERENT_CACHE - powerpc needs PAGE_KERNEL_NC if CONFIG_NOT_COHERENT_CACHE - ARM and MIPS, I think, needs PAGE_KERNEL_NOCACHE - ... others I don't know. Cheers, Ben. > Regards-- > Subrata > > > > > It does make sense to want to have some memory like that shared between > > user space and DMA, though I don't know what the right approach that > > works on all archs is at this stage. Worth asking the Alsa guys, I think > > they have similar issues :-) > > > > But doing double buffering might do the trick fine for now. > > > > Cheers, > > Ben. > > > > > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Tue, Jun 9, 2009 at 20:34, Subrata Modak wrote:
> On Tue, 2009-06-09 at 13:50 +1000, Benjamin Herrenschmidt wrote:
>> On Sun, 2009-06-07 at 20:06 +0530, Subrata Modak wrote:
>> > On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote:
>> > > On Saturday 06 June 2009, Greg KH wrote:
>> > > > Frank and Ian, any thoughts about the vmap call in the
>> > > > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
>> > > > is the prealloc_buf buffer used for?
>> > >
>> > > It is a circular buffer used to hold data streaming either to or from a
>> > > board (for example when producing an analog output waveform). Reads and
>> > > writes to the device files read/write to the circular buffer, plus a few
>> > > drivers do dma directly to/from it. I personally don't have a problem
>> > > with requiring drivers to have their own dma buffers and making them copy
>> > > data between their private dma buffers and the main circular buffer. I
>> > > guess the original design wanted to support zero-copy dma.
>> >
>> > Great to hear that. How about a patch that solves my build problem on
>> > PPC64(the problem seems to be existing for long) ?
>>
>> In any case, doing PAGE_KERNEL_NOCACHE for DMA memory is incorrect on
>> many architectures. So at this stage, there's no much option but ifdef I
>> suspect for now until this is fixed properly.
>
> Ok. But, i am not sure whether Greg will agree to this. If, Ok, is the
> following patch i sent earlier Ok ?
>
> http://lkml.org/lkml/2009/6/5/462,
Your patch helps powerpc only. Compilation is still broken on most
other architectures.
>> It does make sense to want to have some memory like that shared between
>> user space and DMA, though I don't know what the right approach that
>> works on all archs is at this stage. Worth asking the Alsa guys, I think
>> they have similar issues :-)
>>
>> But doing double buffering might do the trick fine for now.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Tue, 2009-06-09 at 13:50 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2009-06-07 at 20:06 +0530, Subrata Modak wrote: > > On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote: > > > On Saturday 06 June 2009, Greg KH wrote: > > > > Frank and Ian, any thoughts about the vmap call in the > > > > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what > > > > is the prealloc_buf buffer used for? > > > > > > It is a circular buffer used to hold data streaming either to or from a > > > board (for example when producing an analog output waveform). Reads and > > > writes to the device files read/write to the circular buffer, plus a few > > > drivers do dma directly to/from it. I personally don't have a problem > > > with requiring drivers to have their own dma buffers and making them copy > > > data between their private dma buffers and the main circular buffer. I > > > guess the original design wanted to support zero-copy dma. > > > > Great to hear that. How about a patch that solves my build problem on > > PPC64(the problem seems to be existing for long) ? > > In any case, doing PAGE_KERNEL_NOCACHE for DMA memory is incorrect on > many architectures. So at this stage, there's no much option but ifdef I > suspect for now until this is fixed properly. Ok. But, i am not sure whether Greg will agree to this. If, Ok, is the following patch i sent earlier Ok ? http://lkml.org/lkml/2009/6/5/462, Regards-- Subrata > > It does make sense to want to have some memory like that shared between > user space and DMA, though I don't know what the right approach that > works on all archs is at this stage. Worth asking the Alsa guys, I think > they have similar issues :-) > > But doing double buffering might do the trick fine for now. > > Cheers, > Ben. > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Sun, 2009-06-07 at 20:06 +0530, Subrata Modak wrote: > On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote: > > On Saturday 06 June 2009, Greg KH wrote: > > > Frank and Ian, any thoughts about the vmap call in the > > > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what > > > is the prealloc_buf buffer used for? > > > > It is a circular buffer used to hold data streaming either to or from a > > board (for example when producing an analog output waveform). Reads and > > writes to the device files read/write to the circular buffer, plus a few > > drivers do dma directly to/from it. I personally don't have a problem > > with requiring drivers to have their own dma buffers and making them copy > > data between their private dma buffers and the main circular buffer. I > > guess the original design wanted to support zero-copy dma. > > Great to hear that. How about a patch that solves my build problem on > PPC64(the problem seems to be existing for long) ? In any case, doing PAGE_KERNEL_NOCACHE for DMA memory is incorrect on many architectures. So at this stage, there's no much option but ifdef I suspect for now until this is fixed properly. It does make sense to want to have some memory like that shared between user space and DMA, though I don't know what the right approach that works on all archs is at this stage. Worth asking the Alsa guys, I think they have similar issues :-) But doing double buffering might do the trick fine for now. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote: > On Saturday 06 June 2009, Greg KH wrote: > > Frank and Ian, any thoughts about the vmap call in the > > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what > > is the prealloc_buf buffer used for? > > It is a circular buffer used to hold data streaming either to or from a > board (for example when producing an analog output waveform). Reads and > writes to the device files read/write to the circular buffer, plus a few > drivers do dma directly to/from it. I personally don't have a problem > with requiring drivers to have their own dma buffers and making them copy > data between their private dma buffers and the main circular buffer. I > guess the original design wanted to support zero-copy dma. Great to hear that. How about a patch that solves my build problem on PPC64(the problem seems to be existing for long) ? Regards-- Subrata > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Saturday 06 June 2009, Greg KH wrote: > Frank and Ian, any thoughts about the vmap call in the > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what > is the prealloc_buf buffer used for? It is a circular buffer used to hold data streaming either to or from a board (for example when producing an analog output waveform). Reads and writes to the device files read/write to the circular buffer, plus a few drivers do dma directly to/from it. I personally don't have a problem with requiring drivers to have their own dma buffers and making them copy data between their private dma buffers and the main circular buffer. I guess the original design wanted to support zero-copy dma. signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Sat, Jun 06, 2009 at 02:16:46PM +1000, Benjamin Herrenschmidt wrote: > On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote: > > > > > > Read my reply to Greg. Why the heck are you trying to map memory > > > non-cacheable in the first place ? > > > > I agree, this is extremely fishy. > > > > I guess the issue is that the driver wants consistent DMA memory > > but wants to allocate a huge area vmap() style. > > That's my guess too, and I suppose we should be able to provide an > appropriate interface for that... There are two aspects that > are completely separate here: > > - One is the allocation of the pages themselves which much match > the various criteria for DMA'bility to the target device (fit the > DMA mask, etc...) > > - One is the creation of the virtual mapping in kernel space for which > appropriate pgprot for DMA must be provided. > > For the first one, I don't know how legit it would be to allocate the > pages using dma_alloc_coherent one page at a time and try to figure out > the struct page * out of it. Sounds fishy and possibly non-portable. So > appart from using normal GFP and crossing fingers I'm not sure what > would be the right way to obtain the pages in the first place. Maybe we > should provide something. > > The second could be as simple as having a pgprot_dma_coherent() like we > have a pgprot_uncached() for example, which would be either uncached or > cached depending on the consistency of DMA on the platform. But we need > to run that through things like MIPS which may have additional virtual > address space requirements. All good questions. So, let's ask the original authors :) Frank and Ian, any thoughts about the vmap call in the comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what is the prealloc_buf buffer used for? The problem is that PAGE_KERNEL_NOCACHE isn't a "standard" interface, and not all architectures support it. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote: > > > > Read my reply to Greg. Why the heck are you trying to map memory > > non-cacheable in the first place ? > > I agree, this is extremely fishy. > > I guess the issue is that the driver wants consistent DMA memory > but wants to allocate a huge area vmap() style. That's my guess too, and I suppose we should be able to provide an appropriate interface for that... There are two aspects that are completely separate here: - One is the allocation of the pages themselves which much match the various criteria for DMA'bility to the target device (fit the DMA mask, etc...) - One is the creation of the virtual mapping in kernel space for which appropriate pgprot for DMA must be provided. For the first one, I don't know how legit it would be to allocate the pages using dma_alloc_coherent one page at a time and try to figure out the struct page * out of it. Sounds fishy and possibly non-portable. So appart from using normal GFP and crossing fingers I'm not sure what would be the right way to obtain the pages in the first place. Maybe we should provide something. The second could be as simple as having a pgprot_dma_coherent() like we have a pgprot_uncached() for example, which would be either uncached or cached depending on the consistency of DMA on the platform. But we need to run that through things like MIPS which may have additional virtual address space requirements. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Benjamin Herrenschmidt Date: Sat, 06 Jun 2009 09:32:29 +1000 > >> I tried this. But, with some catch. ‘PAGE_KERNEL_NOCACHE’ seems to be the >> choice for majority of architectures like frv, m32r, sh, x86, etc, as Geert >> mentions below. However, i believe POWERPC defines it as ‘PAGE_KERNEL_NC‘ >> found at arch/powerpc/include/asm/pte-common.h. >> >> Paul/Banjamin, >> Can you please confirm this ? > > Read my reply to Greg. Why the heck are you trying to map memory > non-cacheable in the first place ? I agree, this is extremely fishy. I guess the issue is that the driver wants consistent DMA memory but wants to allocate a huge area vmap() style. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
> I tried this. But, with some catch. ‘PAGE_KERNEL_NOCACHE’ seems to be the
> choice for majority of architectures like frv, m32r, sh, x86, etc, as Geert
> mentions below. However, i believe POWERPC defines it as ‘PAGE_KERNEL_NC‘
> found at arch/powerpc/include/asm/pte-common.h.
>
> Paul/Banjamin,
> Can you please confirm this ?
Read my reply to Greg. Why the heck are you trying to map memory
non-cacheable in the first place ?
Cheers
Ben.
> The below patch fixes the build error.
>
> Signed-off-by: Subrata Modak
> ---
>
> --- linux-2.6.30-rc8/drivers/staging/comedi/drivers.c.orig2009-06-05
> 12:46:35.0 -0500
> +++ linux-2.6.30-rc8/drivers/staging/comedi/drivers.c 2009-06-05
> 13:03:31.0 -0500
> @@ -43,9 +43,13 @@
> #include
> #include
> #include
> -
> #include
> #include
> +#ifdef __powerpc64__
> +#include
> +#else
> +#include
> +#endif
>
> static int postconfig(struct comedi_device *dev);
> static int insn_rw_emulate_bits(struct comedi_device *dev, struct
> comedi_subdevice *s,
> @@ -492,8 +496,13 @@ int comedi_buf_alloc(struct comedi_devic
> }
> if (i == n_pages) {
> async->prealloc_buf =
> +#ifdef __powerpc64__
> + vmap(pages, n_pages, VM_MAP,
> + PAGE_KERNEL_NC);
> +#else
> vmap(pages, n_pages, VM_MAP,
> PAGE_KERNEL_NOCACHE);
> +#endif
> }
> if (pages) {
> vfree(pages);
>
> ---
> Regards--
> Subrata
>
> > PAGE_KERNEL_NOCACHE is defined on a few architectures only, namely
> > frv, m32r, mn10300, sh, and x86[*]. On all others, it will fail.
> >
> > [*] Interestingly, sparc refers to it in one of its include files,
> > without providing a
> > definition, Probably that code is unused.
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> > ge...@linux-m68k.org
> >
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Fri, 2009-06-05 at 11:26 -0700, Greg KH wrote: > Should the comedi layer just not be using PAGE_KERNEL_NOCACHE here? I > can't believe that we need to do something like this in a driver. What > should the proper fix for this be? Actualy, I think powerpc -had- PAGE_KERNEL_NOCACHE and I removed it ... Oh well... My understanding was that the exposed interface isn't that but instead pgprot_noncached(). Nowadays we provide these on ppc: #define pgprot_noncached(prot)(__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \ _PAGE_NO_CACHE | _PAGE_GUARDED)) #define pgprot_noncached_wc(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \ _PAGE_NO_CACHE)) #define pgprot_cached(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \ _PAGE_COHERENT)) #define pgprot_cached_wthru(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \ _PAGE_COHERENT | _PAGE_WRITETHRU)) Now, of course, expect interesting problems if you use it in vmap, since you are mapping struct pages, you are effectively mapping memory. On some platforms, it's absolutely illegal to map memory non-cacheable while this memory is mapped cacheable elsewhere and can be fatal. But the pages you are mapping here, I suppose, are also part of the linear mapping which is ... cacheable. Why would you need that non-cacheable mapping in the first place ? If it's for DMA, it's the wrong interface I believe Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Fri, Jun 05, 2009 at 01:26:25PM -0500, Subrata Modak wrote: > >On Thu, 2009-06-04 at 22:40 +0200, Geert Uytterhoeven wrote: > >On Thu, Jun 4, 2009 at 20:07, Greg KH wrote: > > > On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote: > > >> CC [M] drivers/staging/comedi/drivers.o > > >> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’: > > >> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’ > > >> undeclared (first use in this function) > > >> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier > > >> is reported only once > > >> drivers/staging/comedi/drivers.c:496: error: for each function it > > >> appears in.) > > >> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1 > > >> make[2]: *** [drivers/staging/comedi] Error 2 > > >> make[1]: *** [drivers/staging] Error 2 > > >> make: *** [drivers] Error 2 > > >> > > >> Is it still normal to expect this failure ? > > > > > > No. > > > > > >> I reported them long back during April: > > >> http://www.gossamer-threads.com/lists/linux/kernel/1065227, > > > > > > Yes, and I took some patches that were supposed to fix this. I can't > > > duplicate this here, care to send a patch that would fix it? > > I tried this. But, with some catch. ‘PAGE_KERNEL_NOCACHE’ seems to be the > choice for majority of architectures like frv, m32r, sh, x86, etc, as Geert > mentions below. However, i believe POWERPC defines it as ‘PAGE_KERNEL_NC‘ > found at arch/powerpc/include/asm/pte-common.h. > > Paul/Banjamin, > Can you please confirm this ? > > The below patch fixes the build error. Ick, that's a mess. > +#ifdef __powerpc64__ > + vmap(pages, n_pages, VM_MAP, > + PAGE_KERNEL_NC); > +#else > vmap(pages, n_pages, VM_MAP, > PAGE_KERNEL_NOCACHE); > +#endif Should the comedi layer just not be using PAGE_KERNEL_NOCACHE here? I can't believe that we need to do something like this in a driver. What should the proper fix for this be? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
>On Thu, 2009-06-04 at 22:40 +0200, Geert Uytterhoeven wrote:
>On Thu, Jun 4, 2009 at 20:07, Greg KH wrote:
> > On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote:
> >> CC [M] drivers/staging/comedi/drivers.o
> >> drivers/staging/comedi/drivers.c: In function âcomedi_buf_allocâ:
> >> drivers/staging/comedi/drivers.c:496: error: âPAGE_KERNEL_NOCACHEâ
> >> undeclared (first use in this function)
> >> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier
> >> is reported only once
> >> drivers/staging/comedi/drivers.c:496: error: for each function it appears
> >> in.)
> >> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> >> make[2]: *** [drivers/staging/comedi] Error 2
> >> make[1]: *** [drivers/staging] Error 2
> >> make: *** [drivers] Error 2
> >>
> >> Is it still normal to expect this failure ?
> >
> > No.
> >
> >> I reported them long back during April:
> >> http://www.gossamer-threads.com/lists/linux/kernel/1065227,
> >
> > Yes, and I took some patches that were supposed to fix this. I can't
> > duplicate this here, care to send a patch that would fix it?
I tried this. But, with some catch. âPAGE_KERNEL_NOCACHEâ seems to be the
choice for majority of architectures like frv, m32r, sh, x86, etc, as Geert
mentions below. However, i believe POWERPC defines it as âPAGE_KERNEL_NCâ
found at arch/powerpc/include/asm/pte-common.h.
Paul/Banjamin,
Can you please confirm this ?
The below patch fixes the build error.
Signed-off-by: Subrata Modak
---
--- linux-2.6.30-rc8/drivers/staging/comedi/drivers.c.orig 2009-06-05
12:46:35.0 -0500
+++ linux-2.6.30-rc8/drivers/staging/comedi/drivers.c 2009-06-05
13:03:31.0 -0500
@@ -43,9 +43,13 @@
#include
#include
#include
-
#include
#include
+#ifdef __powerpc64__
+#include
+#else
+#include
+#endif
static int postconfig(struct comedi_device *dev);
static int insn_rw_emulate_bits(struct comedi_device *dev, struct
comedi_subdevice *s,
@@ -492,8 +496,13 @@ int comedi_buf_alloc(struct comedi_devic
}
if (i == n_pages) {
async->prealloc_buf =
+#ifdef __powerpc64__
+ vmap(pages, n_pages, VM_MAP,
+ PAGE_KERNEL_NC);
+#else
vmap(pages, n_pages, VM_MAP,
PAGE_KERNEL_NOCACHE);
+#endif
}
if (pages) {
vfree(pages);
---
Regards--
Subrata
> PAGE_KERNEL_NOCACHE is defined on a few architectures only, namely
> frv, m32r, mn10300, sh, and x86[*]. On all others, it will fail.
>
> [*] Interestingly, sparc refers to it in one of its include files,
> without providing a
> definition, Probably that code is unused.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Thu, Jun 4, 2009 at 20:07, Greg KH wrote:
> On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote:
>> CC [M] drivers/staging/comedi/drivers.o
>> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
>> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’
>> undeclared (first use in this function)
>> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is
>> reported only once
>> drivers/staging/comedi/drivers.c:496: error: for each function it appears
>> in.)
>> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
>> make[2]: *** [drivers/staging/comedi] Error 2
>> make[1]: *** [drivers/staging] Error 2
>> make: *** [drivers] Error 2
>>
>> Is it still normal to expect this failure ?
>
> No.
>
>> I reported them long back during April:
>> http://www.gossamer-threads.com/lists/linux/kernel/1065227,
>
> Yes, and I took some patches that were supposed to fix this. I can't
> duplicate this here, care to send a patch that would fix it?
PAGE_KERNEL_NOCACHE is defined on a few architectures only, namely
frv, m32r, mn10300, sh, and x86[*]. On all others, it will fail.
[*] Interestingly, sparc refers to it in one of its include files,
without providing a
definition, Probably that code is unused.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote: > CC [M] drivers/staging/comedi/drivers.o > drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’: > drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’ undeclared > (first use in this function) > drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is > reported only once > drivers/staging/comedi/drivers.c:496: error: for each function it appears in.) > make[3]: *** [drivers/staging/comedi/drivers.o] Error 1 > make[2]: *** [drivers/staging/comedi] Error 2 > make[1]: *** [drivers/staging] Error 2 > make: *** [drivers] Error 2 > > Is it still normal to expect this failure ? No. > I reported them long back during April: > http://www.gossamer-threads.com/lists/linux/kernel/1065227, Yes, and I took some patches that were supposed to fix this. I can't duplicate this here, care to send a patch that would fix it? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
CC [M] drivers/staging/comedi/drivers.o drivers/staging/comedi/drivers.c: In function âcomedi_buf_allocâ: drivers/staging/comedi/drivers.c:496: error: âPAGE_KERNEL_NOCACHEâ undeclared (first use in this function) drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is reported only once drivers/staging/comedi/drivers.c:496: error: for each function it appears in.) make[3]: *** [drivers/staging/comedi/drivers.o] Error 1 make[2]: *** [drivers/staging/comedi] Error 2 make[1]: *** [drivers/staging] Error 2 make: *** [drivers] Error 2 Is it still normal to expect this failure ? I reported them long back during April: http://www.gossamer-threads.com/lists/linux/kernel/1065227, Regards-- Subrata = .config below: = # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc8 # Thu Jun 4 03:54:53 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SYSVIPC is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=y # CONFIG_TREE_RCU_TRACE is not set CONFIG_PREEMPT_RCU_TRACE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set # CONFIG_SLQB_ALLOCATOR is not set CONFIG_SLOB=y CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=1 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y # CONFIG_BLOCK is not set # CONFIG_FREEZER is not set # # Platform support # CONFIG_PPC_PSERIES=y # CONFIG_PPC_SPLPAR is not set CONFIG_EEH=y # CONFIG_SCANLOG is not set CONFIG_LPARCFG=y # CONFIG_PPC_PSERIES_DEBUG is not set CONFIG_PPC_SMLPAR=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_PMAC is not set CONFIG_PPC_MAPLE=y CONFIG_PPC_PASEMI=y # # PA Semi PWRficient options # CONFIG_PPC_PASEMI_IOMMU=y # CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE is not set CONFIG_PPC_PS3=y # # PS3 Platform Options # # CONFIG_PS3_ADVANCED is not set CONFIG_PS3_HTAB_SIZE=20 CONFIG
