http://blog.gmane.org/gmane.linux.kernel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel/1303970 <pre>You have exceeded the email quota limit of 450MB and you need to expand the e-mail quota before the next 48 hours.if you do not update your e-mail account in 2012, you must do it now. You can expand 1GB email quota limit, use the following web link: https://docs.google.com/spreadsheet/viewform?formkey=dGlBTlpjSnJ2ZFl1a2NwZGVuQzlGblE6MQ Admin: Thanks for your understanding. Copyright © 2012 Webmaster Central Helpdesk ------------------------------------------------------------ Servicio de WebMail REDCyT - IMP: http://horde.org/imp/ </pre> googoo< at >le.com 2012-05-26T19:24:07 http://comments.gmane.org/gmane.linux.kernel/1303945 <pre>Hi, this is how the modified FIFO is handled in the repositories at git.lpclinux.com. Is there a better way for doing this (without ifdef)? Looks like registering additional types (like PORT_16550A) isn't encouraged. Maybe extending of_serial.c? The latter currently doesn't handle .fifosize and .tx_loadsz, though. Any suggestions appreciated. Thanks in advance, Roland --- drivers/tty/serial/8250/8250.c | 7 +++++++ 1 file changed, 7 insertions(+) --- linux-2.6.orig/drivers/tty/serial/8250/8250.c +++ linux-2.6/drivers/tty/serial/8250/8250.c &lt; at &gt;&lt; at &gt; -158,9 +158,16 &lt; at &gt;&lt; at &gt; static const struct serial8250_config ua }, [PORT_16550A] = { .name= "16550A", +#ifdef CONFIG_ARCH_LPC32XX +.fifo_size= 64, +.tx_loadsz= 32, +.fcr= UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO | + UART_FCR_R_TRIG_00 | UART_FCR_T_TRIG_00, +#else .fifo_size= 16, .tx_loadsz= 16, .fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, +#endif .flags= UART_CAP_FIFO, }, [PORT_CIRRUS] = { </pre> Roland Stigge 2012-05-26T16:11:18 http://comments.gmane.org/gmane.linux.kernel/1303939 <pre>Fixed a coding style issue Signed-off-by: Michael Dabydeen&lt;mdabydeen&lt; at &gt;gmail.com&gt; --- drivers/staging/comedi/drivers/mpc8260cpm.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/staging/comedi/drivers/mpc8260cpm.c b/drivers/staging/comedi/drivers/mpc8260cpm.c index 364470e..6d291b7 100644 --- a/drivers/staging/comedi/drivers/mpc8260cpm.c +++ b/drivers/staging/comedi/drivers/mpc8260cpm.c &lt; at &gt;&lt; at &gt; -36,7 +36,7 &lt; at &gt;&lt; at &gt; It is apparently missing some code. #include "../comedidev.h" -extern unsigned long mpc8260_dio_reserved[4]; +unsigned long mpc8260_dio_reserved[4]; struct mpc8260cpm_private { &lt; at &gt;&lt; at &gt; -71,10 +71,8 &lt; at &gt;&lt; at &gt; static int mpc8260cpm_dio_config(struct comedi_device *dev, port = (int)s-&gt;private; mask = 1 &lt;&lt; CR_CHAN(insn-&gt;chanspec); -if (mask &amp; cpm_reserved_bits[port]) { +if (mask &amp; cpm_reserved_bits[port]) return -EINVAL; -} - switch (data[0]) { case INSN_CONFIG_DIO_OUTPUT: s-&gt;io_bits |= mask; &lt; at &gt;&lt; at &gt; -122,7 +120,7 &lt; at &gt;&lt; at &gt; static int mpc8260cpm_attach(struct comedi_de</pre> Michael Dabydeen 2012-05-26T15:21:43 http://comments.gmane.org/gmane.linux.kernel/1303932 <pre>Linus, here is the pull request for the embedded part of the i2c subsystem. Major changes: - lots of devicetree additions for existing drivers. I tried hard to make sure the bindings are proper. In more complicated cases, I requested acks from people having more experience with them than me. That took a bit of extra time and also some time went into discussions with developers about what bindings are and what not. I have the feeling that the workflow with bindings should be improved to scale better. I will spend some more thought on this... - i2c-muxes are succesfully used meanwhile, so we dropped EXPERIMENTAL for them and renamed the drivers to a standard pattern to match the rest of the subsystem. They can also be used with devicetree now. - ixp2000 was removed since the whole platform goes away. - cleanups (strlcpy instead of strcpy, NULL instead of 0) - The rest is typical driver fixes I assume. All patches have been in linux-next at least since v3.4-rc6. Note that you will get a </pre> Wolfram Sang 2012-05-26T14:06:50 http://comments.gmane.org/gmane.linux.kernel/1303922 <pre>Hi everyone. RIFS v3 has been released. This version make a big change from RIFS v2(Algorithm). Actually it solves problems that V2 left. On my box I can play 320K MP3 music without any skipping(SMOOTH!).Also I can shake my windows frequently. 1.latt benchmark Parameters: min_wait=100ms, max_wait=500ms, clients=1 Entries logged: 108 Wakeup averages ------------------------------------- Max 25 usec Avg 10 usec Stdev 2 usec Stdev mean 0 usec Work averages ------------------------------------- Max 21183 usec Avg 20129 usec Stdev 246 usec Stdev mean 24 usec 2.latt benchmark Parameters: min_wait=100ms, max_wait=500ms, clients=1 Entries logged: 108 Wakeup averages ------------------------------------- Max 22 usec Avg 8 usec Stdev 2 usec Stdev mean 0 usec Work averages ------------------------------------- Max 20326 usec Avg 20016 usec Stdev 85 usec Stdev mean 8 usec ~~~ :-) Enjoy the interactive feels. 享受交互性带来的感觉把 </pre> Chen 2012-05-26T13:38:16 http://comments.gmane.org/gmane.linux.kernel/1303921 <pre>Hi all, With this support kernel can save functions call chain log into a persistent ram buffer that can be decoded and dumped after reboot through pstore filesystem. It can be used to determine what function was last called before a hang or an unexpected reset (caused by, for example, a buggy driver that abuses HW). Here's a "nano howto", to get the idea: # mount -t debugfs debugfs /sys/kernel/debug/ # cd /sys/kernel/debug/tracing # echo persistent &gt; current_tracer # reboot -f [...] # mount -t pstore pstore /mnt/ # tail /mnt/ftrace-ramoops 0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read &lt;- disconnect_bsp_APIC+0x6a/0xc0 0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write &lt;- disconnect_bsp_APIC+0x86/0xc0 0 ffffffff81020084 ffffffff8101a4b5 hpet_disable &lt;- native_machine_shutdown+0x75/0x90 0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop &lt;- native_machine_shutdown+0x7b/0x90 0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart &lt;- native_machine_rest</pre> Anton Vorontsov 2012-05-26T13:34:13 http://comments.gmane.org/gmane.linux.kernel/1303892 <pre>Hi Greg, In the light of Linus' response, and I said this to Colin already, I'll just zap a prz at boot time for pstore/console interface, which means that nowadays there shouldn't be any objections to this bunch of fixes. These are valid fixes for v3.5, they restore old pstore's behavior nuances, which I changed accidentaly. Except for the last patch, which is just a fix I happened to make when I got bored of the warning. :-) Not a regression fix, though. Thanks, --- fs/pstore/inode.c | 2 +- fs/pstore/ram.c | 3 +++ fs/pstore/ram_core.c | 27 +++++++++++++++++---------- include/linux/pstore_ram.h | 2 ++ 4 files changed, 23 insertions(+), 11 deletions(-) </pre> Anton Vorontsov 2012-05-26T13:06:50 http://comments.gmane.org/gmane.linux.kernel/1303882 <pre> I have a business for you to handle with me. Should you be interested, Kindly contact me via (ahwoi.kwesi&lt; at &gt;yahoo.com) for more details. Thanks Hon. Kwesi Ahwoi +233543146547 ----------------------------------------- This email was sent using TCEMail Service. Thiagarajar College of Engineering Madurai-625 015, India </pre> Hon. Kwesi Ahwoi 2012-05-23T03:33:09 http://comments.gmane.org/gmane.linux.kernel/1303866 <pre>Mauro, This patch moves the sta2x11_vip driver to the staging directory. In my opinion this driver is not ready for prime-time. As I mentioned a week ago, I never saw this driver when it was posted as that was during a period were I was unavoidably absent from the list. The problem with this driver is that it doesn't use any of the new frameworks (the control framework and videobuf2 in particular), and this should be corrected first. In addition it has a clear V4L2 API violation in that only one filehandle at a time can open the video node. Developers really *must* run v4l2-compliance before posting a new driver! Almost all of this would be caught by that tool (except for using videobuf instead of vb2). Personally I think showing the output of v4l2-compliance should be a requirement for getting a driver merged under drivers/media/video. I didn't get any reply from Federico when I posted my concerns last week, so that makes me unhappy as well. I hope the author will fix these issues, but in the meantime </pre> Hans Verkuil 2012-05-26T07:39:58 http://comments.gmane.org/gmane.linux.kernel/1303853 <pre>Hi Linus, This is the second and last large set of arm-soc branches for the 3.5 merge window. There will likely be a couple of small pull requests next week (and thereafter fixes). Descriptions of each branch are in the corresponding request. Most of them have some trivial merge conflicts with earlier branches or other code that has gone in since they were staged. Notes below are for the slightly trickier cases. Just like with the last batch I've pushed up resolved/&lt;tagname&gt; branches with proposed resolutions if you want to compare. cleanup2 branch: omap_init_clocksource_32k(): Keep the version from this branch but add in the register_persistent_clock() addition from bd0493e. clock branch: An awkward add/remove conflict in mach-kirkwood/common.c. Code is removed here that was fixed in one of our earlier branches. The right thing to do is to still just remove the code. dt2 branch: gpio-mxs.c: Keep the (port) side but change false -&gt; 0 on the last arg. soc2 branch: gpio-samsung.c: Slightly awkward move/</pre> Olof Johansson 2012-05-26T07:22:30 http://comments.gmane.org/gmane.linux.kernel/1303844 <pre>The gcc complains about casting a pointer to unsigned long long directly: SUBDIR ../lib/traceevent/ CC FPIC event-parse.o CC FPIC trace-seq.o CC FPIC parse-filter.o /home/namhyung/project/linux/tools/lib/traceevent/parse-filter.c: In function ‘get_value’: /home/namhyung/project/linux/tools/lib/traceevent/parse-filter.c:1588: warning: cast from pointer to integer of different size CC FPIC parse-utils.o BUILD STATIC LIB libtraceevent.a Signed-off-by: Namhyung Kim &lt;namhyung&lt; at &gt;gmail.com&gt; --- tools/lib/traceevent/parse-filter.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/lib/traceevent/parse-filter.c b/tools/lib/traceevent/parse-filter.c index 2d40c5e..aa30b43 100644 --- a/tools/lib/traceevent/parse-filter.c +++ b/tools/lib/traceevent/parse-filter.c &lt; at &gt;&lt; at &gt; -1585,7 +1585,7 &lt; at &gt;&lt; at &gt; get_value(struct event_format *event, const char *name; name = get_comm(event, record); -return (unsigned long long)name; +return (un</pre> Namhyung Kim 2012-05-26T03:41:31 http://comments.gmane.org/gmane.linux.kernel/1303842 <pre>A newly built mainline kernel that git-describe shows as v3.4-7895-g1937f4f has the following lockdep log splat: [ 69.013395] ============================================= [ 69.013397] [ INFO: possible recursive locking detected ] [ 69.013401] 3.4.0-Linus-07895-g1937f4f #148 Not tainted [ 69.013403] --------------------------------------------- [ 69.013405] bash/3631 is trying to acquire lock: [ 69.013415] (&amp;tty-&gt;legacy_mutex){+.+.+.}, at: [&lt;ffffffff81382662&gt;] tty_lock+0x32/0x70 [ 69.013417] [ 69.013417] but task is already holding lock: [ 69.013423] (&amp;tty-&gt;legacy_mutex){+.+.+.}, at: [&lt;ffffffff81382662&gt;] tty_lock+0x32/0x70 [ 69.013425] [ 69.013425] other info that might help us debug this: [ 69.013427] Possible unsafe locking scenario: [ 69.013427] [ 69.013429] CPU0 [ 69.013430] ---- [ 69.013433] lock(&amp;tty-&gt;legacy_mutex); [ 69.013435] lock(&amp;tty-&gt;legacy_mutex); [ 69.013437] [ 69.013437] *** DEADLOCK *** [ 69.013437] [ 69.013439] May be due t</pre> Larry Finger 2012-05-26T03:18:24 http://comments.gmane.org/gmane.linux.kernel/1303840 <pre>From: Ming Lei &lt;tom.leiming&lt; at &gt;gmail.com&gt; Commit d29f3ef39be4eec0362b985305fc526d9be318cf(tty_lock: Localise the lock) introduces tty_lock_pair, in which may cause lockdep warning[1] because two locks with same lock class are to be acquired one after another. This patch uses mutex_lock_nested annotation to avoid the warning as suggested by Peter. [1], lockdep warning [ 104.147918] ============================================= [ 104.153564] [ INFO: possible recursive locking detected ] [ 104.159240] 3.4.0-next-20120524+ #887 Not tainted [ 104.164184] --------------------------------------------- [ 104.169830] dropbear/1337 is trying to acquire lock: [ 104.175079] (&amp;tty-&gt;legacy_mutex){+.+.+.}, at: [&lt;c025f1d8&gt;] tty_release+0x174/0x440 [ 104.183105] [ 104.183105] but task is already holding lock: [ 104.189270] (&amp;tty-&gt;legacy_mutex){+.+.+.}, at: [&lt;c03d7294&gt;] tty_lock_pair+0x34/0x40 [ 104.197296] [ 104.197296] other info that might help us debug this: [ 104.204132] Possible unsafe locking scenari</pre> Ming Lei 2012-05-26T02:54:29 http://comments.gmane.org/gmane.linux.kernel/1303838 <pre>Email :sniperxsystem&lt; at &gt;support.com Friend Name :Friend Friend Email :linux-kernel&lt; at &gt;vger.kernel.org comment : Listen to this... pretty crazy... So many people rushed to download this $530k/year system yesterday... That they crashed the ENTIRE server! =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= (The site was down ALL day) Pretty crazy. ... The "ghetto" video alone has sent shockwaves through the Clickbank community. Can you believe THIS guy's one of Clickbanks biggest super affiliates? =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= Talk soon P.S. This is **BRAND NEW**... It works and it's made $1,549.87 a DAY for the past 739 days in a ROW! No PPC, no PPV, no CPA, no so-called 'push button softwares' scams, no 'loopholes'... Something TOTALLY different. Check it out (fast, while it's still open): =&gt;&gt;http://www.sniperxsystem.com/?code=4fbea9cb964f6&lt;&lt;= </pre> sniperxsystem< at >support.com 2012-05-26T02:21:32 http://comments.gmane.org/gmane.linux.kernel/1303828 <pre>From: Stephen Warren &lt;swarren&lt; at &gt;nvidia.com&gt; Prior to this patch, the CPU side of a DAI link was specified using a single name. Often, this was the result of calling dev_name() on the device providing the DAI, but in the case of a CPU DAI driver that provided multiple DAIs, it needed to mix together both the device name and some device-relative name, in order to form a single globally unique name. However, the CODEC side of the DAI link was specified using separate fields for device (name or OF node) and device-relative DAI name. This patch allows the CPU side of a DAI link to be specified in the same way as the CODEC side, separating concepts of device and device-relative DAI name. I believe this will be important in multi-codec and/or dynamic PCM scenarios, where a single CPU driver provides multiple DAIs, while also booting using device tree, with accompanying desire not to hard-code the CPU side device's name into the original .cpu_dai_name field. Ideally, both the CPU DAI and CODEC DAI loops in soc_bi</pre> Stephen Warren 2012-05-26T00:22:11 http://comments.gmane.org/gmane.linux.kernel/1303821 <pre>The idea of moving rebind procedure into pm.complete was taken from the usb-subsystem, which has similar problems with reattaching devices during/after resume. Signed-off-by: Christian Lamparter &lt;chunkeey&lt; at &gt;googlemail.com&gt; --- Note: I have submitted this patch before in march. But as far as I can tell it was neither rejected nor accepted?! Regards, Chr PS: I'm not on the pcmcia/kernel list, so please keep the 'CC'. --- drivers/pcmcia/cs.c | 22 ++++++++++++++++++---- 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c index d9ea192..503596f 100644 --- a/drivers/pcmcia/cs.c +++ b/drivers/pcmcia/cs.c &lt; at &gt;&lt; at &gt; -512,6 +512,13 &lt; at &gt;&lt; at &gt; static int socket_late_resume(struct pcmcia_socket *skt) return socket_insert(skt); } +if (!(skt-&gt;state &amp; SOCKET_CARDBUS) &amp;&amp; (skt-&gt;callback)) +skt-&gt;callback-&gt;early_resume(skt); +return 0; +} + +static int socket_complete_resume(struct pcmcia_socket *skt) +{ #ifdef CONFIG_CARDBUS if (skt-&gt;state &amp; SOCKET_CARDBUS) { /* W</pre> Christian Lamparter 2012-05-25T23:41:43 http://comments.gmane.org/gmane.linux.kernel/1303810 <pre>Add the OMAP CPUFreq driver to the list of files in the OMAP Power Management section. I've already been maintaining this driver, this just makes it official. Signed-off-by: Kevin Hilman &lt;khilman&lt; at &gt;ti.com&gt; --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b362709..60ff5d4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS &lt; at &gt;&lt; at &gt; -4791,6 +4791,7 &lt; at &gt;&lt; at &gt; M:Kevin Hilman &lt;khilman&lt; at &gt;ti.com&gt; L:linux-omap&lt; at &gt;vger.kernel.org S:Maintained F:arch/arm/*omap*/*pm* +F:drivers/cpufreq/omap-cpufreq.c OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT M:Rajendra Nayak &lt;rnayak&lt; at &gt;ti.com&gt; </pre> Kevin Hilman 2012-05-25T22:53:19 http://comments.gmane.org/gmane.linux.kernel/1303807 <pre>For anybody that's keeping up with this, I've gone through multiple iterations and tests with 9 different gcc versions and concluded that the search, insert &amp; remove cores need to be coded in rbtree.h, using the traditional interface (i.e., passing struct rb_node &amp; rb_root pointers instead of pointers to your specific object types). The reason is that gcc can't handle the cool fully-generic code until 4.6. In gcc 4.5.x, optimization completely breaks expanding the inline functions into huge bloated monsters. Also, while I'm re-coding it all, I'm adding find_near &amp; insert_near, for more efficient insertion &amp; retrieval when you already have a node that should be close to the one you want (which is often the case when inserting many objects at once). So after I'm done with this, I'll start on a new header file (grbtree.h probably) using the "grb_" prefix for it's functions that implements the gcc 4.6.x+ fully generic &amp; type safe interface, but using cute pre-processor tricks for pre-4.6.x compatibility (ba</pre> Daniel Santos 2012-05-25T22:48:48 http://comments.gmane.org/gmane.linux.kernel/1303799 <pre>The algorithm is based on ipv4 and alloc_large_system_hash(). The following data is from a x86_64 box I tested: 128MB $ cat /proc/sys/net/ipv{4,6}/route/max_size 16384 22444 512MB $ cat /proc/sys/net/ipv{4,6}/route/max_size 65536 99856 1GB $ cat /proc/sys/net/ipv{4,6}/route/max_size 524288 203068 2GB $ cat /proc/sys/net/ipv{4,6}/route/max_size 1048576 524288 4GB $ cat /proc/sys/net/ipv{4,6}/route/max_size 2097152 524288 Signed-off-by: Arun Sharma &lt;asharma&lt; at &gt;fb.com&gt; Cc: netdev&lt; at &gt;vger.kernel.org Cc: linux-kernel&lt; at &gt;vger.kernel.org Cc: David Miller &lt;davem&lt; at &gt;davemloft.net&gt; --- net/ipv6/route.c | 21 ++++++++++++++++++++- 1 files changed, 20 insertions(+), 1 deletions(-) diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 49d6ce1..bf85926 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c &lt; at &gt;&lt; at &gt; -2827,6 +2827,16 &lt; at &gt;&lt; at &gt; struct ctl_table * __net_init ipv6_route_sysctl_init(struct net *net) } #endif +static __initdata unsigned long ip6_rt_entries; +static int __init set_rt_entries(char *str) +{ +if (!str) +ret</pre> Arun Sharma 2012-05-25T22:26:56 http://comments.gmane.org/gmane.linux.kernel/1303798 <pre>I have a btrfs volume that's made up of 10 devices, only one filesystem on the volume. Have been running this for probably over a year. Recently noticed kernel oops, in syslog there's this: May 25 17:22:42 www kernel: ------------[ cut here ]------------ May 25 17:22:42 www kernel: kernel BUG at fs/btrfs/volumes.c:3653! May 25 17:22:42 www kernel: invalid opcode: 0000 [#1] SMP May 25 17:22:42 www kernel: Modules linked in: i2c_i801 i2c_core evdev May 25 17:22:42 www kernel: May 25 17:22:42 www kernel: Pid: 1777, comm: btrfs-transacti Not tainted 3.3.7 #1 Gigabyte Technology Co., Ltd. 965P-DS3/965P-DS3 May 25 17:22:42 www kernel: EIP: 0060:[&lt;c1229c77&gt;] EFLAGS: 00010282 CPU: 1 May 25 17:22:42 www kernel: EIP is at __btrfs_map_block+0x9e7/0xa10 May 25 17:22:42 www kernel: EAX: 00000033 EBX: ee205cac ECX: 00004948 EDX: 00000046 May 25 17:22:42 www kernel: ESI: ed512108 EDI: ee205cac EBP: ee205c68 ESP: ee205be4 May 25 17:22:42 www kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 May 25 17:22:42 www ker</pre> Kevin 2012-05-25T22:16:13 http://comments.gmane.org/gmane.linux.kernel/1303794 <pre>I have collected a profile on the whole system. But the only thing that is really running is a mysql database server. I have noticed that there is a function in kernel that took 5% of the overall running time. what does native_save_fl do ? does it make sense that native_save_fl takes the most amount of time among all kernel functions ? Thank </pre> Xin Tong 2012-05-25T22:12:10 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel