http://groups.google.com/group/linux.kernel?hl=en
Today's topics:
* [3/4] SLAB: Separate node initialization into separate function - 2 messages,
1 author
http://groups.google.com/group/linux.kernel/t/4398545cf5dbd1de?hl=en
* mISDN: Add PCI ID for HFC-4S Beronet Card PCIe - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0eecde2dc907f476?hl=en
* LZO irreversible output? - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/d82a693a6af1f717?hl=en
* [0/4] SLAB: Fix a couple of slab memory hotadd issues - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en
* i915 #GP [was: mmotm 2010-02-01-16-25 uploaded] - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/126786bfcb1821da?hl=en
* radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner() - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/b9df83e9a4867ffc?hl=en
* perf/trace/lock optimization/scalability improvements - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/88914be5e6b28d7d?hl=en
* ntp: add hardpps implementation - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0c8202dba360df9c?hl=en
* enhanced reimplemention of the kfifo API - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/21e9c147c9adf137?hl=en
* linux-next: manual merge of the percpu tree with the tip tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/bd0cb958dac89db0?hl=en
* Lokdep messages during resume from disk - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bd5a2b75f7a2251a?hl=en
* viafb: split global index up - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8a931ae929a03977?hl=en
* "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to
hang - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/24244e271ec4cffc?hl=en
* [PATCH] PM: disable nonboot cpus before suspending devices - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/e1dc3aa81b42a297?hl=en
* drivers/video/via: Fix continuation line formats - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d822eba66af5e806?hl=en
* ftrace: unify arch_syscall_addr() implementations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
* reiserfs deadlock - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/8725f85be3262cd6?hl=en
* Improving OOM killer - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
==============================================================================
TOPIC: [3/4] SLAB: Separate node initialization into separate function
http://groups.google.com/group/linux.kernel/t/4398545cf5dbd1de?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 1:40 pm
From: Andi Kleen
No functional changes.
Needed for next patch.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
mm/slab.c | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
Index: linux-2.6.33-rc3-ak/mm/slab.c
===================================================================
--- linux-2.6.33-rc3-ak.orig/mm/slab.c
+++ linux-2.6.33-rc3-ak/mm/slab.c
@@ -1171,19 +1171,9 @@ free_array_cache:
}
}
-static int __cpuinit cpuup_prepare(long cpu)
+static int slab_node_prepare(int node)
{
struct kmem_cache *cachep;
- struct kmem_list3 *l3 = NULL;
- int node = cpu_to_node(cpu);
- const int memsize = sizeof(struct kmem_list3);
-
- /*
- * We need to do this right in the beginning since
- * alloc_arraycache's are going to use this list.
- * kmalloc_node allows us to add the slab to the right
- * kmem_list3 and not this cpu's kmem_list3
- */
list_for_each_entry(cachep, &cache_chain, next) {
/*
@@ -1192,9 +1182,10 @@ static int __cpuinit cpuup_prepare(long
* node has not already allocated this
*/
if (!cachep->nodelists[node]) {
- l3 = kmalloc_node(memsize, GFP_KERNEL, node);
+ struct kmem_list3 *l3;
+ l3 = kmalloc_node(sizeof(struct kmem_list3), GFP_KERNEL, node);
if (!l3)
- goto bad;
+ return -1;
kmem_list3_init(l3);
l3->next_reap = jiffies + REAPTIMEOUT_LIST3 +
((unsigned long)cachep) % REAPTIMEOUT_LIST3;
@@ -1213,6 +1204,23 @@ static int __cpuinit cpuup_prepare(long
cachep->batchcount + cachep->num;
spin_unlock_irq(&cachep->nodelists[node]->list_lock);
}
+ return 0;
+}
+
+static int __cpuinit cpuup_prepare(long cpu)
+{
+ struct kmem_cache *cachep;
+ struct kmem_list3 *l3 = NULL;
+ int node = cpu_to_node(cpu);
+
+ /*
+ * We need to do this right in the beginning since
+ * alloc_arraycache's are going to use this list.
+ * kmalloc_node allows us to add the slab to the right
+ * kmem_list3 and not this cpu's kmem_list3
+ */
+ if (slab_node_prepare(node) < 0)
+ goto bad;
/*
* Now we can go ahead with allocating the shared arrays and
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Wed, Feb 3 2010 1:40 pm
From: Andi Kleen
When fallback_alloc() runs the node of the CPU might not be initialized yet.
Handle this case by allocating in another node.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
mm/slab.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
Index: linux-2.6.33-rc3-ak/mm/slab.c
===================================================================
--- linux-2.6.33-rc3-ak.orig/mm/slab.c
+++ linux-2.6.33-rc3-ak/mm/slab.c
@@ -3210,7 +3210,24 @@ retry:
if (local_flags & __GFP_WAIT)
local_irq_enable();
kmem_flagcheck(cache, flags);
- obj = kmem_getpages(cache, local_flags, numa_node_id());
+
+ /*
+ * Node not set up yet? Try one that the cache has been set up
+ * for.
+ */
+ nid = numa_node_id();
+ if (cache->nodelists[nid] == NULL) {
+ for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
+ nid = zone_to_nid(zone);
+ if (cache->nodelists[nid])
+ break;
+ }
+ if (!cache->nodelists[nid])
+ return NULL;
+ }
+
+
+ obj = kmem_getpages(cache, local_flags, nid);
if (local_flags & __GFP_WAIT)
local_irq_disable();
if (obj) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: mISDN: Add PCI ID for HFC-4S Beronet Card PCIe
http://groups.google.com/group/linux.kernel/t/0eecde2dc907f476?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:40 pm
From: Lars Ellenberg
A few subdevice IDs seem to have been dropped when hfc_multi was
included upstream, just compare the list at
http://www.openvox.cn/viewvc/misdn/trunk/hfc_multi.c?revision=75&view=annotate#l175
with the IDs in drivers/isdn/hardware/mISDN/hfcmulti.c
I only have access to the 0xB762 hardware, so I only added that ID.
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
---
As all our daily phone calls run over these cards, I can confirm this
particular card as working just fine, once the driver feels responsible.
But someone should consider to also include the rest of the IDs,
unless there has been a reason to drop them.
diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c b/drivers/isdn/hardware/mISDN/hfcmulti.c
index 1a1420d..446a29c 100644
--- a/drivers/isdn/hardware/mISDN/hfcmulti.c
+++ b/drivers/isdn/hardware/mISDN/hfcmulti.c
@@ -5265,6 +5265,7 @@ static const struct hm_map hfcm_map[] = {
/*31*/ {VENDOR_CCD, "XHFC-4S Speech Design", 5, 4, 0, 0, 0, 0,
HFC_IO_MODE_EMBSD, XHFC_IRQ},
/*32*/ {VENDOR_JH, "HFC-8S (junghanns)", 8, 8, 1, 0, 0, 0, 0, 0},
+/*33*/ {VENDOR_CCD, "HFC-4S Beronet Card PCIe", 4, 4, 1, 0, 0, 0, 0, 0},
};
#undef H
@@ -5300,6 +5301,8 @@ static struct pci_device_id hfmultipci_ids[] __devinitdata = {
PCI_SUBDEVICE_ID_CCD_OV4S, 0, 0, H(28)}, /* OpenVox 4 */
{ PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFC4S, PCI_VENDOR_ID_CCD,
PCI_SUBDEVICE_ID_CCD_OV2S, 0, 0, H(29)}, /* OpenVox 2 */
+ { PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFC4S, PCI_VENDOR_ID_CCD,
+ PCI_SUBDEVICE_ID_CCD_BN4SE, 0, 0, H(33)}, /* BN4S PCIe */
/* Cards with HFC-8S Chip */
{ PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_HFC8S, PCI_VENDOR_ID_CCD,
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index cca8a04..c171690 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1924,6 +1924,7 @@
#define PCI_SUBDEVICE_ID_CCD_HFC8S 0xB622
#define PCI_DEVICE_ID_CCD_B700 0xb700
#define PCI_DEVICE_ID_CCD_B701 0xb701
+#define PCI_SUBDEVICE_ID_CCD_BN4SE 0xb762
#define PCI_SUBDEVICE_ID_CCD_HFCE1 0xC523
#define PCI_SUBDEVICE_ID_CCD_OV2S 0xE884
#define PCI_SUBDEVICE_ID_CCD_OV4S 0xE888
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: LZO irreversible output?
http://groups.google.com/group/linux.kernel/t/d82a693a6af1f717?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 1:40 pm
From: Nigel Cunningham
Hi all.
(Not sent to LKML yesterday; no reply from linux-crypto yet, so resending).
A while back now, I stopped supplying the LZF compression algorithm with
TuxOnIce and made LZO the default algorithm. Around the same time, we
started getting occasional errors when reading images; decompression
failures.
I've finally managed to find the time to properly look at this, and have
managed to find a data page that LZO compresses, but seems to be unable
to decompress back to the original contents. I'm wondering whether this
is because I'm doing something wrong, or because there really is some
data the LZO (or the kernel implementation) can't do reversible
compression on.
I've turned the test case and the way TuxOnIce invokes the compression
and decompression code into a standalone kernel module (attached). On my
64 bit machine, insmoding the module results in the error path being
triggered (skipping the dump of the original page):
[52205.333463] Output 716 bytes. Result 0.
[52205.333468] Compressed to: 06 f8 8f 09 00 00 ea ff ff 00 a1 00 40 7a
00 ff
[52205.333473] Compressed to: ff 27 3c 00 78 01 2b 0c 00 01 30 90 09 00
7c 05
[52205.333478] Compressed to: fc 00 d0 03 3f dd 00 68 dc 06 fc 00 20 07
dd 00
[52205.333483] Compressed to: a0 dc 06 fc 00 20 07 dd 00 d8 dc 06 fc 00
20 07
[52205.333488] Compressed to: de 00 10 91 bc 1b fc 00 20 07 dd 00 48 dc
06 fc
[52205.333493] Compressed to: 00 20 07 dd 00 80 dc 06 fc 00 20 07 dd 00
b8 dc
[52205.333498] Compressed to: 06 fc 00 20 07 dd 00 f0 dc 06 fc 00 20 07
de 00
[52205.333503] Compressed to: 28 92 bc 22 fc 00 20 07 dd 00 60 dc 06 fc
00 20
[52205.333508] Compressed to: 07 dd 00 98 dc 06 fc 00 20 07 dd 00 d0 dc
06 fc
[52205.333512] Compressed to: 00 20 07 de 00 08 93 bc 1b fc 00 20 07 dd
00 40
[52205.333517] Compressed to: dc 06 fc 00 20 07 dd 00 78 dc 06 fc 00 20
07 dd
[52205.333522] Compressed to: 00 b0 dc 06 fc 00 20 07 dd 00 e8 dc 06 fc
00 20
[52205.333527] Compressed to: 07 de 00 20 94 bc 22 fc 00 20 07 dd 00 58
dc 06
[52205.333532] Compressed to: fc 00 20 07 dd 00 90 dc 06 fc 00 20 07 dd
00 c8
[52205.333537] Compressed to: dc 06 fc 00 20 07 de 00 00 95 bc 1b 27 1c
00 a0
[52205.333542] Compressed to: 07 3f 3d 13 38 dc 06 fc 00 b9 06 00 3f dd
00 70
[52205.333546] Compressed to: dc 06 fc 00 20 07 dd 00 a8 dc 06 fc 00 20
07 dd
[52205.333551] Compressed to: 00 e0 dc 06 fc 00 20 07 de 00 18 96 bc 22
fc 00
[52205.333556] Compressed to: 20 07 dd 00 50 dc 06 fc 00 20 07 dd 00 88
dc 06
[52205.333561] Compressed to: fc 00 20 07 dd 00 c0 dc 06 fc 00 20 07 dd
00 f8
[52205.333566] Compressed to: dc 06 fc 00 20 07 de 00 30 97 bc 22 fc 00
20 07
[52205.333571] Compressed to: dd 00 68 dc 06 fc 00 20 07 dd 00 a0 dc 06
fc 00
[52205.333576] Compressed to: 20 07 dd 00 d8 dc 06 fc 00 20 07 de 00 10
98 bc
[52205.333581] Compressed to: 1b fc 00 20 07 dd 00 48 dc 06 fc 00 20 07
dd 00
[52205.333586] Compressed to: 80 dc 06 fc 00 20 07 dd 00 b8 dc 06 fc 00
20 07
[52205.333591] Compressed to: dd 00 f0 dc 06 fc 00 20 07 de 00 28 99 bc
22 fc
[52205.333596] Compressed to: 00 20 07 dd 00 60 dc 06 fc 00 20 07 dd 00
98 dc
[52205.333601] Compressed to: 06 fc 00 20 07 dd 00 d0 dc 06 fc 00 20 07
de 00
[52205.333606] Compressed to: 08 9a bc 1b fc 00 20 07 dd 00 40 dc 06 fc
00 20
[52205.333611] Compressed to: 07 dd 00 78 dc 06 fc 00 20 07 dd 00 b0 dc
06 fc
[52205.333616] Compressed to: 00 20 07 dd 00 e8 dc 06 fc 00 20 07 de 00
20 9b
[52205.333621] Compressed to: bc 22 fc 00 20 07 dd 00 58 dc 06 fc 00 20
07 dd
[52205.333625] Compressed to: 00 90 dc 06 fc 00 20 07 dd 00 c8 dc 06 fc
00 20
[52205.333630] Compressed to: 07 de 00 00 9c bc 1b 27 1c 00 a0 07 3f 1d
1b 38
[52205.333635] Compressed to: dc 06 fc 00 b8 06 20 02 fc 1b dd 06 70 dc
00 20
[52205.333640] Compressed to: 07 dd 00 a8 dc 05 fc 00 20 07 dd 00 e0 dc
06 fc
[52205.333645] Compressed to: 00 20 07 de 00 18 9d bc 22 fc 00 20 07 dd
00 50
[52205.333650] Compressed to: dc 06 fc 00 20 07 dd 00 88 dc 06 fc 00 20
07 dd
[52205.333655] Compressed to: 00 c0 dc 06 fc 00 20 07 dd 00 f8 dc 06 fc
00 20
[52205.333660] Compressed to: 07 de 00 30 9e bc 22 fc 00 20 07 dd 00 68
dc 06
[52205.333665] Compressed to: fc 00 20 07 dd 00 a0 dc 06 fc 00 20 07 dd
00 d8
[52205.333670] Compressed to: dc 06 fc 00 20 07 de 00 10 9f bc 1b fc 00
20 07
[52205.333675] Compressed to: dd 00 48 dc 06 fc 00 20 07 dd 00 80 dc 06
fc 00
[52205.333679] Compressed to: 20 07 dd 00 b8 dc 06 fc 00 20 07 dd 00 f0
dc 06
[52205.333684] Compressed to: 05 f0 9f 09 00 00 ea ff ff 11 00 00
[52205.333689]
[52205.333691] Restored to 0 bytes, result code -22.
Would someone be willing and able to tell me what (if anything) I'm
doing wrong, or whether there is something wrong with the algo or its
implementation?
Thanks!
Nigel
== 2 of 2 ==
Date: Wed, Feb 3 2010 3:00 pm
From: "Rafael J. Wysocki"
On Wednesday 03 February 2010, Nigel Cunningham wrote:
> Hi all.
>
> (Not sent to LKML yesterday; no reply from linux-crypto yet, so resending).
>
> A while back now, I stopped supplying the LZF compression algorithm with
> TuxOnIce and made LZO the default algorithm. Around the same time, we
> started getting occasional errors when reading images; decompression
> failures.
>
> I've finally managed to find the time to properly look at this, and have
> managed to find a data page that LZO compresses, but seems to be unable
> to decompress back to the original contents. I'm wondering whether this
> is because I'm doing something wrong, or because there really is some
> data the LZO (or the kernel implementation) can't do reversible
> compression on.
Well, FWIW, we have never had any problems with the userland LZO in s2disk,
so if anything is wrong with LZO here, I guess it's the kernel code.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: [0/4] SLAB: Fix a couple of slab memory hotadd issues
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 1:50 pm
From: Andi Kleen
This fixes various problems in slab found during memory hotadd testing.
All straight forward bug fixes, so could be still .33 candidates.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Wed, Feb 3 2010 1:50 pm
From: Andi Kleen
cache_reap can run before the node is set up and then reference a NULL
l3 list. Check for this explicitely and just continue. The node
will be eventually set up.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
mm/slab.c | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6.33-rc3-ak/mm/slab.c
===================================================================
--- linux-2.6.33-rc3-ak.orig/mm/slab.c
+++ linux-2.6.33-rc3-ak/mm/slab.c
@@ -4112,6 +4112,9 @@ static void cache_reap(struct work_struc
* we can do some work if the lock was obtained.
*/
l3 = searchp->nodelists[node];
+ /* Note node yet set up */
+ if (!l3)
+ break;
reap_alien(searchp, l3);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: i915 #GP [was: mmotm 2010-02-01-16-25 uploaded]
http://groups.google.com/group/linux.kernel/t/126786bfcb1821da?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 1:50 pm
From: Jiri Slaby
On 02/02/2010 01:25 AM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2010-02-01-16-25 has been uploaded to
Hi, when thunderbird appears on clean X+xterm I get this with the snapshot:
[drm:i915_gem_do_execbuffer] *ERROR* Invalid object handle 1073741824 at
index 1
general protection fault: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:04:00.0/resource
CPU 0
Pid: 3412, comm: X Not tainted 2.6.33-rc6-mm1_64+ #941 To be filled by
O.E.M./To Be Filled By O.E.M.
RIP: 0010:[<ffffffff812579ef>] [<ffffffff812579ef>]
i915_gem_do_execbuffer+0x3ef/0xbf0
RSP: 0018:ffff8801c2313c68 EFLAGS: 00010202
RAX: ffff8801c2f6a7c8 RBX: 0000000000000002 RCX: 0000000000000049
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffff81237e70 RDI: ffff8801c2a28738
RBP: ffff8801c2313d18 R08: 0000000000000000 R09: 0000000002000000
R10: 0000000000000000 R11: 0000000000000004 R12: ffff8801c2f6a7b8
R13: ffff8801c2313d38 R14: 0000000000000000 R15: 00000000fffffff7
FS: 00007f4910c476f0(0000) GS:ffff880100200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f48fb928000 CR3: 00000001c2cd5000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process X (pid: 3412, threadinfo ffff8801c2312000, task ffff8801c3539c00)
Stack:
ffffffff81803580 00000000000000d0 ffff8801c2e043d8 0000000000d7ba90
<0> 0000000000000060 ffffffff810be556 ffff8801c5f918f8 ffff8801c2f6a7b8
<0> ffff8801cbc0a048 0000000000000000 ffff8801c2f6a7b8 ffff8801c5f918d8
Call Trace:
[<ffffffff810be556>] ? __slab_alloc+0x266/0x2f0
[<ffffffff81258584>] i915_gem_execbuffer+0x1b4/0x360
[<ffffffff81253516>] ? i915_gem_sw_finish_ioctl+0x96/0xd0
[<ffffffff812363ed>] drm_ioctl+0x1bd/0x480
[<ffffffff8108fe12>] ? unlock_page+0x22/0x30
[<ffffffff812583d0>] ? i915_gem_execbuffer+0x0/0x360
[<ffffffff810a9dbb>] ? handle_mm_fault+0x18b/0x3c0
[<ffffffff810d7468>] vfs_ioctl+0x38/0xd0
[<ffffffff810d7ca0>] do_vfs_ioctl+0x80/0x340
[<ffffffff81024841>] ? do_page_fault+0x131/0x2d0
[<ffffffff810d7faa>] sys_ioctl+0x4a/0x80
[<ffffffff81002e6b>] system_call_fastpath+0x16/0x1b
Code: 44 8b 5a 08 45 85 db 74 4f 31 db 4c 8b 65 a0 49 89 d5 66 2e 0f 1f
84 00 00 00 00 00 48 63 c3 49 8d 04 c4 48 8b 10 48 85 d2 74 25 <48> 8b
92 80 00 00 00 c7 82 a0 00 00 00 00 00 00 00 48 8b 38 48
RIP [<ffffffff812579ef>] i915_gem_do_execbuffer+0x3ef/0xbf0
RSP <ffff8801c2313c68>
---[ end trace 99140c91bbc9294a ]---
opposing to 2010-01-15-15-34 which was OK. This is a setup with no KMS
with 2.9.1 intel X drv.
thanks,
--
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: radio-si470x-common: -EINVAL overwritten in si470x_vidioc_s_tuner()
http://groups.google.com/group/linux.kernel/t/b9df83e9a4867ffc?hl=en
==============================================================================
== 1 of 1 ==
Date: Wed, Feb 3 2010 2:00 pm
From: Tobias Lorenz
Hello Roel,
no, the default value of retval makes no difference to the function.
Retval is set by si470x_disconnect_check and si470x_set_register.
After each call, retval is checked.
There is no need to reset it passed.
The only reason, there is a default value is my static code checker, saying variables should have default values.
Setting it to -EINVAL seems more reasonable to me than setting it 0.
In fact the patch would bring up the warning on setting default values again.
Bye,
Toby
Am Mittwoch 03 Februar 2010 20:48:05 schrieb Roel Kluin:
> The -EINVAL was overwritten by the si470x_disconnect_check().
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Is this needed?
>
> diff --git a/drivers/media/radio/si470x/radio-si470x-common.c b/drivers/media/radio/si470x/radio-si470x-common.c
> index 4da0f15..65b4a92 100644
> --- a/drivers/media/radio/si470x/radio-si470x-common.c
> +++ b/drivers/media/radio/si470x/radio-si470x-common.c
> @@ -748,12 +748,13 @@ static int si470x_vidioc_s_tuner(struct file *file, void *priv,
> struct v4l2_tuner *tuner)
> {
> struct si470x_device *radio = video_drvdata(file);
> - int retval = -EINVAL;
> + int retval;
>
> /* safety checks */
> retval = si470x_disconnect_check(radio);
> if (retval)
> goto done;
> + retval = -EINVAL;
>
> if (tuner->index != 0)
> goto done;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: perf/trace/lock optimization/scalability improvements
http://groups.google.com/group/linux.kernel/t/88914be5e6b28d7d?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 2:10 pm
From: Frederic Weisbecker
On Wed, Feb 03, 2010 at 11:33:16AM +0100, Peter Zijlstra wrote:
> On Wed, 2010-02-03 at 10:14 +0100, Frederic Weisbecker wrote:
> > - event injection support
>
> I like the idea, I'm just not sure about the name and API details.
>
> I would like to call it something like collection support, and the API
> should have an iterator like interface.
>
> That is, it should not blindly dump all events from a collection at
> once, praying the output buffer is large enough, but either dump a
> specified number and/or stop dumping when the buffer is full. Allowing a
> second invocation to continue where it left off after the buffer content
> has been consumed.
Yeah I agree. But my worry is there are induced races in this scheme.
But probably tight enough that we don't care much.
Consider dumping the task list content:
A -> B -> C -> D
You open a "task" event. And ask to inject it one by one,
you first dump A, and B disappear, then you'll miss it
but you can still get C and D if they don't disappear.
As I said it is tight enough that we don't care. If B disappears
so early, it means it won't have a determinant role in the profiling
anyway (at worst few isolated events in the beginning).
The fact is the async injection will always have such misses by
its nature anyway, you can still dump the whole at once, and you will
miss events that just disappeared before the injection call, so whatever...
>
> Which brings us to the ioctl() interface, we can do the above using
> ioctl()s, but it seems to me we're starting to get ioctl() heavy and
> should be looking at alternative ways of extending this.
>
> Anybody any bright ideas?
>
Using ioctl, we can basically have such structure:
struct perf_inject_req {
int start; (in)
int len; (in)
int *read; (out)
};
Using an idx will often imply rewalk a whole object list from
the beginning, which is perfectly fine.
If you prefer an alternate syscall, I can make it. I've been
told about ioctl drawbacks by the past, I personally think
ioctl has not only drawbacks: it avoids a proliferation
of syscalls. But that's how you prefer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 2 ==
Date: Wed, Feb 3 2010 2:20 pm
From: Frederic Weisbecker
On Wed, Feb 03, 2010 at 10:21:43PM +0100, Jens Axboe wrote:
> On Wed, Feb 03 2010, Frederic Weisbecker wrote:
> > > So while this is orders of magnitude better than the previous patchset,
> > > it's still not anywhere near lean. But I expect you know that, just
> > > consider this a 'I tested it and this is what happened' report :-)
> >
> >
> > Ok, thanks a lot, the fact you can test on a 64 threads box is critically
> > helpful.
>
> My pleasure, I'd love to have a fast and functional perf lockstat. If my
> testing helps getting there, consider me signed up :-)
Great :)
> > I also wonder what happens after this patch applied:
> >
> > diff --git a/kernel/perf_event.c b/kernel/perf_event.c
> > index 98fd360..254b3d4 100644
> > --- a/kernel/perf_event.c
> > +++ b/kernel/perf_event.c
> > @@ -3094,7 +3094,8 @@ static u32 perf_event_tid(struct perf_event *event, struct task_struct *p)
> > if (event->parent)
> > event = event->parent;
> >
> > - return task_pid_nr_ns(p, event->ns);
> > + return p->pid;
> > }
> >
> > In my box it has increased the speed from 2x this patchset.
>
> Cool, I'll give that a spin in the morning, the box is off atm.
Thanks a lot!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: ntp: add hardpps implementation
http://groups.google.com/group/linux.kernel/t/0c8202dba360df9c?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 3 2010 2:10 pm
From: john stultz
On Wed, 2010-02-03 at 23:56 +0300, Alexander Gordeev wrote:
> This commit adds hardpps() implementation based upon the original one
> from the NTPv4 reference kernel code. However, it is highly optimized
> towards very fast syncronization and maximum stickness to PPS signal.
> The typical error is less then a microsecond.
> To make it sync faster I had to throw away exponential phase filter so
> that the full phase offset is corrected immediately. Then I also had to
> throw away median phase filter because it gives a bigger error itself
> if used without exponential filter.
> Maybe we will find an appropriate filtering scheme in the future but
> it's not necessary if the signal quality is ok.
>
> Signed-off-by: Alexander Gordeev <lasaine@lvk.cs.msu.su>
Very cool! Bunch of style comments below.
One other thing: From the comments in the code, it looks like this may
have come straight from the reference implementation. You might want to
provide some extra documentation or comment providing proper credit, and
clarifying that the code is in fact GPLv2 compatible.
Also please review Section 12 of Documentation/SubmittingPatches
thanks
-john
[snip]
> +long pps_tf[3]; /* phase median filter */
> +s64 pps_freq; /* scaled frequency offset (ns/s) */
> +s64 pps_fcount; /* frequency accumulator */
> +long pps_jitter; /* nominal jitter (ns) */
> +long pps_stabil; /* nominal stability (scaled ns/s) */
> +int pps_valid; /* signal watchdog counter */
> +int pps_shift; /* nominal interval duration (s) (shift) */
> +int pps_shiftmax; /* max interval duration (s) (shift) */
> +int pps_intcnt; /* interval counter */
> +
> +/*
> + * PPS signal quality monitors
> + */
> +long pps_calcnt; /* calibration intervals */
> +long pps_jitcnt; /* jitter limit exceeded */
> +long pps_stbcnt; /* stability limit exceeded */
> +long pps_errcnt; /* calibration errors */
> +
Shouldn't all of the above values be made static?
[snip]
> /*
> @@ -233,8 +277,6 @@ static enum hrtimer_restart ntp_leap_second(struct hrtimer *timer)
> */
> void second_overflow(void)
> {
> - s64 delta;
> -
> /* Bump the maxerror field */
> time_maxerror += MAXFREQ / NSEC_PER_USEC;
> if (time_maxerror > NTP_PHASE_LIMIT) {
> @@ -248,9 +290,27 @@ void second_overflow(void)
> */
> tick_length = tick_length_base;
>
> - delta = shift_right(time_offset, SHIFT_PLL + time_constant);
> - time_offset -= delta;
> - tick_length += delta;
> +#ifdef CONFIG_NTP_PPS
> + if (time_status & STA_PPSTIME && time_status & STA_PPSSIGNAL) {
> + tick_length += time_offset;
> + time_offset = 0;
> + } else
> +
No comments:
Post a Comment