* [PATCH] DAPL v2.0: common: remove assert for incorrect events during cm_request
From: Davis, Arlin R @ 2011-10-31 20:53 UTC (permalink / raw)
To: linux-rdma; +Cc: ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1006 bytes --]
Simply print a warning message. Connection callback doesn't
forward invalid events to consumer so no need to assert.
Signed-off-by: Arlin Davis <arlin.r.davis@intel.com>
---
dapl/common/dapl_evd_connection_callb.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dapl/common/dapl_evd_connection_callb.c b/dapl/common/dapl_evd_connection_callb.c
index 3166702..a28d8d6 100644
--- a/dapl/common/dapl_evd_connection_callb.c
+++ b/dapl/common/dapl_evd_connection_callb.c
@@ -181,9 +181,10 @@ dapl_evd_connection_callback(IN dp_ib_cm_handle_t ib_cm_handle,
default:
{
dapl_os_unlock(&ep_ptr->header.lock);
+ dapl_log(DAPL_DBG_TYPE_WARN,
+ "dapl_evd_conn_cb() unknown event 0x%x\n",
+ dat_event_num);
evd_ptr = NULL;
-
- dapl_os_assert(0); /* shouldn't happen */
break;
}
}
--
1.7.3
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ÙšŠ{ayº\x1dʇڙë,j\a¢f£¢·hš‹»öì\x17/oSc¾™Ú³9˜uÀ¦æå‰È&jw¨®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿïêäz¹Þ–Šàþf£¢·hšˆ§~ˆmš
^ permalink raw reply related
* [PATCH] DAPL v2.0: common: dat_evd_free seg faults with resized software EVD
From: Davis, Arlin R @ 2011-10-31 20:53 UTC (permalink / raw)
To: linux-rdma; +Cc: ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org
dapl_evd_resize is attempting to resize a CQ but there is no
CQ attached to a software EVD. Add check for cq_handle
before resizing.
Signed-off-by: Arlin Davis <arlin.r.davis@intel.com>
---
dapl/common/dapl_evd_resize.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/dapl/common/dapl_evd_resize.c b/dapl/common/dapl_evd_resize.c
index 762fad4..f36270c 100644
--- a/dapl/common/dapl_evd_resize.c
+++ b/dapl/common/dapl_evd_resize.c
@@ -108,11 +108,14 @@ DAT_RETURN DAT_API dapl_evd_resize(IN DAT_EVD_HANDLE evd_handle,
goto bail;
}
- dat_status = dapls_ib_cq_resize(evd_ptr->header.owner_ia,
- evd_ptr, &evd_qlen);
- if (dat_status != DAT_SUCCESS) {
- dapl_os_unlock(&evd_ptr->header.lock);
- goto bail;
+ if (evd_ptr->ib_cq_handle) {
+
+ dat_status = dapls_ib_cq_resize(evd_ptr->header.owner_ia,
+ evd_ptr, &evd_qlen);
+ if (dat_status != DAT_SUCCESS) {
+ dapl_os_unlock(&evd_ptr->header.lock);
+ goto bail;
+ }
}
dat_status = dapls_evd_event_realloc(evd_ptr, evd_qlen);
--
1.7.3
^ permalink raw reply related
* [PATCH v5] CPU hotplug, Freezer: Fix race between CPU hotplug and freezer
From: Srivatsa S. Bhat @ 2011-10-31 20:51 UTC (permalink / raw)
To: rjw
Cc: a.p.zijlstra, stern, pavel, len.brown, mingo, akpm,
suresh.b.siddha, lucas.demarchi, linux-pm, rusty, vatsa,
ashok.raj, linux-kernel, tj
The CPU hotplug notifications sent out by the _cpu_up() and _cpu_down()
functions depend on the value of the 'tasks_frozen' argument passed to them
(which indicates whether tasks have been frozen or not).
(Examples for such CPU hotplug notifications: CPU_ONLINE, CPU_ONLINE_FROZEN,
CPU_DEAD, CPU_DEAD_FROZEN).
Thus, it is essential that while the callbacks for those notifications are
running, the state of the system with respect to the tasks being frozen or
not remains unchanged, *throughout that duration*. Hence there is a need for
synchronizing the CPU hotplug code with the freezer subsystem.
Since the freezer is involved only in the Suspend/Hibernate call paths, this
patch hooks the CPU hotplug code to the suspend/hibernate notifiers
PM_[SUSPEND|HIBERNATE]_PREPARE and PM_POST_[SUSPEND|HIBERNATE] to prevent
the race between CPU hotplug and freezer, thus ensuring that CPU hotplug
notifications will always be run with the state of the system really being
what the notifications indicate, _throughout_ their execution time.
v5: * Removed the new freezer notifiers since freezer is used only in suspend
and hibernate call paths. Used the suspend/hibernate notifier events
to synchronize CPU hotplug and freezer.
v4: * Retained the value 0 for the 'tasks_frozen' argument, while calling
_cpu_up() and _cpu_down().
Removed the unnecessary PM_POST_FREEZE and PM_THAW_PREPARE notifications.
v3: * Added synchronization between CPU hotplug and the freezer subsystem
without introducing any new locks in the CPU hotplug call path.
v2: * Removed the atomic_t declaration of tasks_frozen flag and the
atomic_[set|read] functions since they were unnecessary.
* Updated the changelog to give an example scenario where things could go
wrong due to the bug in the CPU hotplug call path.
References:
v1 -> http://thread.gmane.org/gmane.linux.kernel/1198312/
v2 -> http://thread.gmane.org/gmane.linux.kernel/1198312/focus=1199087
v3 -> http://thread.gmane.org/gmane.linux.documentation/3472
v4 -> http://thread.gmane.org/gmane.linux.documentation/3485
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
kernel/cpu.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 12b7458..aa39dd7 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -15,6 +15,7 @@
#include <linux/stop_machine.h>
#include <linux/mutex.h>
#include <linux/gfp.h>
+#include <linux/suspend.h>
#ifdef CONFIG_SMP
/* Serializes the updates to cpu_online_mask, cpu_present_mask */
@@ -476,6 +477,79 @@ static int alloc_frozen_cpus(void)
return 0;
}
core_initcall(alloc_frozen_cpus);
+
+/*
+ * Prevent regular CPU hotplug from racing with the freezer, by disabling CPU
+ * hotplug when tasks are about to be frozen. Also, don't allow the freezer
+ * to continue until any currently running CPU hotplug operation gets
+ * completed.
+ * To modify the 'cpu_hotplug_disabled' flag, we need to acquire the
+ * 'cpu_add_remove_lock'. And this same lock is also taken by the regular
+ * CPU hotplug path and released only after it is complete. Thus, we
+ * (and hence the freezer) will block here until any currently running CPU
+ * hotplug operation gets completed.
+ */
+void cpu_hotplug_disable_before_freeze(void)
+{
+ cpu_maps_update_begin();
+ cpu_hotplug_disabled = 1;
+ cpu_maps_update_done();
+}
+
+
+/*
+ * When tasks have been thawed, re-enable regular CPU hotplug (which had been
+ * disabled while beginning to freeze tasks).
+ */
+void cpu_hotplug_enable_after_thaw(void)
+{
+ cpu_maps_update_begin();
+ cpu_hotplug_disabled = 0;
+ cpu_maps_update_done();
+}
+
+/*
+ * When callbacks for CPU hotplug notifications are being executed, we must
+ * ensure that the state of the system with respect to the tasks being frozen
+ * or not, as reported by the notification, remains unchanged *throughout the
+ * duration* of the execution of the callbacks.
+ * Hence we need to prevent the freezer from racing with regular CPU hotplug.
+ *
+ * This synchronization is implemented by mutually excluding regular CPU
+ * hotplug and Suspend/Hibernate call paths by hooking onto the Suspend/
+ * Hibernate notifications.
+ */
+static int
+cpu_hotplug_pm_callback(struct notifier_block *nb,
+ unsigned long action, void *ptr)
+{
+ switch (action) {
+
+ case PM_SUSPEND_PREPARE:
+ case PM_HIBERNATION_PREPARE:
+ cpu_hotplug_disable_before_freeze();
+ break;
+
+ case PM_POST_SUSPEND:
+ case PM_POST_HIBERNATION:
+ cpu_hotplug_enable_after_thaw();
+ break;
+
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return NOTIFY_OK;
+}
+
+
+int cpu_hotplug_pm_sync_init(void)
+{
+ pm_notifier(cpu_hotplug_pm_callback, 0);
+ return 0;
+}
+core_initcall(cpu_hotplug_pm_sync_init);
+
#endif /* CONFIG_PM_SLEEP_SMP */
/**
^ permalink raw reply related
* Re: Xen 4.1.2 PVHVM guest with Linux 3.1.0 network problem, empty MAC address (all zeroes)
From: Pasi Kärkkäinen @ 2011-10-31 20:51 UTC (permalink / raw)
To: xen-devel; +Cc: xen
In-Reply-To: <20111031201336.GD12984@reaktio.net>
On Mon, Oct 31, 2011 at 10:13:36PM +0200, Pasi Kärkkäinen wrote:
> Hello,
>
> While testing Fedora 16 Xen PVHVM guests I noticed the following problem:
>
> When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0,
> but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the
> vif/tap interfaces disappear from dom0..
> so the bridge in dom0 doesn't have any vifs/taps connected to it anymore.
>
> Has anyone seen that behaviour?
>
> I bet that's also the reason why eth0 inside the PVHVM guest
> has a MAC address with only zeroes in it: 00:00:00:00:00:00.
>
> If I disable PVHVM with "xen_platform_pci=0" in the domain cfgfile
> then network for the guest works OK using the qemu-dm emulated nic.
>
> PVHVM guest cfgfile:
>
<snip>
>
> Some output from inside the PVHVM guest:
>
> # ifconfig eth0
> eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
<snip>
>
> Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email.
> Some parts of the guest dmesg here:
>
> $ egrep -i 'xen|vif' xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
>
<snip>
>
> dom0 kernel (Linux 3.1.0 aswell) messages:
>
<snip>
>
>
> "xm log" doesn't have any errors.
> Any ideas how to fix this? Why do the vif/tap devices disappear from dom0?
>
Well.. it was actually as simple as removing "type=ioemu" from the vif line.
Working vif-example for Xen PVHVM Linux guest VM:
vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]
So uhm.. when enabling PVHVM there's no need to modify the disk line,
but you need to modify the vif-line.. is that like it should be ?
-- Pasi
^ permalink raw reply
* Re: [Qemu-devel] [PULL] [PATCH 00/10] Linux-user patches for 1.0
From: Anthony Liguori @ 2011-10-31 20:49 UTC (permalink / raw)
To: Riku Voipio; +Cc: qemu-devel
In-Reply-To: <20111031192757.GA11442@afflict.kos.to>
On 10/31/2011 02:27 PM, Riku Voipio wrote:
> Fixes related linux-user qemu targetting 1.0 are available in
> the git repository at:
>
> git://git.linaro.org/people/rikuvoipio/qemu.git linux-user-for-upstream
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Alexander Graf (2):
> linux-user: fix openat
> linux-user: implement reboot syscall
>
> Matthias Braun (3):
> linux-user: fix TARGET_RLIM_INFINITY declaration
> linux-user: fix rlimit syscalls on sparc(64)
> linux-user: fix abi_(u)long, target_ulong mismatch
>
> Richard Henderson (5):
> sparc-linux-user: Handle SIGILL.
> sparc-linux-user: Fixup sending SIGSEGV
> sparc-linux-user: Add some missing syscall numbers
> ppc64-linux-user: Properly interpret the entry function descriptor.
> ppc64-linux-user: Fix syscall return type.
>
> linux-user/elfload.c | 8 +-
> linux-user/main.c | 26 ++--
> linux-user/qemu-types.h | 12 ++
> linux-user/signal.c | 22 ++--
> linux-user/sparc/syscall_nr.h | 3 +
> linux-user/strace.c | 4 +-
> linux-user/syscall.c | 272 ++++++++++++++++++++---------------------
> linux-user/syscall_defs.h | 17 ++-
> linux-user/vm86.c | 4 +-
> 9 files changed, 193 insertions(+), 175 deletions(-)
>
>
>
^ permalink raw reply
* Re: [PATCH] bonding:update speed/duplex for NETDEV_CHANGE
From: Ben Hutchings @ 2011-10-31 20:48 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Weiping Pan, netdev, andy, linux-kernel
In-Reply-To: <14973.1320093129@death>
On Mon, 2011-10-31 at 13:32 -0700, Jay Vosburgh wrote:
[...]
> This particular case arises only during enslavement. The call
> to bond_update_speed_duplex call has failed, but the device is marked by
> bonding to be up. Bonding complains that the device isn't down, but it
> cannot get speed and duplex, and therefore is assuming them to be
> 100/Full.
>
> The catch is that this happens only for the ARP monitor, because
> it initially presumes a slave to be up regardless of actual carrier
> state (for historical reasons related to very old 10 or 10/100 drivers,
> prior to the introduction of netif_carrier_*).
Right, I gathered that. Is there any reason to use the ARP monitor when
all slaves support link state notification? Maybe the bonding
documentation should recommend miimon in section 7, not just in section
2.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Simon Glass @ 2011-10-31 20:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311644.02847.vapier@gentoo.org>
Hi Mike,
On Mon, Oct 31, 2011 at 1:44 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 31 October 2011 15:11:35 Simon Glass wrote:
>> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> > If we move the local funcs to the top of the file, and use the
>> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
>> > duplicated prototypes.
>> >
>> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>>
>> This is much cleaner - is the correct style to put attribute tags on
>> the previous line?
>
> when responding to add your own, there isn't any real protocol. ?just normal
> e-mail etiquette (no top posting/etc...). ?patchwork/humans will do the right
> thing when manually updating the changelog.
> -mike
>
Actually I meant the __maybe_unused tag before the function name.
Regards,
Simon
^ permalink raw reply
* [U-Boot] [PATCH 3/4] EHCI: adjust for mx5
From: Jana Rapava @ 2011-10-31 20:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EAE5830.8050700@compulab.co.il>
2011/10/31 Igor Grinberg <grinberg@compulab.co.il>
> > +struct mxc_ulpi_regs {
> > + u8 vendor_id_low; /* 0x00 - Vendor ID lower byte */
> > + u8 vendor_id_high; /* 0x01 - Vendor ID upper byte */
> > + u8 product_id_low; /* 0x02 - Product ID lower byte */
> > + u8 product_id_high; /* 0x03 - Product ID higher byte */
> > + /* Function Control; 0x04 - 0x06 Read, 0x04 Write */
> > + u8 function_ctrl_write;
> > + u8 function_ctrl_set; /* 0x05 Set */
> > + u8 function_ctrl_clear; /* 0x06 Clear */
> > + /* Interface Control; 0x07 - 0x09 Read, 0x07 Write */
> > + u8 iface_ctrl_write;
> > + u8 iface_ctrl_set; /* 0x08 Set */
> > + u8 iface_ctrl_clear; /* 0x09 Clear */
> > + /* OTG Control; 0x0A - 0x0C Read, 0x0A Write */
> > + u8 otg_ctrl_write;
> > + u8 otg_ctrl_set; /* 0x0B Set */
> > + u8 otg_ctrl_clear; /* 0x0C Clear */
> > + /* USB Interrupt Enable Rising; 0x0D - 0x0F Read, 0x0D Write */
> > + u8 usb_ie_rising_write;
> > + u8 usb_ie_rising_set; /* 0x0E Set */
> > + u8 usb_ie_rising_clear; /* 0x0F Clear */
> > + /* USB Interrupt Enable Falling; 0x10 - 0x12 Read, 0x10 Write */
> > + u8 usb_ie_falling_write;
> > + u8 usb_ie_falling_set; /* 0x11 Set */
> > + u8 usb_ie_falling_clear; /* 0x12 Clear */
> > + u8 usb_int_status; /* 0x13 - USB Interrupt Status */
> > + u8 usb_int_latch; /* 0x14 - USB Interrupt Latch */
> > + u8 debug; /* 0x15 - Debug */
> > + /* Scratch Register; 0x16 - 0x18 Read, 0x16 Write */
> > + u8 scratch_write;
> > + u8 scratch_set; /* 0x17 Set */
> > + u8 scratch_clear; /* 0x18 Clear*/
> > +};
>
>
> These are the generic ULPI specification registers
> and not mxc specific.
> I'd expect to have them in a more generic location.
>
This would be fixed in general ULPI support patch I'm working on. It should
be ready for posting in a few days.
> --
>
Regards,
> Igor.
>
^ permalink raw reply
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit integers"
From: David Zeuthen @ 2011-10-31 20:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
Hi,
I looked more into this and we should probably just use
g_ascii_strtoull() since that function always returns a guint64 no
matter whether you are on 32- or 64-bit. The attached patch does this.
Kay: please apply.
Thanks,
David
On Mon, Oct 31, 2011 at 4:32 PM, David Zeuthen <zeuthen@gmail.com> wrote:
> On Mon, Oct 31, 2011 at 4:13 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
>> Perhaps I'm simply misreading something, but won't going from strtoll to
>> strtoul break things for 32bit case ?
>
> What do you think it would break? Or are you perhaps suggesting we
> should be using strtoull() instead? Please be specific.
>
>
> David
>
[-- Attachment #2: 0001-gudev-Use-g_ascii_strtoull-instead-of-strtoul.patch --]
[-- Type: text/x-patch, Size: 1770 bytes --]
From 2a64773ac80432ca70aa747b55cfaadf3f8c55cb Mon Sep 17 00:00:00 2001
From: David Zeuthen <davidz@redhat.com>
Date: Mon, 31 Oct 2011 16:38:14 -0400
Subject: [PATCH] gudev: Use g_ascii_strtoull() instead of strtoul()
This ensures that we get the same behavior on both 32- and
64-bit. Pointed out on the mailing list:
http://permalink.gmane.org/gmane.linux.hotplug.devel/17145
Signed-off-by: David Zeuthen <davidz@redhat.com>
---
| 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
--git a/extras/gudev/gudevdevice.c b/extras/gudev/gudevdevice.c
index e77b34b..38d602c 100644
--- a/extras/gudev/gudevdevice.c
+++ b/extras/gudev/gudevdevice.c
@@ -538,7 +538,7 @@ out:
* @key: Name of property.
*
* Look up the value for @key on @device and convert it to an unsigned
- * 64-bit integer using strtoul().
+ * 64-bit integer using g_ascii_strtoull().
*
* Returns: The value for @key or 0 if @key doesn't exist or isn't a
* #guint64.
@@ -558,7 +558,7 @@ g_udev_device_get_property_as_uint64 (GUdevDevice *device,
if (s == NULL)
goto out;
- result = strtoul (s, NULL, 0);
+ result = g_ascii_strtoull (s, NULL, 0);
out:
return result;
}
@@ -756,7 +756,7 @@ out:
* @name: Name of the sysfs attribute.
*
* Look up the sysfs attribute with @name on @device and convert it to an unsigned
- * 64-bit integer using strtoul().
+ * 64-bit integer using g_ascii_strtoull().
*
* Returns: The value of the sysfs attribute or 0 if there is no such
* attribute.
@@ -776,7 +776,7 @@ g_udev_device_get_sysfs_attr_as_uint64 (GUdevDevice *device,
if (s == NULL)
goto out;
- result = strtoul (s, NULL, 0);
+ result = g_ascii_strtoull (s, NULL, 0);
out:
return result;
}
--
1.7.6.4
^ permalink raw reply related
* [U-Boot] [PATCH] cmd_bdinfo: simplify local static funcs a bit
From: Mike Frysinger @ 2011-10-31 20:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ1+waUNEtw=xh5UGJApxnL2ovVgVOAt0fTGaypUKVJ+WQ@mail.gmail.com>
On Monday 31 October 2011 15:11:35 Simon Glass wrote:
> On Sun, Oct 30, 2011 at 5:54 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > If we move the local funcs to the top of the file, and use the
> > __maybe_unused define, we can drop a lot of ugly ifdef logic and
> > duplicated prototypes.
> >
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>
> This is much cleaner - is the correct style to put attribute tags on
> the previous line?
when responding to add your own, there isn't any real protocol. just normal
e-mail etiquette (no top posting/etc...). patchwork/humans will do the right
thing when manually updating the changelog.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/5fb80343/attachment.pgp
^ permalink raw reply
* Patch in 3.4.3
From: Jonathan Tripathy @ 2011-10-31 20:43 UTC (permalink / raw)
To: xen-devel
Hi Everyone,
Does Xen 3.4.3 contain the following patch:
http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00483.html
We currently get our Xen rpms from Gitco, and are wondering if it
includes this patch
Thanks
^ permalink raw reply
* Re: [PATCH] bonding:update speed/duplex for NETDEV_CHANGE
From: Jay Vosburgh @ 2011-10-31 20:32 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Weiping Pan, netdev, andy, linux-kernel
In-Reply-To: <1320084906.2735.9.camel@bwh-desktop>
Ben Hutchings <bhutchings@solarflare.com> wrote:
>On Mon, 2011-10-31 at 22:19 +0800, Weiping Pan wrote:
>> Zheng Liang(lzheng@redhat.com) found a bug that if we config bonding with
>> arp monitor, sometimes bonding driver cannot get the speed and duplex from
>> its slaves, it will assume them to be 100Mb/sec and Full, please see
>> /proc/net/bonding/bond0.
>> But there is no such problem when uses miimon.
>>
>> (Take igb for example)
>> I find that the reason is that after dev_open() in bond_enslave(),
>> bond_update_speed_duplex() will call igb_get_settings()
>> , but in that function,
>> it runs ethtool_cmd_speed_set(ecmd, -1); ecmd->duplex = -1;
>> because igb get an error value of status.
>> So even dev_open() is called, but the device is not really ready to get its
>> settings.
>>
>> Maybe it is safe for us to call igb_get_settings() only after
>> this message shows up, that is "igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex,
>> Flow Control: RX".
>[...]
I'll first point out that this patch is somewhat cosmetic, and
really only affects what shows up in /proc/net/bonding/bond0 for speed
and duplex. The reason being that the modes that actually need to use
the speed and duplex information require the miimon for link state
checking, and that code path does the right thing already.
This has probably been wrong all along, but relatively recently
code was added to show the speed and duplex in /proc/net/bonding/bond0,
so it now has a visible effect.
So, the patch is ok as far as it goes, in that it will keep the
values displayed in the /proc file up to date.
However, I'm not sure that faking the speed/duplex to 100/Full
is still the correct thing to do. For the modes that use the
information, the ethtool state won't be queried if carrier is down (and
in those cases, if the speed / duplex returns an error while carrier up,
we should probably pay attention). For the modes that the information
is merely cosmetic, displaying "unknown" as ethtool does is probably a
more accurate representation.
Can you additionally remove the "fake to 100/Full" logic? This
involves changing bond_update_speed_duplex to not fake the speed and
duplex, changing bond_enslave to not issue that warning, and changing
bond_info_show_slave to handle "bad" speed and duplex values.
Anybody see a problem with doing that?
>For any device with autonegotiation enabled, you generally cannot get
>the speed and duplex settings until the link is up. While the link is
>down, you may see a value of 0, ~0, or the best mode currently
>advertised. So I think that the bonding driver should avoid updating
>the slave speed and duplex values whenever autoneg is enabled and the
>link is down.
Well, it's a little more complicated than that. Bonding already
generally avoids checking the speed and duplex if the slave isn't up (or
at least normally won't complain if it fails).
This particular case arises only during enslavement. The call
to bond_update_speed_duplex call has failed, but the device is marked by
bonding to be up. Bonding complains that the device isn't down, but it
cannot get speed and duplex, and therefore is assuming them to be
100/Full.
The catch is that this happens only for the ARP monitor, because
it initially presumes a slave to be up regardless of actual carrier
state (for historical reasons related to very old 10 or 10/100 drivers,
prior to the introduction of netif_carrier_*).
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* ext4 bug ? "Intel 320 SSD write performance – contd."
From: Vincent Pelletier @ 2011-10-31 20:38 UTC (permalink / raw)
To: linux-kernel
Hi.
Reading this blog post[1], I thought the "2nd iteration" results could be
considered a bug in mkfs.ext4 (and possibly any mkfs implementation):
shouldn't mkfs run [FI]TRIM on its target before creating filesystem
structure ?
Disclaimers:
I don't know much about mkfs nor in-kernel fs support to tell which part
should implement this - so I cannot even tell for sure this isn't done
already.
I have no idea how expensive those new calls would be (in general, this
means trimming a _lot_ of pages...).
I don't know how other filesystems/os behave on such bench. But I
don't think this is a problem any SSD could solve at its level.
[1] http://www.mysqlperformanceblog.com/2011/09/28/intel-320-ssd-write-performance-contd/
Regards,
--
Vincent Pelletier
^ permalink raw reply
* Re: [ANNOUNCE] xf86-video-intel 2.16.901
From: Bojan Smojver @ 2011-10-31 20:38 UTC (permalink / raw)
To: jcristau; +Cc: intel-gfx
In-Reply-To: <20111031143752.GM3100@radis.liafa.jussieu.fr>
------- Original message -------
> From: Julien Cristau
> Pretty sure what you should be looking for is in the kernel, not the X
> driver.
I thought this announcement covered the kernel side of things too, which it
then obviously does not. OK, there is hope then. ;-)
--
Bojan
^ permalink raw reply
* Re: [PATCHv2] Compile fix for MSVC
From: Junio C Hamano @ 2011-10-31 20:34 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, kusmabite, ramsay, msysgit, gitster
In-Reply-To: <1320088364-25916-1-git-send-email-vfr@lyx.org>
Thanks. The patch looks good from a POSIX person's point of view, and I do
not immediately see how this would break other variants of Windows build
at least from the code inspection.
So I'll queue this, but I'll leave it to you and msysgit folks to decide
if this topic should be merged to 1.7.8-rc1, as I do not have equipment,
expertise, nor time to judge it myself (other than the code inspection we
have already done here).
Please give me an Ack or two by the end of this week. Thanks.
^ permalink raw reply
* Re: In regard of commit "gudev: Use strtoul to parse unsigned 64-bit integers"
From: David Zeuthen @ 2011-10-31 20:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111031201318.GA2447@blackspire>
On Mon, Oct 31, 2011 at 4:13 PM, Rafał Mużyło <galtgendo@gmail.com> wrote:
> Perhaps I'm simply misreading something, but won't going from strtoll to
> strtoul break things for 32bit case ?
What do you think it would break? Or are you perhaps suggesting we
should be using strtoull() instead? Please be specific.
David
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Ted Ts'o @ 2011-10-31 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, git, James Bottomley, Jeff Garzik, Andrew Morton
In-Reply-To: <7vy5w1ow90.fsf@alter.siamese.dyndns.org>
(removing linux-ide and linux-kernel)
On Mon, Oct 31, 2011 at 11:23:55AM -0700, Junio C Hamano wrote:
> On the other hand, the consumers of "Linus kernel" may want to say that
> they trust your tree and your tags because they can verify them with your
> GPG signature, but also they can independently verify the lieutenants'
> trees you pulled from are genuine. Keeping signed tags and publishing them
> is one way to make it possible, but 400 extra tags in 3 months feels like
> an approach with too much downside (i.e. noise) for that benefit.
I wouldn't put it as "we don't trust Linus's tree", because it's not
true. In general, we do trust Linus's tree. On the other hand, it's
useful if the proof which was submitted at the time of the push could
be verified by third parties.
Suppose the project wasn't Linus, but some other project, say, a
hypothetical Desktop system called Troll3. Let's assume that it's run
by a sole dictator, S. Crew Powerusers, who blindly assumes that any
tree on github is secure, and is confident he or she can detect social
engineering attacks caused by a bad guy grabbing a developer's SSH key
used to push to github, and who can fake a pull request to Linus that
looks real but is really originated by the bad guy. Let's assume
further that the pull request has a signed tag which could be used to
detect such forgeries, but because Mr. Powerusers can't be bothered to
check the tag, because he can't figure out how to update his GPG
keyring and besides, he hates crypto stuff --- and the bad guys know
this, and are good (Kevin Mitnick or better) at social engineering
attacks.
In this sort of scenario, it's useful if *other* people could
independently verify the Troll3 git tree via the crypto signatures,
even though the central maintainer couldn't be bothered to check the
crypto signatures.
Here's an idea.... what if the "signed push" information could be
embedded into the merge commit's description? That is, the
information could sent via a signed git tag, or some other mechanism,
but then part of the git merge would incorporate the GPG signature
into the merge commit's description field (and we could always create
a merge commit so there's a place to put the digital siganture). That
way, it's mostly out of the way, but it's in a well-defined place
where it will always easy to have a third party independently verify
the source of a set of commits in the git tree.
The problem with notes and tags is that they have to be pushed
separately, and might get lost; where as if they are stored in the
merge commit's description, they will always be there.
- Ted
^ permalink raw reply
* [Qemu-devel] [PATCH v2] Support running QEMU on Valgrind
From: Stefan Weil @ 2011-10-31 20:29 UTC (permalink / raw)
To: qemu-devel; +Cc: Stefan Weil, Anthony Liguori, Avi Kivity
Valgrind is a tool which can automatically detect many kinds of bugs.
Running QEMU on Valgrind with x86_64 hosts was not possible because
Valgrind aborts when memalign is called with an alignment larger than
1 MiB. QEMU normally uses 2 MiB on Linux x86_64.
Now the alignment is reduced to the page size when QEMU is running on
Valgrind.
v2:
Instead of using the macro RUNNING_ON_VALGRIND from valgrind.h,
the patch now uses a hack from libvirt which tests for the pre-loaded
vgpreload_*.so shared libraries. This avoids the need for valgrind.h.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
oslib-posix.c | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/oslib-posix.c b/oslib-posix.c
index dbc8ee8..6f29762 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
@@ -36,8 +36,11 @@ extern int daemon(int, int);
#endif
#if defined(__linux__) && defined(__x86_64__)
- /* Use 2MB alignment so transparent hugepages can be used by KVM */
+ /* Use 2 MiB alignment so transparent hugepages can be used by KVM.
+ Valgrind does not support alignments larger than 1 MiB,
+ therefore we need special code which handles running on Valgrind. */
# define QEMU_VMALLOC_ALIGN (512 * 4096)
+# define CONFIG_VALGRIND
#else
# define QEMU_VMALLOC_ALIGN getpagesize()
#endif
@@ -47,7 +50,11 @@ extern int daemon(int, int);
#include "trace.h"
#include "qemu_socket.h"
-
+#if defined(CONFIG_VALGRIND)
+static int running_on_valgrind = -1;
+#else
+# define running_on_valgrind 0
+#endif
int qemu_daemon(int nochdir, int noclose)
{
@@ -89,7 +96,16 @@ void *qemu_vmalloc(size_t size)
void *ptr;
size_t align = QEMU_VMALLOC_ALIGN;
- if (size < align) {
+#if defined(CONFIG_VALGRIND)
+ if (running_on_valgrind < 0) {
+ /* First call, test whether we are running on Valgrind.
+ This is a substitute for RUNNING_ON_VALGRIND from valgrind.h. */
+ const char *ld = getenv("LD_PRELOAD");
+ running_on_valgrind = (ld != NULL && strstr(ld, "vgpreload"));
+ }
+#endif
+
+ if (size < align || running_on_valgrind) {
align = getpagesize();
}
ptr = qemu_memalign(align, size);
--
1.7.2.5
^ permalink raw reply related
* Re: jc/lookup-object-hash from pu crashes on ARM
From: Junio C Hamano @ 2011-10-31 20:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111031125648.GA1757@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Even better could be to start aligning the hashes we pass around,
> using something like this:
>
> union object_hash {
> unsigned char sha1[20];
> uint32_t chunk[5];
> };
>
> which could speed up functions like hashcpy(), hashcmp(), and
> hasheq(). But it's probably not worth the fuss.
The "flag" field in struct ref_list should be moved down to assure
alignment.
struct ref_list {
struct ref_list *next;
unsigned char flag; /* ISSYMREF? ISPACKED? */
unsigned char sha1[20];
unsigned char peeled[20];
char name[FLEX_ARRAY];
};
I am very tempted to take that "union" approach (modulo that I would call
that an "object_name") in the longer run, though.
^ permalink raw reply
* [PATH v2 2/2] pinmux: Unify pin type from signed to unsigned.
From: Marek Belisko @ 2011-10-31 20:27 UTC (permalink / raw)
To: swarren, linus.walleij; +Cc: linux-kernel, grant.likely, Marek Belisko
In-Reply-To: <CACRpkdZ1Y1sHh1oQKFVYUEftyZnJnuUGLmXUHg3vaZKbSfra2Q@mail.gmail.com>
Signed-off-by: Marek Belisko <marek.belisko@open-nandra.com>
---
drivers/pinctrl/core.c | 2 +-
drivers/pinctrl/core.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 423522d..18a7dda 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -87,7 +87,7 @@ struct pinctrl_dev *get_pinctrl_dev_from_dev(struct device *dev,
return found ? pctldev : NULL;
}
-struct pin_desc *pin_desc_get(struct pinctrl_dev *pctldev, int pin)
+struct pin_desc *pin_desc_get(struct pinctrl_dev *pctldev, unsigned int pin)
{
struct pin_desc *pindesc;
unsigned long flags;
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
index 472fa13..759dc1f 100644
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -65,7 +65,7 @@ struct pin_desc {
struct pinctrl_dev *get_pinctrl_dev_from_dev(struct device *dev,
const char *dev_name);
-struct pin_desc *pin_desc_get(struct pinctrl_dev *pctldev, int pin);
+struct pin_desc *pin_desc_get(struct pinctrl_dev *pctldev, unsigned int pin);
int pinctrl_get_device_gpio_range(unsigned gpio,
struct pinctrl_dev **outdev,
struct pinctrl_gpio_range **outrange);
--
1.7.5.4
^ permalink raw reply related
* Re: Proposal for a low-level Linux display framework
From: Jesse Barnes @ 2011-10-31 20:24 UTC (permalink / raw)
To: Alan Cox
Cc: Dave Airlie, linux-fbdev, linaro-dev, Florian Tobias Schandinat,
linux-kernel, dri-devel, Archit Taneja, Rob Clark
In-Reply-To: <20110917212529.6b452bf2@lxorguk.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]
On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Just tell the X driver to not use acceleration, and it you won't get
> > any acceleration used, then you get complete stability. If a driver
> > writer wants to turn off all accel in the kernel driver, it can, its
>
> In fact one thing we actually need really is a "dumb" KMS X server to
> replace the fbdev X server that unaccel stuff depends upon and which
> can't do proper mode handling, multi-head or resizing as a result. A dumb
> fb generic request for a back to front copy might also be useful for
> shadowfb, or at least indicators so you know what the cache behaviour is
> so the X server can pick the right policy.
>
> > We've fixed this in KMS, we don't pass direct mappings to userspace
> > that we can't tear down and refault. We only provide objects via
> > handles. The only place its a problem is where we expose fbdev legacy
> > emulation, since we have to fix the pages.
>
> Which is doable. Horrible but doable. The usb framebuffer code has to
> play games like this with the virtual framebuffer in order to track
> changes by faulting.
>
> There are still some architectural screwups however. DRM continues the
> fbdev worldview that outputs, memory and accelerators are tied together
> in lumps we call video cards. That isn't really true for all cases and
> with capture/overlay it gets even less true.
Sorry for re-opening this ancient thread; I'm catching up from the past
2 months of travel & misc.
I definitely agree about the PC card centric architecture of DRM KMS
(and before it, X). But we have a path out of it now, and lots of
interest from vendors and developers, so I don't think it's an
insurmountable problem by any means.
I definitely understand Florian's worries about DRM vs fb. If nothing
else, there's certainly a perception that fb is simpler and easier to
get right. But really, as others have pointed out, it's solving a
different set of problems than the DRM layer. The latter is actually
trying to expose the features of contemporary hardware in a way that's
as portable as possible. That portability comes at a cost though: the
APIs we add need to get lots of review, and there's no doubt we'll need
to add more as newer, weirder hardware comes along.
Really, I see no reason why fb and DRM can't continue to live side by
side. If a vendor really only needs the features provided by the fb
layer, they're free to stick with a simple fb driver. However, I
expect most vendors making phones, tablets, notebooks, etc will need
and want an architecture that looks a lot like the DRM layer, with
authentication for rendering clients, an command submission ioctl for
acceleration, and memory management, so I expect most of the driver
growth to be in DRM in the near future.
And I totally agree with Dave about having a kmscon. I really wish
someone would implement it so I could have my VTs spinning on a cube.
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [ath9k-devel] AR9285 and Thompson TG585 v8 connection problems
From: Adrian Chadd @ 2011-10-31 20:24 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <CAD2nsn3CeqZN6mmv6i9zUdfcroY6a+N5zbgm9Bf008tv=_4LgQ@mail.gmail.com>
On 1 November 2011 00:04, Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> On Sat, Oct 29, 2011 at 9:02 PM, David Summers
> i assume if we remove the antenna in chain0, the performance will be
> bad. as per my assumption tx will always happen in chain0.(does we
> have some tx diversity?)
If you have an AR9285 with an antenna switch (and I don't have one, so
I can't test) then you MAY be ok. But Felix and others have removed
that TX diversity code from ath9k.
So I'm not sure whether the antenna switch based TX diversity code
would work. FreeBSD? It may work.
But unless you're very lucky, I suggest "no" to the AR9285 + TX diversity :)
(I'll see if I can source some more AR9285's, hopefully one will have
the antenna switch hardware attached.)
Adrian
^ permalink raw reply
* Re: Proposal for a low-level Linux display framework
From: Jesse Barnes @ 2011-10-31 20:24 UTC (permalink / raw)
To: Alan Cox
Cc: Dave Airlie, linux-fbdev, linaro-dev, Florian Tobias Schandinat,
linux-kernel, dri-devel, Archit Taneja, Rob Clark
In-Reply-To: <20110917212529.6b452bf2@lxorguk.ukuu.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]
On Sat, 17 Sep 2011 21:25:29 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Just tell the X driver to not use acceleration, and it you won't get
> > any acceleration used, then you get complete stability. If a driver
> > writer wants to turn off all accel in the kernel driver, it can, its
>
> In fact one thing we actually need really is a "dumb" KMS X server to
> replace the fbdev X server that unaccel stuff depends upon and which
> can't do proper mode handling, multi-head or resizing as a result. A dumb
> fb generic request for a back to front copy might also be useful for
> shadowfb, or at least indicators so you know what the cache behaviour is
> so the X server can pick the right policy.
>
> > We've fixed this in KMS, we don't pass direct mappings to userspace
> > that we can't tear down and refault. We only provide objects via
> > handles. The only place its a problem is where we expose fbdev legacy
> > emulation, since we have to fix the pages.
>
> Which is doable. Horrible but doable. The usb framebuffer code has to
> play games like this with the virtual framebuffer in order to track
> changes by faulting.
>
> There are still some architectural screwups however. DRM continues the
> fbdev worldview that outputs, memory and accelerators are tied together
> in lumps we call video cards. That isn't really true for all cases and
> with capture/overlay it gets even less true.
Sorry for re-opening this ancient thread; I'm catching up from the past
2 months of travel & misc.
I definitely agree about the PC card centric architecture of DRM KMS
(and before it, X). But we have a path out of it now, and lots of
interest from vendors and developers, so I don't think it's an
insurmountable problem by any means.
I definitely understand Florian's worries about DRM vs fb. If nothing
else, there's certainly a perception that fb is simpler and easier to
get right. But really, as others have pointed out, it's solving a
different set of problems than the DRM layer. The latter is actually
trying to expose the features of contemporary hardware in a way that's
as portable as possible. That portability comes at a cost though: the
APIs we add need to get lots of review, and there's no doubt we'll need
to add more as newer, weirder hardware comes along.
Really, I see no reason why fb and DRM can't continue to live side by
side. If a vendor really only needs the features provided by the fb
layer, they're free to stick with a simple fb driver. However, I
expect most vendors making phones, tablets, notebooks, etc will need
and want an architecture that looks a lot like the DRM layer, with
authentication for rendering clients, an command submission ioctl for
acceleration, and memory management, so I expect most of the driver
growth to be in DRM in the near future.
And I totally agree with Dave about having a kmscon. I really wish
someone would implement it so I could have my VTs spinning on a cube.
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Subnet router anycast for FE80/10 ?
From: Andreas Hofmeister @ 2011-10-31 20:22 UTC (permalink / raw)
To: netdev
Hi,
I noticed that once forwarding has been enabled on an interface, there
is a "subnet router anycast address" for the link-local address prefix
FE80/10.
This address seems not to be explicitly mentioned in any RFC, but RFC
4291 says "All routers are required to support the Subnet-Router anycast
addresses for the subnets to which they have interfaces."
In the sense that a Linux router actually has an address FE80/10 on each
ipv6 enabled interface, it seems to be correct to also have FE80:: as an
anycast address on all interfaces which have ipv6 and forwarding enabled.
But then, FE80/10 is not actually supposed to be routed at all and so a
router cannot not really be a router for that particular subnet ?
Or is "FE80::" just supposed to be the anycast equivalent for the "all
routers" multicast address ff02::2 ?
Maybe someone on this list could enlighten me.
Ciao
Andi
^ permalink raw reply
* Re: Out of memory error with git rebase
From: Junio C Hamano @ 2011-10-31 20:21 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <83r51ta1rq.fsf@kalahari.s2.org>
Hannu Koivisto <azure@iki.fi> writes:
> From the documentation I can't figure out any reason why one
> wouldn't always want to use -m. Why is it not the default? I
> think it's pretty much impossible for ordinary users to figure out
> that they need -m in a situation like this.
Because most people do not have too large binary blobs in the history, and
at least when "rebase" was originally written, merge-based rebasing was
way slower than patch-based one.
^ 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.