linux.kernel - 3 new messages in 3 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* x86: fix out of order of gsi -- partial - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/58949e2872365c61?hl=en
* fix problems with NETIF_F_HIGHDMA in networking drivers - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/56d0b5c7f786aa38?hl=en
* linux-next requirements - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/68d372e561eb8d5e?hl=en

==============================================================================
TOPIC: x86: fix out of order of gsi -- partial
http://groups.google.com/group/linux.kernel/t/58949e2872365c61?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 12:20 am
From: Ingo Molnar

* Yinghai Lu <yinghai@kernel.org> wrote:

> From: Eric W. Biederman <ebiederm@xmission.com>
>
> found IBM x3950 will have problem after
>
> |commit b9c61b70075c87a8612624736faf4a2de5b1ed30

Have you seen the commit notifications i sent for the v8 patches:

Commit-ID: ca8c764cb39bf6cade71933b38e8c830eb8b73c6
Commit-ID: 519d637a93116ffbcd50e9e3f2591f41584f372c

Those include a much improved changelogs - please adopt those. (and preferably
send deltas against tip:tmp.x86/apic.)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: fix problems with NETIF_F_HIGHDMA in networking drivers
http://groups.google.com/group/linux.kernel/t/56d0b5c7f786aa38?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 12:20 am
From: David Miller

From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Sun, 28 Feb 2010 03:38:19 +0900

> When I proposed such approach (always use swiotlb) before, IIRC,
> the objections were:
>
> - better to make allocation respect dma_mask. (I don't think that this
> approach is possible since we don't know which device handles data
> later when we allocate memory).

And such objects might end up being processed by multiple devices with
different DMA restrictions.

> - swiotlb is not good for small systems since it allocates too much
> memory (we can fix this though).

Indeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next requirements
http://groups.google.com/group/linux.kernel/t/68d372e561eb8d5e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 12:30 am
From: Al Viro

On Sun, Feb 28, 2010 at 08:51:05AM +0100, Ingo Molnar wrote:

> ( Alas, ARM doesnt tend to be a big problem, at least as far as the facilities
> i'm concerned about go: it has implemented most of the core kernel
> infrastructures so there's few if any 'self inflicted' breakages that i can
> remember. )

FWIW, it might make sense to run cross-builds for many targets and post
the things that crop up + analysis to linux-arch... Any takers?

I haven't run a lot of cross-builds lately, but IME most of the breakage
tends to be less dramatic - somebody relying on indirect includes in
driver *or* forgetting to add "depends on" to Kconfig used to be the
most frequent case.

"let other targets rot" attitude has a very nasty effect - it snowballs.
At some point people *can't* check that their patches don't break things,
even if they want to. And that, IMO, sucks. At that point architecture
needs to be either removed or brought to the state when it builds in
mainline.

Note that we have filesystems that are built only on some architectures.
I don't know about you, but I *do* care about not leaving half-converted
interfaces in that area. For entirely rational reasons - people tend
to copy b0rken code from random places in the tree. Playing whack-a-mole
gets old pretty soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en