* [PATCH] ARM: allow, but warn, when issuing ioremap() on RAM
From: Felipe Contreras @ 2010-10-08 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101007192245.GC26435@n2100.arm.linux.org.uk>
On Thu, Oct 7, 2010 at 10:22 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Oct 07, 2010 at 12:44:22PM +0300, Felipe Contreras wrote:
>> Many drivers are broken, and there's no alternative in sight. Such a big
>> change should stay as a warning for now, and only later should it
>> actually fail.
>>
>> The drivers are not doing something correct, we get it, but for now it's
>> better to allow them to work (they do 99% of the time anyway) rather
>> than to force everyone to revert this patch in their internal trees
>> until there's a solution. A slightly broken functionality is better than
>> no functionality at all.
>>
>> A warning lets people know that what they are doing is not right, and
>> they should fix it.
>
> So what are _you_ going to do to fix these drivers? ?Continue reverting
> this patch? ?Or are you just going to ignore the issue entirely?
_I_ don't maintain any of these drivers.
I think when _you_ remove functionality from the architecture, you
should provide a mechanism that drivers can migrate to. Since there's
nothing like that, not even a guideline, you are breaking the drivers
willingly, and expecting other people to fix a difficult problem that
you yourself have no idea how to fix properly. At least for 2.6.36,
and probably 2.6.37, I think it's clear what people will do; revert
that patch in their trees, and think twice before switching to a newer
version.
> Unless people can come up with a plan to fix their drivers using ioremap
> on system RAM thereby violating the architecture specification, I'm
> _not_ going to apply this patch.
And then people wonder why companies don't try to work in upstream as
often as they should. If you, the ARM maintainer doesn't care about
breaking drivers with no warning whatsoever, I wonder why would driver
writers would feel compelled to fix the ARM architecture ASAP (if they
are even capable of doing that), specially if they already missed the
deadline, which had a grace period of between .36-rc1 and .36.
Other projects remove functionality only when there's an alternative
in place, and provide a grace period for the migration. I thought that
was sensible.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] net/tg3: simplify conditional
From: Nicolas Kaiser @ 2010-10-08 9:29 UTC (permalink / raw)
To: Matt Carlson; +Cc: Michael Chan, netdev, linux-kernel
Simplify: ((a && !b) || (!a && b)) => (a != b)
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
---
drivers/net/tg3.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 16e1a95..714f0fb 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -9967,8 +9967,7 @@ static int tg3_set_pauseparam(struct net_device *dev, struct ethtool_pauseparam
if (!(phydev->supported & SUPPORTED_Pause) ||
(!(phydev->supported & SUPPORTED_Asym_Pause) &&
- ((epause->rx_pause && !epause->tx_pause) ||
- (!epause->rx_pause && epause->tx_pause))))
+ (epause->rx_pause != epause->tx_pause)))
return -EINVAL;
tp->link_config.flowctrl = 0;
--
1.7.2.2
^ permalink raw reply related
* Re: [PATCH 09/18] fs: rework icount to be a locked variable
From: Al Viro @ 2010-10-08 9:32 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-10-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:23PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> The inode reference count is currently an atomic variable so that it can be
> sampled/modified outside the inode_lock. However, the inode_lock is still
> needed to synchronise the final reference count and checks against the inode
> state.
>
> To avoid needing the protection of the inode lock, protect the inode reference
> count with the per-inode i_lock and convert it to a normal variable. To avoid
> existing out-of-tree code accidentally compiling against the new method, rename
> the i_count field to i_ref. This is relatively straight forward as there
> are limited external references to the i_count field remaining.
You are overdoing the information hiding here; _way_ too many small
functions that don't buy you anything so far, AFAICS. Moreover, why
the hell not make them static inlines and get rid of the exports?
> - if (atomic_add_unless(&inode->i_count, -1, 1))
> + /* XXX: filesystems should not play refcount games like this */
> + spin_lock(&inode->i_lock);
> + if (inode->i_ref > 1) {
> + inode->i_ref--;
> + spin_unlock(&inode->i_lock);
> return;
> + }
> + spin_unlock(&inode->i_lock);
... or, perhaps, they needs a helper along the lines of "try to do iput()
if it's known to hit easy case".
I really don't like the look of code around -ENOSPC returns, though.
What exactly is going on there? Can it e.g. interfere with that
delayed iput stuff?
> void iref(struct inode *inode)
> {
> spin_lock(&inode_lock);
> + spin_lock(&inode->i_lock);
> iref_locked(inode);
> + spin_unlock(&inode->i_lock);
> spin_unlock(&inode_lock);
> }
*cringe*
> int iref_read(struct inode *inode)
> {
> - return atomic_read(&inode->i_count);
> + int ref;
> +
> + spin_lock(&inode->i_lock);
> + ref = inode->i_ref;
> + spin_unlock(&inode->i_lock);
> + return ref;
What's the point of locking here?
> @@ -1324,8 +1359,16 @@ void iput(struct inode *inode)
> if (inode) {
> BUG_ON(inode->i_state & I_CLEAR);
>
> - if (atomic_dec_and_lock(&inode->i_count, &inode_lock))
> + spin_lock(&inode_lock);
> + spin_lock(&inode->i_lock);
> + inode->i_ref--;
> + if (inode->i_ref == 0) {
> + spin_unlock(&inode->i_lock);
> iput_final(inode);
> + return;
> + }
*UGH* So you take inode_lock on every damn iput()?
> state->owner = owner;
> atomic_inc(&owner->so_count);
> list_add(&state->inode_states, &nfsi->open_states);
> - state->inode = igrab(inode);
> spin_unlock(&inode->i_lock);
> + state->inode = igrab(inode);
Why is that safe?
> --- a/fs/notify/inode_mark.c
> +++ b/fs/notify/inode_mark.c
> @@ -257,7 +257,8 @@ void fsnotify_unmount_inodes(struct list_head *list)
> * actually evict all unreferenced inodes from icache which is
> * unnecessarily violent and may in fact be illegal to do.
> */
> - if (!iref_read(inode))
> + spin_lock(&inode->i_lock);
> + if (!inode->i_ref)
> continue;
Really?
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] check for close() errors on qcow2_create()
From: Stefan Hajnoczi @ 2010-10-08 9:28 UTC (permalink / raw)
To: Eduardo Habkost; +Cc: Kevin Wolf, qemu-devel
In-Reply-To: <1286483105-9768-3-git-send-email-ehabkost@redhat.com>
On Thu, Oct 7, 2010 at 9:25 PM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> Errors when closing the file we just created should not be ignored. I/O errors
> may happen and "qemu-img create" should fail in those cases.
>
> If we are already exiting due to an error, we will still return the original
> error number, though.
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> block/qcow2.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
Sounds good.
> diff --git a/block/qcow2.c b/block/qcow2.c
> index c5fb28e..d3a056b 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -882,7 +882,7 @@ static int qcow_create2(const char *filename, int64_t total_size,
> uint64_t old_ref_clusters;
> QCowCreateState s1, *s = &s1;
> QCowExtension ext_bf = {0, 0};
> - int ret;
> + int ret, cret;
>
> memset(s, 0, sizeof(*s));
>
> @@ -1055,7 +1055,9 @@ exit:
> qemu_free(s->refcount_block);
>
> exit_close:
> - close(fd);
> + cret = close(fd);
> + if (ret == 0 && cret < 0)
if (close(fd) < 0 && ret == 0) {
Does the same without variable cret.
> + ret = -errno;
>
> /* Preallocate metadata */
> if (ret == 0 && prealloc) {
> --
> 1.6.5.5
>
>
>
^ permalink raw reply
* Re: introduce dm-snap-mv
From: McPacino @ 2010-10-08 9:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Daniel Phillips, linux-fsdevel, linux-kernel, dm-devel,
Andrew Morton, Alexander Viro, Nick Piggin
In-Reply-To: <20101008092427.GA5426@lst.de>
Thank you very very much...
On Fri, Oct 8, 2010 at 5:24 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, Oct 08, 2010 at 05:14:27PM +0800, McPacino wrote:
>> Hi Christoph,
>>
>> I have to take care the cache problem If using the bio directly.
>> BHs can be released by kernel when necessary.
>>
>> Is there any existing code using bio to read/write metadata
>> blocks? How do they handle the timing freeing bios? I really
>> wish to learn something form it.
>
> If you actually need caching just use the pagecache, e.g.
> read_mapping_page to read in your data. That completely abstracts
> away the underlying block size.
>
>
^ permalink raw reply
* Re: fallocate() on XFS clobbers S*ID-bits
From: Andreas Wiese @ 2010-10-08 9:26 UTC (permalink / raw)
To: Dave Chinner; +Cc: Linux Kernel Mailing List, Ciaran McCreesh, xfs
In-Reply-To: <20101007232451.GO4681@dastard>
Dave Chinner wrote:
> [ added xfs list on cc ]
>
Thanks. ;)
> On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> > Hello.
> >
> > I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
> > fallocate() on XFS. After open()ing some file and setting it S*ID via
> > fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
> > for non-root users, but it also happens for root.
> >
> > Is this intended behaviour or did we spot a bug here?
> >
> > At least on ext2 it works as expected, thus I guess it's the latter one.
>
> ext2 does not support the fallocate syscall. How does ext4 behave?
>
Oh, crap. I first tested on tmpfs (which doesn't support fallocate,
too) and had a » && errno != ENOTSUP« to avoid bailing out but forgot to
warn. :/
But I did now and ext4 does _not_ touch the permissions any further.
> > I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
> > doesn't seem to address this issue.
>
> XFS has always cleared SUID/SGID bits when doing preallocation (via
> XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for
> fallocate, I'd argue that the XFS behaviour is the on that should be
> followed.
>
If that's consense, we at least found a bug in ext4…
> It'd be a bit silly for two different preallocation interfaces to
> have different behaviour w.r.t. SUID bits, but it's not clear to me
> which behaviour is correct. I'm happy to defer to whoever can say
> what the behaviour is supposed to be here...
>
I would appreciate that, too.
And while on it… just tested BTRFS, which behaves like ext4 (not
altering permissions). CIFS and OCFS are not testable here due to lack
of according servers.
[snip…]
HAND & LG -- aw
np: Johnossi (Johnossi) — 08. Happiness a La Mode
^ permalink raw reply
* [PATCH v2 for 2.6.36 1/2] cpuimx27: fix compile when ULPI is selected
From: Uwe Kleine-König @ 2010-10-08 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286527061-3013-1-git-send-email-eric@eukrea.com>
On Fri, Oct 08, 2010 at 10:37:40AM +0200, Eric B?nard wrote:
> without this patch we get :
> arch/arm/mach-imx/built-in.o: In function `eukrea_cpuimx27_init':
> eukrea_mbimx27-baseboard.c:(.init.text+0x44c): undefined reference to `mxc_ulpi_access_ops'
>
> Signed-off-by: Eric B?nard <eric@eukrea.com>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
> v2 : remove SPI's select which leaked in previous patch
> arch/arm/mach-imx/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index c5c0369..2f7e272 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -122,6 +122,7 @@ config MACH_CPUIMX27
> select IMX_HAVE_PLATFORM_IMX_I2C
> select IMX_HAVE_PLATFORM_IMX_UART
> select IMX_HAVE_PLATFORM_MXC_NAND
> + select MXC_ULPI if USB_ULPI
> help
> Include support for Eukrea CPUIMX27 platform. This includes
> specific configurations for the module and its peripherals.
> --
> 1.7.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] bdi: use deferable timer for sync_supers task
From: Christoph Hellwig @ 2010-10-08 9:25 UTC (permalink / raw)
To: Yong Wang
Cc: Jens Axboe, Christoph Hellwig, Artem Bityutskiy, Wu Fengguang,
linux-kernel, linux-mm, xia.wu
In-Reply-To: <20101008083514.GA12402@ywang-moblin2.bj.intel.com>
On Fri, Oct 08, 2010 at 04:35:14PM +0800, Yong Wang wrote:
> sync_supers task currently wakes up periodically for superblock
> writeback. This hurts power on battery driven devices. This patch
> turns this housekeeping timer into a deferable timer so that it
> does not fire when system is really idle.
How long can the timer be defereed? We can't simply stop writing
out data for a long time. I think the current timer value should be
the upper bound, but allowing to fire earlier to run during the
same wakeup cycle as others is fine.
^ permalink raw reply
* Re: [PATCH] bdi: use deferable timer for sync_supers task
From: Christoph Hellwig @ 2010-10-08 9:25 UTC (permalink / raw)
To: Yong Wang
Cc: Jens Axboe, Christoph Hellwig, Artem Bityutskiy, Wu Fengguang,
linux-kernel, linux-mm, xia.wu
In-Reply-To: <20101008083514.GA12402@ywang-moblin2.bj.intel.com>
On Fri, Oct 08, 2010 at 04:35:14PM +0800, Yong Wang wrote:
> sync_supers task currently wakes up periodically for superblock
> writeback. This hurts power on battery driven devices. This patch
> turns this housekeeping timer into a deferable timer so that it
> does not fire when system is really idle.
How long can the timer be defereed? We can't simply stop writing
out data for a long time. I think the current timer value should be
the upper bound, but allowing to fire earlier to run during the
same wakeup cycle as others is fine.
--
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: [PATCH 2/2] apic, x86: Use BIOS settings for IBS and MCE threshold interrupt LVT offsets
From: Robert Richter @ 2010-10-08 9:24 UTC (permalink / raw)
To: Cyrill Gorcunov; +Cc: Ingo Molnar, LKML
In-Reply-To: <20101006194150.GA17647@lenovo>
On 06.10.10 15:41:50, Cyrill Gorcunov wrote:
> On Wed, Oct 06, 2010 at 12:27:54PM +0200, Robert Richter wrote:
> > We want the BIOS to setup the EILVT APIC registers. The offsets were
> > hardcoded and BIOS settings were overwritten by the OS. Now, the
> > subsystems for MCE threshold and IBS determine the LVT offset from the
> > registers the BIOS has setup. If the BIOS setup is buggy on a family
> > 10h system, a workaround enables IBS. If the OS determines an invalid
> > register setup, a "[Firmware Bug]: " error message is reported.
> >
> > We need this change also for upcomming cpu families.
> >
> > Signed-off-by: Robert Richter <robert.richter@amd.com>
> > ---
>
> Hi Robert, a few comments
>
> ...
> > /*
> > * Program the next event, relative to now
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c b/arch/x86/kernel/cpu/mcheck/mce_amd.c
> > index 5e97529..e13d4bd 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
> > @@ -131,7 +131,8 @@ void mce_amd_feature_init(struct cpuinfo_x86 *c)
> > u32 low = 0, high = 0, address = 0;
> > unsigned int bank, block;
> > struct thresh_restart tr;
> > - u8 lvt_off;
> > + int lvt_off = -1;
> > + u8 offset;
> >
> > for (bank = 0; bank < NR_BANKS; ++bank) {
> > for (block = 0; block < NR_BLOCKS; ++block) {
> > @@ -165,8 +166,28 @@ void mce_amd_feature_init(struct cpuinfo_x86 *c)
> > if (shared_bank[bank] && c->cpu_core_id)
> > break;
> > #endif
> > - lvt_off = setup_APIC_eilvt_mce(THRESHOLD_APIC_VECTOR,
> > - APIC_EILVT_MSG_FIX, 0);
> > + offset = (high & MASK_LVTOFF_HI) >> 20;
> > + if (lvt_off < 0) {
> > + if (setup_APIC_eilvt(offset,
> > + THRESHOLD_APIC_VECTOR,
> > + APIC_EILVT_MSG_FIX, 0)) {
> > + pr_err(FW_BUG "cpu %d, failed to "
> > + "setup threshold interrupt "
> > + "for bank %d, block %d "
> > + "(MSR%08X=0x%x%08x)",
> > + smp_processor_id(), bank, block,
> > + address, high, low);
> > + continue;
> > + }
> > + lvt_off = offset;
> > + } else if (lvt_off != offset) {
>
> Could we put explicit type specificator here? For better readbility.
> ...
Cyrill,
Do you mean an explicit type cast here, or something else?
>
> > +static int force_ibs_eilvt_setup(void)
> > +{
> > + int i;
> > + int ret;
> > +
> > + /* find the next free available EILVT entry */
> > + for (i = 1; i < 4; i++) {
>
> APIC_EILVT_NR_MAX here, no?
Yes, will update this if a -v2 patch set will be necessary.
Thanks for review,
-Robert
>
> > + if (!eilvt_is_available(i))
> > + continue;
> > + ret = setup_ibs_ctl(i);
> > + if (ret)
> > + return ret;
> > + return 0;
> > }
> >
>
> Cyrill
>
--
Advanced Micro Devices, Inc.
Operating System Research Center
^ permalink raw reply
* Re: fallocate() on XFS clobbers S*ID-bits
From: Andreas Wiese @ 2010-10-08 9:26 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs, Linux Kernel Mailing List, Ciaran McCreesh
In-Reply-To: <20101007232451.GO4681@dastard>
Dave Chinner wrote:
> [ added xfs list on cc ]
>
Thanks. ;)
> On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> > Hello.
> >
> > I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
> > fallocate() on XFS. After open()ing some file and setting it S*ID via
> > fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
> > for non-root users, but it also happens for root.
> >
> > Is this intended behaviour or did we spot a bug here?
> >
> > At least on ext2 it works as expected, thus I guess it's the latter one.
>
> ext2 does not support the fallocate syscall. How does ext4 behave?
>
Oh, crap. I first tested on tmpfs (which doesn't support fallocate,
too) and had a » && errno != ENOTSUP« to avoid bailing out but forgot to
warn. :/
But I did now and ext4 does _not_ touch the permissions any further.
> > I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
> > doesn't seem to address this issue.
>
> XFS has always cleared SUID/SGID bits when doing preallocation (via
> XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for
> fallocate, I'd argue that the XFS behaviour is the on that should be
> followed.
>
If that's consense, we at least found a bug in ext4…
> It'd be a bit silly for two different preallocation interfaces to
> have different behaviour w.r.t. SUID bits, but it's not clear to me
> which behaviour is correct. I'm happy to defer to whoever can say
> what the behaviour is supposed to be here...
>
I would appreciate that, too.
And while on it… just tested BTRFS, which behaves like ext4 (not
altering permissions). CIFS and OCFS are not testable here due to lack
of according servers.
[snip…]
HAND & LG -- aw
np: Johnossi (Johnossi) — 08. Happiness a La Mode
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic
From: Jarek Poplawski @ 2010-10-08 9:24 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, bugzilla-daemon, bugme-daemon, eminak71, Anton Vorontsov
In-Reply-To: <20101004135310.6a5f8e93.akpm@linux-foundation.org>
Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Mon, 4 Oct 2010 06:25:14 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=19692
>>
>> Summary: linux-2.6.36-rc5 crash with gianfar ethernet at full
>> line rate traffic
...
Emin, until there is something better I hope you could try this patch.
(not tested nor compiled)
Thanks,
Jarek P.
---
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 4f7c3f3..db47b55 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2515,7 +2515,7 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
skb_recycle_check(skb, priv->rx_buffer_size +
RXBUF_ALIGNMENT)) {
gfar_align_skb(skb);
- __skb_queue_head(&priv->rx_recycle, skb);
+ skb_queue_head(&priv->rx_recycle, skb);
} else
dev_kfree_skb_any(skb);
@@ -2598,7 +2598,7 @@ struct sk_buff * gfar_new_skb(struct net_device *dev)
struct gfar_private *priv = netdev_priv(dev);
struct sk_buff *skb = NULL;
- skb = __skb_dequeue(&priv->rx_recycle);
+ skb = skb_dequeue(&priv->rx_recycle);
if (!skb)
skb = gfar_alloc_skb(dev);
@@ -2754,7 +2754,7 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
if (unlikely(!newskb))
newskb = skb;
else if (skb)
- __skb_queue_head(&priv->rx_recycle, skb);
+ skb_queue_head(&priv->rx_recycle, skb);
} else {
/* Increment the number of packets */
rx_queue->stats.rx_packets++;
^ permalink raw reply related
* Re: introduce dm-snap-mv
From: Christoph Hellwig @ 2010-10-08 9:24 UTC (permalink / raw)
To: McPacino
Cc: Christoph Hellwig, Daniel Phillips, linux-fsdevel, linux-kernel,
dm-devel, Andrew Morton, Alexander Viro, Nick Piggin
In-Reply-To: <AANLkTim9KFuP1_mrUUsMOEspxkfA=SZW2dmTX4WJbfep@mail.gmail.com>
On Fri, Oct 08, 2010 at 05:14:27PM +0800, McPacino wrote:
> Hi Christoph,
>
> I have to take care the cache problem If using the bio directly.
> BHs can be released by kernel when necessary.
>
> Is there any existing code using bio to read/write metadata
> blocks? How do they handle the timing freeing bios? I really
> wish to learn something form it.
If you actually need caching just use the pagecache, e.g.
read_mapping_page to read in your data. That completely abstracts
away the underlying block size.
^ permalink raw reply
* [PATCH 7/6] spi/imx: Support different fifo sizes
From: Uwe Kleine-König @ 2010-10-08 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100902143908.GK14214@pengutronix.de>
From: David Jander <david@protonic.nl>
The i.MX51 ECSPI has a fifo size of 64 entries instead of 8 entries as
found on the other cspi bus devices.
Cc: Jason Wang <jason77.wang@gmail.com>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
this patch depends on patches already acked by Grant Likely and sitting
in Sascha Hauer's imx-for-2.6.37 branch.
Best regards
Uwe
drivers/spi/spi_imx.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
index 6bab2cf..55a38e2 100644
--- a/drivers/spi/spi_imx.c
+++ b/drivers/spi/spi_imx.c
@@ -77,6 +77,7 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ unsigned int fifosize;
};
struct spi_imx_data {
@@ -541,6 +542,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx1_trigger,
.rx_available = mx1_rx_available,
.reset = mx1_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_0_0
@@ -550,6 +552,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx27_trigger,
.rx_available = mx27_rx_available,
.reset = spi_imx0_0_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_0_4
@@ -559,6 +562,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx31_trigger,
.rx_available = mx31_rx_available,
.reset = spi_imx0_4_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_0_7
@@ -568,6 +572,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx31_trigger,
.rx_available = mx31_rx_available,
.reset = spi_imx0_4_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_2_3
@@ -577,6 +582,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = spi_imx2_3_trigger,
.rx_available = spi_imx2_3_rx_available,
.reset = spi_imx2_3_reset,
+ .fifosize = 64,
},
#endif
};
@@ -596,7 +602,7 @@ static void spi_imx_chipselect(struct spi_device *spi, int is_active)
static void spi_imx_push(struct spi_imx_data *spi_imx)
{
- while (spi_imx->txfifo < 8) {
+ while (spi_imx->txfifo < spi_imx->devtype_data.fifosize) {
if (!spi_imx->count)
break;
spi_imx->tx(spi_imx);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 7/6] spi/imx: Support different fifo sizes
From: Uwe Kleine-König @ 2010-10-08 9:24 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: Jason Wang, Sascha Hauer, amit.kucheria-Z7WLFzj8eWMS+FvcfC7Uqw,
David Jander, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20100902143908.GK14214-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: David Jander <david@protonic.nl>
The i.MX51 ECSPI has a fifo size of 64 entries instead of 8 entries as
found on the other cspi bus devices.
Cc: Jason Wang <jason77.wang@gmail.com>
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
this patch depends on patches already acked by Grant Likely and sitting
in Sascha Hauer's imx-for-2.6.37 branch.
Best regards
Uwe
drivers/spi/spi_imx.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c
index 6bab2cf..55a38e2 100644
--- a/drivers/spi/spi_imx.c
+++ b/drivers/spi/spi_imx.c
@@ -77,6 +77,7 @@ struct spi_imx_devtype_data {
void (*trigger)(struct spi_imx_data *);
int (*rx_available)(struct spi_imx_data *);
void (*reset)(struct spi_imx_data *);
+ unsigned int fifosize;
};
struct spi_imx_data {
@@ -541,6 +542,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx1_trigger,
.rx_available = mx1_rx_available,
.reset = mx1_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_0_0
@@ -550,6 +552,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx27_trigger,
.rx_available = mx27_rx_available,
.reset = spi_imx0_0_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_0_4
@@ -559,6 +562,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx31_trigger,
.rx_available = mx31_rx_available,
.reset = spi_imx0_4_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_0_7
@@ -568,6 +572,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = mx31_trigger,
.rx_available = mx31_rx_available,
.reset = spi_imx0_4_reset,
+ .fifosize = 8,
},
#endif
#ifdef CONFIG_SPI_IMX_VER_2_3
@@ -577,6 +582,7 @@ static struct spi_imx_devtype_data spi_imx_devtype_data[] __devinitdata = {
.trigger = spi_imx2_3_trigger,
.rx_available = spi_imx2_3_rx_available,
.reset = spi_imx2_3_reset,
+ .fifosize = 64,
},
#endif
};
@@ -596,7 +602,7 @@ static void spi_imx_chipselect(struct spi_device *spi, int is_active)
static void spi_imx_push(struct spi_imx_data *spi_imx)
{
- while (spi_imx->txfifo < 8) {
+ while (spi_imx->txfifo < spi_imx->devtype_data.fifosize) {
if (!spi_imx->count)
break;
spi_imx->tx(spi_imx);
--
1.7.2.3
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply related
* Re: Kernel Ooops when using kdesu
From: Edward Shishkin @ 2010-10-08 9:22 UTC (permalink / raw)
To: Sven Müller; +Cc: reiserfs-devel
In-Reply-To: <20101007203544.222170@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 4745 bytes --]
Sven Müller wrote:
> Hi Edward,
>
> according to the advice in Gentoo Forums:
>
> http://forums.gentoo.org/viewtopic-t-845764.html
>
> I'll send you the bug report.
>
Hello.
Could you please try the attached patch and report about results?
Thanks,
Edward.
> Behaviour:
> When I try start a program via kdesu (KDE4) I'll get a Kernel Ooops. It's reproducible. The Ooops occurs on x86 and amd64. I've tested it on 2.6.34 and on 2.6.35 (r1 and r5). And until now it seems that only kdesu is affected.
>
> Configuration:
> Kernel: Gentoo-Sources-2.6.35-r5
> Root Device is Reiser4
> Reiser4 Patch is from Kernel.org (Reiser4-for-2.6.35.patch)
> CPU: x86
> The Posting in Gentoo Forums (Link) is from a amd64.
>
> /var/log/messages:
>
> Oct 7 22:26:32 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at (null)
> Oct 7 22:26:32 localhost kernel: IP: [<c01b846a>] checkin_logical_cluster+0xb1/0x176
> Oct 7 22:26:32 localhost kernel: *pde = 00000000
> Oct 7 22:26:32 localhost kernel: Oops: 0000 [#1]
> Oct 7 22:26:32 localhost kernel: last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
> Oct 7 22:26:32 localhost kernel: Modules linked in: pcmcia
> Oct 7 22:26:32 localhost kernel:
> Oct 7 22:26:32 localhost kernel: Pid: 2306, comm: kio_file Not tainted 2.6.35-gentoo-r5 #2 Latitude C610 /Latitude C610
> Oct 7 22:26:32 localhost kernel: EIP: 0060:[<c01b846a>] EFLAGS: 00010246 CPU: 0
> Oct 7 22:26:32 localhost kernel: EIP is at checkin_logical_cluster+0xb1/0x176
> Oct 7 22:26:32 localhost kernel: EAX: 00000001 EBX: c9176d58 ECX: 00000000 EDX: 00000000
> Oct 7 22:26:32 localhost kernel: ESI: 00000000 EDI: 00000000 EBP: cb572eb4 ESP: c9176d14
> Oct 7 22:26:32 localhost kernel: DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Oct 7 22:26:32 localhost kernel: Process kio_file (pid: 2306, ti=c9176000 task=cb376360 task.ti=c9176000)
> Oct 7 22:26:32 localhost kernel: Stack:
> Oct 7 22:26:32 localhost kernel: 00000000 c9176d58 00000000 cb572eb4 00000000 c9176d58 00000000 cb572eb4
> Oct 7 22:26:32 localhost kernel: <0> 00000000 c01bacff 00000000 c9192100 00000000 0000000d cb572eb4 c01baf36
> Oct 7 22:26:32 localhost kernel: <0> fffffff4 00000000 00000000 00000000 00000000 00000001 00000000 00000000
> Oct 7 22:26:32 localhost kernel: Call Trace:
> Oct 7 22:26:32 localhost kernel: [<c01bacff>] ? capture_page_cluster+0xa2/0xc7
> Oct 7 22:26:32 localhost kernel: [<c01baf36>] ? write_end_cryptcompress+0x212/0x222
> Oct 7 22:26:32 localhost kernel: [<c01b7455>] ? reiser4_write_end_careful+0xe8/0x153
> Oct 7 22:26:32 localhost kernel: [<c0148127>] ? pagecache_write_end+0x37/0x3e
> Oct 7 22:26:32 localhost kernel: [<c01ac107>] ? reiser4_dirty_inode+0x8/0x59
> Oct 7 22:26:32 localhost kernel: [<c017c356>] ? pipe_to_file+0x109/0x114
> Oct 7 22:26:32 localhost kernel: [<c01ac107>] ? reiser4_dirty_inode+0x8/0x59
> Oct 7 22:26:32 localhost kernel: [<c01ac107>] ? reiser4_dirty_inode+0x8/0x59
> Oct 7 22:26:32 localhost kernel: [<c017b3ff>] ? splice_from_pipe_feed+0x31/0x9e
> Oct 7 22:26:32 localhost kernel: [<c017c24d>] ? pipe_to_file+0x0/0x114
> Oct 7 22:26:32 localhost kernel: [<c017c1c0>] ? generic_file_splice_write+0xa2/0x12f
> Oct 7 22:26:32 localhost kernel: [<c017c11e>] ? generic_file_splice_write+0x0/0x12f
> Oct 7 22:26:32 localhost kernel: [<c017bca0>] ? vfs_splice_from+0x53/0x5a
> Oct 7 22:26:32 localhost kernel: [<c017c093>] ? direct_splice_actor+0x14/0x18
> Oct 7 22:26:32 localhost kernel: [<c017bb35>] ? splice_direct_to_actor+0xbe/0x172
> Oct 7 22:26:32 localhost kernel: [<c017c07f>] ? direct_splice_actor+0x0/0x18
> Oct 7 22:26:32 localhost kernel: [<c017bc34>] ? do_splice_direct+0x4b/0x64
> Oct 7 22:26:32 localhost kernel: [<c0166440>] ? do_sendfile+0x16c/0x1b5
> Oct 7 22:26:32 localhost kernel: [<c01664c9>] ? sys_sendfile64+0x40/0x86
> Oct 7 22:26:32 localhost kernel: [<c0102510>] ? sysenter_do_call+0x12/0x26
> Oct 7 22:26:32 localhost kernel: Code: 01 74 09 31 f6 83 f8 02 75 1e eb 05 8b 73 3c eb 17 8b 43 0c 31 ff 8b 70 04 03 30 81 c6 ff 0f 00 00 83 d7 00 0f ac fe 0c 8b 7b 48 <8b> 07 f6 c4 01 74 24 89 e8 e8 2f 4a fe ff e8 ac a3 fe ff 8b 4b
> Oct 7 22:26:32 localhost kernel: EIP: [<c01b846a>] checkin_logical_cluster+0xb1/0x176 SS:ESP 0068:c9176d14
> Oct 7 22:26:32 localhost kernel: CR2: 0000000000000000
> Oct 7 22:26:32 localhost kernel: ---[ end trace 401667030bed02db ]---
>
>
> addr2line -e /usr/src/linux/vmlinux -i c01b846a:
>
> /usr/src/linux/fs/reiser4/plugin/file/cryptcompress.c:1722
> /usr/src/linux/fs/reiser4/plugin/file/cryptcompress.c:1780
>
> Let me know if you need any further information. I would be glad if I could help you.
>
> Thx
> Sven
>
[-- Attachment #2: reiser4-fix-write_begin_end_aops.patch --]
[-- Type: text/plain, Size: 5175 bytes --]
Fix write_end_cryptcompress():
update i_size, if pos + count > old i_size.
Signed-off-by: Edward Shishkin <edward.shishkin@gmail.com>
---
fs/reiser4/plugin/file/cryptcompress.c | 47 +++++++++++++++++++++++--------
fs/reiser4/plugin/file/file.c | 2 -
fs/reiser4/plugin/file/file.h | 4 +-
fs/reiser4/plugin/file/file_conversion.c | 6 ---
fs/reiser4/plugin/plugin.h | 2 -
5 files changed, 41 insertions(+), 20 deletions(-)
--- linux-2.6.35.orig/fs/reiser4/plugin/file/cryptcompress.c
+++ linux-2.6.35/fs/reiser4/plugin/file/cryptcompress.c
@@ -3749,13 +3749,14 @@ int write_begin_cryptcompress(struct fil
/* plugin->commit_write */
int write_end_cryptcompress(struct file *file, struct page *page,
- unsigned from, unsigned to)
+ loff_t pos, unsigned copied)
{
- int ret;
+ int ret = 0;
hint_t *hint;
lock_handle *lh;
struct inode * inode;
struct cluster_handle clust;
+ struct reiser4_slide *win = NULL;
unlock_page(page);
@@ -3769,17 +3770,41 @@ int write_end_cryptcompress(struct file
cluster_init_read(&clust, NULL);
clust.hint = hint;
- ret = alloc_cluster_pgset(&clust, cluster_nrpages(inode));
- if (ret)
- goto out;
- clust.index = pg_to_clust(page->index, inode);
- ret = capture_page_cluster(&clust, inode);
- if (ret)
- warning("edward-1557",
- "Capture failed (inode %llu, result=%i)",
- (unsigned long long)get_inode_oid(inode), ret);
+ if (pos + copied > inode->i_size) {
+ win = kmalloc(sizeof(*win), reiser4_ctx_gfp_mask_get());
+ if (win == NULL)
+ goto out;
+ /* make sure there is no holes */
+ assert("edward-xxx", pos <= inode->i_size);
+ ret = set_cluster_by_window(inode, &clust, win, copied, pos);
+ if (ret)
+ goto out;
+ ret = capture_page_cluster(&clust, inode);
+ if (ret) {
+ warning("edward-xxx",
+ "Capture failed (inode %llu, result=%i)",
+ (unsigned long long)get_inode_oid(inode), ret);
+ goto out;
+ }
+ /* FIXME-EDWARD:
+ reserve space for update_sd in write_begin() */
+ ret = update_sd_cryptcompress(inode);
+ }
+ else {
+ ret = alloc_cluster_pgset(&clust, cluster_nrpages(inode));
+ if (ret)
+ goto out;
+ clust.index = pg_to_clust(page->index, inode);
+ ret = capture_page_cluster(&clust, inode);
+ if (ret)
+ warning("edward-1557",
+ "Capture failed (inode %llu, result=%i)",
+ (unsigned long long)get_inode_oid(inode), ret);
+ }
out:
done_lh(lh);
+ if (win)
+ kfree(win);
kfree(hint);
put_cluster_handle(&clust);
return ret;
--- linux-2.6.35.orig/fs/reiser4/plugin/file/file.c
+++ linux-2.6.35/fs/reiser4/plugin/file/file.c
@@ -893,7 +893,7 @@ static int capture_page_and_create_exten
/* plugin->write_end() */
int write_end_unix_file(struct file *file, struct page *page,
- unsigned from, unsigned to)
+ loff_t pos, unsigned copied)
{
unlock_page(page);
return capture_page_and_create_extent(page);
--- linux-2.6.35.orig/fs/reiser4/plugin/file/file.h
+++ linux-2.6.35/fs/reiser4/plugin/file/file.h
@@ -97,7 +97,7 @@ int writepages_unix_file(struct address_
int write_begin_unix_file(struct file *file, struct page *page,
unsigned from, unsigned to);
int write_end_unix_file(struct file *file, struct page *page,
- unsigned from, unsigned to);
+ loff_t pos, unsigned copied);
sector_t bmap_unix_file(struct address_space *, sector_t lblock);
/* other private methods */
@@ -137,7 +137,7 @@ int writepages_cryptcompress(struct addr
int write_begin_cryptcompress(struct file *file, struct page *page,
unsigned from, unsigned to);
int write_end_cryptcompress(struct file *file, struct page *page,
- unsigned from, unsigned to);
+ loff_t pos, unsigned copied);
sector_t bmap_cryptcompress(struct address_space *, sector_t lblock);
/* other private methods */
--- linux-2.6.35.orig/fs/reiser4/plugin/file/file_conversion.c
+++ linux-2.6.35/fs/reiser4/plugin/file/file_conversion.c
@@ -694,16 +694,12 @@ int reiser4_write_end_careful(struct fil
{
int ret;
reiser4_context *ctx;
- unsigned start, end;
struct inode *inode = page->mapping->host;
assert("umka-3101", file != NULL);
assert("umka-3102", page != NULL);
assert("umka-3093", PageLocked(page));
- start = pos & (PAGE_CACHE_SIZE - 1);
- end = start + len;
-
flush_dcache_page(page);
SetPageUptodate(page);
@@ -713,7 +709,7 @@ int reiser4_write_end_careful(struct fil
ret = PTR_ERR(ctx);
goto out;
}
- ret = PROT_PASSIVE(int, write_end, (file, page, start, end));
+ ret = PROT_PASSIVE(int, write_end, (file, page, pos, copied));
/* don't commit transaction under inode semaphore */
context_set_commit_async(ctx);
--- linux-2.6.35.orig/fs/reiser4/plugin/plugin.h
+++ linux-2.6.35/fs/reiser4/plugin/plugin.h
@@ -251,7 +251,7 @@ typedef struct file_plugin {
int (*write_begin)(struct file *file, struct page *page,
unsigned from, unsigned to);
int (*write_end)(struct file *file, struct page *page,
- unsigned from, unsigned to);
+ loff_t pos, unsigned copied);
sector_t (*bmap) (struct address_space * mapping, sector_t lblock);
/* other private methods */
/* save inode cached stat-data onto disk. It was called
^ permalink raw reply
* Re: [PATCH 2 of 3] support of cpupools in xl: commands and library changes
From: Gianni Tedesco @ 2010-10-08 9:21 UTC (permalink / raw)
To: Ian Campbell; +Cc: Juergen Gross, xen-devel@lists.xensource.com
In-Reply-To: <1286527934.22445.48.camel@zakaz.uk.xensource.com>
On Fri, 2010-10-08 at 09:52 +0100, Ian Campbell wrote:
> On Fri, 2010-10-08 at 09:41 +0100, Juergen Gross wrote:
> > On 10/06/10 15:47, Gianni Tedesco wrote:
> > > On Tue, 2010-10-05 at 14:45 +0100, Juergen Gross wrote:
> > >> diff -r cfce8e755505 -r baee85a24411 tools/python/xen/lowlevel/xl/xl.c
> > >> --- a/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 14:19:13 2010 +0200
> > >> +++ b/tools/python/xen/lowlevel/xl/xl.c Tue Oct 05 15:26:24 2010 +0200
> > >> @@ -208,6 +208,11 @@
> > >> return -1;
> > >> }
> > >>
> > >> +int attrib__uint64_t_ptr_set(PyObject *v, uint64_t * *pptr)
> > >> +{
> > >> + return -1;
> > >> +}
> > >> +
> > >> int attrib__libxl_cpumap_set(PyObject *v, libxl_cpumap *pptr)
> > >> {
> > >> return -1;
> > >> @@ -254,6 +259,11 @@
> > >> }
> > >>
> > >> PyObject *attrib__libxl_cpuid_policy_list_get(libxl_cpuid_policy_list
> > >> *pptr)
> > >> +{
> > >> + return NULL;
> > >> +}
> > >> +
> > >> +PyObject *attrib__uint64_t_ptr_get(uint64_t * *pptr)
> > >> {
> > >> return NULL;
> > >> }
> > >
> > > Because of using Reference(Uint64) directly in the idl - the python
> > > bindings autogenerate these type-marshalling functions. It's not quite
> > > clear how these are supposed to be implemented in a generic way! :)
> > >
> > > There ought to be a builtin type for this ala libxl_uuid and other types
> > > to generate correct bindings.
> >
> > Gianni, I suppose I need a builtin for the complete libxl_cpumap type, not
> > only for the uint64_t array due to the size info which is needed to access
> > the array correctly.
Yes exactly, creating a full struct as you have done is "the right way
to do it"(tm). See detailed comments below.
> Yes, I think so.
>
> There is no way in the IDL to have a pure bitmap type which refers to a
> different field in the containing structure to get the length, and doing
> this would likely be unnecessarily complicated.
>
> > I'm not sure how to translate this into the correct bindings. I think the
> > cpumap should be translated into a python list.
>
> Yes, I think lists make sense.
>
> > Which methods do I need to include in xc.c?
>
> I think it will become clear when you try to build it, just follow the
> build errors ;-)
>
> > Or would it be okay to add just some minimal dummy
> > functions and put in the functionality if needed?
Yes exactly as Ian says. You will notice plenty of similar stubbed out
and unimplemented functions in the python bindings that we can do such
nice things with later. If you would like to flesh out the cpupool stuff
at the same time as adding it then that would be much appreciated but
given how incomplete the binding is we can't say it's 'mandatory' and
keep a straight face.
> Personally, given that you are planning to change the type from uint64_t
> to bytes I'd be happy if you stubbed them out for uint64_t for now and
> only implemented properly during the conversion.
Yeha on closer inspection, this is all kind of moot from the binding
perspective. What needs to happen is for libxl_cpumap to be the builtin
type defined in libxl.h (and possibly c&p any destructor functions that
were generated in to libxl.c). We don't need to generate bindings for an
object who's attributes are: (array, length)... Similar to
libxl_string_list.
In that case the existing attrib__libxl_cpumap_(set|get) for cpupoolinfo
can do all of the necessary work of converting to and from python lists
and no patch is required to tools/python/.../xl.c.
But yes, no point doing an non-dummy implementation of that if it's only
going to change before the rest of the binding is actually written! :)
Gianni
^ permalink raw reply
* Re: Parsing a bus fault message?
From: tiejun.chen @ 2010-10-08 9:22 UTC (permalink / raw)
To: david.hagood; +Cc: Scott Wood, linuxppc-dev, Ira W. Snyder
In-Reply-To: <af75f13d9ed8beb29470dffe56d295f5.squirrel@localhost>
david.hagood@gmail.com wrote:
>> Scott Wood wrote:
>> I also meet machine check exception if configure LAW improperly for PCI.
>> (i.e.
>> unmatched PCIe controller id.)
>>
>> From you log looks 0xexxxxxxx should be your PCI space. So you can check
>> if that
>> fall into appropriate LAW configuration. Maybe you can post your boot log
>> and
>> error log here.
>
> Using EP8641A machine description
> Total memory = 1024MB; using 2048kB for hash table (at cfa00000)
> Linux version 2.6.26.2-ep1.10 (SRWhite@WIC-102333) (gcc version 4.0.0
> (DENX ELDK 4.1 4.0.0)) #269 SMP PREEMPT Tue Sep 28 15:48:43 CDT 2010
> Found initrd at 0xcfdfa000:0xcffa9663
> Found legacy serial port 0 for /soc8641@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=500000000, speed=0
> Found legacy serial port 1 for /soc8641@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=500000000, speed=0
> CPU maps initialized for 1 thread per core
> (thread shift is 0)
> console [udbg0] enabled
> Entering add_active_range(0, 0, 262144) 0 entries of 256 used
> EP8641A board from Embedded Planet
> Top of RAM: 0x40000000, Total RAM: 0x40000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0 -> 196608
> Normal 196608 -> 196608
> HighMem 196608 -> 262144
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 262144
> On node 0 totalpages: 262144
> DMA zone: 1536 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 195072 pages, LIFO batch:31
> Normal zone: 0 pages used for memmap
> HighMem zone: 512 pages used for memmap
> HighMem zone: 65024 pages, LIFO batch:15
> Movable zone: 0 pages used for memmap
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
> Kernel command line: root=/dev/ram rw console=ttyS0,115200
> ip=10.200.120.158:::255.255.0.0::eth0
> mtdparts=physmap-flash.0:0x1300000(linux)ro,0x6bc0000(jffs),-(rsvd)ro
> mpic: Setting up MPIC " MPIC " version 1.2 at e0040000, max 2 CPUs
> mpic: ISU size: 16, shift: 4, mask: f
> mpic: Initializing for 80 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> time_init: decrementer frequency = 125.000000 MHz
> time_init: processor frequency = 1500.000000 MHz
> clocksource: timebase mult[2000000] shift[22] registered
> clockevent: decrementer mult[2000] shift[16] cpu[0]
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> High memory: 262144k
> Memory: 1031248k/1048576k available (3064k kernel code, 16476k reserved,
> 84k data, 149k bss, 164k init)
> Calibrating delay loop... 249.85 BogoMIPS (lpj=499712)
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> Synchronizing timebase
> Got ack
> score 299, offset 1000
> score 299, offset 500
> score 299, offset 250
> score 299, offset 125
> score 299, offset 62
> score 297, offset 31
> score -299, offset 15
> score 297, offset 23
> score 253, offset 19
> score -299, offset 17
> score -269, offset 18
> Min 18 (score -269), Max 19 (score 253)
> Final offset: 19 (269/300)
> clockevent: decrementer mult[2000] shift[16] cpu[1]
> Brought up 2 CPUs
> net_namespace: 208 bytes
> NET: Registered protocol family 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> NET: Registered protocol family 1
> checking if image is initramfs...it isn't (no cpio magic); looks like an
> initrd
> Freeing initrd memory: 1725k freed
> setup_kcore: restrict size=3fffffff
> of-fsl-dma e0021300.dma: Probe the Freescale DMA driver for
> fsl,eloplus-dma controller at e0021300...
> of-fsl-dma-channel e0021100.dma-channe: #0 (fsl,eloplus-dma-channel), irq 20
> of-fsl-dma-channel e0021180.dma-channe: #1 (fsl,eloplus-dma-channel), irq 21
> of-fsl-dma-channel e0021200.dma-channe: #2 (fsl,eloplus-dma-channel), irq 22
> of-fsl-dma-channel e0021280.dma-channe: #3 (fsl,eloplus-dma-channel), irq 23
> Setting up RapidIO peer-to-peer network /rapidio@e00c0000
> fsl-of-rio e00c0000.rapidio: Of-device full name /rapidio@e00c0000
> fsl-of-rio e00c0000.rapidio: Regs start 0xe00c0000 size 0x20000
> fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
> 0x0000000020000000.
> fsl-of-rio e00c0000.rapidio: bellirq: 50, txirq: 53, rxirq 54
> fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
> fsl-of-rio e00c0000.rapidio: Hardware port width: 4
> fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
> fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> JFFS2 version 2.2. (NAND) � 2001-2006 Red Hat, Inc.
> msgmni has been set to 1507
> io scheduler noop registered (default)
> Generic RTC Driver v1.07
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 28) is a 16550A
> brd: module loaded
> loop: module loaded
> Gianfar MII Bus: probed
> eth0: Gianfar Ethernet Controller Version 1.2, 00:10:ec:01:1a:d3
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.2, 00:10:ec:81:1a:d3
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> eth2: Gianfar Ethernet Controller Version 1.2, 00:10:ec:41:1a:d3
> eth2: Running with NAPI enabled
> eth2: 256/256 RX/TX BD ring size
> eth3: Gianfar Ethernet Controller Version 1.2, 00:10:ec:c1:1a:d3
> eth3: Running with NAPI enabled
> eth3: 256/256 RX/TX BD ring size
> physmap platform flash device: 08000000 at f8000000
> physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> physmap-flash.0: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> 3 cmdlinepart partitions found on MTD device physmap-flash.0
> Creating 3 MTD partitions on "physmap-flash.0":
> 0x00000000-0x01300000 : "linux"
> 0x01300000-0x07ec0000 : "jffs"
> 0x07ec0000-0x08000000 : "rsvd"
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> IP-Config: Complete:
> device=eth0, addr=10.200.120.158, mask=255.255.0.0, gw=255.255.255.255,
> host=10.200.120.158, domain=, nis-domain=(none),
> bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 164k init
> PHY: e0024520:10 - Link is Up - 100/Full
> RIO: discover master port 0, RIO0 mport
> rionetlink_init: receive handler registration suceeded!!!!
> rionetlink_init: rio_register_driver suceeded!!!!
>
> Besides, in my setup, there are 2 LAWS programmed to point at the PEX: one
> mapping A0000000 to BFFFFFFF to the PEX, and one mapping E2000000 to
> E2FFFFFF. My code directly scans the LAWS and picks the first one it sees
> mapped to the PEX, so it is picking A00000000, and using that. Is there an
> issue with having 2 LAWs mapping the same device to different locations?
>
I think it should be allowed to use two LAWs to map different space for PCIe
since I ever saw more one LAWs are created for different RAM space.
Sorry for this delay response.
-Tiejun
>
> Being unfortunately a man of many hats, I haven't had a lot of time today
> to work on this particular fire. Hopefully in the next couple of days I
> can get some more time to look into it more.
>
> I do thank all of you for the pointers, and I'll look into them.
>
> (BTW: Anybody near Wichita, and want to earn some extra $$$ helping me out?)
>
>
>
^ permalink raw reply
* Re: Peculiar stuff in hci_ath3k/badness in hci_uart
From: Suraj Sumangala @ 2010-10-08 9:18 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel@vger.kernel.org, marcel@holtmann.org,
linux-bluetooth@vger.kernel.org
In-Reply-To: <20101007214134.6bcd2e8f@lxorguk.ukuu.org.uk>
Hi Alan,
On 10/8/2010 2:11 AM, Alan Cox wrote:
> Noticed this while looking at Savoy's stuff
>
>
> ath_wakeup_ar3k:
>
> int status = tty->driver->ops->tiocmget(tty, NULL);
>
I agree, it will be a problem if the underlying driver try to access the
"struct file". Is there any other way I can get the MCR status here
without providing user space pointer?
>
> Fortunately I looked further and the further I looked the more fun it gets
>
> in hci_uart we have
>
> len = tty->ops->write(tty, skb->data, skb->len);
>
Regards
Suraj
^ permalink raw reply
* Re: g_ether broken on musb
From: Grazvydas Ignotas @ 2010-10-08 9:17 UTC (permalink / raw)
To: Ming Lei
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi
In-Reply-To: <AANLkTintN9anKx1JVGVjusyEX9Q9cr-Bo_oiNdkvwa_m-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> I have tried patch-v2.6.36-rc6-next-20101006 on my beagle B5, seems
> no such problem.
Did you try booting with the cable attached? The problem only shows up
if I boot the board with cable attached, no such problem after replug.
I also have g_ether compiled into kernel, maybe that makes a
difference. Could also be bootloader messing things up..
> Are your musb working at fullspeed? I know musb at fullspeed has bee
> broken for some time.
I think it's hi-speed, PC lists the gadget attached to EHCI root hub
(not sure how to confirm).
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH] ARM: imx serial driver: fix resume
From: Uwe Kleine-König @ 2010-10-08 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286384236-4241-1-git-send-email-daniel@caiaq.de>
Hello Daniel (and Volker),
On Wed, Oct 06, 2010 at 06:57:16PM +0200, Daniel Mack wrote:
> From: Volker Ernst <volker.ernst@txtr.com>
>
> I just came across a bug in the IMX31 serial driver which is still
> present in the newest kernels and which prevents successful
> resume-operation for the IMX31 serial ports.
>
> What happens is that in "drivers/serial/imx.c" on resume function
> "serial_imx_resume" gets called. This function in turn calls
> "uart_resume_port" (in the generic serial driver "serial_core.c"),
> which in turn calls "imx_start_tx" in "imx.c" (in case the SIO-port
> was really suspended) which in turn calls "imx_transmit_buffer".
>
> However calling "imx_transmit_buffer" with an empty TX-fifo (as is
> usually the case) will result in the serial port starting to transmit
> (actually the old [already sent] tx-buffer), as there is no check if
> the tx-buffer is empty before starting to feed tx-fifo-data to the
> serial port hardware.
>
> Signed-off-by: Volker Ernst <volker.ernst@txtr.com>
> Cc: Daniel Mack <daniel@caiaq.de>
> Cc: Andy Green <andy@warmcat.com>
> ---
>
> Volker did all the work on this, he just doesn't want to push his great
> contributions upstream, so I do it for him :)
>
>
> drivers/serial/imx.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/serial/imx.c b/drivers/serial/imx.c
> index 66ecc7a..0170119 100644
> --- a/drivers/serial/imx.c
> +++ b/drivers/serial/imx.c
> @@ -328,13 +328,13 @@ static inline void imx_transmit_buffer(struct imx_port *sport)
> struct circ_buf *xmit = &sport->port.state->xmit;
>
> while (!(readl(sport->port.membase + UTS) & UTS_TXFULL)) {
> + if (uart_circ_empty(xmit))
> + break;
As readl is a hardware access and uart_circ_empty "only" needs RAM, I
wonder if using
while (!uart_circ_empty(xmit) &&
!(readl(sport->port.membase + UTS) & UTS_TXFULL)) {
would be a tad smarter.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [Qemu-devel] [PATCH 7/7] Remove obsolete 'f' double parameter type
From: Jes.Sorensen @ 2010-10-08 9:16 UTC (permalink / raw)
To: qemu-devel; +Cc: pbonzini, armbru
In-Reply-To: <1286529360-5715-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
'f' double is no longer used, and we should be using floating point
variables to store byte sizes. Remove it.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
monitor.c | 18 +-----------------
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/monitor.c b/monitor.c
index 6dd1926..6678fb5 100644
--- a/monitor.c
+++ b/monitor.c
@@ -83,10 +83,6 @@
* suffix, which multiplies the value by 2^40 for
* suffixes T and t, 2^30 for suffixes G and g, 2^20 for
* M and m, 2^10 for K and k
- * 'f' double
- * user mode accepts an optional G, g, M, m, K, k suffix,
- * which multiplies the value by 2^30 for suffixes G and
- * g, 2^20 for M and m, 2^10 for K and k
* 'T' double
* user mode accepts an optional ms, us, ns suffix,
* which divides the value by 1e3, 1e6, 1e9, respectively
@@ -3726,7 +3722,6 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
p = end;
}
break;
- case 'f':
case 'T':
{
double val;
@@ -3742,17 +3737,7 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
if (get_double(mon, &val, &p) < 0) {
goto fail;
}
- if (c == 'f' && *p) {
- switch (*p) {
- case 'K': case 'k':
- val *= 1 << 10; p++; break;
- case 'M': case 'm':
- val *= 1 << 20; p++; break;
- case 'G': case 'g':
- val *= 1 << 30; p++; break;
- }
- }
- if (c == 'T' && p[0] && p[1] == 's') {
+ if (p[0] && p[1] == 's') {
switch (*p) {
case 'm':
val /= 1e3; p += 2; break;
@@ -4230,7 +4215,6 @@ static int check_client_args_type(const QDict *client_args,
return -1;
}
break;
- case 'f':
case 'T':
if (qobject_type(client_arg) != QTYPE_QINT &&
qobject_type(client_arg) != QTYPE_QFLOAT) {
--
1.7.2.3
^ permalink raw reply related
* [Qemu-devel] [PATCH 6/7] Clarify default values in migration speed argument in monitor
From: Jes.Sorensen @ 2010-10-08 9:15 UTC (permalink / raw)
To: qemu-devel; +Cc: pbonzini, armbru
In-Reply-To: <1286529360-5715-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
hmp-commands.hx | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 95bdb91..f138a76 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -756,7 +756,8 @@ ETEXI
.name = "migrate_set_speed",
.args_type = "value:o",
.params = "value",
- .help = "set maximum speed (in bytes) for migrations",
+ .help = "set maximum speed (in bytes) for migrations. "
+ "Defaults to KB if no size suffix is specified, ie. K/M/G/T",
.user_print = monitor_user_noop,
.mhandler.cmd_new = do_migrate_set_speed,
},
--
1.7.2.3
^ permalink raw reply related
* [Qemu-devel] [PATCH 5/7] Switch migrate_set_speed() to take an 'o' argument rather than a float.
From: Jes.Sorensen @ 2010-10-08 9:15 UTC (permalink / raw)
To: qemu-devel; +Cc: pbonzini, armbru
In-Reply-To: <1286529360-5715-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
hmp-commands.hx | 2 +-
migration.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 81999aa..95bdb91 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -754,7 +754,7 @@ ETEXI
{
.name = "migrate_set_speed",
- .args_type = "value:f",
+ .args_type = "value:o",
.params = "value",
.help = "set maximum speed (in bytes) for migrations",
.user_print = monitor_user_noop,
diff --git a/migration.c b/migration.c
index 468d517..9ee8b17 100644
--- a/migration.c
+++ b/migration.c
@@ -132,10 +132,10 @@ int do_migrate_cancel(Monitor *mon, const QDict *qdict, QObject **ret_data)
int do_migrate_set_speed(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
- double d;
+ int64_t d;
FdMigrationState *s;
- d = qdict_get_double(qdict, "value");
+ d = qdict_get_int(qdict, "value");
d = MAX(0, MIN(UINT32_MAX, d));
max_throttle = d;
--
1.7.2.3
^ permalink raw reply related
* [Qemu-devel] [PATCH 4/7] Add support for 'o' octet (bytes) format as monitor parameter.
From: Jes.Sorensen @ 2010-10-08 9:15 UTC (permalink / raw)
To: qemu-devel; +Cc: pbonzini, armbru
In-Reply-To: <1286529360-5715-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Octet format relies on strtosz which supports K/k, M/m, G/g, T/t
suffixes and unit support for humans, like 1.3G
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
monitor.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index fbb678d..6dd1926 100644
--- a/monitor.c
+++ b/monitor.c
@@ -78,6 +78,11 @@
* 'l' target long (32 or 64 bit)
* 'M' just like 'l', except in user mode the value is
* multiplied by 2^20 (think Mebibyte)
+ * 'o' octets (aka bytes)
+ * user mode accepts an optional T, t, G, g, M, m, K, k
+ * suffix, which multiplies the value by 2^40 for
+ * suffixes T and t, 2^30 for suffixes G and g, 2^20 for
+ * M and m, 2^10 for K and k
* 'f' double
* user mode accepts an optional G, g, M, m, K, k suffix,
* which multiplies the value by 2^30 for suffixes G and
@@ -3699,6 +3704,28 @@ static const mon_cmd_t *monitor_parse_command(Monitor *mon,
qdict_put(qdict, key, qint_from_int(val));
}
break;
+ case 'o':
+ {
+ ssize_t val;
+ char *end;
+
+ while (qemu_isspace(*p))
+ p++;
+ if (*typestr == '?') {
+ typestr++;
+ if (*p == '\0') {
+ break;
+ }
+ }
+ val = strtosz(p, &end);
+ if (val < 0) {
+ monitor_printf(mon, "invalid size\n");
+ goto fail;
+ }
+ qdict_put(qdict, key, qint_from_int(val));
+ p = end;
+ }
+ break;
case 'f':
case 'T':
{
@@ -4196,6 +4223,7 @@ static int check_client_args_type(const QDict *client_args,
case 'i':
case 'l':
case 'M':
+ case 'o':
if (qobject_type(client_arg) != QTYPE_QINT) {
qerror_report(QERR_INVALID_PARAMETER_TYPE, client_arg_name,
"int");
--
1.7.2.3
^ permalink raw reply related
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.