* [PATCH v3 1/2] Add new strace-graph package to avoid making perl a dependecy for all of strace
From: Matthew McClintock @ 2011-10-31 16:26 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <201110310905.49436.paul.eggleton@linux.intel.com>
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
v2: Change to use PACKAGES_prepend instead of explictly listing all packages
and also fixing the fact we missed the -dev and -dbg packages before
v3: Use += instead of _prepend to add strace-graph packages
meta/recipes-devtools/strace/strace_4.5.20.bb | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/strace/strace_4.5.20.bb b/meta/recipes-devtools/strace/strace_4.5.20.bb
index b3d2aa5..53df067 100644
--- a/meta/recipes-devtools/strace/strace_4.5.20.bb
+++ b/meta/recipes-devtools/strace/strace_4.5.20.bb
@@ -5,7 +5,9 @@ LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=4535377ede62550fdeaf39f595fd550a"
PR = "r2"
-RDEPENDS = "perl"
+PACKAGES =+ "${PN}-graph "
+FILES_${PN}-graph = "${bindir}/strace-graph"
+RDEPENDS_${PN}-graph = "perl"
SRC_URI = "${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.bz2 \
file://sigmask.patch \
--
1.7.6.1
^ permalink raw reply related
* Re: bigalloc and max file size
From: Andreas Dilger @ 2011-10-31 16:34 UTC (permalink / raw)
To: Andreas Dilger
Cc: Theodore Tso, i@coly.li, Andreas Dilger, linux-ext4 development,
Alex Zhuravlev, Tao Ma, hao.bigrat@gmail.com
In-Reply-To: <422BEB28-76D0-4FD8-B7AE-130C9AAE10C0@dilger.ca>
On 2011-10-31, at 10:08 AM, Andreas Dilger <adilger@dilger.ca> wrote:
> On 2011-10-31, at 4:22 AM, Theodore Tso <tytso@MIT.EDU> wrote:
>
>> For cluster file systems, such as when you might build Hadoop on top of ext4, there's no real advantage of using RAID arrays as opposed to having single file systems on each disk. In fact, due to the specd of being able to check multiple disk spindles in parallel, it's advantageous to build cluster file systems on single disk file systems.
>
> For Lustre at least there are a number of reasons why it uses large RAID devices to store the data instead of many small devices:
> - fewer devices that need to be managed at the Filesystem level. Lustre runs on systems with more than 13000 drives, and having to manage connection state for that many internal devices is a lot of overhead.
Doh, hit send too soon...
- reduced complexity of filesystem allocation decisions with fewer large LUNs vs many smaller LUNs
- reduced free space and file fragmentation with fewer large LUNs, since the block allocator for each LUN has more blocks to choose from
- sysadmin of so many unique devices is difficult, while clustering them into RAID sets with hardware management features (we call this blinkenlights) makes this tractable compared to software RAID on generic hardware.
- performance management of the RAID hardware can detect and mask individual drives that are slow compared to others in that RAID set, which is much harder if each drive is treated individually
These reasons don't apply to all cluster filesystems, but I thought I'd chime in on why we use large LUNs even though we could also handle more smaller LUNs.
Cheers, Andreas
^ permalink raw reply
* Re: [PATCH 0/4] opensm: Add mtu validation to SA
From: Alex Netes @ 2011-10-31 16:33 UTC (permalink / raw)
To: Hal Rosenstock
Cc: linux-rdma (linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org)
In-Reply-To: <4E8B0FBF.3070606-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>
Hi Hal,
On 09:53 Tue 04 Oct , Hal Rosenstock wrote:
> The following patch series adds MTU validation to SA and is similar to the previous series on rate validation.
>
> [PATCH 1/4] opensm/osm_helper: Add ib_mtu_is_valid
> [PATCH 2/4] opensm/osm_sa_path_record.c: Add mtu validation if supplied
> [PATCH 3/4] opensm/osm_sa_mcmember_record.c: Add mtu validation if supplied
> [PATCH 4/4] opensm/osm_sa_multipath_record.c: Add mtu validation if supplied
> --
Applied, thanks.
--
-- Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [U-Boot] [PATCH V3 0/2] fix: regression in SMDK6400
From: Simon Schwarz @ 2011-10-31 16:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318762212-6763-1-git-send-email-simonschwarzcor@gmail.com>
This is a fix for a regression introduced by my patch
55f429bb39614a16b1bacc9a8bea9ac01a60bfc8 to u-boot-ti/next
The issue is described here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/108873
changes V3:
- fix for: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/114559
- http://article.gmane.org/gmane.comp.boot-loaders.u-boot/114558
Simon Schwarz (2):
nand: Add common functions to linux/mtd/nand.h
Fix regression in SMDK6400
drivers/mtd/nand/nand_base.c | 6 +++---
drivers/mtd/nand/s3c64xx.c | 28 ++--------------------------
include/linux/mtd/nand.h | 7 +++++++
include/nand.h | 3 ---
nand_spl/board/samsung/smdk6400/Makefile | 9 ++++++---
5 files changed, 18 insertions(+), 35 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [U-Boot] [PATCH V3 1/2] nand: Add common functions to linux/mtd/nand.h
From: Simon Schwarz @ 2011-10-31 16:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320078885-383-1-git-send-email-simonschwarzcor@gmail.com>
Functions often used in SPL are now part of linux/mtd/nand.h.
Static modifiers are removed from these functions in
drivers/mtd/nand/nand_base.c.
Signed-off-by: Simon Schwarz <simonschwarzcor@gmail.com>
Cc: scottwood at freescale.com
Cc: s-paulraj at ti.com
Cc: albert.u.boot at aribaud.net
---
Changes V2:
CHG moved function definiton from nand.h to linux/mtd/nand.h because of:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/110219
Changes V3:
CHG moved the definitions before double inculsion detection end
CHG combined function definition and prototype in one patch as advised here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/114558
---
drivers/mtd/nand/nand_base.c | 6 +++---
include/linux/mtd/nand.h | 7 +++++++
include/nand.h | 3 ---
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index e7dfcb1..109d2cf 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -133,7 +133,7 @@ static void nand_release_device (struct mtd_info *mtd)
*
* Default read function for 8bit buswith
*/
-static uint8_t nand_read_byte(struct mtd_info *mtd)
+uint8_t nand_read_byte(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd->priv;
return readb(chip->IO_ADDR_R);
@@ -196,7 +196,7 @@ static void nand_select_chip(struct mtd_info *mtd, int chipnr)
*
* Default write function for 8bit buswith
*/
-static void nand_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+void nand_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
{
int i;
struct nand_chip *chip = mtd->priv;
@@ -249,7 +249,7 @@ static int nand_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
*
* Default write function for 16bit buswith
*/
-static void nand_write_buf16(struct mtd_info *mtd, const uint8_t *buf, int len)
+void nand_write_buf16(struct mtd_info *mtd, const uint8_t *buf, int len)
{
int i;
struct nand_chip *chip = mtd->priv;
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 987a2ec..1cdc7ae 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -623,4 +623,11 @@ struct platform_nand_chip *get_platform_nandchip(struct mtd_info *mtd)
return chip->priv;
}
+/* Standard NAND functions from nand_base.c */
+void nand_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len);
+void nand_write_buf16(struct mtd_info *mtd, const uint8_t *buf, int len);
+void nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len);
+void nand_read_buf16(struct mtd_info *mtd, uint8_t *buf, int len);
+uint8_t nand_read_byte(struct mtd_info *mtd);
+
#endif /* __LINUX_MTD_NAND_H */
diff --git a/include/nand.h b/include/nand.h
index b4140794..d444ddc 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -135,9 +135,6 @@ int nand_get_lock_status(nand_info_t *meminfo, loff_t offset);
int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst);
void nand_deselect(void);
-void nand_read_buf16(struct mtd_info *mtd, uint8_t *buf, int len);
-void nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len);
-
#ifdef CONFIG_SYS_NAND_SELECT_DEVICE
void board_nand_select_device(struct nand_chip *nand, int chip);
#endif
--
1.7.4.1
^ permalink raw reply related
* [U-Boot] [PATCH V3 2/2] Fix regression in SMDK6400
From: Simon Schwarz @ 2011-10-31 16:34 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320078885-383-1-git-send-email-simonschwarzcor@gmail.com>
s3c64xx.c implemented its own nand_read_byte, nand_write_buf and
nand_read_buf functions. This provoked a regression when these functions
were made public by patch 55f429bb39614a16b1bacc9a8bea9ac01a60bfc8.
This deletes these duplicated functions from s3c64xx.c and adds the generic
implementations in nand_base.c to the spl Makefile. It also adds
-ffcuntion-sections and -gc-sections to the compilation flags of the SPL to
avoid errors originating from unused functions in nand_base.c.
Description of the regression:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/108873
Signed-off-by: Simon Schwarz <simonschwarzcor@gmail.com>
Cc: scottwood at freescale.com
Cc: s-paulraj at ti.com
Cc: albert.u.boot at aribaud.net
---
Changes V2:
CHG include linux/mtd/nand.h because of:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/110219
Changes V3:
none
---
drivers/mtd/nand/s3c64xx.c | 28 ++--------------------------
nand_spl/board/samsung/smdk6400/Makefile | 9 ++++++---
2 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/mtd/nand/s3c64xx.c b/drivers/mtd/nand/s3c64xx.c
index 084e475..87f0341 100644
--- a/drivers/mtd/nand/s3c64xx.c
+++ b/drivers/mtd/nand/s3c64xx.c
@@ -28,6 +28,8 @@
#include <common.h>
#include <nand.h>
+#include <linux/mtd/nand.h>
+
#include <asm/arch/s3c6400.h>
#include <asm/io.h>
@@ -60,32 +62,6 @@ static void print_oob(const char *header, struct mtd_info *mtd)
}
#endif /* S3C_NAND_DEBUG */
-#ifdef CONFIG_NAND_SPL
-static u_char nand_read_byte(struct mtd_info *mtd)
-{
- struct nand_chip *this = mtd->priv;
- return readb(this->IO_ADDR_R);
-}
-
-static void nand_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
-{
- int i;
- struct nand_chip *this = mtd->priv;
-
- for (i = 0; i < len; i++)
- writeb(buf[i], this->IO_ADDR_W);
-}
-
-static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
-{
- int i;
- struct nand_chip *this = mtd->priv;
-
- for (i = 0; i < len; i++)
- buf[i] = readb(this->IO_ADDR_R);
-}
-#endif
-
static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
{
int ctrl = readl(NFCONT);
diff --git a/nand_spl/board/samsung/smdk6400/Makefile b/nand_spl/board/samsung/smdk6400/Makefile
index 2f9c307..c9e75ba 100644
--- a/nand_spl/board/samsung/smdk6400/Makefile
+++ b/nand_spl/board/samsung/smdk6400/Makefile
@@ -33,12 +33,12 @@ nandobj := $(OBJTREE)/nand_spl/
LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
- $(LDFLAGS_FINAL)
+ $(LDFLAGS_FINAL) -gc-sections
AFLAGS += -DCONFIG_NAND_SPL
-CFLAGS += -DCONFIG_NAND_SPL
+CFLAGS += -DCONFIG_NAND_SPL -ffunction-sections
SOBJS = start.o cpu_init.o lowlevel_init.o
-COBJS = nand_boot.o nand_ecc.o s3c64xx.o smdk6400_nand_spl.o
+COBJS = nand_boot.o nand_ecc.o s3c64xx.o smdk6400_nand_spl.o nand_base.o
SRCS := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
@@ -98,6 +98,9 @@ $(obj)smdk6400_nand_spl.c:
@rm -f $@
@ln -s $(TOPDIR)/board/samsung/smdk6400/smdk6400_nand_spl.c $@
+$(obj)nand_base.c:
+ @rm -f $@
+ @ln -s $(TOPDIR)/drivers/mtd/nand/nand_base.c $@
#########################################################################
$(obj)%.o: $(obj)%.S
--
1.7.4.1
^ permalink raw reply related
* Re: Linux RT patch for Pandaboard Omap 4 kernel 3.0.0-1205 error when compiling
From: Sankara Muthukrishnan @ 2011-10-31 16:35 UTC (permalink / raw)
To: HUNG BUI; +Cc: linux-rt-users
In-Reply-To: <CAF7pde80C8C=vfN34uR4rS2HZ2-pY0BBJ0EsWm612BgHgtfETw@mail.gmail.com>
On Wed, Oct 26, 2011 at 6:25 PM, HUNG BUI <buihung@gmail.com> wrote:
> Hi everybody,
>
> I am trying to patch and compile realtime patch for kernel 3.0.0-1205
> (TI-OMAP4) on Pandaboard. However I faced lots of error, and couldn't
> finish the compiling process yet.
>
> I followed the instruction of compiling Pandaboard kernel from here
>
> http://adventuresinsilicon.blogspot.com/2011/02/pandaboard-ubuntu-how-to-recompile.html
> http://www.omappedia.com/wiki/Ubuntu_kernel_for_OMAP4
>
> My kernel was downloaded with the command :
>
> sudo apt-get build-dep linux-image-$(uname -r)
>
> which is arm-linux-3.0.0-1205-omap4 or linux-ti-omap4
> tar file : linux-ti-omap4_3.0.0-1205.10.tar.gz
> The patch I used is : patch-3.0-rt6.patch.bz2
>
> Pandaboard running on Ubuntu Oneiric Desktop. GCC 4.6
>
> I tried the following commands :
>
> patch -p1 < ../patch-3.0-rt6.patch
> fakeroot debian/rules editconfigs
> (# Kernel Features -> Preemption Model -> Fully Preemptible Kernel (RT) )
> fakeroot debian/rules clean
> dpkg-buildpackage -B -uc -us
>
> First the patch showed that there are some :
>
> Reversed (or previously applied) patch detected! Assume - R Apply
> anyway n] with 2 files :
> drivers/rtc/interface.c
> drivers/rtc/rtc-tegra.c
>
> (Don't have this problem if i apply rt8 or latter However they are for
> kernel 3.0.1 which I don;t know how to get)
>
> I answer No for both assume -r and Apply anyway , I am not sure it's
> correct or not
>
> Also the patch showed that there are some hunk failed with 3 files :
>
> arch/arm/mm/cache-l2x0.c
> init/main.c
> kernel/stop_machine.c
> I tried to fix this manually with the .rej files (otherwise it will
> cause this error when compile:
>
> kernel/stop_machine.c:176:2: note: each undeclared identifier is
> reported only once for each function it appears in
> kernel/stop_machine.c: In function ‘cpu_stopper_thread’:
> kernel/stop_machine.c:290:3: error: ‘stopper_lock’ undeclared (first
> use in this function)
>
>
> Then when I compile the kernel, i got some more errors which i can
> search and find the way to fix them however when it come to the
> following error, I couldn't find the solution for it :
>
> drivers/dsp/syslink/multicore_ipc/transportshm.c:261:2: error: request
> for member ‘lock’ in something not a structure or union
> drivers/dsp/syslink/multicore_ipc/transportshm.c:261:2: warning:
> dereferencing ‘void *’ pointer [enabled by default]
> drivers/dsp/syslink/multicore_ipc/transportshm.c:261:2: error: request
> for member ‘lock’ in something not a structure or union
> make[2]: *** [drivers/dsp/syslink/multicore_ipc/transportshm.o] Error 1
>
> I am not sure if the patch (3.0 rt6), kernel(linux-ti-omap4 3.0.0) ,
> gcc (4.6), and the commands i am using is correct, or there is some
> mismatches between them that make more and more errors happened when
> compiling.
>
> Thanks in advance,
>
> Hung Bui
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi Hung,
I recommend building the RT patch against the mainline Linux kernel,
as it would apply clean. If you need to use OMAP kernel git tree, then
you may have to resolve the hunks by yourself. I am not sure how far
off it is from the mainline and how much work applying the patch would
be. I can give you the instructions that I follow to build the
RT-patched kernel for panda board. Hope it is useful to you.
(1) Use a cross-compiler for ARM on x86 development Linux machine (or
a Linux VM). I found code-sourcery toolchain to be simple and easy to
install and use on my x86 Linux development machine. You can get that
from https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription3053
(I think I use "Sourcery G++ Lite 2009q1-161" and use the binary
installer "IA32 GNU/Linux Installer"). Add the code-sourcery
tool-chain to the PATH. (Or, you can use OpenEmbedded toolchain which
is a very common one too)
(2) git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
my3.0.y-stbl-rt
(3) git checkout -b my3.0.6 v3.0.6
(4) As suggested by Frank Rowand in
http://marc.info/?l=linux-rt-users&m=131352000121791&w=2 you can
create a default kernel configuration for panda board as follows or
use the .config file he had attached in the same post and tweak it.
(4.1) make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- omap2plus_defconfig
(4.2) make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
# this allows USB thumb drive
# Device Drivers -> USB support -> EHCI HCD (USB 2.0) support
CONFIG_USB_EHCI_HCD=y
# Device Drivers -> USB support -> EHCI support for OMAP3 and later chips
CONFIG_USB_EHCI_HCD_OMAP=y
# ethernet device
# Device Drivers -> Network device support -> USB Network Adapters ->
# Multi-purpose USB Networking Framework ->
# SMSC LAN95XX based USB 2.0 10/100 ethernet devices
CONFIG_USB_NET_SMSC95XX=y
# Preeemption model
# Kernel Features -> Preemption Model -> Preemptible Kernel
(Low-Latency Desktop)
(5) make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage
(5.1) ssh this uImage to your panda board and see whether it works.
panda board sometimes hangs on boot. Resetting and/or power-cycling a
few times will make it boot. If it does not boot at all after several
resets, then it is possible you did not build the kernel correctly. I
usually do this step as a sanity check that there is no major issue
with building and booting the vanilla kernel without the RT patch.
(6) patch -p1 --merge -i <path_of_the_patch_file>/patch-3.0.6-rt17.patch
(7) Run menuconfig again as in Step-4 and choose "Fully Preemptible
Kernel (RT)" as the preemption model.
(8) Build the kernel image and test it as in Step-5.
(9) Run the cyclictest and see the latencies. Latencies are huge
without the high resolution timer.
(10) You can turn on the high-resolution timer (by disabling the 32
KHz Timer and applying the high-resolution timer patch) and measure
the latencies. There is a bug on panda board (or OMAP4430 in general)
about time-stamps jumping backwards (which appears to be an issue with
the clock source). If you search for my other posts in this mailing
list, you will find info and links about that.
Hope this helps.
Thanks,
Sankara
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-devel] Problem under OSX Lion: GThread-ERROR **: GThread system may only be initialized once
From: Daniel P. Berrange @ 2011-10-31 16:36 UTC (permalink / raw)
To: Juan Pineda; +Cc: aliguori, qemu-devel, Andreas Färber
In-Reply-To: <C86F4598-4BE3-444E-B29B-DA95CB46AB76@logician.com>
On Mon, Oct 31, 2011 at 09:25:26AM -0700, Juan Pineda wrote:
> The current Qemu master branch crashes under OSX with a GThread error.
> Commenting out vlc.c line 2188 (call to g_thread_init) allows it to run
> successfully.
As a general rule all calls to 'g_thread_init(NULL)' should be protected
by a conditional thus:
if (!g_thread_supported())
g_thread_init(NULL);
Even though QEMU calls g_thread_init() very early in main(), there is
always the possibility that some library QEMU links to, has got an ELF
initializer, triggering before main(), which calls g_thread_init().
NB on GLib versions >= 2.24, g_thread_init() is a no-op if called more
than once[1], but for sake of compatibility QEMU ought to use the conditonal
check.
Regards,
Daniel
[1] The reason for this change is that GObject itself actually calls
g_thread_init() secretly too.
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply
* Re: 3.1+ iwlwifi lockup
From: Guy, Wey-Yi @ 2011-10-31 15:44 UTC (permalink / raw)
To: Dave Jones
Cc: Linux Kernel, ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <20111031143408.GA17152@redhat.com>
On Mon, 2011-10-31 at 07:34 -0700, Dave Jones wrote:
> I just got this trace, and a driver lockup that caused me to have to
> unload & reload the iwlwifi module to get networking back.
> hardware is..
> 04:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
>
> This is new as of 3.1+ (This kernel was Linus' tree as of last night)
>
this is cause by an command queue bug and we will looking into it now.
Wey
> Dave
>
> [ 2669.712377] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.712381] Hardware name: Adamo 13
> [ 2669.712384] wrong command queue 0 (should be 4), sequence 0x0 readp=54 writep=54
> [ 2669.712386] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.712493] Pid: 2332, comm: firefox Not tainted 3.1.0+ #9
> [ 2669.712495] Call Trace:
> [ 2669.712497] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.712509] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.712519] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.712529] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.712535] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.712539] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.712544] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.712549] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.712553] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.712557] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.712561] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.712563] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.712570] ---[ end trace e86fa0935f9dc7a5 ]---
> [ 2669.712573] iwl data: 00000000: 00 00 55 55 00 00 00 00 08 53 e0 00 00 00 00 00 ..UU.....S......
> [ 2669.712577] iwl data: 00000010: 00 00 00 00 7e 04 19 00 05 00 04 00 94 07 02 00 ....~...........
> [ 2669.712619] ------------[ cut here ]------------
> [ 2669.712628] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.712631] Hardware name: Adamo 13
> [ 2669.712634] wrong command queue 11 (should be 4), sequence 0x6B6B readp=54 writep=54
> [ 2669.712636] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.712729] Pid: 2332, comm: firefox Tainted: G W 3.1.0+ #9
> [ 2669.712731] Call Trace:
> [ 2669.712733] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.712743] [<ffffffff8164de90>] ? _raw_spin_unlock_irqrestore+0x40/0x90
> [ 2669.712747] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.712753] [<ffffffff810c189f>] ? trace_hardirqs_on_caller+0x1f/0x1b0
> [ 2669.712762] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.712772] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.712777] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.712781] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.712785] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.712789] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.712792] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.712796] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.712800] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.712802] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.712808] ---[ end trace e86fa0935f9dc7a6 ]---
> [ 2669.712811] iwl data: 00000000: 00 00 55 55 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ..UUkkkkkkkkkkkk
> [ 2669.712815] iwl data: 00000010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 2669.712818] ------------[ cut here ]------------
> [ 2669.712826] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.712829] Hardware name: Adamo 13
> [ 2669.712832] wrong command queue 11 (should be 4), sequence 0x6B6B readp=54 writep=54
> [ 2669.712834] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.712925] Pid: 2332, comm: firefox Tainted: G W 3.1.0+ #9
> [ 2669.712928] Call Trace:
> [ 2669.712930] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.712938] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.712948] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.712958] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.712963] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.712967] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.712971] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.712975] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.712979] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.712982] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.712986] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.712988] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.712994] ---[ end trace e86fa0935f9dc7a7 ]---
> [ 2669.712997] iwl data: 00000000: 00 00 55 55 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ..UUkkkkkkkkkkkk
> [ 2669.713018] iwl data: 00000010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 2669.713136] ------------[ cut here ]------------
> [ 2669.713146] WARNING: at drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c:927 iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]()
> [ 2669.713150] Hardware name: Adamo 13
> [ 2669.713153] wrong command queue 11 (should be 4), sequence 0x6B6B readp=54 writep=54
> [ 2669.713157] Modules linked in: nfs fscache auth_rpcgss nfs_acl ppdev parport_pc lp parport fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle tun bridge stp llc lockd bnep bluetooth ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables arc4 dell_wmi sparse_keymap uvcvideo videodev snd_usb_audio v4l2_compat_ioctl32 snd_usbmidi_lib cdc_ether snd_rawmidi cdc_wdm usbnet cdc_acm mii snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device dell_laptop iwlwifi dcdbas microcode snd_pcm mac80211 joydev i2c_i801 pcspkr snd_timer iTCO_wdt iTCO_vendor_support snd soundcore cfg80211 snd_page_alloc tg3 rfkill wmi virtio_net kvm_intel kvm uinput sunrpc ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
> [ 2669.713292] Pid: 2332, comm: firefox Tainted: G W 3.1.0+ #9
> [ 2669.713295] Call Trace:
> [ 2669.713297] <IRQ> [<ffffffff8107d16f>] warn_slowpath_common+0x7f/0xc0
> [ 2669.713308] [<ffffffff8107d266>] warn_slowpath_fmt+0x46/0x50
> [ 2669.713319] [<ffffffffa038090e>] iwl_tx_cmd_complete+0x2ee/0x330 [iwlwifi]
> [ 2669.713331] [<ffffffffa037e280>] iwl_irq_tasklet+0x210/0x8e0 [iwlwifi]
> [ 2669.713337] [<ffffffff810851fd>] tasklet_action+0x9d/0x240
> [ 2669.713342] [<ffffffff81085e28>] __do_softirq+0xc8/0x3d0
> [ 2669.713347] [<ffffffff81657f3c>] call_softirq+0x1c/0x30
> [ 2669.713353] [<ffffffff8101c735>] do_softirq+0xa5/0xe0
> [ 2669.713357] [<ffffffff810864a6>] irq_exit+0xa6/0xf0
> [ 2669.713362] [<ffffffff81658813>] do_IRQ+0x63/0xd0
> [ 2669.713367] [<ffffffff8164e5f3>] common_interrupt+0x73/0x73
> [ 2669.713369] <EOI> [<ffffffff81655c7a>] ? sysret_check+0x2e/0x69
> [ 2669.713377] ---[ end trace e86fa0935f9dc7a8 ]---
> [ 2669.713380] iwl data: 00000000: 00 00 55 55 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ..UUkkkkkkkkkkkk
> [ 2669.713385] iwl data: 00000010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> [ 2670.784424] iwlwifi 0000:04:00.0: Microcode SW error detected. Restarting 0x2000000.
> [ 2670.784431] iwlwifi 0000:04:00.0: Loaded firmware version: 8.83.5.1 build 33692
> [ 2670.784556] iwlwifi 0000:04:00.0: Start IWL Error Log Dump:
> [ 2670.784559] iwlwifi 0000:04:00.0: Status: 0x000412E4, count: 5
> [ 2670.784562] iwlwifi 0000:04:00.0: 0x00000005 | SYSASSERT
> [ 2670.784565] iwlwifi 0000:04:00.0: 0x000024EC | uPc
> [ 2670.784568] iwlwifi 0000:04:00.0: 0x000024C8 | branchlink1
> [ 2670.784570] iwlwifi 0000:04:00.0: 0x000024C8 | branchlink2
> [ 2670.784573] iwlwifi 0000:04:00.0: 0x00000916 | interruptlink1
> [ 2670.784576] iwlwifi 0000:04:00.0: 0x00000000 | interruptlink2
> [ 2670.784578] iwlwifi 0000:04:00.0: 0x000000FF | data1
> [ 2670.784580] iwlwifi 0000:04:00.0: 0x00000489 | data2
> [ 2670.784583] iwlwifi 0000:04:00.0: 0x00000489 | line
> [ 2670.784585] iwlwifi 0000:04:00.0: 0x1A41414C | beacon time
> [ 2670.784588] iwlwifi 0000:04:00.0: 0x54956EB4 | tsf low
> [ 2670.784591] iwlwifi 0000:04:00.0: 0x000004FB | tsf hi
> [ 2670.784593] iwlwifi 0000:04:00.0: 0x00000000 | time gp1
> [ 2670.784596] iwlwifi 0000:04:00.0: 0x9D4D53F1 | time gp2
> [ 2670.784598] iwlwifi 0000:04:00.0: 0x00000000 | time gp3
> [ 2670.784601] iwlwifi 0000:04:00.0: 0x00010853 | uCode version
> [ 2670.784603] iwlwifi 0000:04:00.0: 0x00000024 | hw version
> [ 2670.784606] iwlwifi 0000:04:00.0: 0x00480302 | board version
> [ 2670.784609] iwlwifi 0000:04:00.0: 0x0B15001C | hcmd
> [ 2670.784611] iwlwifi 0000:04:00.0: CSR values:
> [ 2670.784614] iwlwifi 0000:04:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
> [ 2670.784641] iwlwifi 0000:04:00.0: CSR_HW_IF_CONFIG_REG: 0X00480302
> [ 2670.784666] iwlwifi 0000:04:00.0: CSR_INT_COALESCING: 0X00000040
> [ 2670.784691] iwlwifi 0000:04:00.0: CSR_INT: 0X00000000
> [ 2670.784715] iwlwifi 0000:04:00.0: CSR_INT_MASK: 0X00000000
> [ 2670.784740] iwlwifi 0000:04:00.0: CSR_FH_INT_STATUS: 0X00000000
> [ 2670.784765] iwlwifi 0000:04:00.0: CSR_GPIO_IN: 0X00000000
> [ 2670.784790] iwlwifi 0000:04:00.0: CSR_RESET: 0X00000000
> [ 2670.784814] iwlwifi 0000:04:00.0: CSR_GP_CNTRL: 0X080403c5
> [ 2670.784839] iwlwifi 0000:04:00.0: CSR_HW_REV: 0X00000024
> [ 2670.784864] iwlwifi 0000:04:00.0: CSR_EEPROM_REG: 0X00000000
> [ 2670.784889] iwlwifi 0000:04:00.0: CSR_EEPROM_GP: 0X90000004
> [ 2670.784914] iwlwifi 0000:04:00.0: CSR_OTP_GP_REG: 0X00060000
> [ 2670.784938] iwlwifi 0000:04:00.0: CSR_GIO_REG: 0X00080042
> [ 2670.784963] iwlwifi 0000:04:00.0: CSR_GP_UCODE_REG: 0X00007c71
> [ 2670.784988] iwlwifi 0000:04:00.0: CSR_GP_DRIVER_REG: 0X00000000
> [ 2670.785012] iwlwifi 0000:04:00.0: CSR_UCODE_DRV_GP1: 0X00000000
> [ 2670.785037] iwlwifi 0000:04:00.0: CSR_UCODE_DRV_GP2: 0X00000000
> [ 2670.785062] iwlwifi 0000:04:00.0: CSR_LED_REG: 0X00000058
> [ 2670.785086] iwlwifi 0000:04:00.0: CSR_DRAM_INT_TBL_REG: 0X8811a5a0
> [ 2670.785111] iwlwifi 0000:04:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
> [ 2670.785136] iwlwifi 0000:04:00.0: CSR_ANA_PLL_CFG: 0X00880300
> [ 2670.785161] iwlwifi 0000:04:00.0: CSR_HW_REV_WA_REG: 0X0001001a
> [ 2670.785186] iwlwifi 0000:04:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0000
> [ 2670.785188] iwlwifi 0000:04:00.0: FH register values:
> [ 2670.785224] iwlwifi 0000:04:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X1174de00
> [ 2670.785243] iwlwifi 0000:04:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X012abbb0
> [ 2670.785261] iwlwifi 0000:04:00.0: FH_RSCSR_CHNL0_WPTR: 0X00000048
> [ 2670.785280] iwlwifi 0000:04:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
> [ 2670.785300] iwlwifi 0000:04:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
> [ 2670.785343] iwlwifi 0000:04:00.0: FH_MEM_RSSR_RX_STATUS_REG: 0X02630000
> [ 2670.785362] iwlwifi 0000:04:00.0: FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
> [ 2670.785380] iwlwifi 0000:04:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
> [ 2670.785389] iwlwifi 0000:04:00.0: FH_TSSR_TX_ERROR_REG: 0X00000000
> [ 2670.785389] iwlwifi 0000:04:00.0: Start IWL Event Log Dump: display last 20 entries
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638087993:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088265:0x00000113:0106
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088266:0x00000000:0302
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088289:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088453:0x00000113:0106
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088455:0x00000000:0302
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088478:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088750:0x0b15001c:0206
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088752:0x00000001:0204
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088755:0x00000001:0214
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638088756:0x01002111:0209
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089055:0x00000000:0210
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089065:0x00000000:0207
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089067:0x01002111:0211
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638089072:0x00000000:0212
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090106:0x00000000:0215
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090108:0x00000008:0220
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090127:0x00000000:0301
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2638090315:0x00000000:0355
> [ 2670.785389] iwlwifi 0000:04:00.0: EVT_LOGT:2639090696:0x00000000:0125
> [ 2670.795643] ieee80211 phy0: Hardware restart was requested
> [ 2670.795729] iwlwifi 0000:04:00.0: L1 Enabled; Disabling L0S
> [ 2670.798779] iwlwifi 0000:04:00.0: Radio type=0x0-0x2-0x0
>
^ permalink raw reply
* [VTD] Intel iommu IOTLB flush really slow
From: Jean Guyader @ 2011-10-31 16:38 UTC (permalink / raw)
To: xen-devel@lists.xensource.com; +Cc: Kay, Allen M
Hi,
Some IOMMU DMA remapping engine sometimes take longer to flush the IOTLBs.
For instance on Ibex Peak a iommu_map_page can in the order of milisecondes.
In the Intel IOMMU spec you can see that you don't need to flush if the PTE was
present so it's all good when we are creating a domain because we don't need to
flush anything. Some problem happen when we try to move memory arround.
Here is some code from hvmloader, pci.c:190 on xen-unstable:
while ( (pci_mem_start >> PAGE_SHIFT) < hvm_info->low_mem_pgend )
{
struct xen_add_to_physmap xatp;
if ( hvm_info->high_mem_pgend == 0 )
hvm_info->high_mem_pgend = 1ull << (32 - PAGE_SHIFT);
xatp.domid = DOMID_SELF;
xatp.space = XENMAPSPACE_gmfn;
xatp.idx = --hvm_info->low_mem_pgend;
xatp.gpfn = hvm_info->high_mem_pgend++;
if ( hypercall_memory_op(XENMEM_add_to_physmap, &xatp) != 0 )
BUG();
}
This code gets triggered when the PCI hole increased so much that it
overlaps with the allocated RAM. So we have to relocate the section that
overlap in the top memory.
If we folow the code down to Xen we can find that add_to_physmap calls
set_p2m_entry which uses either p2m_set_entry or ept_set_entry with an order
or 0, yes we only try to move one page.
Both implementations update the iommu page table with iommu_map_page.
So at the end we end up doing a loop of iommu_map_page driven by this loop
in hvmloader.
The IOMMU DMA remapping enigne of the Intel GPU is really really
slow to flush. So when we try to create a domain that does Intel GPU pass
through with enough memory to force a relocation of the top RAM below 4G
the domain can take minutes to start!
There are multiple approches that we can use to fix this problem, but before I
start working on a patch I would like to get the list's point of view.
Plan A:
- Add a new XENMEM add_to_physmap_range that would relocate a gfn range to a new gfn.
- Add a flag in the IOMMU API to delay the IOTLB flush
- Add a new API call to flush the the IOTLB manully once we relocate all the range.
Plan B:
- Add a new XENMEM add_to_physmap_range that would relocate a gfn range to a new gfn.
- Add a new set_p2m_entry function that will understand batches of gfns and mfns.
- Implement batch operation for shadow and HAP.
- Add new IOMMU API to support batch operation
(A) isn't very nice but has the benefit of not modifying to much code, (B) would be the
right thing to do but would be quite disruptive in term of code and API change.
Let me know what you think,
Jean
^ permalink raw reply
* RE: [GIT PULL] mm: frontswap (for 3.2 window)
From: Dan Magenheimer @ 2011-10-31 16:38 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Linus Torvalds, linux-mm, LKML, Andrew Morton, Konrad Wilk,
Jeremy Fitzhardinge, Seth Jennings, ngupta, levinsasha928,
Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet, Neo Jia
In-Reply-To: <20111031171321.097a166c.kamezawa.hiroyu@jp.fujitsu.com>
> From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@jp.fujitsu.com]
> Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
Hi Kame --
Thanks for your reply and for your earlier reviews of frontswap,
and my apologies that I accidentally left you off of the Cc list \
for the basenote of this git-pull request.
> I don't have heavy concerns to the codes itself but this process as bypassing -mm
> or linux-next seems ugly.
First, frontswap IS in linux-next and it has been since June 3
and v11 has been in linux-next since September 23. This
is stated in the base git-pull request.
> Why bypass -mm tree ?
>
> I think you planned to merge this via -mm tree and, then, posted patches
> to linux-mm with CC -mm guys.
Hmmm... the mm process is not clear or well-documented.
I am a relative newbie here. Linus has repeatedly spoken
of ensuring that code is in linux-next, and there is no
(last I checked) current -mm git tree. I was aware that
the mm tree still existed, but thought it was for shaking
out major features, not for adding a handful of hooks.
I was aware that akpm's blessing was highly desirable,
but his (offlist) reply was essentially "I'm not interested,
I don't have time to deal with this, and I don't think anyone
will use it." I explained about all the users (many of whom
have replied to this thread to support frontswap), but got
no further reply. I was advised by several people that, in
the case of disagreement, Linus will decide, so I pushed
forward. This is the same as the process I used for
cleancache, which Linus merged.
I have been instructed offlist and onlist that this was a big
mistake, that it appears that I am subverting the process,
and that I am probably insulting akpm. If so, I am
truly sorry and would be happy to take instruction
on how to proceed correctly. However, in turn, I hope
that those driving the process aren't blocking useful
code simply due to lack of time.
> I think you posted 2011/09/16 at the last time, v10. But no further submission
> to gather acks/reviews from Mel, Johannes, Andrew, Hugh etc.. and no inclusion
> request to -mm or -next. _AND_, IIUC, at v10, the number of posted pathces was 6.
> Why now 8 ? Just because it's simple changes ?
See https://lkml.org/lkml/2011/9/21/373. Konrad Wilk
helped me to reorganize the patches (closer to what you
suggested I think), but there were no code changes between
v10 and v11, just dividing up the patches differently
as Konrad thought there should be more smaller commits.
So no code change between v10 and v11 but the number of
patches went from 6 to 8.
My last line in that post should also make it clear that
I thought I was done and ready for the 3.2 window, so there
was no evil intent on my part to subvert a process.
It would have been nice if someone had told me there
were uncompleted steps in the -mm process or, even better,
pointed me to a (non-existent?) document where I could see
for myself if I was missing steps!
So... now what?
Thanks,
Dan
P.S. It appears that this excerpt from the LWN KS2011 report
might be related to the problem?
"Andrew complained about the acceptance of entirely new
features into the kernel. Those features often land on
his doorstep without much justification, forcing him to
ask the developers to explain their motivations. The kernel
community, he complained, is not supporting him well. Who
can tell him if a given patch makes sense? Mistakes have
been made in the past; bad features have been merged and
good stuff has been lost. How, he asked, can he find
people who know better about the desirability of
specific patches?"
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Peng Tao @ 2011-10-31 16:38 UTC (permalink / raw)
To: Trond Myklebust; +Cc: linux-nfs, bhalevy, Peng Tao
In-Reply-To: <1320076148.4714.4.camel@lade.trondhjem.org>
On Mon, Oct 31, 2011 at 11:49 PM, Trond Myklebust
<Trond.Myklebust@netapp.com> wrote:
> On Mon, 2011-10-31 at 08:15 -0700, Peng Tao wrote:
>> For blocklayout, we need to issue layoutreturn to return layouts when
>> handling CB_RECALL_ANY.
>
> Why?
Because replying NFS4_OK to CB_RECALL_ANY indicates that client knows
that server wants client to return layout. And server will be waiting
for layoutreturn in such case.
Thanks,
Tao
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
>
>
^ permalink raw reply
* RE: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address filtering support for passthru mode
From: Rose, Gregory V @ 2011-10-31 16:38 UTC (permalink / raw)
To: Roopa Prabhu, netdev@vger.kernel.org
Cc: sri@us.ibm.com, dragos.tatulea@gmail.com, kvm@vger.kernel.org,
arnd@arndb.de, mst@redhat.com, davem@davemloft.net,
mchan@broadcom.com, dwang2@cisco.com, shemminger@vyatta.com,
eric.dumazet@gmail.com, kaber@trash.net, benve@cisco.com
In-Reply-To: <20111029023159.5198.60245.stgit@rhel6.1>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Roopa Prabhu
> Sent: Friday, October 28, 2011 7:34 PM
> To: netdev@vger.kernel.org
> Cc: sri@us.ibm.com; dragos.tatulea@gmail.com; kvm@vger.kernel.org;
> arnd@arndb.de; mst@redhat.com; davem@davemloft.net; Rose, Gregory V;
> mchan@broadcom.com; dwang2@cisco.com; shemminger@vyatta.com;
> eric.dumazet@gmail.com; kaber@trash.net; benve@cisco.com
> Subject: [net-next-2.6 PATCH 0/6 RFC v3] macvlan: MAC Address filtering
> support for passthru mode
>
> v2 -> v3
> - Moved set and get filter ops from rtnl_link_ops to netdev_ops
> - Support for SRIOV VFs.
> [Note: The get filters msg might get too big for SRIOV vfs.
> But this patch follows existing sriov vf get code and
> accomodate filters for all VF's in a PF.
> And for the SRIOV case I have only tested the fact that the VF
> arguments are getting delivered to rtnetlink correctly. The rest of
> the code follows existing sriov vf handling code so it should work
> just fine]
> - Fixed all op and netlink attribute names to start with IFLA_RX_FILTER
> - Changed macvlan filter ops to call corresponding lowerdev op if lowerdev
> supports it for passthru mode. Else it falls back on macvlan handling
> the
> filters locally as in v1 and v2
>
> v1 -> v2
> - Instead of TUNSETTXFILTER introduced rtnetlink interface for the same
>
[snip...]
>
> This patch series implements the following
> 01/6 rtnetlink: Netlink interface for setting MAC and VLAN filters
> 02/6 netdev: Add netdev_ops to set and get MAC/VLAN rx filters
> 03/6 rtnetlink: Add support to set MAC/VLAN filters
> 04/6 rtnetlink: Add support to get MAC/VLAN filters
> 05/6 macvlan: Add support to set MAC/VLAN filter netdev ops
> 06/6 macvlan: Add support to get MAC/VLAN filter netdev ops
>
> Please comment. Thanks.
After some preliminary review this looks pretty good to me in so far as adding the necessary hooks to do what I need to do. I appreciate your effort on this.
I'm sort of a hands-on type of person so I need to apply this patch to a private git tree and then take it for a test drive (so to speak). If I have further comments I'll get back to you.
Did you have any plans for modifying any user space tools such as 'ip' to use this interface?
- Greg
>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 12/13] mtd/docg3: add ECC correction code
From: Robert Jarzmik @ 2011-10-31 16:39 UTC (permalink / raw)
To: Mike Dunn; +Cc: linux-mtd
In-Reply-To: <4EAE9FB6.6090200@newsguy.com>
Mike Dunn <mikedunn@newsguy.com> writes:
> Hi Robert,
>
> A few comments (limited to the bch decode for now)...
> To avoid confusion with the terminology in Ivan's BCH algorithm, I wouldn't call
> it calc_ecc. It's actually recv_ecc ^ calc_ecc, where recv_ecc is what the hw
> read from the ecc field of the oob data, and calc_ecc is what the hw calculated
> from the page data. Maybe just hwecc or similiar.
Yep, point taken for V2, hwecc sounds good.
...zip...
>> + numerrs = decode_bch(docg3_bch, NULL, DOC_ECC_BCH_COVERED_BYTES,
>> + NULL, ecc, NULL, errorpos);
> This looks right, with the redefined DOC_ECC_BCH_COVERED_BYTES (now 520).
>
> Some commentary would be helpful (though maybe I'm too verbose)...
>
> /*
> * The hardware ecc unit produces oob_ecc ^ calc_ecc. The kernel's bch
> * algorithm is used to decode this. However the hw operates on page
> * data in a bit order that is the reverse of that of the bch alg,
> * requiring that the bits be reversed on the result. Thanks to Ivan
> * Djelic for his analysis.
> */
Right again. I will copy paste that explanation in the code.
> I recommend you test this. One way would be to compile the bch algorithm in
> userspace and use it to generate the ecc for a 520 byte test vector. Reverse
> the bits of this ecc, then flip a few bits in the test vector and write it to a
> page in flash, with your driver modified to write the calculated ecc instead of
> that served up by the hardware. Then when you read the page, the above code
> should identify and correct the bits you flipped (assuming a genuine flash error
> did not occur while reading back the page). I have the bch alg modified for
> userspace, if that would help.
I did test it in userspace.
And after Ivan's proposition, I tested it also with nandwrite/nanddump by
introducing some random errors. The error correction code works, a few
amendments (for V2) will be added for "bitflipped" data writes/reads.
But the conclusion is that Ivan and your work is indeed directly applicable in
the G3 case, and tested :)
>> + if (numerrs < 0)
>> + return numerrs;
>
> I recommend you check for the -EINVAL return value and issue a big fat error.
> Maybe BUG_ON(numerrs == -EINVAL), at least for now.
Okay.
>
> Another explanatory comment here...
> /* undo last step in BCH alg (modulo mirroring not needed) */
Is that the same as the function comment about bit reversing (the modulo
mirroring part) ? If so, the function comment might not be clear enough. If not,
could you explain a bit further please ?
Thanks for the review.
Cheers.
--
Robert
^ permalink raw reply
* RE: [GIT PULL] mm: frontswap (for 3.2 window)
From: Dan Magenheimer @ 2011-10-31 16:38 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Linus Torvalds, linux-mm, LKML, Andrew Morton, Konrad Wilk,
Jeremy Fitzhardinge, Seth Jennings, ngupta, levinsasha928,
Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet, Neo Jia
In-Reply-To: <20111031171321.097a166c.kamezawa.hiroyu@jp.fujitsu.com>
> From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@jp.fujitsu.com]
> Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
Hi Kame --
Thanks for your reply and for your earlier reviews of frontswap,
and my apologies that I accidentally left you off of the Cc list \
for the basenote of this git-pull request.
> I don't have heavy concerns to the codes itself but this process as bypassing -mm
> or linux-next seems ugly.
First, frontswap IS in linux-next and it has been since June 3
and v11 has been in linux-next since September 23. This
is stated in the base git-pull request.
> Why bypass -mm tree ?
>
> I think you planned to merge this via -mm tree and, then, posted patches
> to linux-mm with CC -mm guys.
Hmmm... the mm process is not clear or well-documented.
I am a relative newbie here. Linus has repeatedly spoken
of ensuring that code is in linux-next, and there is no
(last I checked) current -mm git tree. I was aware that
the mm tree still existed, but thought it was for shaking
out major features, not for adding a handful of hooks.
I was aware that akpm's blessing was highly desirable,
but his (offlist) reply was essentially "I'm not interested,
I don't have time to deal with this, and I don't think anyone
will use it." I explained about all the users (many of whom
have replied to this thread to support frontswap), but got
no further reply. I was advised by several people that, in
the case of disagreement, Linus will decide, so I pushed
forward. This is the same as the process I used for
cleancache, which Linus merged.
I have been instructed offlist and onlist that this was a big
mistake, that it appears that I am subverting the process,
and that I am probably insulting akpm. If so, I am
truly sorry and would be happy to take instruction
on how to proceed correctly. However, in turn, I hope
that those driving the process aren't blocking useful
code simply due to lack of time.
> I think you posted 2011/09/16 at the last time, v10. But no further submission
> to gather acks/reviews from Mel, Johannes, Andrew, Hugh etc.. and no inclusion
> request to -mm or -next. _AND_, IIUC, at v10, the number of posted pathces was 6.
> Why now 8 ? Just because it's simple changes ?
See https://lkml.org/lkml/2011/9/21/373. Konrad Wilk
helped me to reorganize the patches (closer to what you
suggested I think), but there were no code changes between
v10 and v11, just dividing up the patches differently
as Konrad thought there should be more smaller commits.
So no code change between v10 and v11 but the number of
patches went from 6 to 8.
My last line in that post should also make it clear that
I thought I was done and ready for the 3.2 window, so there
was no evil intent on my part to subvert a process.
It would have been nice if someone had told me there
were uncompleted steps in the -mm process or, even better,
pointed me to a (non-existent?) document where I could see
for myself if I was missing steps!
So... now what?
Thanks,
Dan
P.S. It appears that this excerpt from the LWN KS2011 report
might be related to the problem?
"Andrew complained about the acceptance of entirely new
features into the kernel. Those features often land on
his doorstep without much justification, forcing him to
ask the developers to explain their motivations. The kernel
community, he complained, is not supporting him well. Who
can tell him if a given patch makes sense? Mistakes have
been made in the past; bad features have been merged and
good stuff has been lost. How, he asked, can he find
people who know better about the desirability of
specific patches?"
^ permalink raw reply
* Re: profiling ceph
From: Sage Weil @ 2011-10-31 16:42 UTC (permalink / raw)
To: sheng qiu; +Cc: ceph-devel
In-Reply-To: <CAB7xdik94Dc5C=PGaiknk-9fVDGJ35hTUfsoeOdCt+G5_oAXuQ@mail.gmail.com>
On Sun, 30 Oct 2011, sheng qiu wrote:
> hi,
>
> is there any way to see how much time spend on each part of ceph when
> running it. i just want to see which part of ceph codes spend more
> time or have larger cost.
> i tried to config ceph adding -pg, but when i use gprof command, it
> said no gmon.out.
> i also checked the ceph wiki, the profiling on cpu part do get an
> output on time cost. but it does not show details on ceph (how much
> time spend on each part).
I've used gprof in the past, but not recently. Two things to watch out
for, IIRC:
- The gmon.out is written out on shutdown in the current directory. do
'--chdir .' on the command line, and make sure you somehow tell the daemon
to stop in order to get some output.
- You used to need to LD_PRELOAD gprof_helper.so in order to get results
for all threads. There should be a copy of the source in test/ or
scripts/, although there is no Makefile line. Google it for more info.
sage
>
> Thanks,
> Sheng
>
> --
> Sheng Qiu
> Texas A & M University
> Room 302 Wisenbaker
> email: herbert1984106@gmail.com
> College Station, TX 77843-3259
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: femon patch for dB
From: James @ 2011-10-31 16:42 UTC (permalink / raw)
Cc: linux-media Mailing List
In-Reply-To: <CAOcJUbw4512cswquogyUg19QXm=sKcsPQGsBty6+738f9mnvkw@mail.gmail.com>
On 10/30/11 10:01, Michael Krufky wrote:
> The patch is actually OK with me, except that i disagree
> with the -2 parameter choice. I propose instead, to use a lowercase
> 'h' ...
diff -r d4e8bf5658ce util/femon/femon.c
--- a/util/femon/femon.c Fri Oct 07 01:26:04 2011 +0530
+++ b/util/femon/femon.c Mon Oct 31 12:29:14 2011 -0400
@@ -16,6 +16,9 @@
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * James Lockie: Oct. 2011
+ * modified to add a switch (-h) to show signal/snr in dB
*/
@@ -37,11 +40,16 @@
#include <libdvbapi/dvbfe.h>
+/* the s5h1409 delivers both fields in 0.1dB increments, while
+ * some demods expect signal to be 0-65535 and SNR to be in 1/256 increments
+*/
+
#define FE_STATUS_PARAMS (DVBFE_INFO_LOCKSTATUS|DVBFE_INFO_SIGNAL_STRENGTH|DVBFE_INFO_BER|DVBFE_INFO_SNR|DVBFE_INFO_UNCORRECTED_BLOCKS)
static char *usage_str =
"\nusage: femon [options]\n"
- " -H : human readable output\n"
+ " -H : human readable output: (signal: 0-65335, snr: 1/256 increments)\n"
+ " -h : human readable output: (signal and snr in .1 dB increments)\n"
" -A : Acoustical mode. A sound indicates the signal quality.\n"
" -r : If 'Acoustical mode' is active it tells the application\n"
" is called remotely via ssh. The sound is heard on the 'real'\n"
@@ -62,7 +70,7 @@
static
-int check_frontend (struct dvbfe_handle *fe, int human_readable, unsigned int count)
+int check_frontend (struct dvbfe_handle *fe, int human_readable, int db_readable, unsigned int count)
{
struct dvbfe_info fe_info;
unsigned int samples = 0;
@@ -93,31 +101,32 @@
fprintf(stderr, "Problem retrieving frontend information: %m\n");
}
+ // print the status code
+ printf ("status %c%c%c%c%c | ",
+ fe_info.signal ? 'S' : ' ',
+ fe_info.carrier ? 'C' : ' ',
+ fe_info.viterbi ? 'V' : ' ',
+ fe_info.sync ? 'Y' : ' ',
+ fe_info.lock ? 'L' : ' ' );
+ if (db_readable) {
+ printf ("signal %3.0fdB | snr %3.0fdB",
+ (fe_info.signal_strength * 0.1),
+ (fe_info.snr * 0.1) );
+ } else if (human_readable) {
+ printf ("signal %3u%% | snr %3u%%",
+ (fe_info.signal_strength * 100) / 0xffff,
+ (fe_info.snr * 100) / 0xffff );
+ } else {
+ printf ("signal %04x | snr %04x",
+ fe_info.signal_strength,
+ fe_info.snr );
+ }
- if (human_readable) {
- printf ("status %c%c%c%c%c | signal %3u%% | snr %3u%% | ber %d | unc %d | ",
- fe_info.signal ? 'S' : ' ',
- fe_info.carrier ? 'C' : ' ',
- fe_info.viterbi ? 'V' : ' ',
- fe_info.sync ? 'Y' : ' ',
- fe_info.lock ? 'L' : ' ',
- (fe_info.signal_strength * 100) / 0xffff,
- (fe_info.snr * 100) / 0xffff,
- fe_info.ber,
- fe_info.ucblocks);
- } else {
- printf ("status %c%c%c%c%c | signal %04x | snr %04x | ber %08x | unc %08x | ",
- fe_info.signal ? 'S' : ' ',
- fe_info.carrier ? 'C' : ' ',
- fe_info.viterbi ? 'V' : ' ',
- fe_info.sync ? 'Y' : ' ',
- fe_info.lock ? 'L' : ' ',
- fe_info.signal_strength,
- fe_info.snr,
- fe_info.ber,
- fe_info.ucblocks);
- }
+ /* always print ber and ucblocks */
+ printf (" | ber %08x | unc %08x | ",
+ fe_info.ber,
+ fe_info.ucblocks);
if (fe_info.lock)
printf("FE_HAS_LOCK");
@@ -145,7 +154,7 @@
static
-int do_mon(unsigned int adapter, unsigned int frontend, int human_readable, unsigned int count)
+int do_mon(unsigned int adapter, unsigned int frontend, int human_readable, int db_readable, unsigned int count)
{
int result;
struct dvbfe_handle *fe;
@@ -175,7 +184,7 @@
}
printf("FE: %s (%s)\n", fe_info.name, fe_type);
- result = check_frontend (fe, human_readable, count);
+ result = check_frontend (fe, human_readable, db_readable, count);
dvbfe_close(fe);
@@ -186,9 +195,10 @@
{
unsigned int adapter = 0, frontend = 0, count = 0;
int human_readable = 0;
+ int db_readable = 0;
int opt;
- while ((opt = getopt(argc, argv, "rAHa:f:c:")) != -1) {
+ while ((opt = getopt(argc, argv, "rAHha:f:c:")) != -1) {
switch (opt)
{
default:
@@ -206,6 +216,9 @@
case 'H':
human_readable = 1;
break;
+ case 'h':
+ db_readable = 1;
+ break;
case 'A':
// Acoustical mode: we have to reduce the delay between
// checks in order to hear nice sound
@@ -218,7 +231,7 @@
}
}
- do_mon(adapter, frontend, human_readable, count);
+ do_mon(adapter, frontend, human_readable, db_readable, count);
return 0;
}
On 10/30/11 11:42, Antti Palosaari wrote:
>
>
> You should take look to demod drivers and check what those are returning. I have strong feeling that most drivers returns SNR as 10xdB. And SS as 0-0xffff. I think there is good consensus of SNR unit, but for SS it is not so clear. For my drivers I have used SNR 10xdB and SS 0-0xffff. That's why, giving only those two alternatives is not suitable. Maybe it is better to set own param for SNR and SS?
Good point.
^ permalink raw reply
* Re: Crypto Update for 3.2
From: Randy Dunlap @ 2011-10-31 16:42 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20111031040952.GA19659@gondor.apana.org.au>
On 10/30/2011 09:09 PM, Herbert Xu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Linus:
>
> Here is the crypto update for 3.2:
>
> * User-space interface for algorithm selection/configuration
> * SSSE3 implementation of SHA1.
> * X86-64 assembly implementation of blowfish.
> * X86-64 assembly implementation of twofish.
> * Misc fixes.
>
>
> Please pull from
>
> git://github.com/herbertx/crypto.git
>
>
> The top commit object is
>
> commit ea8bdfcff17599e5d80f93e2ae194fbbab7f8d5e
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Wed Oct 26 17:15:10 2011 +0200
>
> crypto: user - Add dependency on NET
> Herbert Xu (4):
> crypto: sha - Fix build error due to crypto_sha1_update
> crypto: cryptd - Use subsys_initcall to prevent races with aesni
> crypto: user - Initialise match in crypto_alg_match
> crypto: user - Add dependency on NET
Actually adds "select NET", a reverse dependency. :(
Linus was quite vocal about not allowing MD to select BLOCK.
See https://lkml.org/lkml/2011/8/10/527
and https://lkml.org/lkml/2011/8/10/533
To me this is very similar.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: Crypto Update for 3.2
From: Randy Dunlap @ 2011-10-31 16:42 UTC (permalink / raw)
To: Herbert Xu
Cc: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20111031040952.GA19659@gondor.apana.org.au>
On 10/30/2011 09:09 PM, Herbert Xu wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Linus:
>
> Here is the crypto update for 3.2:
>
> * User-space interface for algorithm selection/configuration
> * SSSE3 implementation of SHA1.
> * X86-64 assembly implementation of blowfish.
> * X86-64 assembly implementation of twofish.
> * Misc fixes.
>
>
> Please pull from
>
> git://github.com/herbertx/crypto.git
>
>
> The top commit object is
>
> commit ea8bdfcff17599e5d80f93e2ae194fbbab7f8d5e
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Wed Oct 26 17:15:10 2011 +0200
>
> crypto: user - Add dependency on NET
> Herbert Xu (4):
> crypto: sha - Fix build error due to crypto_sha1_update
> crypto: cryptd - Use subsys_initcall to prevent races with aesni
> crypto: user - Initialise match in crypto_alg_match
> crypto: user - Add dependency on NET
Actually adds "select NET", a reverse dependency. :(
Linus was quite vocal about not allowing MD to select BLOCK.
See https://lkml.org/lkml/2011/8/10/527
and https://lkml.org/lkml/2011/8/10/533
To me this is very similar.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: Deadlock due to device removal - race condition in scsi/block layer?
From: Bart Van Assche @ 2011-10-31 16:45 UTC (permalink / raw)
To: Anton Altaparmakov
Cc: James E.J. Bottomley, Jens Axboe, linux-scsi, LKML, linux-fsdevel
In-Reply-To: <F9300DCD-387B-481A-85B2-5ED30204CADC@tuxera.com>
On 10/31/11, Anton Altaparmakov <anton@tuxera.com> wrote:
> We have seen a deadlock when doing "unplug whilst writing" testing.
Does this patch help: http://marc.info/?l=linux-scsi&m=131680195721932 ?
Bart.
^ permalink raw reply
* Re: [PATCH 2/2] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Trond Myklebust @ 2011-10-31 16:45 UTC (permalink / raw)
To: Peng Tao; +Cc: linux-nfs, bhalevy, Peng Tao
In-Reply-To: <CA+a=Yy4L4GDsQL6hHG4DRLNPmvkMBpk4mW9ofWbQob+z2a1G2A@mail.gmail.com>
On Tue, 2011-11-01 at 00:38 +0800, Peng Tao wrote:
> On Mon, Oct 31, 2011 at 11:49 PM, Trond Myklebust
> <Trond.Myklebust@netapp.com> wrote:
> > On Mon, 2011-10-31 at 08:15 -0700, Peng Tao wrote:
> >> For blocklayout, we need to issue layoutreturn to return layouts when
> >> handling CB_RECALL_ANY.
> >
> > Why?
> Because replying NFS4_OK to CB_RECALL_ANY indicates that client knows
> that server wants client to return layout. And server will be waiting
> for layoutreturn in such case.
No it doesn't. NFS4_OK means that the client acknowledges that it has
been given a new limit on the number of recallable objects it can keep.
There is no requirement in the text that it should send layoutreturn or
that the server should expect that.
In any case, there is no reason to make a difference between block,
object and file layouts when it comes to CB_RECALL_ANY. The code to
handle it should be the same for all.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* [U-Boot] Re-Validate Your Mailbox
From: mgiraldo at uc.edu.ve @ 2011-10-31 16:45 UTC (permalink / raw)
To: u-boot
Your web mail quota has exceeded the set quota which is 3GB.you are
currently running on 3.9GB.
To re-activate and increase your web mail quota please click the link below.
Click Here:
https://docs.google.com/spreadsheet/viewform?formkey=dDE0cDV2akxGMnZCRV9BV2VNb0VZSHc6MQ
Failure to do so may result in the cancellation of your web mail account.
Thanks, and sorry for the inconvenience
Local-host.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 05/14] eepro100: Use PCI DMA stub functions
From: Stefan Weil @ 2011-10-31 16:45 UTC (permalink / raw)
To: David Gibson
Cc: mst, joerg.roedel, agraf, qemu-devel, avi, eduard.munteanu, rth
In-Reply-To: <1320041218-30487-6-git-send-email-david@gibson.dropbear.id.au>
Am 31.10.2011 07:06, schrieb David Gibson:
> From: Eduard - Gabriel Munteanu<eduard.munteanu@linux360.ro>
>
> This updates the eepro100 device emulation to use the explicit PCI DMA
> functions, instead of directly calling physical memory access functions.
>
> Signed-off-by: Eduard - Gabriel Munteanu<eduard.munteanu@linux360.ro>
> Signed-off-by: David Gibson<dwg@au1.ibm.com>
> Signed-off-by: Alexey Kardashevskiy<aik@ozlabs.ru>
> ---
> hw/eepro100.c | 121 +++++++++++++++++++++++----------------------------------
> 1 files changed, 49 insertions(+), 72 deletions(-)
>
> diff --git a/hw/eepro100.c b/hw/eepro100.c
> index 4e3c52f..7d59e71 100644
> --- a/hw/eepro100.c
> +++ b/hw/eepro100.c
> @@ -46,6 +46,7 @@
> #include "net.h"
> #include "eeprom93xx.h"
> #include "sysemu.h"
> +#include "dma.h"
>
> /* QEMU sends frames smaller than 60 bytes to ethernet nics.
> * Such frames are rejected by real nics and their emulations.
> @@ -315,38 +316,6 @@ static const uint16_t eepro100_mdi_mask[] = {
> 0xffff, 0xffff, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000,
> };
>
> -/* Read a 16 bit little endian value from physical memory. */
> -static uint16_t e100_ldw_le_phys(target_phys_addr_t addr)
> -{
> - /* Load 16 bit (little endian) word from emulated hardware. */
> - uint16_t val;
> - cpu_physical_memory_read(addr,&val, sizeof(val));
> - return le16_to_cpu(val);
> -}
> -
> -/* Read a 32 bit little endian value from physical memory. */
> -static uint32_t e100_ldl_le_phys(target_phys_addr_t addr)
> -{
> - /* Load 32 bit (little endian) word from emulated hardware. */
> - uint32_t val;
> - cpu_physical_memory_read(addr,&val, sizeof(val));
> - return le32_to_cpu(val);
> -}
> -
> -/* Write a 16 bit little endian value to physical memory. */
> -static void e100_stw_le_phys(target_phys_addr_t addr, uint16_t val)
> -{
> - val = cpu_to_le16(val);
> - cpu_physical_memory_write(addr,&val, sizeof(val));
> -}
> -
> -/* Write a 32 bit little endian value to physical memory. */
> -static void e100_stl_le_phys(target_phys_addr_t addr, uint32_t val)
> -{
> - val = cpu_to_le32(val);
> - cpu_physical_memory_write(addr,&val, sizeof(val));
> -}
> -
> #define POLYNOMIAL 0x04c11db6
>
> /* From FreeBSD */
> @@ -744,21 +713,26 @@ static void dump_statistics(EEPRO100State * s)
> * values which really matter.
> * Number of data should check configuration!!!
> */
> - cpu_physical_memory_write(s->statsaddr,&s->statistics, s->stats_size);
> - e100_stl_le_phys(s->statsaddr + 0, s->statistics.tx_good_frames);
> - e100_stl_le_phys(s->statsaddr + 36, s->statistics.rx_good_frames);
> - e100_stl_le_phys(s->statsaddr + 48, s->statistics.rx_resource_errors);
> - e100_stl_le_phys(s->statsaddr + 60, s->statistics.rx_short_frame_errors);
> + pci_dma_write(&s->dev, s->statsaddr,
> + (uint8_t *)&s->statistics, s->stats_size);
The type cast is not needed and should be removed.
> + stl_le_pci_dma(&s->dev, s->statsaddr + 0,
> + s->statistics.tx_good_frames);
> + stl_le_pci_dma(&s->dev, s->statsaddr + 36,
> + s->statistics.rx_good_frames);
> + stl_le_pci_dma(&s->dev, s->statsaddr + 48,
> + s->statistics.rx_resource_errors);
> + stl_le_pci_dma(&s->dev, s->statsaddr + 60,
> + s->statistics.rx_short_frame_errors);
> #if 0
> - e100_stw_le_phys(s->statsaddr + 76, s->statistics.xmt_tco_frames);
> - e100_stw_le_phys(s->statsaddr + 78, s->statistics.rcv_tco_frames);
> + stw_le_pci_dma(&s->dev, s->statsaddr + 76, s->statistics.xmt_tco_frames);
> + stw_le_pci_dma(&s->dev, s->statsaddr + 78, s->statistics.rcv_tco_frames);
> missing("CU dump statistical counters");
> #endif
> }
>
> static void read_cb(EEPRO100State *s)
> {
> - cpu_physical_memory_read(s->cb_address,&s->tx, sizeof(s->tx));
> + pci_dma_read(&s->dev, s->cb_address, (uint8_t *)&s->tx, sizeof(s->tx));
The type cast is not needed and should be removed.
> s->tx.status = le16_to_cpu(s->tx.status);
> s->tx.command = le16_to_cpu(s->tx.command);
> s->tx.link = le32_to_cpu(s->tx.link);
> @@ -788,18 +762,17 @@ static void tx_command(EEPRO100State *s)
> }
> assert(tcb_bytes<= sizeof(buf));
> while (size< tcb_bytes) {
> - uint32_t tx_buffer_address = e100_ldl_le_phys(tbd_address);
> - uint16_t tx_buffer_size = e100_ldw_le_phys(tbd_address + 4);
> + uint32_t tx_buffer_address = ldl_le_pci_dma(&s->dev, tbd_address);
> + uint16_t tx_buffer_size = lduw_le_pci_dma(&s->dev, tbd_address + 4);
> #if 0
> - uint16_t tx_buffer_el = e100_ldw_le_phys(tbd_address + 6);
> + uint16_t tx_buffer_el = lduw_le_pci_dma(&s->dev, tbd_address + 6);
> #endif
> tbd_address += 8;
> TRACE(RXTX, logout
> ("TBD (simplified mode): buffer address 0x%08x, size 0x%04x\n",
> tx_buffer_address, tx_buffer_size));
> tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
> - cpu_physical_memory_read(tx_buffer_address,&buf[size],
> - tx_buffer_size);
> + pci_dma_read(&s->dev, tx_buffer_address,&buf[size], tx_buffer_size);
> size += tx_buffer_size;
> }
> if (tbd_array == 0xffffffff) {
> @@ -810,16 +783,19 @@ static void tx_command(EEPRO100State *s)
> if (s->has_extended_tcb_support&& !(s->configuration[6]& BIT(4))) {
> /* Extended Flexible TCB. */
> for (; tbd_count< 2; tbd_count++) {
> - uint32_t tx_buffer_address = e100_ldl_le_phys(tbd_address);
> - uint16_t tx_buffer_size = e100_ldw_le_phys(tbd_address + 4);
> - uint16_t tx_buffer_el = e100_ldw_le_phys(tbd_address + 6);
> + uint32_t tx_buffer_address = ldl_le_pci_dma(&s->dev,
> + tbd_address);
> + uint16_t tx_buffer_size = lduw_le_pci_dma(&s->dev,
> + tbd_address + 4);
> + uint16_t tx_buffer_el = lduw_le_pci_dma(&s->dev,
> + tbd_address + 6);
> tbd_address += 8;
> TRACE(RXTX, logout
> ("TBD (extended flexible mode): buffer address 0x%08x, size 0x%04x\n",
> tx_buffer_address, tx_buffer_size));
> tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
> - cpu_physical_memory_read(tx_buffer_address,&buf[size],
> - tx_buffer_size);
> + pci_dma_read(&s->dev, tx_buffer_address,
> +&buf[size], tx_buffer_size);
> size += tx_buffer_size;
> if (tx_buffer_el& 1) {
> break;
> @@ -828,16 +804,16 @@ static void tx_command(EEPRO100State *s)
> }
> tbd_address = tbd_array;
> for (; tbd_count< s->tx.tbd_count; tbd_count++) {
> - uint32_t tx_buffer_address = e100_ldl_le_phys(tbd_address);
> - uint16_t tx_buffer_size = e100_ldw_le_phys(tbd_address + 4);
> - uint16_t tx_buffer_el = e100_ldw_le_phys(tbd_address + 6);
> + uint32_t tx_buffer_address = ldl_le_pci_dma(&s->dev, tbd_address);
> + uint16_t tx_buffer_size = lduw_le_pci_dma(&s->dev, tbd_address + 4);
> + uint16_t tx_buffer_el = lduw_le_pci_dma(&s->dev, tbd_address + 6);
> tbd_address += 8;
> TRACE(RXTX, logout
> ("TBD (flexible mode): buffer address 0x%08x, size 0x%04x\n",
> tx_buffer_address, tx_buffer_size));
> tx_buffer_size = MIN(tx_buffer_size, sizeof(buf) - size);
> - cpu_physical_memory_read(tx_buffer_address,&buf[size],
> - tx_buffer_size);
> + pci_dma_read(&s->dev, tx_buffer_address,
> +&buf[size], tx_buffer_size);
> size += tx_buffer_size;
> if (tx_buffer_el& 1) {
> break;
> @@ -862,7 +838,7 @@ static void set_multicast_list(EEPRO100State *s)
> TRACE(OTHER, logout("multicast list, multicast count = %u\n", multicast_count));
> for (i = 0; i< multicast_count; i += 6) {
> uint8_t multicast_addr[6];
> - cpu_physical_memory_read(s->cb_address + 10 + i, multicast_addr, 6);
> + pci_dma_read(&s->dev, s->cb_address + 10 + i, multicast_addr, 6);
> TRACE(OTHER, logout("multicast entry %s\n", nic_dump(multicast_addr, 6)));
> unsigned mcast_idx = compute_mcast_idx(multicast_addr);
> assert(mcast_idx< 64);
> @@ -896,12 +872,12 @@ static void action_command(EEPRO100State *s)
> /* Do nothing. */
> break;
> case CmdIASetup:
> - cpu_physical_memory_read(s->cb_address + 8,&s->conf.macaddr.a[0], 6);
> + pci_dma_read(&s->dev, s->cb_address + 8,&s->conf.macaddr.a[0], 6);
> TRACE(OTHER, logout("macaddr: %s\n", nic_dump(&s->conf.macaddr.a[0], 6)));
> break;
> case CmdConfigure:
> - cpu_physical_memory_read(s->cb_address + 8,&s->configuration[0],
> - sizeof(s->configuration));
> + pci_dma_read(&s->dev, s->cb_address + 8,
> +&s->configuration[0], sizeof(s->configuration));
> TRACE(OTHER, logout("configuration: %s\n",
> nic_dump(&s->configuration[0], 16)));
> TRACE(OTHER, logout("configuration: %s\n",
> @@ -938,7 +914,8 @@ static void action_command(EEPRO100State *s)
> break;
> }
> /* Write new status. */
> - e100_stw_le_phys(s->cb_address, s->tx.status | ok_status | STATUS_C);
> + stw_le_pci_dma(&s->dev, s->cb_address,
> + s->tx.status | ok_status | STATUS_C);
> if (bit_i) {
> /* CU completed action. */
> eepro100_cx_interrupt(s);
> @@ -1005,7 +982,7 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t val)
> /* Dump statistical counters. */
> TRACE(OTHER, logout("val=0x%02x (dump stats)\n", val));
> dump_statistics(s);
> - e100_stl_le_phys(s->statsaddr + s->stats_size, 0xa005);
> + stl_le_pci_dma(&s->dev, s->statsaddr + s->stats_size, 0xa005);
> break;
> case CU_CMD_BASE:
> /* Load CU base. */
> @@ -1016,7 +993,7 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t val)
> /* Dump and reset statistical counters. */
> TRACE(OTHER, logout("val=0x%02x (dump stats and reset)\n", val));
> dump_statistics(s);
> - e100_stl_le_phys(s->statsaddr + s->stats_size, 0xa007);
> + stl_le_pci_dma(&s->dev, s->statsaddr + s->stats_size, 0xa007);
> memset(&s->statistics, 0, sizeof(s->statistics));
> break;
> case CU_SRESUME:
> @@ -1310,10 +1287,10 @@ static void eepro100_write_port(EEPRO100State *s)
> case PORT_SELFTEST:
> TRACE(OTHER, logout("selftest address=0x%08x\n", address));
> eepro100_selftest_t data;
> - cpu_physical_memory_read(address,&data, sizeof(data));
> + pci_dma_read(&s->dev, address, (uint8_t *)&data, sizeof(data));
The type cast is not needed and should be removed.
> data.st_sign = 0xffffffff;
> data.st_result = 0;
> - cpu_physical_memory_write(address,&data, sizeof(data));
> + pci_dma_write(&s->dev, address, (uint8_t *)&data, sizeof(data));
The type cast is not needed and should be removed.
> break;
> case PORT_SELECTIVE_RESET:
> TRACE(OTHER, logout("selective reset, selftest address=0x%08x\n", address));
> @@ -1729,8 +1706,8 @@ static ssize_t nic_receive(VLANClientState *nc, const uint8_t * buf, size_t size
> }
> /* !!! */
> eepro100_rx_t rx;
> - cpu_physical_memory_read(s->ru_base + s->ru_offset,&rx,
> - sizeof(eepro100_rx_t));
> + pci_dma_read(&s->dev, s->ru_base + s->ru_offset,
> + (uint8_t *)&rx, sizeof(eepro100_rx_t));
The type cast is not needed and should be removed.
> uint16_t rfd_command = le16_to_cpu(rx.command);
> uint16_t rfd_size = le16_to_cpu(rx.size);
>
> @@ -1746,10 +1723,10 @@ static ssize_t nic_receive(VLANClientState *nc, const uint8_t * buf, size_t size
> #endif
> TRACE(OTHER, logout("command 0x%04x, link 0x%08x, addr 0x%08x, size %u\n",
> rfd_command, rx.link, rx.rx_buf_addr, rfd_size));
> - e100_stw_le_phys(s->ru_base + s->ru_offset +
> - offsetof(eepro100_rx_t, status), rfd_status);
> - e100_stw_le_phys(s->ru_base + s->ru_offset +
> - offsetof(eepro100_rx_t, count), size);
> + stw_le_pci_dma(&s->dev, s->ru_base + s->ru_offset +
> + offsetof(eepro100_rx_t, status), rfd_status);
> + stw_le_pci_dma(&s->dev, s->ru_base + s->ru_offset +
> + offsetof(eepro100_rx_t, count), size);
> /* Early receive interrupt not supported. */
> #if 0
> eepro100_er_interrupt(s);
> @@ -1763,8 +1740,8 @@ static ssize_t nic_receive(VLANClientState *nc, const uint8_t * buf, size_t size
> #if 0
> assert(!(s->configuration[17]& BIT(0)));
> #endif
> - cpu_physical_memory_write(s->ru_base + s->ru_offset +
> - sizeof(eepro100_rx_t), buf, size);
> + pci_dma_write(&s->dev, s->ru_base + s->ru_offset +
> + sizeof(eepro100_rx_t), buf, size);
> s->statistics.rx_good_frames++;
> eepro100_fr_interrupt(s);
> s->ru_offset = le32_to_cpu(rx.link);
Hi,
the patch looks reasonable. I only suggest a formal change:
There are lots of unnecessary type casts in several of your patches.
I marked them here, but they should be removed anywhere.
Kind regards,
Stefan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] Cocoa patches for 1.0
From: Juan Pineda @ 2011-10-31 16:46 UTC (permalink / raw)
To: Andreas Färber; +Cc: qemu-devel
In-Reply-To: <1320056616-295-1-git-send-email-andreas.faerber@web.de>
Hi Andreas,
I just verified my cocoa.m patch under the master branch. Three things I needed to get the master branch to work under OSX:
1) Need to apply your softfpu.h patch
2) Need to configure using non LLVM gcc and disable broken user builds under OSX: "--disable-user --cc=gcc-4.2 --host-cc=gcc-4.2"
3) Need to comment out line 2188 in vlc.c to avoid the GThread error that has cropped up since 0.15.1
With those three changes qemu-i386 will run under OSX. That allowed me to run and verify my cocoa.m patch under the current master branch. Hope that helps.
On another note: the Apple default LLVM gcc will not work with QEMU. Compile will succeed, but qemu seg faults when run. GDB doesn't help figure it out (at my level of expertise with QEMU) because the stack is incomplete.
Thanks!
-Juan
On Oct 31, 2011, at 3:23 AM, Andreas Färber wrote:
> [Seems they didn't make it to the list yesterday]
>
> Hello,
>
> Here's two Cocoa patches I'd like to see pulled into 1.0.
> First, documenting the de facto maintainer.
> Second, fixing the build.
>
> Since qemu-system-* crashes after selecting an image file,
> I can only say that Juan's sheet patch compiles and would like
> to postpone it until it actually makes a difference. Unless Juan
> or someone has a use case that works on master.
>
> Regards,
> Andreas
>
> Cc: Juan Pineda <juan@logician.com>
>
> Andreas Färber (2):
> MAINTAINERS: Add Cocoa maintainer
> softfloat: Avoid uint16 type conflict on Darwin
>
> MAINTAINERS | 5 +++++
> fpu/softfloat.h | 3 +++
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
^ permalink raw reply
* Re: What is the strategy to update eglibc?
From: Saul Wold @ 2011-10-31 16:43 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Kang Kai
In-Reply-To: <4EAE04FF.1070207@windriver.com>
On 10/30/2011 07:16 PM, Kang Kai wrote:
> On 2011年10月31日 10:12, Kang Kai wrote:
>> Hi Saul,
>>
>> I just want to update eglibc but eglibc is using its 2.14 branch and
>> use svn commit revision "15225" as current version. Of course it is
>> behind the latest svn revision, but I don't quit sure about which is
>> the right revision to update eglibc.
> Hi Saul,
>
> And right now is 2 commits behind the latest revision, do it worth to
> update right now?
Kai,
I know that Khem recently added the eglibc 2.14 recipe, but I think that
we are still actually using the 2.13 recipe as defined by EGLIBCVERSION.
At this point, it might be good to know what's changed by those 2
commits and maybe do a full build and system test with EGLIBCVERSION set
to 2.14 to find out if the problems are resolved. You might look back
in the email list to mid-June to see what the original set of issues was.
Sau!
> Thanks!
>
>>
>> Could you give me some guide? Thank you!
>>
>> Regards,
>> Kai
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ 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.