* [PATCH 5/9] SA1100: make gpio_to_irq and reverse a macro
From: Thomas Kunze @ 2009-10-12 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20091011121512.GB1356@ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>> The function can't be used for static initialisations so
>> convert them to macros.
>>
>> Signed-off-by: Thomas Kunze <thommycheck@gmx.de>
>>
>
> Do you actually use them in initializers?
>
Yes the last patch of the series does.
^ permalink raw reply
* blkdev_issue_flush really issues a WRITE_BARRIER -- is that okay?
From: Jeff Moyer @ 2009-10-12 17:31 UTC (permalink / raw)
To: Linux Kernel Mailing; +Cc: Jens Axboe
Hi,
While looking though Christoph's patch to call blkdev_issue_flush for
fsync on block devices, I noticed that it only issues a WRITE_BARRIER.
I don't see how that guarantees that data is on stable storage. Am I
missing something? Shouldn't this translate to a FLUSH CACHE or
SYNCHRONIZE CACHE command?
My apologies if this has been discussed before.
Thanks!
Jeff
^ permalink raw reply
* Re: [Bug #14141] order 2 page allocation failures in iwlagn
From: Frans Pop @ 2009-10-12 17:32 UTC (permalink / raw)
To: Mel Gorman
Cc: David Rientjes, KOSAKI Motohiro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Pekka Enberg,
Reinette Chatre, Bartlomiej Zolnierkiewicz, Karol Lewandowski,
Mohamed Abbas, John W. Linville, linux-mm
In-Reply-To: <20091012134328.GB8200@csn.ul.ie>
On Monday 12 October 2009, Mel Gorman wrote:
> Maybe. Your commit id's are different to what I see. Maybe it's because
> your tree has been shuffled around a bit
No, the commit IDs should be identical. My tree is just plain mainline.
Just to make sure... You did remove the "g" from the IDs, right?
So v2.6.30-rc6-1103-gb1bc81a becomes 'b1bc81a' and if you do
'git describe b1bc81a' you really should end up with the same IDs I have.
> but after some digging around in this general area, I saw this patch
>
> 4752c93c30 iwlcore: Allow skb allocation from tasklet
That is v2.6.30-rc6-773-g4752c93, which is part of the first wireless
merge I tested and where I saw no issues. But see below.
> This patch increases the number of GFP_ATOMIC allocations that can occur
> by allocating GFP_ATOMIC in some cases and GFP_KERNEL in others.
> Previously, only GFP_KERNEL was used and I didn't realise this
> allocation method was so recent. Problems of this sort have cropped up
> before and while there are later changes that suppress some of these
> warnings, I believe this is a strong candidate for where the allocation
> failures started appearing.
>
> > v2.6.30-rc6-1032-g7ba10a8 mac80211: fix transposed min/max CW values
> > 1.13 -
> > This is a bugfix for aa837ee1d from an earlier merge! Could this maybe
There's a typo here. That ID should be: aa837e1d.
> > influence the test results in between? There are various SKB related
> > changes there, for example: dfbf97f3..e5b9215e.
> > v2.6.30-rc6-1037-g2c5b9e5 wireless: libertas: fix unaligned accesses
> > 1.12 +-
> > v2.6.30-rc6-1044-g729e9c7 cfg80211: fix for duplicate userspace replies
> > 1.10 +-
> > v2.6.30-rc6-1075-gc587de0 iwlwifi: unify station management
> > 1.9 ++-|+-
> > v2.6.30-rc6-1076-gd14d444 iwl3945: port allow skb allocation in tasklet
> > I thought this was a prime candidate, but as you can see
> > several commits before failed too. Still worth looking at I think!
>
> Your commit IDs are different to what I see but it's the commit merge at
> b1bc81a0ef86b86fa410dd303d84c8c7bd09a64d. I agree that the last commit
> (d14d44407b9f06e3cf967fcef28ccb780caf0583) could make the problem worse
> because it expands the use of GFP_ATOMIC for another driver.
No, that was a mistake of mine. d14d444 is in a driver I don't even compile.
The one you identified (which is the same change for iwlagn) is much more
interesting.
I really do think that v2.6.30-rc6-1032-g7ba10a8 could play a role here.
That's a fix for v2.6.30-rc1-1131-gaa837e1. So that bug was introduced
_before_ the merge 82d0481 and may thus well explain both the latencies I
saw _and_ why that merge tested without problems. And that would also go a
long way to explain my test results.
So I'm going to retest 82d0481 with 7ba10a8 cherry-picked on top.
> > BISECTION of akpm (mm) MERGE
> > ----------------------------
[...]
> While I didn't spot anything too out of the ordinary here, they did
> occur shortly after a number of other page allocator related patches.
> One small thing I noticed there is that kswapd is getting woken up less
> now than it did previously. Generally, I wouldn't have expected it to
> make a difference but it's possible that kswapd is not being woken up to
> reclaim at a higher order than it was previously. I have a patch for
> this below. It'd be nice if you could apply it and see do fewer
> allocation failures occur on current mainline.
I'll give that patch a try and report back.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Bug #14141] order 2 page allocation failures in iwlagn
From: Frans Pop @ 2009-10-12 17:32 UTC (permalink / raw)
To: Mel Gorman
Cc: David Rientjes, KOSAKI Motohiro, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Pekka Enberg,
Reinette Chatre, Bartlomiej Zolnierkiewicz, Karol Lewandowski,
Mohamed Abbas, John W. Linville, linux-mm
In-Reply-To: <20091012134328.GB8200@csn.ul.ie>
On Monday 12 October 2009, Mel Gorman wrote:
> Maybe. Your commit id's are different to what I see. Maybe it's because
> your tree has been shuffled around a bit
No, the commit IDs should be identical. My tree is just plain mainline.
Just to make sure... You did remove the "g" from the IDs, right?
So v2.6.30-rc6-1103-gb1bc81a becomes 'b1bc81a' and if you do
'git describe b1bc81a' you really should end up with the same IDs I have.
> but after some digging around in this general area, I saw this patch
>
> 4752c93c30 iwlcore: Allow skb allocation from tasklet
That is v2.6.30-rc6-773-g4752c93, which is part of the first wireless
merge I tested and where I saw no issues. But see below.
> This patch increases the number of GFP_ATOMIC allocations that can occur
> by allocating GFP_ATOMIC in some cases and GFP_KERNEL in others.
> Previously, only GFP_KERNEL was used and I didn't realise this
> allocation method was so recent. Problems of this sort have cropped up
> before and while there are later changes that suppress some of these
> warnings, I believe this is a strong candidate for where the allocation
> failures started appearing.
>
> > v2.6.30-rc6-1032-g7ba10a8 mac80211: fix transposed min/max CW values
> > 1.13 -
> > This is a bugfix for aa837ee1d from an earlier merge! Could this maybe
There's a typo here. That ID should be: aa837e1d.
> > influence the test results in between? There are various SKB related
> > changes there, for example: dfbf97f3..e5b9215e.
> > v2.6.30-rc6-1037-g2c5b9e5 wireless: libertas: fix unaligned accesses
> > 1.12 +-
> > v2.6.30-rc6-1044-g729e9c7 cfg80211: fix for duplicate userspace replies
> > 1.10 +-
> > v2.6.30-rc6-1075-gc587de0 iwlwifi: unify station management
> > 1.9 ++-|+-
> > v2.6.30-rc6-1076-gd14d444 iwl3945: port allow skb allocation in tasklet
> > I thought this was a prime candidate, but as you can see
> > several commits before failed too. Still worth looking at I think!
>
> Your commit IDs are different to what I see but it's the commit merge at
> b1bc81a0ef86b86fa410dd303d84c8c7bd09a64d. I agree that the last commit
> (d14d44407b9f06e3cf967fcef28ccb780caf0583) could make the problem worse
> because it expands the use of GFP_ATOMIC for another driver.
No, that was a mistake of mine. d14d444 is in a driver I don't even compile.
The one you identified (which is the same change for iwlagn) is much more
interesting.
I really do think that v2.6.30-rc6-1032-g7ba10a8 could play a role here.
That's a fix for v2.6.30-rc1-1131-gaa837e1. So that bug was introduced
_before_ the merge 82d0481 and may thus well explain both the latencies I
saw _and_ why that merge tested without problems. And that would also go a
long way to explain my test results.
So I'm going to retest 82d0481 with 7ba10a8 cherry-picked on top.
> > BISECTION of akpm (mm) MERGE
> > ----------------------------
[...]
> While I didn't spot anything too out of the ordinary here, they did
> occur shortly after a number of other page allocator related patches.
> One small thing I noticed there is that kswapd is getting woken up less
> now than it did previously. Generally, I wouldn't have expected it to
> make a difference but it's possible that kswapd is not being woken up to
> reclaim at a higher order than it was previously. I have a patch for
> this below. It'd be nice if you could apply it and see do fewer
> allocation failures occur on current mainline.
I'll give that patch a try and report back.
^ permalink raw reply
* [git pull] PCI fixes
From: Jesse Barnes @ 2009-10-12 17:32 UTC (permalink / raw)
To: Linus Torvalds, linux-pci, linux-kernel
The following changes since commit
0eca52a92735f43462165efe00a7e394345fb38e: Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/ide-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 for-linus
Nothing earth shattering here since there haven't been any big PCI related
regressions reported (yet). Probably the most significant change here is from
Yinghai; a patch to allocate larger bridge ranges if possible. It's the only
one with potential to cause big trouble, but it looks safe and doesn't seem
to have caused issues so far...
Bjorn Helgaas (2):
PCI: PCIe portdrv: remove "-driver" from driver name
PCI: remove pci_assign_resource_fixed()
Gabe Black (1):
PCI quirk: TI XIO200a erroneously reports support for fast b2b transfers
Kenji Kaneshige (1):
PCI: Prevent AER driver from being loaded on non-root port PCIE devices
Rafael J. Wysocki (1):
PCI PM: Read device power state from register after updating it
Randy Dunlap (1):
PCI: pci.c: fix kernel-doc notation
Yinghai Lu (1):
PCI: get larger bridge ranges when space is available
drivers/pci/pci.c | 14 +++++++++-----
drivers/pci/pcie/aer/aerdrv.c | 2 +-
drivers/pci/pcie/portdrv_pci.c | 3 +--
drivers/pci/quirks.c | 19 +++++++++++++++++++
drivers/pci/setup-bus.c | 13 +++++++++++--
drivers/pci/setup-res.c | 37 -------------------------------------
include/linux/pci_ids.h | 1 +
7 files changed, 42 insertions(+), 47 deletions(-)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [ofa-general] Re: [GIT PULL] please pull ummunotify
From: Peter Zijlstra @ 2009-10-12 17:33 UTC (permalink / raw)
To: Roland Dreier
Cc: Ingo Molnar, Pavel Machek, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Mackerras,
Anton Blanchard, general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <ada3a5uq1dk.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
On Wed, 2009-10-07 at 15:34 -0700, Roland Dreier wrote:
> > So I looked a little deeper into this, and I don't think (even with the
> > filtering extensions) that perf events are directly applicable to this
> > problem. The first issue is that, assuming I'm understanding the
> > comment in perf_event.c:
> >
> > /*
> > * Raw tracepoint data is a severe data leak, only allow root to
> > * have these.
> > */
> >
> > currently tracepoints can only be used by privileged processes. A key
> > feature of ummunotify is that ordinary unprivileged processes can use it.
> >
> > So would it be acceptable to add something like PERF_TYPE_MMU_NOTIFIER
> > as a way of letting unprivileged userspace get access to just MMU events
> > for their own process? Clearly this touches core infrastructure and is
> > not as simple as just adding two tracepoints.
> >
> > Then, assuming we have some way to create an "MMU notifier" perf event,
> > we need a way for userspace to specify which address ranges it would
> > like events for (I don't think the string filter expression used by
> > existing trace filtering works, because if userspace is looking at a few
> > hundred regions, then the size of the filtering expression explodes, and
> > adding or removing a single range becomes a pain). So I guess a new
> > ioctl() to add/remove ranges for MMU_NOTIFIER perf events?
> >
> > I think filtering is needed, because otherwise events for ranges that
> > are not of interest are just a waste of resources to generate and
> > process, and make losing good events because of overflow much more
> > likely.
> >
> > We still have the problem of lost events if the mmap buffer overflows,
> > but userspace should be able to size the buffer so that such events are
> > rare I guess.
> >
> > In the end this seems to just take the ummunotify code I have, and make
> > it be a new type of perf counter instead of a character special device.
> > I'd actually be OK with that, since having an oddball new char dev
> > interface is not particularly nice. But on the other hand just
> > multiplexing a new type of thing under perf events is not all that much
> > better. What do you think?
>
> Ingo/Peter/<anyone suggesting perf events> -- can you comment on this
> plan of creating PERF_TYPE_MMU_NOTIFIER for perf events to implement
> ummunotify? To me it looks like a wash -- the main difference is how
> userspace gets the magic ummunotify file descriptor, either by
> open("/dev/ummunotify") or by perf_event_open(...PERF_TYPE_MMU_NOTIFIER...),
> but pretty much everything else stays pretty much the same in terms of
> how much kernel code is involved. We do reuse the perf events mmap
> buffer code but I think that ends up being more complicated than
> returning events via read().
>
> Anyway, before I spend the time converting over to the new
> infrastructure and causing the MPI guys to churn their code, I'd like to
> make sure that this is what you guys have in mind.
>
> (By the way, after thinking about this more, I really do think that
> filtering events by address range is a must-have -- with filtering,
> userspace can map sufficient buffer space to avoid losing events for a
> given number of regions; without filtering, events might get lost just
> because of invalidate events for ranges userspace didn't even care about)
I think something like
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_MUNMAP + $filter
or
PERF_TYPE_TRACEPOINT, //events/vm/munmap/id + $filter
As for the read/poll issue, I think we can do something like
PERF_FORMAT_BLOCK which would make read() block when ->count hasn't
changed, and make poll() work without requiring a mmap().
As to filter, we can do two things, add a simple single range filter to
perf_event_attr, which is something ia64 has hardware support for IIRC,
or we can possibly use this trace filter muck.
Would something like that be sufficient? With such events only
generating a wakeup (poll) when the unmap actually happens, you'd not
even need an mmap() buffer to keep up with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3 of 7] xen: allows more hypercalls from stubdoms
From: Samuel Thibault @ 2009-10-12 17:33 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel
In-Reply-To: <alpine.DEB.2.00.0910121757360.4616@kaball-desktop>
Hello,
Stefano Stabellini, le Mon 12 Oct 2009 18:20:09 +0100, a écrit :
> Stubdoms need to be able to make all the passthrough related hypercalls
> on behalf of the guest.
Tried before, nacked by Keir :)
> diff -r 65a13cafbbef xen/arch/x86/irq.c
> --- a/xen/arch/x86/irq.c Wed Jul 22 15:59:44 2009 +0100
> +++ b/xen/arch/x86/irq.c Wed Jul 22 16:15:14 2009 +0100
> @@ -917,7 +917,7 @@
> ASSERT(spin_is_locked(&pcidevs_lock));
> ASSERT(spin_is_locked(&d->event_lock));
>
> - if ( !IS_PRIV(current->domain) )
> + if ( !IS_PRIV_FOR(current->domain, d) )
> return -EPERM;
>
> if ( pirq < 0 || pirq >= d->nr_pirqs || vector < 0 || vector >= NR_VECTORS )
For instance, here. It's not because a stubdomain has privilege over
another domain that it suddendly is allowed to reroute all IRQs of the
machine :)
This needs proper accounting: xend should tell the hypervisor which IRQs
domains are allowed to use. Same for physdev, pci functions, etc.
Samuel
^ permalink raw reply
* Re: [tip:x86/pat] x86: Relegate CONFIG_PAT and CONFIG_MTRR configurability to EMBEDDED
From: H. Peter Anvin @ 2009-10-12 17:28 UTC (permalink / raw)
To: mingo, hpa, linux-kernel, arjan, torvalds, arjan, hmh, rdreier,
tglx, mingo
Cc: linux-tip-commits
In-Reply-To: <tip-c03cb3149daed3e411657e3212d05ae27cf1a874@git.kernel.org>
On 10/12/2009 04:10 AM, tip-bot for Arjan van de Ven wrote:
> Commit-ID: c03cb3149daed3e411657e3212d05ae27cf1a874
> Gitweb: http://git.kernel.org/tip/c03cb3149daed3e411657e3212d05ae27cf1a874
> Author: Arjan van de Ven <arjan@infradead.org>
> AuthorDate: Sun, 11 Oct 2009 10:33:02 -0700
> Committer: Ingo Molnar <mingo@elte.hu>
> CommitDate: Mon, 12 Oct 2009 13:06:57 +0200
>
> x86: Relegate CONFIG_PAT and CONFIG_MTRR configurability to EMBEDDED
>
> MTRR and PAT support (which got added to CPUs over 10 years ago)
> are no longer really optional in that more and more things are
> depending on PAT just working, including various drivers and newer
> versions of X. (to not even speak of MTRR)
>
> Having this as a regular config option just no longer makes sense.
>
> This patch relegates CONFIG_X86_PAT to the EMBEDDED category so
> ultra-embedded can still disable it if they really need to.
>
Should we combine this with removing the whitelist (which is largely
vestigial at this point) and replace it with a blacklist (possibly
empty)? I still haven't seen any evidence that there are any CPUs which
have problems, and PAT support go back all the way to Pentium III -- and
page table attributes can be used all the way back to 386, it just
excludes the WC type.
-hpa
^ permalink raw reply
* Re: [ofa-general] Re: [GIT PULL] please pull ummunotify
From: Peter Zijlstra @ 2009-10-12 17:33 UTC (permalink / raw)
To: Roland Dreier
Cc: Ingo Molnar, Pavel Machek, linux-rdma, linux-kernel,
Paul Mackerras, Anton Blanchard, general, akpm, torvalds
In-Reply-To: <ada3a5uq1dk.fsf@cisco.com>
On Wed, 2009-10-07 at 15:34 -0700, Roland Dreier wrote:
> > So I looked a little deeper into this, and I don't think (even with the
> > filtering extensions) that perf events are directly applicable to this
> > problem. The first issue is that, assuming I'm understanding the
> > comment in perf_event.c:
> >
> > /*
> > * Raw tracepoint data is a severe data leak, only allow root to
> > * have these.
> > */
> >
> > currently tracepoints can only be used by privileged processes. A key
> > feature of ummunotify is that ordinary unprivileged processes can use it.
> >
> > So would it be acceptable to add something like PERF_TYPE_MMU_NOTIFIER
> > as a way of letting unprivileged userspace get access to just MMU events
> > for their own process? Clearly this touches core infrastructure and is
> > not as simple as just adding two tracepoints.
> >
> > Then, assuming we have some way to create an "MMU notifier" perf event,
> > we need a way for userspace to specify which address ranges it would
> > like events for (I don't think the string filter expression used by
> > existing trace filtering works, because if userspace is looking at a few
> > hundred regions, then the size of the filtering expression explodes, and
> > adding or removing a single range becomes a pain). So I guess a new
> > ioctl() to add/remove ranges for MMU_NOTIFIER perf events?
> >
> > I think filtering is needed, because otherwise events for ranges that
> > are not of interest are just a waste of resources to generate and
> > process, and make losing good events because of overflow much more
> > likely.
> >
> > We still have the problem of lost events if the mmap buffer overflows,
> > but userspace should be able to size the buffer so that such events are
> > rare I guess.
> >
> > In the end this seems to just take the ummunotify code I have, and make
> > it be a new type of perf counter instead of a character special device.
> > I'd actually be OK with that, since having an oddball new char dev
> > interface is not particularly nice. But on the other hand just
> > multiplexing a new type of thing under perf events is not all that much
> > better. What do you think?
>
> Ingo/Peter/<anyone suggesting perf events> -- can you comment on this
> plan of creating PERF_TYPE_MMU_NOTIFIER for perf events to implement
> ummunotify? To me it looks like a wash -- the main difference is how
> userspace gets the magic ummunotify file descriptor, either by
> open("/dev/ummunotify") or by perf_event_open(...PERF_TYPE_MMU_NOTIFIER...),
> but pretty much everything else stays pretty much the same in terms of
> how much kernel code is involved. We do reuse the perf events mmap
> buffer code but I think that ends up being more complicated than
> returning events via read().
>
> Anyway, before I spend the time converting over to the new
> infrastructure and causing the MPI guys to churn their code, I'd like to
> make sure that this is what you guys have in mind.
>
> (By the way, after thinking about this more, I really do think that
> filtering events by address range is a must-have -- with filtering,
> userspace can map sufficient buffer space to avoid losing events for a
> given number of regions; without filtering, events might get lost just
> because of invalidate events for ranges userspace didn't even care about)
I think something like
PERF_TYPE_SOFTWARE, PERF_COUNT_SW_MUNMAP + $filter
or
PERF_TYPE_TRACEPOINT, //events/vm/munmap/id + $filter
As for the read/poll issue, I think we can do something like
PERF_FORMAT_BLOCK which would make read() block when ->count hasn't
changed, and make poll() work without requiring a mmap().
As to filter, we can do two things, add a simple single range filter to
perf_event_attr, which is something ia64 has hardware support for IIRC,
or we can possibly use this trace filter muck.
Would something like that be sufficient? With such events only
generating a wakeup (poll) when the unmap actually happens, you'd not
even need an mmap() buffer to keep up with that.
^ permalink raw reply
* Re: Patch "USB: Work around BIOS bugs by quiescing USB controllers earlier" causes MCEs
From: Bjorn Helgaas @ 2009-10-12 17:34 UTC (permalink / raw)
To: Nick Piggin
Cc: Mikael Pettersson, David Woodhouse, Linux Kernel Mailing List,
Andrew Patterson
In-Reply-To: <20091006044401.GA30316@wotan.suse.de>
On Monday 05 October 2009 10:44:01 pm Nick Piggin wrote:
> On Fri, Oct 02, 2009 at 09:28:32PM +0200, Mikael Pettersson wrote:
> > Mikael Pettersson writes:
> > > Nick Piggin writes:
> > > > Hi,
> > > >
> > > > Your patch db8be50c4307dac2b37305fc59c8dc0f978d09ea is causing my
> > > > ia64 Altix system to die with an MCE in early boot.
> > >
> > > The same commit has been confirmed by two people on the ARM list
> > > to cause boot failures on two different Intel XScale IOP machines.
> > > The machines have serial consoles, but only show
> > >
> > > Uncompressing Linux... done. Booting the kernel.
> > >
> > > before they hang.
> >
> > I've just investigated this on one of my ARM boxes that this commit kills.
> >
> > The commit changed quirk_usb_early_handoff to be a FIXUP_HEADER, which
> > caused it to be invoked during the early stages of the platform's PCI
> > init (arch/arm/kernel/bios32.c). quirk_usb_handoff_uhci() gets a bogus
> > I/O base address, passes that down to uhci_reset_hc(), causing a kernel
> > page fault in the first "outw(UHCI_USBCMD_HCRESET, base + UHCI_USBCMD);",
> > causing the kernel to oops.
> >
> > (All this occurs before the serial console works, so I had to add a
> > platform-specific puts() and lots of tracing statements.)
> >
> > Changing this quirk back to a FIXUP_FINAL allows the platform's PCI
> > init to complete. Later on the generic pci_init() calls the quirk,
> > which now gets the correct I/O base address, and the outw()s in
> > uhci_reset_hc() don't fail.
>
> Thanks for this, I guess we await David's response.
The problem seen by Andrew on ia64 is that FIXUP_HEADER happens between
device discovery and the PCI fixups, and in this interval, the struct
pci_dev contains PCI bus addresses, not CPU (host) addresses. Often
the PCI bus address and the CPU address are the same, but on machines
where they differ, we can't access PCI BARs in this interval.
I don't know about ARM, but on ia64, we do have enough information to
avoid this problem by always putting the CPU addresses in the pci_dev,
i.e., by doing the PCI fixups immediately at device discovery-time.
I think this is the best solution, because it removes the restriction
that FIXUP_HEADER can't access PCI BARs on certain machines.
Bjorn
^ permalink raw reply
* Re: [PATCH 2 of 7] pcilib: define endianness for minios
From: Stefano Stabellini @ 2009-10-12 17:35 UTC (permalink / raw)
To: Samuel Thibault; +Cc: xen-devel@lists.xensource.com, Stefano Stabellini
In-Reply-To: <20091012173121.GA5961@const.bordeaux.inria.fr>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On Mon, 12 Oct 2009, Samuel Thibault wrote:
> Stefano Stabellini, le Mon 12 Oct 2009 18:19:57 +0100, a écrit :
> > Include endian.h for MiniOS.
>
> Err, could you reorder the hooks the same way as in the existing pcilib
> patch? As it is now, your patch is unreadable just because of this :)
>
I know it is unreadable, this is the actual difference between the two
trees:
diff -uNpbE -r pciutils-x86_32/lib/sysdep.h /dev/xensource/xen-unstable-stubdompass/stubdom/pciutils-x86_32/lib/sysdep.h
--- pciutils-x86_32/lib/sysdep.h 2007-02-06 12:00:18.000000000 +0000
+++ /dev/xensource/xen-unstable-stubdompass/stubdom/pciutils-x86_32/lib/sysdep.h 2009-10-09 19:01:51.000000000 +0100
@@ -32,6 +32,10 @@ typedef u16 word;
#else
+#ifdef PCI_OS_MINIOS
+#include <machine/endian.h>
+#endif
+
#ifdef PCI_OS_LINUX
#include <endian.h>
#define BYTE_ORDER __BYTE_ORDER
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore
From: Greg KH @ 2009-10-12 17:35 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Éric Piel, Linux Kernel Mailing List, linux-input
In-Reply-To: <20091012154846.GB7996@core.coreip.homeip.net>
On Mon, Oct 12, 2009 at 08:48:46AM -0700, Dmitry Torokhov wrote:
> > So at least, unbind should fail as well as bind.
> >
>
> That would be Greg's domain s it is driver core decision whether to
> allow unbinding platform devices registered with
> platform_driver_probe().
No, I do not see why that should not be allowed.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2 of 7] pcilib: define endianness for minios
From: Samuel Thibault @ 2009-10-12 17:36 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <alpine.DEB.2.00.0910121834130.4616@kaball-desktop>
Stefano Stabellini, le Mon 12 Oct 2009 18:35:06 +0100, a écrit :
> I know it is unreadable, this is the actual difference between the two
> trees:
Then please just reorder the hooks in your patch to make it match the
existing patch so that the commit diff becomes readable.
Samuel
^ permalink raw reply
* Re: 2.6.32-rc4: Reported regressions from 2.6.31
From: Linus Torvalds @ 2009-10-12 17:35 UTC (permalink / raw)
To: David Woodhouse
Cc: Rafael J. Wysocki, Greg Kroah-Hartman, Linux Kernel Mailing List,
Adrian Bunk, Andrew Morton, Natalie Protasevich
In-Reply-To: <1255362962.32729.63.camel@macbook.infradead.org>
On Mon, 12 Oct 2009, David Woodhouse wrote:
>
> > The other solution would be to just _enable_ (and do all the setup) of the
> > IOMMU early. And then just leave a legacy mapping for the IOMMU, and then
> > _after_all_devices_are_set_up_ can you then remove the legacy mapping.
>
> That involves allocating a _shitload_ of page tables for a 1:1 mapping
> of all of physical memory.
I don't think that's true.
Nobody cares about "all physical memory". For one thing, we know that
anything that we consider to be normal memory (ie it's listed in the e820
tables as RAM) can't be all that interesting, since the BIOS definitely
released that to us.
That said, as long as the IOMMU is clearly enabled after the quirks have
run, for this particular case we don't much care.
But I could also imagine something similar happening for some BIOS-enabled
ethernet device being set up to listen to packets into some BIOS data
areas (left-overs from whatever bootp thing or other), which doesn't have
a quirk, and which ends up doing DMA until we actually load the driver.
Of course, we'd hope that the DMA just fails and nothing bad really
happens (hopefully the driver re-init will clear up any hung device). But
I can also imagine the hardware simply being really really unhappy, and
not recovering.
So in many ways it would be safest to leave memory that we don't know
about and we don't own as DMA'able in the IOMMU.
And no, I don't think it would be a shitload of pages. Quite the reverse.
It's probably not very many at all.
Linus
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Bill Nottingham @ 2009-10-12 17:37 UTC (permalink / raw)
To: Scott James Remnant
Cc: Matt Domsch, Narendra K, netdev, linux-hotplug, jordan_hargrave
In-Reply-To: <1255344075.2143.1.camel@warcraft>
Scott James Remnant (scott@ubuntu.com) said:
> On the other hand, they *tend* to be unique for a wide range of systems.
> This makes them pretty comparable to LABELs on disks, and we have
> a /dev/disk/by-label
>
> Remember that udev already supports symlink stacking, and priorities and
> such.
>
> I don't think there's any danger of supporting a /dev/netdev/by-mac by
> default, it'll be a benefit to most and those who don't have unique MACs
> will just ignore it.
At the moment, we do not appear to get the proper change uevents from things
like 'ip link set dev <foo> address <bar>', so we can't currently maintain
these symlinks.
Bill
^ permalink raw reply
* Re: [PATCH 5/5] Always print panic message on current console
From: Andi Kleen @ 2009-10-12 17:36 UTC (permalink / raw)
To: Bernhard Walle; +Cc: akpm, linux-kernel, jbarnes
In-Reply-To: <1255207870-24496-6-git-send-email-bernhard@bwalle.de>
Bernhard Walle <bernhard@bwalle.de> writes:
> The kernel offers with TIOCL_GETKMSGREDIRECT ioctl() the possibility to
> redirect the kernel messages to a specific console.
>
> However, since it's not possible to switch to the kernel message console after
> a panic(), it would be nice if the kernel would print the panic message on the
> current console.
The basic idea is good, but you really need to call this in a lot
more places, which print some addition needed information before the panic.
The one liner panic is often not enough to decide what went wrong.
Example are machine checks, oopses, probably more.
In general for the recent work to switch the video mode on panic
we need a generalized hook for this anyways, so you could use
some generalized function.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: assign-dev: Purpose of interrupt_work
From: Marcelo Tosatti @ 2009-10-12 17:36 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Avi Kivity, Gleb Natapov, kvm-devel
In-Reply-To: <4AD2F1D0.4090005@web.de>
On Mon, Oct 12, 2009 at 11:07:28AM +0200, Jan Kiszka wrote:
> Avi Kivity wrote:
> > On 10/12/2009 09:50 AM, Jan Kiszka wrote:
> >>> Apic is lockless. For ioapic/pic I used spinlocks initially, but Avi
> >>> prefers mutexes. Theoretically it is possible to make them lockless,
> >>> but code will be complex and eventually more slow, since more then two
> >>> atomic operation will be used on irq injection path.
> >>>
> >> Well, lockless is another thing.
> >>
> >> But also converting to spinlocks would indeed add some overhead:
> >> irqsave/restore. But I wonder if this isn't worth it, at least when
> >> looking at the (supposed to be fast) device passthrough scenario which
> >> would be simpler and faster.
> >>
> >
> > I'm worried about disabling irqs for non-device-assignment cases. It
> > would be more palatable if ioapic was completely O(1) (there are some
> > per-vcpu loops in there, shouldn't be too bad for 16 vcpus, but we want
> > to scale).
>
> Yeah, what a pity. That's likely not solvable in a generic way, given
> that the guest finally decided how many VCPUs may listen to a line.
>
> OK, but dropping interrupt_work from the MSI path is still worthwhile,
> and probably more future-proof anyway.
Seems appropriate to convert the process context work to threaded
interrupt (instead of workqueue). That should help latency.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Bill Nottingham @ 2009-10-12 17:37 UTC (permalink / raw)
To: Scott James Remnant
Cc: Matt Domsch, Narendra K, netdev, linux-hotplug, jordan_hargrave
In-Reply-To: <1255344075.2143.1.camel@warcraft>
Scott James Remnant (scott@ubuntu.com) said:
> On the other hand, they *tend* to be unique for a wide range of systems.
> This makes them pretty comparable to LABELs on disks, and we have
> a /dev/disk/by-label
>
> Remember that udev already supports symlink stacking, and priorities and
> such.
>
> I don't think there's any danger of supporting a /dev/netdev/by-mac by
> default, it'll be a benefit to most and those who don't have unique MACs
> will just ignore it.
At the moment, we do not appear to get the proper change uevents from things
like 'ip link set dev <foo> address <bar>', so we can't currently maintain
these symlinks.
Bill
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] tcg, tci: Add TCG and interpreter for bytecode (virtual machine)
From: Stuart Brady @ 2009-10-12 17:39 UTC (permalink / raw)
To: malc; +Cc: qemu-devel
In-Reply-To: <Pine.LNX.4.64.0910121624010.2142@linmac.oyster.ru>
On Mon, Oct 12, 2009 at 04:33:10PM +0400, malc wrote:
> On Mon, 12 Oct 2009, Stuart Brady wrote:
>
> > Huh? If you're using a function pointer with the *correct* type,
> > I hardly see how that's not sufficient.
>
> Let me give you an example:
>
[snip]
*Mind boggles* :-)
You seem to be ignoring the words "correct type" in all of my sentences.
My suggestion was to give op_call handling the information it that needs
iff TCI is used. Yes, the code in tcg_gen_callN() is clearly not
appropriate for TCI, although I'd somehow missed the fact that it may
also need to be changed in future to support other new TCG back-ends.
I'm quite aware that functions must be invoked using the *correct type*
of function pointer, though. Perhaps I wasn't specific enough in what
I said, but please, I'm not completely clueless... :-)
Cheers,
--
Stuart Brady
^ permalink raw reply
* Re: [PATCH tracing/kprobes v3 4/7] tracing/kprobes: Avoid field name confliction
From: Frederic Weisbecker @ 2009-10-12 17:37 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Steven Rostedt, Ingo Molnar, lkml, systemtap, DLE,
Thomas Gleixner, Arnaldo Carvalho de Melo, Mike Galbraith,
Paul Mackerras, Peter Zijlstra, Christoph Hellwig,
Ananth N Mavinakayanahalli, Jim Keniston, Frank Ch. Eigler
In-Reply-To: <20091007222807.1684.26880.stgit@dhcp-100-2-132.bos.redhat.com>
On Wed, Oct 07, 2009 at 06:28:07PM -0400, Masami Hiramatsu wrote:
> Check whether the argument name is conflict with other field names.
>
> Changes in v3:
> - Check strcmp() == 0 instead of !strcmp().
>
> Changes in v2:
> - Add common_lock_depth to reserved name list.
>
> Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Christoph Hellwig <hch@infradead.org>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Cc: Jim Keniston <jkenisto@us.ibm.com>
> Cc: Frank Ch. Eigler <fche@redhat.com>
> ---
>
> kernel/trace/trace_kprobe.c | 65 +++++++++++++++++++++++++++++++++++--------
> 1 files changed, 53 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 030f28c..e3b824a 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -38,6 +38,25 @@
> #define MAX_EVENT_NAME_LEN 64
> #define KPROBE_EVENT_SYSTEM "kprobes"
>
> +/* Reserved field names */
> +#define FIELD_STRING_IP "ip"
> +#define FIELD_STRING_NARGS "nargs"
> +#define FIELD_STRING_RETIP "ret_ip"
> +#define FIELD_STRING_FUNC "func"
> +
> +const char *reserved_field_names[] = {
> + "common_type",
> + "common_flags",
> + "common_preempt_count",
> + "common_pid",
> + "common_tgid",
> + "common_lock_depth",
> + FIELD_STRING_IP,
> + FIELD_STRING_NARGS,
> + FIELD_STRING_RETIP,
> + FIELD_STRING_FUNC,
> +};
> +
> /* currently, trace_kprobe only supports X86. */
>
> struct fetch_func {
> @@ -537,6 +556,20 @@ static int parse_probe_arg(char *arg, struct fetch_func *ff, int is_return)
> return ret;
> }
>
> +/* Return 1 if name is reserved or already used by another argument */
> +static int conflict_field_name(const char *name,
> + struct probe_arg *args, int narg)
> +{
> + int i;
> + for (i = 0; i < ARRAY_SIZE(reserved_field_names); i++)
> + if (strcmp(reserved_field_names[i], name) == 0)
> + return 1;
> + for (i = 0; i < narg; i++)
> + if (strcmp(args[i].name, name) == 0)
> + return 1;
> + return 0;
> +}
> +
> static int create_trace_probe(int argc, char **argv)
> {
> /*
> @@ -637,6 +670,12 @@ static int create_trace_probe(int argc, char **argv)
> *arg++ = '\0';
> else
> arg = argv[i];
> +
> + if (conflict_field_name(argv[i], tp->args, i)) {
> + ret = -EINVAL;
The conflict issue might not be obvious for a user desperately trying to set
a kprobe. Even for other failcases, it might not be obvious (blacklisted
symbols, syntax errors...)
May be should you improve the error granularity and print a KERN_DEBUG
message?
Thanks.
^ permalink raw reply
* Re: *Really* bad I/O latency with md raid5+dm-crypt+lvm
From: Mike Galbraith @ 2009-10-12 17:37 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: linux-kernel, pernegger, arjan
In-Reply-To: <4AD341B2.6000704@wpkg.org>
On Mon, 2009-10-12 at 16:48 +0200, Tomasz Chmielewski wrote:
> > Summary: I was hoping to use a layered storage setup, namely lvm on
> > dm-crypt on md raid5 for a new box I'm setting up, but that isn't
> > looking so good since a single heavyish writer will monopolise any and
> > all I/O on the "device". F. ex. while cp'ing a few GB of data from an
> > external disk to the array it takes ~10sec to run ls and ~2min to
> > start aptitude. Clueless attempts at a diagnosis below.
>
> Did you try running strace to see where ls pauses?
>
> Did you try running latencytop (and generally, top/htop while doing your
> tests)?
>
>
> (...)
>
> > Anyway, as soon as I copy something to the array or create a larger
> > (upwards of a few hundred MiB) tar archive the box becomes utterly
> > unresponsive until that job is finished. Even on the local console the
> > completion time for a simple ls or cat is of the order of tens of
> > seconds, just forget about launching emacs.
> > Now I know that people have been ranting about desktop responsiveness
> > for a while but that was very much an abstract thing for me until now.
>
> I think the above (big latency when doing some bigger IO) is a general
> Linux problem.
It would be interesting to test latest -rc. Though it may prove to be
unrelated. the symptoms sound very much like a recent thread wrt writers
starving readers.
-Mike
^ permalink raw reply
* Re: Mass-Hardlinking Oops
From: John Dong @ 2009-10-12 17:42 UTC (permalink / raw)
To: jim owens; +Cc: Pär Andersson, linux-btrfs
In-Reply-To: <4AD35667.3020103@hp.com>
On Oct 12, 2009, at 12:16 PM, jim owens wrote:
> P=E4r Andersson wrote:
>> I just ran into the max hard link per directory limit, and remembere=
d
>> this thread. I get EMLINK when trying to create more than 311 (not =20
>> 272)
>> links in a directory, so at least the BUG() is fixed.
>> What is the reason for the limit, and is there any chance of =20
>> increasing
>> it to something more reasonable as Mikhail suggested?
>> For comparison I tried to create 200k hardlinks to the the same =20
>> file in
>> the same directory on btrfs, ext4, reiserfs and xfs:
>
> what real-world application uses and needs this many hard links?
>
> jim
I don't think that's a good counterargument for why this is not a bug.
Can't think of any off the top of my head for Linux, but definitely in =
=20
OS X Time Machine can easily create 200+ hardlinks.--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] panic.c: export panic_on_oops
From: Linus Torvalds @ 2009-10-12 17:43 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: LKML, Koskinen Aaro (Nokia-D/Helsinki), linux-mtd, Simon Kagstrom,
Ingo Molnar, David Woodhouse, Andrew Morton, Alan Cox
In-Reply-To: <1255368557.27022.226.camel@localhost>
On Mon, 12 Oct 2009, Artem Bityutskiy wrote:
>
> But mtdoops tries to solves the following problem. What if we are
> oopsing in an interrupt, which interrupted the mtd driver, so we have
> all the locks held, and the mtd driver is in a unexpected stage ATM? Or
> what if we are oopsing in the mtd driver, or in something which was
> called by the MTD driver.?
Well, quite frankly, if you have an oops while holding a spinlock, then
the machine is dead _anyway_.
So what I would suggest is to just ignore the above problem. No amount of
workqueue logic will help it - if the oops happened while an interrupt
held a critical mtd lock, that lock will _never_ be released, so exactly
what would be helped?
Now, I realize that _if_ you treat mtdoops as a 'console' layer, then you
need to do that crazy thing, because you still want the oops to print out
to the other consoles, and you're only getting data one line at a time.
But since that was the wrong thing to do for a lot of other reasons
anyway, that's not a very good argument.
Once you do the final flush in a controlled place _after_ you've printed
out all the oops information, you simply don't care about locks any more.
Because if you were holding critical locks, you're done anyway.
Sure, maybe you want to do a "trylock()" and skip the oops flush entirely
in the mtd layer if you can't do it, but it's the "let's use a workqueue"
or something that doesn't seem to make a lot of sense to me.
Linus
^ permalink raw reply
* Re: git refuses to work with gvim
From: Markus Heidelberg @ 2009-10-12 17:37 UTC (permalink / raw)
To: sebastian; +Cc: git
In-Reply-To: <20091012134312.236d250e@gzip.coli.uni-saarland.de>
sebastian@coli.uni-sb.de, 12.10.2009:
> Hi,
> a few days ago I decided to switch from vim to gvim. To make use of
> this in most cases I added :gui to my .vimrc which should make most
> applications automatically switch to use gvim if they used the vim
> command before.
>
> But git seems to have problems with this. If I do now a "git commit
> something" not the gui is opened but the console-version of vim.
git probably calls vi and not vim. Maybe vi doesn't respect your .vimrc?
> OS: Debian Lenny
Doesn't install Debian a vim-tiny package for vi without gui and another
for vim?
Markus
^ permalink raw reply
* Re: [PATCH] panic.c: export panic_on_oops
From: Linus Torvalds @ 2009-10-12 17:43 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: Simon Kagstrom, Ingo Molnar, David Woodhouse, LKML,
Koskinen Aaro (Nokia-D/Helsinki), linux-mtd, Andrew Morton,
Alan Cox
In-Reply-To: <1255368557.27022.226.camel@localhost>
On Mon, 12 Oct 2009, Artem Bityutskiy wrote:
>
> But mtdoops tries to solves the following problem. What if we are
> oopsing in an interrupt, which interrupted the mtd driver, so we have
> all the locks held, and the mtd driver is in a unexpected stage ATM? Or
> what if we are oopsing in the mtd driver, or in something which was
> called by the MTD driver.?
Well, quite frankly, if you have an oops while holding a spinlock, then
the machine is dead _anyway_.
So what I would suggest is to just ignore the above problem. No amount of
workqueue logic will help it - if the oops happened while an interrupt
held a critical mtd lock, that lock will _never_ be released, so exactly
what would be helped?
Now, I realize that _if_ you treat mtdoops as a 'console' layer, then you
need to do that crazy thing, because you still want the oops to print out
to the other consoles, and you're only getting data one line at a time.
But since that was the wrong thing to do for a lot of other reasons
anyway, that's not a very good argument.
Once you do the final flush in a controlled place _after_ you've printed
out all the oops information, you simply don't care about locks any more.
Because if you were holding critical locks, you're done anyway.
Sure, maybe you want to do a "trylock()" and skip the oops flush entirely
in the mtd layer if you can't do it, but it's the "let's use a workqueue"
or something that doesn't seem to make a lot of sense to me.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.