Adrian Bunk wrote:
Adding a dependency of XEN on X86_CMPXCHG should not be a problem and
not prevent any reasonable real-life usage.
But what worries me is that a seemingly architecture independent
driver uses a function only available in some configurations.
Still present as of 2.6.22-
On Sat, Jun 02, 2007 at 03:57:12PM +0200, Adrian Bunk wrote:
> I'm getting the following compile error in 2.6.22-rc3-mm1 with
> CONFIG_X86_CMPXCHG=n (with -Werror-implicit-function-declaration -
> otherwise it would be a link error):
>
> <-- snip -->
>
> ...
> CC drivers/xen/grant-tabl
On Mon, 04 Jun 2007 14:00:56 -0400 [EMAIL PROTECTED] wrote:
> On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>
> Under 22-rc2-mm1, if my VPN connection got reset, ppp0 just quietly went away.
>
>
On Tue, Jun 05, 2007 at 09:17:35AM -0700, Andrew Morton wrote:
> On Tue, 05 Jun 2007 14:05:36 +0200 Zoltan Boszormenyi <[EMAIL PROTECTED]>
> wrote:
>
> > Hi!
> >
> > > -drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
> > > -drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp5
On Tue, 05 Jun 2007 14:05:36 +0200 Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > -drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
> > -drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix.patch
> > -drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp
On Wed, 2007-05-30 at 23:58 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
drivers/built-in.o: In function `ahci_port_start':
/home/rusty/linux-2.6.22-rc3-mm1/drivers/ata/ahci.c:1631: undefined reference
to `ahci_port_resume'
Hi!
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix-tidy.patch
Merged into mainline or a subsystem tree
They aren't. They are
Hello.
I looked at your long attachment. It seems, you have problems with hardware.
Would you please check your root drive (sde) by badblocks program?
Thanks,
Edward.
Berck E. Nash wrote:
All appears to work fine, until I try to boot a kernel with a Reiser4 /
partition. Then I get endless err
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > commenting out check_nmi_watchdog() produces a booting kernel too. So
> > it's a side-effect of check_nmi_watchdog(). Problem is, nothing in
> > nmi.c changed in -mm1 AFAICS.
>
> ah, plain -rc3 hangs
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> commenting out check_nmi_watchdog() produces a booting kernel too. So
> it's a side-effect of check_nmi_watchdog(). Problem is, nothing in
> nmi.c changed in -mm1 AFAICS.
ah, plain -rc3 hangs too. So it's one of these commits i guess:
commit 1eeb66a1
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i have put an early_printk() into the NMI handler but it never
> triggers.
commenting out check_nmi_watchdog() produces a booting kernel too. So
it's a side-effect of check_nmi_watchdog(). Problem is, nothing in nmi.c
changed in -mm1 AFAICS.
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yeah. I tried !hres and !dynticks too and that doesnt make any
> difference to the end result - so my guess is on the NMI watchdog
> re-programming thing on K8 CPUs (running the 32-bit kernel), which is
> done in every NMI tick. check_watchdog() for s
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Jun 2007 11:11:51 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm, mm1 hangs during bootup on one of my boxes:
> >
> > Calling initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44()
> > initcall 0xc0628d39: pci_mmcfg_late_i
On Tue, 5 Jun 2007 11:11:51 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, mm1 hangs during bootup on one of my boxes:
>
> Calling initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44()
> initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44() returned 0.
> initcall 0xc062
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the NMI watchdog warning is a bit weird:
>
> Calling initcall 0xc0613e4f: check_nmi_watchdog+0x0/0x1a8()
> Testing NMI watchdog ... CPU#0: NMI appears to be stuck (0->0)!
> CPU#1: NMI appears to be stuck (0->0)!
> initcall 0xc0613e4f: check_nmi_watc
On Tue, Jun 05, 2007 at 01:52:38AM +0200, Martin Peschke wrote:
> Andrew Morton wrote:
> >On Sat, 2 Jun 2007 19:14:25 +0200
> >Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> >>statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
> >>
> >>shows why __attribute__((we
Andrew Morton wrote:
On Sat, 2 Jun 2007 19:14:25 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
shows why __attribute__((weak)) is harmful because you don't see if a
required non-weak implemtation is missing:
On Sat, 2 Jun 2007 19:14:25 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
>
> shows why __attribute__((weak)) is harmful because you don't see if a
> required non-weak implemtation is missing:
>
> In this
On Sat, 2007-06-02 at 13:11 -0600, Berck E. Nash wrote:
> All appears to work fine, until I try to boot a kernel with a Reiser4 /
> partition. Then I get endless errors of the sort:
>
> [ 206.349450] sd 1:0:0:0: [sdc] Result: hostbyte=DID_BAD_TARGET
> driverbyte=DRIVER_OK,SUGGEST_OK
>
> (See at
Yeah, allmodconfig tends to fall over in a heap on a lot of the
less-lavishly-maintained architectures.
To be fair, almost all of the powerpc allmodconfig build
problems are caused by x86-only drivers (and most of those
I doubt still work on x86, even).
Segher
-
To unsubscribe from this list:
On Fri, 2007-06-01 at 14:02 -0700, Andrew Morton wrote:
>
>
> Yeah, allmodconfig tends to fall over in a heap on a lot of the
> less-lavishly-maintained architectures. If any of these are specific
> to
> -mm then I guess we should fix them up, prevent the kernel from
> actually
> going backwards
On Fri, Jun 01, 2007 at 03:47:35PM -0700, Andrew Morton wrote:
> Right. I did a lot of tricksy work for rc3-mm1 to merge git-ocfs2 on top
> of Nick's stuff. Then I repulled your tree and lost it all. This is
> because I was dumb and I fixed rc3-mm1's git-ocfs.patch rather than doing a
> separate
On Fri, 1 Jun 2007 15:33:02 -0700
Mark Fasheh <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 01, 2007 at 03:25:37PM -0700, Andrew Morton wrote:
> > > Andrew, if this is ok with you I'd really like to see that fix in -mm.
> > > Ocfs2
> > > shared write mmap will instantly deadlock without it.
> >
> > u
On Fri, Jun 01, 2007 at 03:25:37PM -0700, Andrew Morton wrote:
> > Andrew, if this is ok with you I'd really like to see that fix in -mm. Ocfs2
> > shared write mmap will instantly deadlock without it.
>
> ug, OK. I get a ginormous reject when merging ocfs2 on Nick's stuff which
> I've been large
On Fri, 1 Jun 2007 15:01:18 -0700
Mark Fasheh <[EMAIL PROTECTED]> wrote:
> On Thu, May 31, 2007 at 10:20:39PM -0700, Mark Fasheh wrote:
> > Ok. So how about the attached patch? It's a bit different than discussed,
> > but I think it's much cleaner because it preserves the current behavior of
> > t
On Thu, May 31, 2007 at 10:20:39PM -0700, Mark Fasheh wrote:
> Ok. So how about the attached patch? It's a bit different than discussed,
> but I think it's much cleaner because it preserves the current behavior of
> the callback and keeps that bit of page locking inside core code. Not tested
> as o
> > > > This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> > > > in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to
> > > > find
> > > > the patch to blame hmm.
> > > >
> > > > arch/powerpc/platforms/cell/spufs/file.c: In function
> > > > 'spufs_mem_mmap
On Fri, 1 Jun 2007 22:50:58 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> > > This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> > > in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> > > the patch to blame hmm.
> > >
> > > arch/powerpc/platforms/
> > This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> > in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> > the patch to blame hmm.
> >
> > arch/powerpc/platforms/cell/spufs/file.c: In function
> > 'spufs_mem_mmap_fault':
> > arch/powerpc/platforms/c
On (01/06/07 10:00), Andrew Morton didst pronounce:
> On Fri, 1 Jun 2007 17:42:04 +0100 [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > mm/memory.c: In function `do_wp_page':
> > mm/memory.c:1700: error: parse error before "__changed"
> > mm/memory.c:1700: error: parse error before ')' token
> > mm/me
On Fri, 1 Jun 2007 17:42:04 +0100 [EMAIL PROTECTED] (Mel Gorman) wrote:
> mm/memory.c: In function `do_wp_page':
> mm/memory.c:1700: error: parse error before "__changed"
> mm/memory.c:1700: error: parse error before ')' token
> mm/memory.c:1704: error: parse error before "ret"
this?
--- a/inclu
On Thu, 31 May 2007 15:10:05 -0700,
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Cornelia, afaict your patch has no actual delendency upon Dan's
> dma-mapping-prevent-dma-dependent-code-from-linking-on.patch, correct? If
> so, I can merge it via James and then merge Dan's patch once James has
> mer
"Michael Ellerman" <[EMAIL PROTECTED]> writes:
> On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
>>
> ...
>> +msi-fix-the-ordering-of-msix-irqs.patch
>> +msi-mask-the-msix-vector-before-we-unmap-it.patch
> ...
>> 2.6.22 probable-queue
>
> I think these two should be in the 2.6.22 definite-qu
On Fri, Jun 01, 2007 at 03:53:49AM +0200, Nick Piggin wrote:
> On Thu, May 31, 2007 at 06:45:17PM -0700, Mark Fasheh wrote:
> > On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote:
> > > > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock
> > > > the
> > > > page, so lo
On 5/31/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
...
+msi-fix-the-ordering-of-msix-irqs.patch
+msi-mask-the-msix-vector-before-we-unmap-it.patch
...
2.6.22 probable-queue
I think these two should be in the 2.6.22 definite-queue, unless Eric disagrees.
cheers
-
To unsubscribe from thi
Andrew Morton wrote:
On Thu, 31 May 2007 23:01:15 -0300 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
- Merged the convert-cpusets-to-container-infrastructure patches.
On Thu, 31 May 2007 23:01:15 -0300 Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> >
> > - Merged the convert-cpusets-to-container-infrastructure patches. These
> > will pr
Hi,
On Fri, Jun 01, 2007 at 12:27:02AM +0200, Michal Piotrowski wrote:
> On 01/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
> >>
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> >
> >Build
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
- Merged the convert-cpusets-to-container-infrastructure patches. These
will probably be dropped and redone.
x86 things
+add-select-phylib-to-the-ucc_geth-kconfig-option.pa
On Thu, May 31, 2007 at 06:45:17PM -0700, Mark Fasheh wrote:
> On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote:
> > > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the
> > > page, so long as it's returned in a locked state? Though, do we even need
> > > the page
On Fri, Jun 01, 2007 at 03:34:02AM +0200, Nick Piggin wrote:
> > Here's a nasty idea... Would it be valid for ->page_mkwrite to unlock the
> > page, so long as it's returned in a locked state? Though, do we even need
> > the page lock that early? It seemed to me that you were adding it for
> > cons
On Thu, May 31, 2007 at 06:24:40PM -0700, Mark Fasheh wrote:
> On Fri, Jun 01, 2007 at 03:01:29AM +0200, Nick Piggin wrote:
> > Ah, I didn't realise you were using that yet. I expect ocfs2 is using
> > VM_CAN_INVALIDATE there anyway.
> >
> > Hmm, this becomes easier to deal with after page_mkwrite
On Fri, Jun 01, 2007 at 03:01:29AM +0200, Nick Piggin wrote:
> Ah, I didn't realise you were using that yet. I expect ocfs2 is using
> VM_CAN_INVALIDATE there anyway.
>
> Hmm, this becomes easier to deal with after page_mkwrite is merged with
> ->fault. But for now, can we just lock the page at th
On Thu, May 31, 2007 at 04:13:54PM -0700, Mark Fasheh wrote:
> On Wed, May 30, 2007 at 11:58:23PM -0700, Andrew Morton wrote:
> > git-ocfs2.patch
>
> Andrew, thanks for getting that back in there.
>
>
> mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch broke ocfs2 shared
> writable mmap
On Wed, May 30, 2007 at 11:58:23PM -0700, Andrew Morton wrote:
> git-ocfs2.patch
Andrew, thanks for getting that back in there.
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch broke ocfs2 shared
writable mmap. We hang on a page lock because ->page_mkwrite() is
being called with the pa
On Thu, 31 May 2007 18:05:04 -0400
[EMAIL PROTECTED] wrote:
> On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>
> Builds, boots, seems to be behaving on my laptop (Dell D820, X86_64).
cool, thanks.
On Thu, 31 May 2007 16:13:38 +0100
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Thu, May 31, 2007 at 08:35:13AM -0400, Jeff Garzik wrote:
> > Cornelia Huck wrote:
> > >On Thu, 31 May 2007 06:15:57 -0600,
> > >Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> > >
> > >>On Thu, May 31, 2007 at 02:09:
On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
Builds, boots, seems to be behaving on my laptop (Dell D820, X86_64).
Meta-question: Is there a useful address/mailbox/webpage to toss *working*
reports
On Thursday, 31 May 2007 23:25, Michal Piotrowski wrote:
> On 31/05/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > On Thursday, 31 May 2007 17:29, Michal Piotrowski wrote:
> > > Hi,
> > >
> > > Andrew Morton napisał(a):
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6
On Thursday, 31 May 2007 21:58, Rafael J. Wysocki wrote:
> On Thursday, 31 May 2007 17:29, Michal Piotrowski wrote:
> > Hi,
> >
> > Andrew Morton napisał(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> > >
> >
> > FYI suspend to disk doesn't w
On Thu, 31 May 2007 22:43:18 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello
>
> This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
> in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
> the patch to blame hmm.
>
> arch/powerpc/platforms/cell
Hello
This is from iMac G3. The spufs_mem_mmap_fault() code looks bad
in arch/powerpc/platforms/cell/spufs/file.c but somehow I'm unable to find
the patch to blame hmm.
arch/powerpc/platforms/cell/spufs/file.c: In function 'spufs_mem_mmap_fault':
arch/powerpc/platforms/cell/spufs/file.c:1
On Thursday, 31 May 2007 17:29, Michal Piotrowski wrote:
> Hi,
>
> Andrew Morton napisał(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> >
>
> FYI suspend to disk doesn't work anymore on my box, system hangs after
> "Suspending console(s)" mess
On Thu, 31 May 2007, Andrew Morton wrote:
> we're not disbling local irqs on the cpu hotplug path.
>
> Could do local_irq_disable() in slab_cpuup_callback(), I guess.
Ahh I see.
SLUB: Fix locking for hotplug callbacks.
Hotplug callbacks seem to be performed with interrupts enabled. Slub requi
On Thu, 31 May 2007 11:41:22 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > Perhaps a suitable fix would be local_irq_disable() in flush_slab().
>
> As far as I can tell: Interrupts are always disabled when flush_slab is
> run.
>
> Sometimes we use spin_lock_irqsave for the list_
On Thu, 31 May 2007, Andrew Morton wrote:
> > l *0xc0181288
> > 0xc0181288 is in add_partial (/home/devel/linux-mm/mm/slub.c:1193).
> > 1188}
> > 1189
> > 1190static void add_partial(struct kmem_cache_node *n, struct page
> > *page)
> > 1191{
> > 1192spin_lock(&n->list_loc
On Thu, 31 May 2007 19:53:07 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Andrew Morton napisa__(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
> >
>
> CPU hotplug test triggered this
>
> [ 4972.038008] CPU 1 is now offline
> [ 4972.0414
Michal Piotrowski napisał(a):
> Andrew Morton napisał(a):
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>>
>
> CPU hotplug test triggered this
>
> [ 4972.038008] CPU 1 is now offline
> [ 4972.041411] lockdep: not fixing up alternatives.
> [ 4972.05155
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>
CPU hotplug test triggered this
[ 4972.038008] CPU 1 is now offline
[ 4972.041411] lockdep: not fixing up alternatives.
[ 4972.051553]
[ 4972.051555] ==
Hi,
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
>
FYI suspend to disk doesn't work anymore on my box, system hangs after
"Suspending console(s)" message.
[ 186.297753] Shrinking memory... -\|/-\|done (113064 pag
On Thu, May 31, 2007 at 08:35:13AM -0400, Jeff Garzik wrote:
> Cornelia Huck wrote:
> >On Thu, 31 May 2007 06:15:57 -0600,
> >Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> >
> >>On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
> >>>I split those functions out into a new file. Builds on
On Thu, 31 May 2007 08:35:13 -0400,
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Thu, 31 May 2007 06:15:57 -0600,
> > Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> >
> >> On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
> >>> I split those functions out into a
Cornelia Huck wrote:
On Thu, 31 May 2007 06:15:57 -0600,
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
I split those functions out into a new file. Builds on s390 and i386.
Why not just put #ifdef CONFIG_HAS_DMA / #endif around the pa
On Thu, 31 May 2007 06:15:57 -0600,
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
> > I split those functions out into a new file. Builds on s390 and i386.
>
> Why not just put #ifdef CONFIG_HAS_DMA / #endif around the pair of
> functio
On Thu, May 31, 2007 at 02:09:22PM +0200, Cornelia Huck wrote:
> I split those functions out into a new file. Builds on s390 and i386.
Why not just put #ifdef CONFIG_HAS_DMA / #endif around the pair of
functions? I don't see the need to add a new Kconfig symbol and a new
file for this.
-
To unsu
On Wed, 30 May 2007 23:58:23 -0700,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
With
> +dma-mapping-prevent-dma-dependent-code-from-linking-on.patch
scsi fails to build on !HAS_DMA architectures:
driver
66 matches
Mail list logo
