* [Lustre-devel] Queries regarding LDLM_ENQUEUE
From: Andreas Dilger @ 2010-10-20 8:24 UTC (permalink / raw)
To: lustre-devel
In-Reply-To: <4CBEA415.80307@gmail.com>
On 2010-10-20, at 02:11, bzzz.tomas at gmail.com wrote:
> On 10/20/10 11:55 AM, Andreas Dilger wrote:
>> There is a separate proposal that has been underway in the Linux community for some time, to allow a user process to get a file handle (i.e. binary blob returned from a new name_to_handle() syscall) from the kernel for a given pathname, and then later use that file handle in another process to open a file descriptor without re-traversing the path.
>>
>> I've been thinking this would be very useful for Lustre (and MPI in general), and have tried to steer the Linux development in a direction that would allow this to happen. Is this in line with what you are investigating?
>
> with FIDs is quite possible and even safe if application can learn it
> (using xattr_get or ioctl). then it should be trivial to export FID
> namespace on MDS via special .lustre-fids directory?
I'm reluctant to expose the whole FID namespace to applications, since this completely bypasses all directory permissions and allows opening files only based on their inode permissions. If we require a name_to_handle() syscall to succeed first, before allowing open_by_handle() to work, then at least we know that one of the involved processes was able to do a full path traversal.
> another idea was to do whole path traversal on MDS within a single RPC.
> bug that'd require amount of changes to llite and/or VFS and keep MDS
> a bottleneck.
This was discussed a long time ago, and has the potential drawback that if one of the path components is over-mounted on the client (e.g. local RAM-based tmpfs on a Lustre root filesystem) then the MDS-side path traversal would be incorrect. It could return an entry underneath the mountpoint, instead of inside it.
Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.
^ permalink raw reply
* [patch 1/9] efikamx: read board id
From: Sascha Hauer @ 2010-10-20 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=SbFy1eFzQ3XUGDjurme=stUSiqmTRVR=EtX5q@mail.gmail.com>
On Tue, Oct 19, 2010 at 04:30:25PM -0500, Matt Sealey wrote:
> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
> >> read board id value from the GPIO3_16/17/11
> >>
> >>
> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
> >> +*/
> >> +static void __init mx51_efikamx_board_id(void)
> >> +{
> >> + ? ? int id;
> >> +
> >> + ? ? /* things are taking time to settle */
> >> + ? ? msleep(500);
> >
> > Is it really necessary to delay the boot process such a long time?
>
> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
> (a pulldown on the board on newer revisions will keep it down). IOMUX
> and GPIO stuff takes a little while to settle in, so if you do it
> immediately, it will return some freakish values based on random GPIO
> setup (it may be high, low, or none of the above at any point before
> the pad setting kicks in).
Maybe it's possible to delay only the registering of the devices which
depend on the board revision, perhaps with a workqueue. But ok, I don't
care much and this won't be a show stopper for this patch.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3] Add generic exponentially weighted moving average (EWMA) function
From: Bruno Randolf @ 2010-10-20 8:23 UTC (permalink / raw)
To: randy.dunlap, br1, akpm, kevin.granade; +Cc: Lars_Ericsson, blp, linux-kernel
This adds generic functions for calculating Exponentially Weighted Moving
Averages (EWMA). This implementation makes use of a structure which keeps the
EWMA parameters and a scaled up internal representation to reduce rounding
errors.
The original idea for this implementation came from the rt2x00 driver
(rt2x00link.c). I would like to use it in several places in the mac80211 and
ath5k code and I hope it can be useful in many other places in the kernel code.
Signed-off-by: Bruno Randolf <br1@einfach.org>
--
v3: Addressing Andrew Mortons comments: Implement in lib/average.c and make
access and initalization functions. Use unsigned int for values. Rename
functions to ewma_* since there might be other moving average
implementations which are not exponentially weighted.
v2: Renamed 'samples' to 'weight'. Added more documentation. Use avg_val
pointer. Add a WARN_ON_ONCE for invalid values of 'weight'. Divide
and round up/down.
---
include/linux/average.h | 32 +++++++++++++++++++++++++
lib/Makefile | 2 +-
lib/average.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 92 insertions(+), 1 deletions(-)
create mode 100644 include/linux/average.h
create mode 100644 lib/average.c
diff --git a/include/linux/average.h b/include/linux/average.h
new file mode 100644
index 0000000..56bef6c
--- /dev/null
+++ b/include/linux/average.h
@@ -0,0 +1,32 @@
+#ifndef _LINUX_AVERAGE_H
+#define _LINUX_AVERAGE_H
+
+#include <linux/kernel.h>
+
+/* Exponentially weighted moving average (EWMA) */
+
+/* For more documentation see lib/average.c */
+
+struct ewma {
+ unsigned int internal;
+ unsigned int factor;
+ unsigned int weight;
+};
+
+extern struct ewma* ewma_init(struct ewma *avg, const unsigned int factor,
+ const unsigned int weight);
+
+extern struct ewma* ewma_add(struct ewma *avg, const unsigned int val);
+
+/**
+ * ewma_get() - Get average value
+ * @avg: Average structure
+ *
+ * Returns the average value held in @avg.
+ */
+static inline unsigned int ewma_get(const struct ewma *avg)
+{
+ return DIV_ROUND_CLOSEST(avg->internal, avg->factor);
+}
+
+#endif /* _LINUX_AVERAGE_H */
diff --git a/lib/Makefile b/lib/Makefile
index e6a3763..f66acf7 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -21,7 +21,7 @@ lib-y += kobject.o kref.o klist.o
obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
- string_helpers.o gcd.o lcm.o list_sort.o uuid.o
+ string_helpers.o gcd.o lcm.o list_sort.o uuid.o average.o
ifeq ($(CONFIG_DEBUG_KOBJECT),y)
CFLAGS_kobject.o += -DDEBUG
diff --git a/lib/average.c b/lib/average.c
new file mode 100644
index 0000000..081a8fd
--- /dev/null
+++ b/lib/average.c
@@ -0,0 +1,59 @@
+/*
+ * lib/average.c
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2. See the file COPYING for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/average.h>
+
+/**
+ * DOC: Exponentially Weighted Moving Average (EWMA)
+ *
+ * These are generic functions for calculating Exponentially Weighted Moving
+ * Averages (EWMA). We keep a structure with the EWMA parameters and a scaled
+ * up internal representation of the average value to prevent rounding errors.
+ * The factor for scaling up and the exponential weight (or decay rate) have to
+ * be specified thru the init fuction. The structure should not be accessed
+ * directly but only thru the helper functions.
+ */
+
+/**
+ * ewma_init() - Initialize EWMA parameters
+ * @avg: Average structure
+ * @factor: Factor to use for the scaled up internal value. The maximum value
+ * of averages can be UINT_MAX/(factor*weight).
+ * @weight: Exponential weight, or decay rate. This defines how fast the
+ * influence of older values decreases. Has to be bigger than 1.
+ *
+ * Initialize the EWMA parameters for a given struct ewma @avg.
+ */
+struct ewma*
+ewma_init(struct ewma *avg, const unsigned int factor,
+ const unsigned int weight)
+{
+ WARN_ON(weight <= 1 || factor == 0);
+ avg->weight = weight;
+ avg->factor = factor;
+ return avg;
+}
+EXPORT_SYMBOL(ewma_init);
+
+/**
+ * ewma_add() - Exponentially weighted moving average (EWMA)
+ * @avg: Average structure
+ * @val: Current value
+ *
+ * Add a sample to the average.
+ */
+struct ewma*
+ewma_add(struct ewma *avg, const unsigned int val)
+{
+ avg->internal = avg->internal ?
+ (((avg->internal * (avg->weight - 1)) +
+ (val * avg->factor)) / avg->weight) :
+ (val * avg->factor);
+ return avg;
+}
+EXPORT_SYMBOL(ewma_add);
^ permalink raw reply related
* [Qemu-devel] [PATCH v6 04/12] ioh3420: pcie root port in X58 ioh
From: Isaku Yamahata @ 2010-10-20 8:18 UTC (permalink / raw)
To: qemu-devel; +Cc: skandasa, adnan, wexu2, mst, yamahata, etmartin
In-Reply-To: <cover.1287562197.git.yamahata@valinux.co.jp>
Implements pcie root port switch in intel X58 ioh
whose device id is 0x3420.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
---
Changes v5 -> v6:
- compilation adjustment.
- eliminated aer bits.
Changes v4 -> v5:
- use pci_xxx_test_and_xxx_mask()
Changes v3 -> v4:
- rename pcie_root -> ioh3420
- compilation adjustment.
Changes v2 -> v3:
- compilation adjustment.
---
Makefile.objs | 1 +
hw/ioh3420.c | 188 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
hw/ioh3420.h | 10 +++
3 files changed, 199 insertions(+), 0 deletions(-)
create mode 100644 hw/ioh3420.c
create mode 100644 hw/ioh3420.h
diff --git a/Makefile.objs b/Makefile.objs
index c73d12b..3a05322 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -140,6 +140,7 @@ hw-obj-y =
hw-obj-y += vl.o loader.o
hw-obj-y += virtio.o virtio-console.o
hw-obj-y += fw_cfg.o pci.o pci_host.o pcie_host.o pci_bridge.o
+hw-obj-y += ioh3420.o
hw-obj-y += watchdog.o
hw-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o
hw-obj-$(CONFIG_ECC) += ecc.o
diff --git a/hw/ioh3420.c b/hw/ioh3420.c
new file mode 100644
index 0000000..1f340d3
--- /dev/null
+++ b/hw/ioh3420.c
@@ -0,0 +1,188 @@
+/*
+ * ioh3420.c
+ * Intel X58 north bridge IOH
+ * PCI Express root port device id 3420
+ *
+ * Copyright (c) 2010 Isaku Yamahata <yamahata at valinux co jp>
+ * VA Linux Systems Japan K.K.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "pci_ids.h"
+#include "msi.h"
+#include "pcie.h"
+#include "ioh3420.h"
+
+#define PCI_DEVICE_ID_IOH_EPORT 0x3420 /* D0:F0 express mode */
+#define PCI_DEVICE_ID_IOH_REV 0x2
+#define IOH_EP_SSVID_OFFSET 0x40
+#define IOH_EP_SSVID_SVID PCI_VENDOR_ID_INTEL
+#define IOH_EP_SSVID_SSID 0
+#define IOH_EP_MSI_OFFSET 0x60
+#define IOH_EP_MSI_SUPPORTED_FLAGS PCI_MSI_FLAGS_MASKBIT
+#define IOH_EP_MSI_NR_VECTOR 2
+#define IOH_EP_EXP_OFFSET 0x90
+#define IOH_EP_AER_OFFSET 0x100
+
+static void ioh3420_write_config(PCIDevice *d,
+ uint32_t address, uint32_t val, int len)
+{
+ uint16_t sltctl =
+ pci_get_word(d->config + d->exp.exp_cap + PCI_EXP_SLTCTL);
+
+ pci_bridge_write_config(d, address, val, len);
+ msi_write_config(d, address, val, len);
+ pcie_cap_slot_write_config(d, address, val, len, sltctl);
+ /* TODO: AER */
+}
+
+static void ioh3420_reset(DeviceState *qdev)
+{
+ PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+ msi_reset(d);
+ pcie_cap_root_reset(d);
+ pcie_cap_deverr_reset(d);
+ pcie_cap_slot_reset(d);
+ pci_bridge_reset(qdev);
+ pci_bridge_disable_base_limit(d);
+ /* TODO: AER */
+}
+
+static int ioh3420_initfn(PCIDevice *d)
+{
+ PCIBridge* br = DO_UPCAST(PCIBridge, dev, d);
+ PCIEPort *p = DO_UPCAST(PCIEPort, br, br);
+ PCIESlot *s = DO_UPCAST(PCIESlot, port, p);
+ int rc;
+
+ rc = pci_bridge_initfn(d);
+ if (rc < 0) {
+ return rc;
+ }
+
+ d->config[PCI_REVISION_ID] = PCI_DEVICE_ID_IOH_REV;
+ pcie_port_init_reg(d);
+
+ pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_INTEL);
+ pci_config_set_device_id(d->config, PCI_DEVICE_ID_IOH_EPORT);
+
+ rc = pci_bridge_ssvid_init(d, IOH_EP_SSVID_OFFSET,
+ IOH_EP_SSVID_SVID, IOH_EP_SSVID_SSID);
+ if (rc < 0) {
+ return rc;
+ }
+ rc = msi_init(d, IOH_EP_MSI_OFFSET, IOH_EP_MSI_NR_VECTOR,
+ IOH_EP_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_64BIT,
+ IOH_EP_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_MASKBIT);
+ if (rc < 0) {
+ return rc;
+ }
+ rc = pcie_cap_init(d, IOH_EP_EXP_OFFSET, PCI_EXP_TYPE_ROOT_PORT, p->port);
+ if (rc < 0) {
+ return rc;
+ }
+ pcie_cap_deverr_init(d);
+ pcie_cap_slot_init(d, s->slot);
+ pcie_chassis_create(s->chassis);
+ rc = pcie_chassis_add_slot(s);
+ if (rc < 0) {
+ return rc;
+ }
+ pcie_cap_root_init(d);
+ /* TODO: AER */
+ return 0;
+}
+
+static int ioh3420_exitfn(PCIDevice *d)
+{
+ /* TODO: AER */
+ msi_uninit(d);
+ pcie_cap_exit(d);
+ return pci_bridge_exitfn(d);
+}
+
+PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
+ const char *bus_name, pci_map_irq_fn map_irq,
+ uint8_t port, uint8_t chassis, uint16_t slot)
+{
+ PCIDevice *d;
+ PCIBridge *br;
+ DeviceState *qdev;
+
+ d = pci_create_multifunction(bus, devfn, multifunction, "ioh3420");
+ if (!d) {
+ return NULL;
+ }
+ br = DO_UPCAST(PCIBridge, dev, d);
+
+ qdev = &br->dev.qdev;
+ pci_bridge_map_irq(br, bus_name, map_irq);
+ qdev_prop_set_uint8(qdev, "port", port);
+ qdev_prop_set_uint8(qdev, "chassis", chassis);
+ qdev_prop_set_uint16(qdev, "slot", slot);
+ qdev_init_nofail(qdev);
+
+ return DO_UPCAST(PCIESlot, port, DO_UPCAST(PCIEPort, br, br));
+}
+
+static const VMStateDescription vmstate_ioh3420 = {
+ .name = "ioh-3240-express-root-port",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .minimum_version_id_old = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_PCIE_DEVICE(port.br.dev, PCIESlot),
+ /* TODO: AER */
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+static PCIDeviceInfo ioh3420_info = {
+ .qdev.name = "ioh3420",
+ .qdev.desc = "Intel IOH device id 3420 PCIE Root Port",
+ .qdev.size = sizeof(PCIESlot),
+ .qdev.reset = ioh3420_reset,
+ .qdev.vmsd = &vmstate_ioh3420,
+
+ .is_express = 1,
+ .is_bridge = 1,
+ .config_write = ioh3420_write_config,
+ .init = ioh3420_initfn,
+ .exit = ioh3420_exitfn,
+
+ .qdev.props = (Property[]) {
+ DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
+ DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
+ DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
+ /* TODO: AER */
+ DEFINE_PROP_END_OF_LIST(),
+ }
+};
+
+static void ioh3420_register(void)
+{
+ pci_qdev_register(&ioh3420_info);
+}
+
+device_init(ioh3420_register);
+
+/*
+ * Local variables:
+ * c-indent-level: 4
+ * c-basic-offset: 4
+ * tab-width: 8
+ * indent-tab-mode: nil
+ * End:
+ */
diff --git a/hw/ioh3420.h b/hw/ioh3420.h
new file mode 100644
index 0000000..68c523a
--- /dev/null
+++ b/hw/ioh3420.h
@@ -0,0 +1,10 @@
+#ifndef QEMU_IOH3420_H
+#define QEMU_IOH3420_H
+
+#include "pcie_port.h"
+
+PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction,
+ const char *bus_name, pci_map_irq_fn map_irq,
+ uint8_t port, uint8_t chassis, uint16_t slot);
+
+#endif /* QEMU_IOH3420_H */
--
1.7.1.1
^ permalink raw reply related
* [U-Boot] [PATCH] MAKEALL: drop non-existent i386 config
From: Graeme Russ @ 2010-10-20 8:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287560059-31305-1-git-send-email-vapier@gentoo.org>
On Wednesday, October 20, 2010, Mike Frysinger <vapier@gentoo.org> wrote:
> ---
> ?MAKEALL | ? ?4 +---
> ?1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/MAKEALL b/MAKEALL
> index c1f3842..febf89c 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -559,9 +559,7 @@ LIST_mips_el=" ? ? ? ? ? ? ? ? ? ? ?\
> ?## i386 Systems
> ?#########################################################################
>
> -LIST_x86="$(boards_by_arch i386)
> - ? ? ? sc520_eNET ? ? ?\
> -"
> +LIST_x86="$(boards_by_arch i386)"
>
Thanks Mike. I won't get a chance to test this until next week though
RL needs more attention ATM :)
Regards,
Graeme
^ permalink raw reply
* XFS bad inode magic/vsn daddr 64 #8 (magic=5858)
From: Nick Piggin @ 2010-10-20 8:24 UTC (permalink / raw)
To: xfs
Hi, I keep hitting this bug running xfstests, and managed to
reproduce it several times on current vanilla upstream kernel
too, below is one trace.
Nothing special about the xfstests run, except that it is run
on brd device for both the test and the scratch mounts. No
special mount options or mkfs flags. It seems pretty reproducable
though, triggering every time I've run the tests like this.
I didn't narrow down the test that causes the bug because it
keeps running other tests and then eventually hanging. Any hints
to narrow it down?
Thanks,
Nick
[ 1161.193017] Device ram1 - bad inode magic/vsn daddr 64 #8
(magic=5858)
[ 1161.193200] ------------[ cut here ]------------
[ 1161.193359] kernel BUG at fs/xfs/support/debug.c:61!
[ 1161.193518] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 1161.193953] last sysfs file:
/sys/devices/virtual/block/ram1/removable
[ 1161.194004] CPU 3
[ 1161.194004] Modules linked in: ext2 xfs exportfs brd [last unloaded:
scsi_wait_scan]
[ 1161.194004]
[ 1161.194004] Pid: 2599, comm: mount Not tainted 2.6.36-rc8+ #16
S5520UR/S5520UR
[ 1161.194004] RIP: 0010:[<ffffffffa00aa049>] [<ffffffffa00aa049>]
cmn_err+0xd9/0xe0 [xfs]
[ 1161.194004] RSP: 0018:ffff880134965a58 EFLAGS: 00010246
[ 1161.194004] RAX: ffff880134965fd8 RBX: 0000000000000000 RCX: 0000000000000000
[ 1161.194004] RDX: 00000000000000d8 RSI: 0000000000000000 RDI: 0000000000000001
[ 1161.194004] RBP: ffff880134965ac8 R08: 0000000000000000 R09: 0000000000000000[
1161.194004] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000286
[ 1161.194004] R13: ffffffffa00ba480 R14: 0000000000000040 R15: ffff8801c02db860
[ 1161.194004] FS: 00007f5357eff7e0(0000) GS:ffff880132c20000(0000) knlGS:0000000000000000
[ 1161.194004] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1161.194004] CR2: 0000000001fa9788 CR3: 0000000140adf000 CR4: 00000000000006e0
[ 1161.194004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1161.194004] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1161.194004] Process mount (pid: 2599, threadinfo ffff880134964000, task ffff88013424be80)
[ 1161.194004] Stack:
[ 1161.194004] ffff880100000030 ffff880134965ad8 ffff880134965a78
ffff88012dd0109c
[ 1161.194004] <0> 00000000000000b5 0000000000005858 ffff880134965b18 0000000000000040
[ 1161.194004] <0> 0000000000000008 0000000000005858 ffff88012d4452d0 0000000000000008
[ 1161.194004] Call Trace:
[ 1161.194004] [<ffffffffa00724d6>] xfs_imap_to_bp+0x166/0x240 [xfs]
[ 1161.194004] [<ffffffffa00756c3>] ? xfs_iread+0x83/0x200 [xfs]
[ 1161.194004] [<ffffffffa00756c3>] xfs_iread+0x83/0x200 [xfs]
[ 1161.194004] [<ffffffffa006ea22>] xfs_iget+0x3c2/0x970 [xfs]
[ 1161.194004] [<ffffffffa008bb31>] xfs_mountfs+0x391/0x780 [xfs]
[ 1161.194004] [<ffffffffa0069100>] ? xfs_fstrm_free_func+0x0/0x1d0
[xfs]
[ 1161.194004] [<ffffffffa008c6ed>] ? xfs_mru_cache_create+0x18d/0x1c0
[xfs]
[ 1161.194004] [<ffffffffa00a7ee4>] xfs_fs_fill_super+0x1f4/0x3d0 [xfs]
[ 1161.194004] [<ffffffff811788aa>] ? disk_name+0xba/0xc0
[ 1161.194004] [<ffffffff8111310f>] get_sb_bdev+0x18f/0x1d0
[ 1161.194004] [<ffffffffa00a7cf0>] ? xfs_fs_fill_super+0x0/0x3d0 [xfs]
[ 1161.194004] [<ffffffffa00a58a3>] xfs_fs_get_sb+0x13/0x20 [xfs]
[ 1161.194004] [<ffffffff811116f5>] vfs_kern_mount+0x65/0x150
[ 1161.194004] [<ffffffff8111184d>] do_kern_mount+0x4d/0x130
[ 1161.194004] [<ffffffff815bbeca>] ? _lock_kernel+0x6a/0x1a0
[ 1161.194004] [<ffffffff8112dbf7>] do_mount+0x2d7/0x870
[ 1161.194004] [<ffffffff810dbbe3>] ? strndup_user+0x53/0x70
[ 1161.194004] [<ffffffff8112e9c3>] sys_mount+0x93/0xe0
[ 1161.194004] [<ffffffff810030ab>] system_call_fastpath+0x16/0x1b
[ 1161.194004] Code: c7 e0 a6 0c a0 e8 78 18 51 e1 85 db 74 1d 48 83 c4
58 5b 41 5c 41 5d c9 c3 66 0f 1f 84 00 00 00 00 00 c6 82 c0 83 0d a0 00
eb b0 <0f> 0b eb fe 90 90 90 55 48 85 ff 48 89 e5 74 37 80 3f 00 75 32
[ 1161.194004] RIP [<ffffffffa00aa049>] cmn_err+0xd9/0xe0 [xfs]
[ 1161.194004] RSP <ffff880134965a58>
[ 1161.208585] ---[ end trace c4cb90fb4c1c6dc9 ]---
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* is RBD supported in qemu 0.13?
From: Xiaoguang Liu @ 2010-10-20 8:22 UTC (permalink / raw)
To: ceph-devel
just saw qemu 0.13 released, but without a change log. wondering if
RBD patch included in this release. since Ceph website said "The
qemu/kvm patches will likely be included in the next major qemu
release."
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Oct 19
From: Alexander Graf @ 2010-10-20 8:21 UTC (permalink / raw)
To: Chris Wright; +Cc: kvm, qemu-devel
In-Reply-To: <20101019151441.GA24673@x200.localdomain>
On 19.10.2010, at 17:14, Chris Wright wrote:
> 0.13.X -stable
> - Anthony will send note to qemu-devel on this
> - move 0.13.X -stable to a separate tree
> - driven independently of main qemu tree
> - challenge is always in the porting and testing of backported fixes
> - looking for volunteers
>
> 0.14
> - would like to do this before end of the year
> - 0.13 forked off a while back (~July),
> - 0.14 features
> - QMP stabilized
> - 0.13.0 -> 0.14 QMP
> - hard attempt not to break compatibility
> - new commands, rework, async, human monitor passthrough
> - goal getting to libvirt not needing human monitor at all
> - QMP KVM autotest test suite submitted
> - in-kernel apic, tpr patching still outstanding
> - QED coroutine concurrency
Would it be realistic to declare deprecating the qemu-kvm fork for 0.14 as goal?
> Live snapshots
> - merge snapshot?
> - already supported, question about mgmt of snapshot chain
> - integrate with fsfreeze (and windows alternative)
>
> Guest Agent
> - have one coming RSN (poke Anthony for details)
Would there be a chance to have a single agent for everyone, so that we actually form a Qemu agent instead of a dozen individual ones? I'm mainly thinking Spice here.
Alex
^ permalink raw reply
* Re: New issue with git fetcher?
From: Tian, Kevin @ 2010-10-20 8:20 UTC (permalink / raw)
To: Richard Purdie, Garman, Scott A; +Cc: yocto@yoctoproject.org
In-Reply-To: <1287505758.1720.1673.camel@rex>
>From: Richard Purdie
>Sent: Wednesday, October 20, 2010 12:29 AM
>
>On Tue, 2010-10-19 at 13:55 +0100, Richard Purdie wrote:
>> I've pushed some more invasive changes to the fetcher in the Poky master
>> branch. I'd appreciate the teams help in finding out if these work or
>> not, with both existing builds and with totally fresh from scratch
>> builds.
>>
>> If they prove not to have major issues we're likely to merge these into
>> the release branch as what is there is going to bite people and look
>> rather bad.
>
>There were some issues that Tom and Joshua were seeing which I debugged
>and found that we weren't adding in new branches in the fetching code.
>
>I was able to reproduce and then have added a patch to the git fetcher
>which ensures these things are cloned correctly and any new branches are
>created. I talked with Bruce to confirm my diagnosis and the solution.
>
>This fix makes an awful lot of sense and explains various issues we've
>been chasing for a while with the fetcher bugs so I'm very pleased to
>have this fix checked in.
>
>Could people continue to test the code and report any problems...
>
I tried "bitbake poky-image-sdk -c fetchall" both with an existing source directory
and with a fresh new download. Everything works fine.
Thanks
Kevin
^ permalink raw reply
* [U-Boot] [PATCH 0/5] New environment code
From: Wolfgang Denk @ 2010-10-20 8:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201010200408.15020.vapier@gentoo.org>
Dear Mike Frysinger,
In message <201010200408.15020.vapier@gentoo.org> you wrote:
>
> > The following patch series adds some utilities (qsort and hash table
> > based database functions) and uses these to reimplement the code used
> > for the internal handling of environment variables.
>
> seems to break autocompletion CONFIG_AUTO_COMPLETE :(
Yes, this was already noted and discussed before.
I'm still not sure how to (re-) add this optimally.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It became apparent that one reason why the Ice Giants were known as
the Ice Giants was because they were, well, giants. The other was
that they were made of ice. -Terry Pratchett, _Sourcery_
^ permalink raw reply
* Re: [PATCH v5] GPIO: add support for 74x164 serial-in/parallel-out 8-bit shift register
From: Miguel Ojeda @ 2010-10-20 8:17 UTC (permalink / raw)
To: Andrew Morton
Cc: Florian Fainelli, David Brownell, Willy Tarreau, linux-kernel,
Samuel Ortiz, Miguel Gaio, dbrownell, Juhos Gabor
In-Reply-To: <AANLkTi==o4dJSfuC5HT64ZWb0f3ZMG-hjTiK8Sh9UYoR@mail.gmail.com>
On Wed, Oct 20, 2010 at 9:52 AM, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
> On Wed, Oct 20, 2010 at 1:00 AM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
>> On Tue, 19 Oct 2010 09:26:42 +0200
>> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>>
>>> On Mon, Oct 18, 2010 at 9:35 PM, Florian Fainelli <florian@openwrt.org> wrote:
>>> > From: Miguel Gaio <miguel.gaio@efixo.com>
>>> >
>>> > This patch adds support for generic 74x164 serial-in/parallel-out 8-bits
>>> > shift register. This driver can be used as a GPIO output expander.
>>> >
>>> ...
>>> > +struct gen_74x164_chip {
>>> > + struct spi_device *spi;
>>> > + struct gpio_chip gpio_chip;
>>> > + struct mutex lock;
>>> > + u8 port_config;
>>> > +};
>>> ...
>>> > +static void gen_74x164_set_value(struct gpio_chip *gc,
>>> > + unsigned offset, int val)
>>> > +{
>>> > + struct gen_74x164_chip *chip = gpio_to_chip(gc);
>>> > + bool refresh;
>>> > +
>>> > + mutex_lock(&chip->lock);
>>> > + if (val)
>>> > + chip->port_config |= (1 << offset);
>>> > + else
>>> > + chip->port_config &= ~(1 << offset);
>>>
>>> set_bit(), clear_bit() ?
>>
>> They're only to be used on `unsigned long' types, and `port_config' is
>> u8.
>>
>
> Right as always! Maybe BIT()? Don't we have a {SET,CLEAR}_BIT()-like
> macros somewhere?
>
> #define SET_BIT(var,nr) (var) |= BIT((nr))
> #define CLEAR_BIT(var,nr) (var) &= ~BIT((nr))
> #define PUT_BIT(var,nr,value) do { \
> if ((value)) \
> SET_BIT((var), (nr)); \
> else \
> CLEAR_BIT((var), (nr)); \
> } while(0)
>
> May I make a patch and try to see who could use it? I suppose a
> Coccinelle's semantic patch would be great here.
>
Well, after trying a few minutes spatch for my first time it has
already found a lot of places where the macros could be applied. I
will prepare a patch.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/3] Introduce threadlets
From: Stefan Hajnoczi @ 2010-10-20 8:16 UTC (permalink / raw)
To: Arun R Bharadwaj; +Cc: qemu-devel
In-Reply-To: <20101019174245.16514.14542.stgit@localhost6.localdomain6>
On Tue, Oct 19, 2010 at 6:42 PM, Arun R Bharadwaj
<arun@linux.vnet.ibm.com> wrote:
> +/**
> + * cancel_threadletwork_on_queue: Cancel a task queued on a Queue.
> + * @queue: The queue containing the task to be cancelled.
> + * @work: Contains the information of the task that needs to be cancelled.
> + *
> + * Returns: 0 if the task is successfully cancelled.
> + * 1 otherwise.
The return value comment doesn't correspond to how I read the code.
If the work was cancelled the code returns 1. Otherwise it returns 0.
> + */
> +int cancel_threadletwork_on_queue(ThreadletQueue *queue, ThreadletWork *work)
> +{
> + ThreadletWork *ret_work;
> + int ret = 0;
> +
> + qemu_mutex_lock(&(queue->lock));
> + QTAILQ_FOREACH(ret_work, &(queue->request_list), node) {
> + if (ret_work == work) {
> + QTAILQ_REMOVE(&(queue->request_list), ret_work, node);
> + ret = 1;
> + break;
> + }
> + }
> + qemu_mutex_unlock(&(queue->lock));
> +
> + return ret;
> +}
Stefan
^ permalink raw reply
* [patch 3/9] imx51: enhance/fix iomux configuration
From: Arnaud Patard (Rtp) @ 2010-10-20 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101019210422.GZ28242@pengutronix.de>
Sascha Hauer <s.hauer@pengutronix.de> writes:
Hi,
>
> Some of these are used in 2/9, right? So this patch should be before
> 2/9.
oh, yeah. sorry. I've reorder the series for some tests and manage to
get this wrong. Will fix.
Arnaud
^ permalink raw reply
* [U-Boot] ARM: Warning with current master
From: Wolfgang Denk @ 2010-10-20 8:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4CBE98A1.9020301@arcor.de>
Dear =?ISO-8859-15?Q?Matthias_Wei=DFer?=,
In message <4CBE98A1.9020301@arcor.de> you wrote:
>
> after pulling the latest changes I get the following warning during
> linking of arm boards (I tested jadecpu and tx25).
>
> arm-unknown-eabi-ld: warning: creating a DT_TEXTREL in object.
Which exact tool chain is this?
> Must have something to do with the latest ELF based relocation changes
> but I am not an expert in these tool chain related issues to dig a bit
> deeper into this issue.
Building with ELDK 4.2 works fine:
-> ./MAKEALL jadecpu tx25
Configuring for jadecpu board...
text data bss dec hex filename
197763 19360 266416 483539 760d3 ./u-boot
Configuring for tx25 board...
text data bss dec hex filename
158718 8668 37120 204506 31eda ./u-boot
--------------------- SUMMARY ----------------------------
Boards compiled: 2
----------------------------------------------------------
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The world is no nursery. - Sigmund Freud
^ permalink raw reply
* [patch 9/9] efikamx: add reset
From: Arnaud Patard (Rtp) @ 2010-10-20 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <636242.78053.qm@web51007.mail.re2.yahoo.com>
Fabio Estevam <fabioestevam@yahoo.com> writes:
> Hi Arnaud,
Hi,
>
> --- On Tue, 10/19/10, Arnaud Patard <arnaud.patard@rtp-net.org> wrote:
> ...
>> +void mx51_efikamx_reset(int mode, const char *cmd)
>> +{
>> +??? if (system_rev == 0x11)
>> +??? ???
>
> Couldn't it be void mx51_efikamx_reset(void) instead?
>
> 'mode' and 'cmd' are not being used.
I took the same prototype as arch_reset() but I can remove it (and will
do).
Thanks,
Arnaud
^ permalink raw reply
* [patch 1/9] efikamx: read board id
From: Arnaud Patard (Rtp) @ 2010-10-20 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101020075446.GG2562@matterhorn.lan>
Amit Kucheria <amit.kucheria@linaro.org> writes:
> On 10 Oct 19, Matt Sealey wrote:
>> On Tue, Oct 19, 2010 at 4:15 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> > On Tue, Oct 19, 2010 at 10:42:54PM +0200, Arnaud Patard wrote:
>> >> read board id value from the GPIO3_16/17/11
>> >>
>> >>
>> >> +/* ? PCBID2 ?PCBID1 PCBID0 ?STATE
>> >> + ? ? 1 ? ? ? 1 ? ? ?1 ? ?ER1:rev1.1
>> >> + ? ? 1 ? ? ? 1 ? ? ?0 ? ?ER2:rev1.2
>> >> + ? ? 1 ? ? ? 0 ? ? ?1 ? ?ER3:rev1.3
>> >> + ? ? 1 ? ? ? 0 ? ? ?0 ? ?ER4:rev1.4
>> >> +*/
>> >> +static void __init mx51_efikamx_board_id(void)
>> >> +{
>> >> + ? ? int id;
>> >> +
>> >> + ? ? /* things are taking time to settle */
>> >> + ? ? msleep(500);
>> >
>> > Is it really necessary to delay the boot process such a long time?
>>
>> Yes. On older boards the PCBID pins are pulled high by IOMUX settings
>> (a pulldown on the board on newer revisions will keep it down). IOMUX
>> and GPIO stuff takes a little while to settle in, so if you do it
>> immediately, it will return some freakish values based on random GPIO
>> setup (it may be high, low, or none of the above at any point before
>> the pad setting kicks in).
>
> Then perhaps do this only for the older boards?
How can you detect older boards without looking at board id pins ? :)
>
> So by default there is no delay, but when a (new) config option is enabled,
> delay boot.
I don't think it's a good idea. This would mean that the same kernel
can't run on old and new boards. Also, there's no way to easily know
which board you have (I don't consider opening the box is an easy way)
so it's likely that someone will get this wrong sooner or later.
Arnaud
^ permalink raw reply
* [U-Boot] Observation: rebasing against current master increases code size by 1.8k
From: Mike Frysinger @ 2010-10-20 8:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4CBEA212.6030502@emk-elektronik.de>
On Wednesday, October 20, 2010 04:02:26 Reinhard Meyer wrote:
> Mike Frysinger wrote:
> > On Wednesday, October 20, 2010 03:30:33 Reinhard Meyer wrote:
> >> Just an observation on my AT91SAM9XE based board:
> >>
> >> based on yesterday's master + arm elf relocations +
> >> my (then not mainstreamed) patches: 256288 bytes
> >>
> >> based on current master: 258020 bytes
> >>
> >> Otherwise it compiles without warnings and runs fine.
> >> Just some non-reloc-related patches have increased
> >> code size by that amount - finding out which are to
> >> "blame" is probably not worth the effort.
> >
> > look at the env change ?
> >
> > ea882baf9c17cd142c99e3ff640d3ab01daa5cec
>
> That (old) commit was in mainstream already. Related fixups
> do not matter for my board since env_mmc ist not included
> and ARM_RELOC_FIXUP_WORKS is set.
it isnt old. it was *committed* a while ago, but wasnt *merged* into mainline
until after the latest release (v2010.09). so it's new to the master branch.
that's the only common code change that pops into my mind after the v2010.09
release was made.
-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/20101020/64149e48/attachment.pgp
^ permalink raw reply
* Re: Interesting possible XFS crash condition
From: Michael Monnerie @ 2010-10-20 8:12 UTC (permalink / raw)
To: xfs; +Cc: Shawn Usry
In-Reply-To: <4CBE887F.6020506@dolphinlogic.com>
[-- Attachment #1.1: Type: Text/Plain, Size: 1145 bytes --]
On Mittwoch, 20. Oktober 2010 Shawn Usry wrote:
> Limited information shown in what I've been able to capture in the
> kernel crash. Nothing really specific or repeatable (different
> message each time) - some instances to the term "atomic" and "xfs"
> - other times "irq" related
I'm not a dev, but I'd say a kernel crash dump would be very helpful.
Can't you at least take pictures of the messages?
I've never read about such XFS errors, maybe you should
1) xfs_metadump
2) xfs_mdrestore (into a file)
3) mount that file
and try to access files there. If this also crashes, it will really be
XFS related.
Also, can you try putting the hard disks onto another system, possibly
with changing the RAID controller? It might be a hardware error.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31
****** Radiointerview zum Thema Spam ******
http://www.it-podcast.at/archiv.html#podcast-100716
// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [Lustre-devel] Queries regarding LDLM_ENQUEUE
From: bzzz.tomas at gmail.com @ 2010-10-20 8:11 UTC (permalink / raw)
To: lustre-devel
In-Reply-To: <EF473480-D749-4AF4-B843-697A2EDE10A2@oracle.com>
On 10/20/10 11:55 AM, Andreas Dilger wrote:
> There is a separate proposal that has been underway in the Linux community for some time, to allow a user process to get a file handle (i.e. binary blob returned from a new name_to_handle() syscall) from the kernel for a given pathname, and then later use that file handle in another process to open a file descriptor without re-traversing the path.
>
> I've been thinking this would be very useful for Lustre (and MPI in general), and have tried to steer the Linux development in a direction that would allow this to happen. Is this in line with what you are investigating?
with FIDs is quite possible and even safe if application can learn it
(using xattr_get or ioctl). then it should be trivial to export FID
namespace on MDS via special .lustre-fids directory?
another idea was to do whole path traversal on MDS within a single RPC.
bug that'd require amount of changes to llite and/or VFS and keep MDS
a bottleneck.
thanks, z
^ permalink raw reply
* Re: [PATCH 13/15] initscripts-shr: add mountdevtmpfs init script for palmpre machine
From: Klaus 'mrmoku' Kurzmann @ 2010-10-20 8:04 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1287427884-1517-14-git-send-email-morphis@gravedo.de>
Acked-by: Klaus Kurzmann <mok@fluxnetz.de>
> On the palmpre machine we are currently come into the SHR rootfs through
> mounting it from /boot and switch the rootfs via pivot_root. So we can't
> automatically mount devtmpfs on /dev. Instead we do this right after SHR
> begins to boot and before any other filesystem is mounted on the new
> rootfs.
>
> Signed-off-by: Simon Busch <morphis@gravedo.de>
> ---
> .../shr/initscripts-shr/palmpre/mountdevtmpfs.sh | 9 +++++++++
> recipes/shr/initscripts-shr_0.0.1.bb | 9 ++++++++-
> 2 files changed, 17 insertions(+), 1 deletions(-)
> create mode 100644 recipes/shr/initscripts-shr/palmpre/mountdevtmpfs.sh
>
> diff --git a/recipes/shr/initscripts-shr/palmpre/mountdevtmpfs.sh
> b/recipes/shr/initscripts-shr/palmpre/mountdevtmpfs.sh new file mode
> 100644
> index 0000000..dbeb7c0
> --- /dev/null
> +++ b/recipes/shr/initscripts-shr/palmpre/mountdevtmpfs.sh
> @@ -0,0 +1,9 @@
> +#!/bin/sh
> +
> +mount -t devtmpfs -o mode=0755,nr_inodes=0 devtmpfs /dev
> +
> +# Create additional nodes which devtmpfs does not provide
> +test -c /dev/fd || ln -s /proc/self/fd /dev/fd
> +test -c /dev/stdin || ln -s fd/0 /dev/stdin
> +test -c /dev/stdout || ln -s fd/1 /dev/stdout
> +test -c /dev/stderr || ln -s fd/2 /dev/stderr
> diff --git a/recipes/shr/initscripts-shr_0.0.1.bb
> b/recipes/shr/initscripts-shr_0.0.1.bb index e4dc736..ce76fbd 100644
> --- a/recipes/shr/initscripts-shr_0.0.1.bb
> +++ b/recipes/shr/initscripts-shr_0.0.1.bb
> @@ -5,7 +5,7 @@ DEPENDS = ""
> RDEPENDS_${PN} = "procps"
> LICENSE = "GPL"
> PV = "0.0.1"
> -PR = "r20"
> +PR = "r21"
>
> RCONFLICTS_${PN} = "initscripts"
>
> @@ -32,6 +32,8 @@ SRC_URI = "file://alignment.sh \
> file://umountnfs.sh \
> "
>
> +SRC_URI_append_palmpre = " file://mountdevtmpfs.sh"
> +
> inherit base
>
> do_install () {
> @@ -74,6 +76,11 @@ do_install () {
> install -m 0755 ${WORKDIR}/umountfs ${D}${sysconfdir}/init.d
> install -m 0755 ${WORKDIR}/umountnfs.sh ${D}${sysconfdir}/init.d
>
> + if [ "${MACHINE}" == "palmpre" ]; then
> + install -m 0755 ${WORKDIR}/mountdevtmpfs.sh ${D}${sysconfdir}/init.d
> + ln -sf ../init.d/mountdevtmpfs.sh
> ${D}${sysconfdir}/rcS.d/S03mountdevtmpfs.sh + fi
> +
> #
> # Create runlevel links
> #
--
Klaus 'mrmoku' Kurzmann
^ permalink raw reply
* [U-Boot] Notification in Malloc
From: Kostaras Nikolaos @ 2010-10-20 8:08 UTC (permalink / raw)
To: u-boot
Hi,
During some tests with the u-boot-2010.09 source release, I discovered that
when invoking malloc with size 0, the code proceeds and corrupts the malloc
structures, thus totally breaking the malloc invocations from then on
(malloc
will always fail after that). The cause of my problem was a burned flash
chip,
that returned 0 in regions, in the "cfi_mtd_set_erasesize" call. My
solution was
to modify the first check of malloc, in order not to freeze when there
was an
error on the requested space. New condition includes the equal as well
as the less:
if ((long)bytes <= 0) return 0;
This seems to fix the problems, after the malloc invocation with size 0.
If there is
another way to deal with this, plz keep me posted.
Thanks,
Nik
^ permalink raw reply
* [U-Boot] [PATCH 0/5] New environment code
From: Mike Frysinger @ 2010-10-20 8:08 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1279395948-25864-1-git-send-email-wd@denx.de>
On Saturday, July 17, 2010 15:45:43 Wolfgang Denk wrote:
> The following patch series adds some utilities (qsort and hash table
> based database functions) and uses these to reimplement the code used
> for the internal handling of environment variables.
seems to break autocompletion CONFIG_AUTO_COMPLETE :(
if i checkout the previous commit (0fe247b973d9b8f7e2c04cc159fcdd2e64591e55),
things work fine. but checking out the env change and it no longer works.
-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/20101020/efa120a3/attachment.pgp
^ permalink raw reply
* snd-usb-audio for Radikal Technologies SAC-2K
From: Raphaël Doursenaud @ 2010-10-20 8:04 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm working on getting the usb part of this very nice control surface to
work with alsa. I sniffed the usb traffic of the windows driver then
browsed the snd-usb-audio source code for clues.
I managed to get it partially working using a modified QUIRK_MIDI_EMAGIC
since the protocols are fairly similar (at least the 0xF5 port switching
part).
Please find attached the patch I came up to.
I have a few problems and dark areas I hope you'll be able to light up a
little :
First, I more or less get the picture of what the code is doing but
there's one part I fiddled with that I don't understand fully. What are
the .out_cables and .in_cables bitmasks doing besides defining the
number of ports ?
Next, the input part seem to work flawlessly on all ports, but I have
what seems to be a buffer overflow on the device when outputting midi
data. Comparing the windows and linux usb traffic, something obvious
shows up : the windows driver seem to be waiting for the device's
acknowledgment after each sent byte before sending the next one while
the snd-usb-audio module sends a bunch of bytes at once that ends up
confusing the device _and_ module. How can I make it behave like the
windows driver ?
I have traffic and error logs available if needed.
Thanks.
- --
Raphaël Doursenaud
http://raphael.doursenaud.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAky+oqQACgkQaZKmNAdXaVUopgCgifnK+eSsCNpR5rx21iUqmXBQ
wJIAoJlt4h7Tp8tYYSbg9ZfLekE1QQfL
=d7vi
-----END PGP SIGNATURE-----
[-- Attachment #2: sac-2K.patch --]
[-- Type: text/plain, Size: 6950 bytes --]
diff -Nurp linux-2.6.36-rc6/sound/usb/midi.c linux-2.6.36-rc6.patched/sound/usb/midi.c
--- linux-2.6.36-rc6/sound/usb/midi.c 2010-09-29 03:01:22.000000000 +0200
+++ linux-2.6.36-rc6.patched/sound/usb/midi.c 2010-10-18 00:16:43.146000091 +0200
@@ -59,7 +59,7 @@
/*
* define this to log all USB packets
*/
-/* #define DUMP_PACKETS */
+#define DUMP_PACKETS
/*
* how long to wait after some USB errors, so that khubd can disconnect() us
@@ -987,6 +987,108 @@ static struct usb_protocol_ops snd_usbmi
.finish_out_endpoint = snd_usbmidi_emagic_finish_out,
};
+/*
+ * Radikal USB MIDI protocol: raw MIDI with "F5 xx" port switching and "FF" padded data.
+ */
+
+static void snd_usbmidi_radikal_input(struct snd_usb_midi_in_endpoint* ep,
+ uint8_t* buffer, int buffer_length)
+{
+ int i;
+
+ /* 0xFF indicates end of valid data */
+ for (i = 0; i < buffer_length; ++i)
+ if (buffer[i] == 0xff) {
+ buffer_length = i;
+ break;
+ }
+
+ /* handle 0xF5 at end of last buffer */
+ if (ep->seen_f5)
+ goto switch_port;
+
+ while (buffer_length > 0) {
+ /* determine size of data until next 0xF5 */
+ for (i = 0; i < buffer_length; ++i)
+ if (buffer[i] == 0xf5)
+ break;
+ snd_usbmidi_input_data(ep, ep->current_port, buffer, i);
+ buffer += i;
+ buffer_length -= i;
+
+ if (buffer_length <= 0)
+ break;
+ ep->seen_f5 = 1;
+ ++buffer;
+ --buffer_length;
+
+ switch_port:
+ if (buffer_length <= 0)
+ break;
+ if (buffer[0] < 0x80) {
+ ep->current_port = (buffer[0] - 1) & 15;
+ ++buffer;
+ --buffer_length;
+ }
+ ep->seen_f5 = 0;
+ }
+}
+
+static void snd_usbmidi_radikal_output(struct snd_usb_midi_out_endpoint* ep,
+ struct urb *urb)
+{
+ int port0 = ep->current_port;
+ uint8_t* buf = urb->transfer_buffer;
+ int buf_free = ep->max_transfer;
+ int length, i;
+
+ for (i = 0; i < 0x10; ++i) {
+ /* round-robin, starting at the last current port */
+ int portnum = (port0 + i) & 15;
+ struct usbmidi_out_port* port = &ep->ports[portnum];
+
+ if (!port->active)
+ continue;
+ if (snd_rawmidi_transmit_peek(port->substream, buf, 1) != 1) {
+ port->active = 0;
+ continue;
+ }
+
+ if (portnum != ep->current_port) {
+ if (buf_free < 2)
+ break;
+ ep->current_port = portnum;
+ buf[0] = 0xf5;
+ buf[1] = (portnum + 1) & 15;
+ buf += 2;
+ buf_free -= 2;
+ }
+
+ if (buf_free < 1)
+ break;
+ length = snd_rawmidi_transmit(port->substream, buf, buf_free);
+ if (length > 0) {
+ buf += length;
+ buf_free -= length;
+ if (buf_free < 1)
+ break;
+ }
+ }
+
+ /* pad remaining bytes with 0xFF */
+ while (buf_free < ep->max_transfer && buf_free > 0) {
+ *buf = 0xff;
+ ++buf;
+ --buf_free;
+ }
+ urb->transfer_buffer_length = ep->max_transfer - buf_free;
+}
+
+static struct usb_protocol_ops snd_usbmidi_radikal_ops = {
+ .input = snd_usbmidi_radikal_input,
+ .output = snd_usbmidi_radikal_output,
+};
+
static void update_roland_altsetting(struct snd_usb_midi* umidi)
{
@@ -1533,6 +1635,13 @@ static struct port_info {
EXTERNAL_PORT(0x086a, 0x0001, 8, "%s Broadcast"),
EXTERNAL_PORT(0x086a, 0x0002, 8, "%s Broadcast"),
EXTERNAL_PORT(0x086a, 0x0003, 4, "%s Broadcast"),
+ /* Radikal Technologies */
+ CONTROL_PORT(0x0a35, 0x002a, 0, "%s Control"),
+ EXTERNAL_PORT(0x0a35, 0x002a, 1, "%s MIDI"),
+ CONTROL_PORT(0x0a35, 0x002a, 2, "%s Instrument 3"),
+ CONTROL_PORT(0x0a35, 0x002a, 3, "%s Instrument 4"),
+ CONTROL_PORT(0x0a35, 0x002a, 4, "%s Instrument 5"),
+ CONTROL_PORT(0x0a35, 0x002a, 5, "%s Config"),
/* Akai MPD16 */
CONTROL_PORT(0x09e8, 0x0062, 0, "%s Control"),
PORT_INFO(0x09e8, 0x0062, 1, "%s MIDI", 0,
@@ -2134,6 +2243,12 @@ int snd_usbmidi_create(struct snd_card *
memcpy(&endpoints[0], quirk->data,
sizeof(struct snd_usb_midi_endpoint_info));
err = snd_usbmidi_detect_endpoints(umidi, &endpoints[0], 1);
+ break;
+ case QUIRK_MIDI_RADIKAL:
+ umidi->usb_protocol_ops = &snd_usbmidi_radikal_ops;
+ memcpy(&endpoints[0], quirk->data,
+ sizeof(struct snd_usb_midi_endpoint_info));
+ err = snd_usbmidi_detect_endpoints(umidi, &endpoints[0], 1);
break;
case QUIRK_MIDI_CME:
umidi->usb_protocol_ops = &snd_usbmidi_cme_ops;
diff -Nurp linux-2.6.36-rc6/sound/usb/midi.h linux-2.6.36-rc6.patched/sound/usb/midi.h
--- linux-2.6.36-rc6/sound/usb/midi.h 2010-09-29 03:01:22.000000000 +0200
+++ linux-2.6.36-rc6.patched/sound/usb/midi.h 2010-10-17 03:54:25.066000034 +0200
@@ -35,6 +35,9 @@ struct snd_usb_midi_endpoint_info {
/* for QUIRK_MIDI_EMAGIC, data points to a snd_usb_midi_endpoint_info
* structure (out_cables and in_cables only) */
+/* for QUIRK_MIDI_RADIKAL, data points to a snd_usb_midi_endpoint_info
+ * structure (out_cables and in_cables only) */
+
/* for QUIRK_MIDI_CME, data is NULL */
/* for QUIRK_MIDI_AKAI, data is NULL */
diff -Nurp linux-2.6.36-rc6/sound/usb/quirks-table.h linux-2.6.36-rc6.patched/sound/usb/quirks-table.h
--- linux-2.6.36-rc6/sound/usb/quirks-table.h 2010-09-29 03:01:22.000000000 +0200
+++ linux-2.6.36-rc6.patched/sound/usb/quirks-table.h 2010-10-17 04:39:49.509000034 +0200
@@ -1972,6 +1972,37 @@ YAMAHA_DEVICE(0x7010, "UB99"),
}
}
},
+/* Radikal Technologies devices */
+{
+ USB_DEVICE(0x0a35, 0x002a),
+ .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
+ .vendor_name = "Radikal Technologies",
+ .product_name = "SAC-2K",
+ .ifnum = QUIRK_ANY_INTERFACE,
+ .type = QUIRK_COMPOSITE,
+ .data = (const struct snd_usb_audio_quirk[]) {
+ {
+ .ifnum = 0,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 1,
+ .type = QUIRK_IGNORE_INTERFACE
+ },
+ {
+ .ifnum = 2,
+ .type = QUIRK_MIDI_RADIKAL,
+ .data = & (const struct snd_usb_midi_endpoint_info) {
+ .out_cables = 0x801f,
+ .in_cables = 0x801f
+ }
+ },
+ {
+ .ifnum = -1
+ }
+ }
+ }
+},
/* AKAI devices */
{
diff -Nurp linux-2.6.36-rc6/sound/usb/quirks.c linux-2.6.36-rc6.patched/sound/usb/quirks.c
--- linux-2.6.36-rc6/sound/usb/quirks.c 2010-09-29 03:01:22.000000000 +0200
+++ linux-2.6.36-rc6.patched/sound/usb/quirks.c 2010-10-17 03:54:28.202000034 +0200
@@ -289,6 +289,7 @@ int snd_usb_create_quirk(struct snd_usb_
[QUIRK_MIDI_NOVATION] = create_any_midi_quirk,
[QUIRK_MIDI_FASTLANE] = create_any_midi_quirk,
[QUIRK_MIDI_EMAGIC] = create_any_midi_quirk,
+ [QUIRK_MIDI_RADIKAL] = create_any_midi_quirk,
[QUIRK_MIDI_CME] = create_any_midi_quirk,
[QUIRK_MIDI_AKAI] = create_any_midi_quirk,
[QUIRK_AUDIO_STANDARD_INTERFACE] = create_standard_audio_quirk,
diff -Nurp linux-2.6.36-rc6/sound/usb/usbaudio.h linux-2.6.36-rc6.patched/sound/usb/usbaudio.h
--- linux-2.6.36-rc6/sound/usb/usbaudio.h 2010-09-29 03:01:22.000000000 +0200
+++ linux-2.6.36-rc6.patched/sound/usb/usbaudio.h 2010-10-17 03:54:37.210000034 +0200
@@ -72,6 +72,7 @@ enum quirk_type {
QUIRK_MIDI_NOVATION,
QUIRK_MIDI_FASTLANE,
QUIRK_MIDI_EMAGIC,
+ QUIRK_MIDI_RADIKAL,
QUIRK_MIDI_CME,
QUIRK_MIDI_AKAI,
QUIRK_MIDI_US122L,
[-- Attachment #3: rdoursenaud.vcf --]
[-- Type: text/x-vcard, Size: 200 bytes --]
begin:vcard
fn;quoted-printable:Rapha=C3=ABl Doursenaud
n;quoted-printable:Doursenaud;Rapha=C3=ABl
email;internet:raphael@doursenaud.fr
url:http://raphael.doursenaud.fr
version:2.1
end:vcard
[-- Attachment #4: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* PFIFO_CACHE_ERROR
From: Grzesiek Sójka @ 2010-10-20 8:04 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Hi there!
I'm using GeForce FX5200 and today I installed
Mesa-dri-driver-nouveau-7.9-3.i686. Now when I shut down the Xserver I
get lots of PFIFO_CACHE_ERROR. Is it something serious or a kind of a
versions problem? I'm using very recent nouveau kernel and
xorg-driver-video-nouveau-0.0.16-0.20100921.1.i686.
This is the dmesg
[ 778.944749] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/2
Mthd 0x0000 Data 0x88000001
[ 778.944828] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/2
Mthd 0x0180 Data 0x88000000
[ 778.944877] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/3
Mthd 0x0000 Data 0x88000002
[ 778.944909] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/3
Mthd 0x0184 Data 0xbeef0201
[ 778.944933] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/3
Mthd 0x0188 Data 0xbeef0201
[ 778.944998] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/4
Mthd 0x0000 Data 0x88000003
[ 778.945040] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/4
Mthd 0x0180 Data 0x88000000
[ 778.945092] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/4
Mthd 0x019c Data 0x88000002
[ 778.945114] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/4
Mthd 0x02fc Data 0x00000003
[ 778.945166] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/5
Mthd 0x0000 Data 0x88000004
[ 778.945212] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/5
Mthd 0x0180 Data 0x88000000
[ 778.945263] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/5
Mthd 0x0198 Data 0x88000002
[ 778.945286] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/5
Mthd 0x02fc Data 0x00000003
[ 778.945314] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/5
Mthd 0x0304 Data 0x00000002
[ 778.945360] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/6
Mthd 0x0000 Data 0x88000005
[ 778.945412] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0000 Data 0x88000006
[ 778.945458] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0000 Data 0xbeef3097
[ 778.945509] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0180 Data 0xbeef0301
[ 778.945532] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0184 Data 0xbeef0201
[ 778.945560] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0188 Data 0xbeef0202
[ 778.945583] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x018c Data 0xbeef0201
[ 778.945611] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0194 Data 0xbeef0201
[ 778.945634] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0198 Data 0xbeef0201
[ 778.945663] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x019c Data 0xbeef0201
[ 778.945685] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x01a0 Data 0xbeef0202
[ 778.945737] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x01a4 Data 0x00000000
[ 778.945782] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x01a8 Data 0xbeef0302
[ 778.945811] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x01ac Data 0xbeef0201
[ 778.945833] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x01b0 Data 0xbeef0201
[ 778.945862] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02c8 Data 0x00000000
[ 778.945884] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02cc Data 0x00000000
[ 778.945913] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02d0 Data 0x00000000
[ 778.945935] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02d4 Data 0x00000000
[ 778.945964] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02d8 Data 0x00000000
[ 778.945986] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02dc Data 0x00000000
[ 778.946015] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02e0 Data 0x00000000
[ 778.946037] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02e4 Data 0x00000000
[ 778.946067] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02e8 Data 0x00000000
[ 778.946089] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02ec Data 0x00000000
[ 778.946118] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02f0 Data 0x00000000
[ 778.946140] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02f4 Data 0x00000000
[ 778.946169] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02f8 Data 0x00000000
[ 778.946191] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x02fc Data 0x00000000
[ 778.946221] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0220 Data 0x00000001
[ 778.946242] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x03b0 Data 0x00100000
[ 778.946272] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1454 Data 0x00000000
[ 778.946293] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1d80 Data 0x00000003
[ 778.946323] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1450 Data 0x00030004
[ 778.946345] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1e98 Data 0x00000000
[ 778.946374] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x17e0 Data 0x00000000
[ 778.946396] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x17e4 Data 0x00000000
[ 778.946425] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x17e8 Data 0x3f800000
[ 778.946446] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f80 Data 0x00000000
[ 778.946476] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f84 Data 0x00000000
[ 778.946498] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f88 Data 0x00000000
[ 778.946527] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f8c Data 0x00000000
[ 778.946549] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f90 Data 0x00000000
[ 778.946579] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f94 Data 0x00000000
[ 778.946622] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f98 Data 0x00000000
[ 778.946646] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1f9c Data 0x00000000
[ 778.946672] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fa0 Data 0x0000ffff
[ 778.946696] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fa4 Data 0x00000000
[ 778.946718] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fa8 Data 0x00000000
[ 778.946744] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fac Data 0x00000000
[ 778.946769] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fb0 Data 0x00000000
[ 778.946799] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fb4 Data 0x00000000
[ 778.946820] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fb8 Data 0x00000000
[ 778.946848] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1fbc Data 0x00000000
[ 778.946872] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0120 Data 0x00000000
[ 778.946899] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0124 Data 0x00000001
[ 778.946923] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0128 Data 0x00000002
[ 778.946950] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1d88 Data 0x00001200
[ 778.946974] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x08fc Data 0x00000000
[ 778.947001] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0394 Data 0x00000000
[ 778.947025] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x0398 Data 0x3f800000
[ 778.947052] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1d7c Data 0xffff0000
[ 778.947075] [drm] nouveau 0000:01:05.0: PFIFO_CACHE_ERROR - Ch 2/7
Mthd 0x1e94 Data 0x00000013
^ permalink raw reply
* RE: [PATCH/RFC v3 0/7] Videobuf2 framework
From: Hans Verkuil @ 2010-10-20 8:02 UTC (permalink / raw)
To: Marek Szyprowski; +Cc: linux-media, pawel, kyungmin.park, mchehab
In-Reply-To: <004901cb702a$10a69100$31f3b300$%szyprowski@samsung.com>
> Hello,
>
> On Wednesday, October 20, 2010 9:15 AM wrote:
>
>> On Wednesday, October 20, 2010 08:41:06 Marek Szyprowski wrote:
>> > Hello,
>> >
>> > As I promissed I continue the development of the VideoBuf2 at Samsung
>> > until Pawel finds some spare time to help us. This is a third version
>> of
>> > the framework. Besides the minor bugfixes here and there I've added a
>> > complete read() callback emulator. This emulator provides 2 types of
>> > read() operation - 'streaming' and 'one shot'. It is suitable to
>> replace
>> > both videobuf_read_stream() and videobuf_read_one() methods from the
>> old
>> > videobuf.
>>
>> One thing I never understood: what is the point of supporting 'one shot'
>> read
>> mode? Why not support just streaming? Does anyone know?
>
> I can imagine that some simple cameras that capture pure JPG frames might
> want
> to use 'one shot' mode. This enables easier scripting and things like
> 'cat /dev/video >capture.jpg' working. If you think that 'one shot' mode
> should
> be removed - let me know.
I did a grep for videobuf_read_one in the sources and the only ones that
use it are bttv, saa7134, zr364xx, cx88 and cx23885. AFAIK zr364xx is the
only webcam driver in this set.
Mauro, do you know if there are any guidelines on what drivers are
supposed to use? Right now it seems random as to what drivers use.
The only constant I see is that vbi and compressed video (e.g. mpeg)
streaming is always using read_stream. Raw video seems to depend purely on
what the driver developer chose.
>> Another question: how hard is it to support write mode as well? I think
>> vb2 should support both. I suspect that once we have a read emulator it
>> isn't
>> difficult to make a write emulator too.
>
> Well, that's possible. If you really think that write() emulator is also
> required, I can implement both. This shouldn't be much work.
If it is not much work, then we should do that. The reason write wasn't
present before is simply that few drivers supported output streaming. But
that is changing these days so write support would definitely be a good
idea.
Regards,
Hans
>> A last remark: the locking has changed recently in videobuf due to the
>> work
>> done on eliminating the BKL. It's probably a good idea to incorporate
>> those
>> changes as well in vb2.
>
> Yes, I noticed that there are a lot of changes in for-2.6.37 staging tree,
> I
> will try to get through them and update relevant parts of vb2. The current
> version the vb2 patches is based on 2.6.36-rc8. Kernel tree with vb2
> patches
> (and the required multiplane patches) will be available in a few hours on:
>
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/v4l/vb2
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
>
>
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
^ 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.