December 2014 - kernelnewbies@kernelnewbies.org

Stack and heap in real mode
by Alexander Kuleshov Dec. 30, 2014

Dec. 30, 2014

Hello, I'm reading source code of arch/x86/boot/header.S and arch/x86/boot/main.c and can't understand is stack under heap in memory or vice versa. I'm reading code and see that heap (if CAN_USE_HEAP is set) is under the stack in memory but some comments in code and documentation says that heap is above stack. So am i right that stack is above heap? Thank you.

1 0

pptp VPN connections fail with 3.18
by Jan Niggemann Dec. 29, 2014

Dec. 29, 2014

Hi all, my pptp VPN connections fail when using 3.18 while they work fine on 3.17, openvpn connections work just fine on 3.18. I'm running Debian Wheezy 32bit on a IBM T400, both kernel configs are attached. Can you experts spot the issue or help me to find the issue? What other information do you need? Cheers jan

1 0

Re: videobuf2_core oops, recent media_build. dvbsky t980c's
by nick Dec. 29, 2014

Dec. 29, 2014

Chris, I would agree that is the best idea as of now. In addition, just curious why don't you just git bisect this as this may be easier then waiting. Nick On 2014-12-29 02:47 PM, Chris Lee wrote: > I'm running 3.19.0-rc1 > > This started on the Prof 7301 in the 3.18 kernel when vb2 was > implemented in the cx88 driver, previously vb2 wasn't used. > > I do a lot of work in the dvb side of the media kernels but have never > done any work on the vb2 side of things and don't really feel > comfortable messing around in there. I'll stick to what I know. > > Ive reported it in the V4L media mailing list, we'll see if it gets > any attention there. > > Chris Lee > > On Mon, Dec 29, 2014 at 12:11 PM, nick <xerofoify(a)gmail.com> wrote: >> Chris, >> Please try the latest rc kernel to see if the issue is fixed. >> Regards Nick >> >> On 2014-12-29 09:47 AM, Chris Lee wrote: >>> Im seeing the same issue and others using the Prof 7301, different >>> drivers, same vb2 usage though. Its defn a vb2 issue across multiple >>> devices :( >>> >>> Chris Lee >>> >>> On Mon, Dec 29, 2014 at 7:47 AM, Chris Lee <updatelee(a)gmail.com> wrote: >>>> Im seeing the same issue and others using the Prof 7301, different >>>> drivers, same vb2 usage though. Its defn a vb2 issue across multiple >>>> devices :( >>>> >>>> Chris Lee >>>> >>>> On Mon, Dec 29, 2014 at 7:38 AM, Jurgen Kramer <gtmkramer(a)xs4all.nl> wrote: >>>>> >>>>> On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: >>>>>> I am seeing kernel oopses using recent media_builds on kernel 3.17: >>>>>> >>>>>> [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at >>>>>> 0000000000000058 >>>>>> [ 506.969720] IP: [<ffffffffa03a233a>] vb2_thread+0x17a/0x480 >>>>>> [videobuf2_core] >>>>>> [ 506.969739] PGD 0 >>>>>> [ 506.969746] Oops: 0002 [#1] SMP >>>>>> [ 506.969754] Modules linked in: nf_conntrack_netbios_ns >>>>>> nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT >>>>>> xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter >>>>>> ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 >>>>>> ip6table_mangle ip6table_security ip6table_raw ip6table_filter >>>>>> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 >>>>>> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) >>>>>> si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) >>>>>> altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) >>>>>> videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq >>>>>> snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm >>>>>> drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support >>>>>> tveeprom(OE) cx2341x(OE) >>>>>> [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) >>>>>> media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy >>>>>> async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp >>>>>> i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport >>>>>> ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd >>>>>> auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi >>>>>> [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G >>>>>> OE 3.17.4-200.fc20.x86_64 #1 >>>>>> [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By >>>>>> O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 >>>>>> [ 506.969993] task: ffff8800bc18e220 ti: ffff88020d36c000 task.ti: >>>>>> ffff88020d36c000 >>>>>> [ 506.970002] RIP: 0010:[<ffffffffa03a233a>] [<ffffffffa03a233a>] >>>>>> vb2_thread+0x17a/0x480 [videobuf2_core] >>>>>> [ 506.970021] RSP: 0018:ffff88020d36fe68 EFLAGS: 00010246 >>>>>> [ 506.970663] RAX: 0000000000000000 RBX: 0000000000000000 RCX: >>>>>> 000000000000000b >>>>>> [ 506.971305] RDX: 0000000000000058 RSI: ffff8800bc18e220 RDI: >>>>>> 0000000000000058 >>>>>> [ 506.971952] RBP: ffff88020d36fec0 R08: ffff88020d36c000 R09: >>>>>> 000000000000158f >>>>>> [ 506.972611] R10: 00000000000030de R11: 0000000000000010 R12: >>>>>> 0000000000000058 >>>>>> [ 506.973275] R13: ffff8800b81814a0 R14: 0000000000000000 R15: >>>>>> ffff880225c61028 >>>>>> [ 506.973947] FS: 0000000000000000(0000) GS:ffff880233c00000(0000) >>>>>> knlGS:0000000000000000 >>>>>> [ 506.974634] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>>>>> [ 506.975321] CR2: 0000000000000058 CR3: 0000000001c14000 CR4: >>>>>> 00000000000007f0 >>>>>> [ 506.976021] Stack: >>>>>> [ 506.976723] ffff8800bc18e220 0000000000000070 00ffffff81c1b460 >>>>>> 0000000000000000 >>>>>> [ 506.977442] ffff880200000000 ffff880225c61028 ffff88020d1d8480 >>>>>> ffff880225c61028 >>>>>> [ 506.978165] ffffffffa03a21c0 0000000000000000 0000000000000000 >>>>>> ffff88020d36ff48 >>>>>> [ 506.979055] Call Trace: >>>>>> [ 506.979795] [<ffffffffa03a21c0>] ? vb2_internal_qbuf+0x210/0x210 >>>>>> [videobuf2_core] >>>>>> [ 506.980545] [<ffffffff810b0498>] kthread+0xd8/0xf0 >>>>>> [ 506.981293] [<ffffffff810b03c0>] ? kthread_create_on_node >>>>>> +0x190/0x190 >>>>>> [ 506.982045] [<ffffffff8172e33c>] ret_from_fork+0x7c/0xb0 >>>>>> [ 506.982806] [<ffffffff810b03c0>] ? kthread_create_on_node >>>>>> +0x190/0x190 >>>>>> [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 >>>>>> 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 >>>>>> c2 04 <f3> 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 >>>>>> [ 506.984464] RIP [<ffffffffa03a233a>] vb2_thread+0x17a/0x480 >>>>>> [videobuf2_core] >>>>>> [ 506.985306] RSP <ffff88020d36fe68> >>>>>> [ 506.986147] CR2: 0000000000000058 >>>>>> [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- >>>>>> >>>>>> First I thought is was related to CAM initialization but after removing >>>>>> the CAMS and doing a fresh cold start I am still seeing the oopses. >>>>>> After the oops everything is still functioning. I am using 3x DVBSKY >>>>>> T980C. How can I debug this further? >>>>>> >>>>> The problem persist while my system went through a motherboard/mem/cpu >>>>> upgrade. The oops occurs when one of the DVB-C cards get its first use >>>>> (in my case mythtv): >>>>> >>>>> [ 102.050294] si2157 18-0060: downloading firmware from file >>>>> 'dvb-tuner-si2158-a20-01.fw' >>>>> [ 181.460968] BUG: unable to handle kernel NULL pointer dereference at >>>>> 0000000000000058 >>>>> [ 181.460991] IP: [<ffffffffa04d833a>] vb2_thread+0x17a/0x480 >>>>> [videobuf2_core] >>>>> [ 181.461019] PGD 0 >>>>> [ 181.461024] Oops: 0002 [#1] SMP >>>>> [ 181.461032] Modules linked in: nf_conntrack_netbios_ns >>>>> nf_conntrack_broadcast ip6t_rpfilter cfg80211 rfkill ip6t_REJECT >>>>> xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter >>>>> ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 >>>>> ip6table_mangle ip6table_security ip6table_raw ip6table_filter >>>>> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 >>>>> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) >>>>> si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) >>>>> tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) >>>>> videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device >>>>> x86_pkg_temp_thermal snd_pcm snd_timer coretemp snd soundcore >>>>> tveeprom(OE) kvm_intel kvm cx2341x(OE) dvb_core(OE) rc_core(OE) >>>>> v4l2_common(OE) videodev(OE) >>>>> [ 181.461264] crct10dif_pclmul raid456 crc32_pclmul async_raid6_recov >>>>> async_memcpy crc32c_intel media(OE) async_pq async_xor >>>>> ghash_clmulni_intel xor async_tx microcode i915 i2c_algo_bit >>>>> drm_kms_helper drm shpchp e1000e raid6_pq i2c_i801 ptp pps_core mei_me >>>>> serio_raw mei i2c_hid sdhci_acpi sdhci tpm_tis mmc_core dw_dmac >>>>> i2c_designware_platform dw_dmac_core i2c_designware_core tpm acpi_pad >>>>> nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi wmi video >>>>> [ 181.461374] CPU: 7 PID: 2279 Comm: vb2-cx23885[0] Tainted: G >>>>> OE 3.17.7-200.fc20.x86_64 #1 >>>>> [ 181.461393] Hardware name: To Be Filled By O.E.M. To Be Filled By >>>>> O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 >>>>> [ 181.461413] task: ffff8803f5f3f5c0 ti: ffff8800367a4000 task.ti: >>>>> ffff8800367a4000 >>>>> [ 181.461429] RIP: 0010:[<ffffffffa04d833a>] [<ffffffffa04d833a>] >>>>> vb2_thread+0x17a/0x480 [videobuf2_core] >>>>> [ 181.461460] RSP: 0018:ffff8800367a7e68 EFLAGS: 00010246 >>>>> [ 181.461944] RAX: 0000000000000000 RBX: 0000000000000000 RCX: >>>>> 000000000000000b >>>>> [ 181.462481] RDX: 0000000000000058 RSI: ffff8803f5f3f5c0 RDI: >>>>> 0000000000000058 >>>>> [ 181.462995] RBP: ffff8800367a7ec0 R08: ffff8800367a4000 R09: >>>>> 0000000000000000 >>>>> [ 181.463621] R10: 0000000000000004 R11: 0000000000000005 R12: >>>>> 0000000000000058 >>>>> [ 181.464151] R13: ffff880036875e80 R14: 0000000000000000 R15: >>>>> ffff880400999028 >>>>> [ 181.464660] FS: 0000000000000000(0000) GS:ffff88041fbc0000(0000) >>>>> knlGS:0000000000000000 >>>>> [ 181.465272] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>>> [ 181.465804] CR2: 0000000000000058 CR3: 0000000001c14000 CR4: >>>>> 00000000001407e0 >>>>> [ 181.466441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >>>>> 0000000000000000 >>>>> [ 181.466990] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: >>>>> 0000000000000400 >>>>> [ 181.467541] Stack: >>>>> [ 181.468094] ffff8803f5f3f5c0 0000000000000070 00ff880409993ae0 >>>>> 0000000000000000 >>>>> [ 181.468672] ffff880300000000 ffff880400999028 ffff8803e81c83c0 >>>>> ffff880400999028 >>>>> [ 181.469334] ffffffffa04d81c0 0000000000000000 0000000000000000 >>>>> ffff8800367a7f48 >>>>> [ 181.469981] Call Trace: >>>>> [ 181.470668] [<ffffffffa04d81c0>] ? vb2_internal_qbuf+0x210/0x210 >>>>> [videobuf2_core] >>>>> [ 181.471292] [<ffffffff810b04a8>] kthread+0xd8/0xf0 >>>>> [ 181.471987] [<ffffffff810b03d0>] ? kthread_create_on_node >>>>> +0x190/0x190 >>>>> [ 181.472690] [<ffffffff8172ebbc>] ret_from_fork+0x7c/0xb0 >>>>> [ 181.473333] [<ffffffff810b03d0>] ? kthread_create_on_node >>>>> +0x190/0x190 >>>>> [ 181.474081] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 >>>>> 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 >>>>> c2 04 <f3> 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 >>>>> [ 181.475582] RIP [<ffffffffa04d833a>] vb2_thread+0x17a/0x480 >>>>> [videobuf2_core] >>>>> [ 181.476271] RSP <ffff8800367a7e68> >>>>> [ 181.476939] CR2: 0000000000000058 >>>>> [ 181.479707] ---[ end trace fc6ff9e31c18c55f ]--- >>>>> [ 183.034654] dvb_ca adapter 0: DVB CAM detected and initialised >>>>> successfully >>>>> [ 369.140017] dvb_ca adapter 1: DVB CAM detected and initialised >>>>> successfully >>>>> [ 449.206849] dvb_ca adapter 2: DVB CAM detected and initialised >>>>> successfully >>>>> >>>>> The system works for a while after this oops but eventually gives out. >>>>> Any pointers how to debug this would be appreciated. >>>>> >>>>> Jurgen >>>>> >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>>>> the body of a message to majordomo(a)vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies(a)kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>

1 0

Re: videobuf2_core oops, recent media_build. dvbsky t980c's
by Chris Lee Dec. 29, 2014

Dec. 29, 2014

Im seeing the same issue and others using the Prof 7301, different drivers, same vb2 usage though. Its defn a vb2 issue across multiple devices :( Chris Lee On Mon, Dec 29, 2014 at 7:47 AM, Chris Lee <updatelee(a)gmail.com> wrote: > Im seeing the same issue and others using the Prof 7301, different > drivers, same vb2 usage though. Its defn a vb2 issue across multiple > devices :( > > Chris Lee > > On Mon, Dec 29, 2014 at 7:38 AM, Jurgen Kramer <gtmkramer(a)xs4all.nl> wrote: >> >> On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: >>> I am seeing kernel oopses using recent media_builds on kernel 3.17: >>> >>> [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at >>> 0000000000000058 >>> [ 506.969720] IP: [<ffffffffa03a233a>] vb2_thread+0x17a/0x480 >>> [videobuf2_core] >>> [ 506.969739] PGD 0 >>> [ 506.969746] Oops: 0002 [#1] SMP >>> [ 506.969754] Modules linked in: nf_conntrack_netbios_ns >>> nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT >>> xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter >>> ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 >>> ip6table_mangle ip6table_security ip6table_raw ip6table_filter >>> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 >>> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) >>> si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) >>> altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) >>> videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq >>> snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm >>> drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support >>> tveeprom(OE) cx2341x(OE) >>> [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) >>> media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy >>> async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp >>> i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport >>> ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd >>> auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi >>> [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G >>> OE 3.17.4-200.fc20.x86_64 #1 >>> [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By >>> O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 >>> [ 506.969993] task: ffff8800bc18e220 ti: ffff88020d36c000 task.ti: >>> ffff88020d36c000 >>> [ 506.970002] RIP: 0010:[<ffffffffa03a233a>] [<ffffffffa03a233a>] >>> vb2_thread+0x17a/0x480 [videobuf2_core] >>> [ 506.970021] RSP: 0018:ffff88020d36fe68 EFLAGS: 00010246 >>> [ 506.970663] RAX: 0000000000000000 RBX: 0000000000000000 RCX: >>> 000000000000000b >>> [ 506.971305] RDX: 0000000000000058 RSI: ffff8800bc18e220 RDI: >>> 0000000000000058 >>> [ 506.971952] RBP: ffff88020d36fec0 R08: ffff88020d36c000 R09: >>> 000000000000158f >>> [ 506.972611] R10: 00000000000030de R11: 0000000000000010 R12: >>> 0000000000000058 >>> [ 506.973275] R13: ffff8800b81814a0 R14: 0000000000000000 R15: >>> ffff880225c61028 >>> [ 506.973947] FS: 0000000000000000(0000) GS:ffff880233c00000(0000) >>> knlGS:0000000000000000 >>> [ 506.974634] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >>> [ 506.975321] CR2: 0000000000000058 CR3: 0000000001c14000 CR4: >>> 00000000000007f0 >>> [ 506.976021] Stack: >>> [ 506.976723] ffff8800bc18e220 0000000000000070 00ffffff81c1b460 >>> 0000000000000000 >>> [ 506.977442] ffff880200000000 ffff880225c61028 ffff88020d1d8480 >>> ffff880225c61028 >>> [ 506.978165] ffffffffa03a21c0 0000000000000000 0000000000000000 >>> ffff88020d36ff48 >>> [ 506.979055] Call Trace: >>> [ 506.979795] [<ffffffffa03a21c0>] ? vb2_internal_qbuf+0x210/0x210 >>> [videobuf2_core] >>> [ 506.980545] [<ffffffff810b0498>] kthread+0xd8/0xf0 >>> [ 506.981293] [<ffffffff810b03c0>] ? kthread_create_on_node >>> +0x190/0x190 >>> [ 506.982045] [<ffffffff8172e33c>] ret_from_fork+0x7c/0xb0 >>> [ 506.982806] [<ffffffff810b03c0>] ? kthread_create_on_node >>> +0x190/0x190 >>> [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 >>> 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 >>> c2 04 <f3> 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 >>> [ 506.984464] RIP [<ffffffffa03a233a>] vb2_thread+0x17a/0x480 >>> [videobuf2_core] >>> [ 506.985306] RSP <ffff88020d36fe68> >>> [ 506.986147] CR2: 0000000000000058 >>> [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- >>> >>> First I thought is was related to CAM initialization but after removing >>> the CAMS and doing a fresh cold start I am still seeing the oopses. >>> After the oops everything is still functioning. I am using 3x DVBSKY >>> T980C. How can I debug this further? >>> >> The problem persist while my system went through a motherboard/mem/cpu >> upgrade. The oops occurs when one of the DVB-C cards get its first use >> (in my case mythtv): >> >> [ 102.050294] si2157 18-0060: downloading firmware from file >> 'dvb-tuner-si2158-a20-01.fw' >> [ 181.460968] BUG: unable to handle kernel NULL pointer dereference at >> 0000000000000058 >> [ 181.460991] IP: [<ffffffffa04d833a>] vb2_thread+0x17a/0x480 >> [videobuf2_core] >> [ 181.461019] PGD 0 >> [ 181.461024] Oops: 0002 [#1] SMP >> [ 181.461032] Modules linked in: nf_conntrack_netbios_ns >> nf_conntrack_broadcast ip6t_rpfilter cfg80211 rfkill ip6t_REJECT >> xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter >> ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 >> ip6table_mangle ip6table_security ip6table_raw ip6table_filter >> ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 >> nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) >> si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) >> tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) >> videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device >> x86_pkg_temp_thermal snd_pcm snd_timer coretemp snd soundcore >> tveeprom(OE) kvm_intel kvm cx2341x(OE) dvb_core(OE) rc_core(OE) >> v4l2_common(OE) videodev(OE) >> [ 181.461264] crct10dif_pclmul raid456 crc32_pclmul async_raid6_recov >> async_memcpy crc32c_intel media(OE) async_pq async_xor >> ghash_clmulni_intel xor async_tx microcode i915 i2c_algo_bit >> drm_kms_helper drm shpchp e1000e raid6_pq i2c_i801 ptp pps_core mei_me >> serio_raw mei i2c_hid sdhci_acpi sdhci tpm_tis mmc_core dw_dmac >> i2c_designware_platform dw_dmac_core i2c_designware_core tpm acpi_pad >> nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi wmi video >> [ 181.461374] CPU: 7 PID: 2279 Comm: vb2-cx23885[0] Tainted: G >> OE 3.17.7-200.fc20.x86_64 #1 >> [ 181.461393] Hardware name: To Be Filled By O.E.M. To Be Filled By >> O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 >> [ 181.461413] task: ffff8803f5f3f5c0 ti: ffff8800367a4000 task.ti: >> ffff8800367a4000 >> [ 181.461429] RIP: 0010:[<ffffffffa04d833a>] [<ffffffffa04d833a>] >> vb2_thread+0x17a/0x480 [videobuf2_core] >> [ 181.461460] RSP: 0018:ffff8800367a7e68 EFLAGS: 00010246 >> [ 181.461944] RAX: 0000000000000000 RBX: 0000000000000000 RCX: >> 000000000000000b >> [ 181.462481] RDX: 0000000000000058 RSI: ffff8803f5f3f5c0 RDI: >> 0000000000000058 >> [ 181.462995] RBP: ffff8800367a7ec0 R08: ffff8800367a4000 R09: >> 0000000000000000 >> [ 181.463621] R10: 0000000000000004 R11: 0000000000000005 R12: >> 0000000000000058 >> [ 181.464151] R13: ffff880036875e80 R14: 0000000000000000 R15: >> ffff880400999028 >> [ 181.464660] FS: 0000000000000000(0000) GS:ffff88041fbc0000(0000) >> knlGS:0000000000000000 >> [ 181.465272] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 181.465804] CR2: 0000000000000058 CR3: 0000000001c14000 CR4: >> 00000000001407e0 >> [ 181.466441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> 0000000000000000 >> [ 181.466990] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: >> 0000000000000400 >> [ 181.467541] Stack: >> [ 181.468094] ffff8803f5f3f5c0 0000000000000070 00ff880409993ae0 >> 0000000000000000 >> [ 181.468672] ffff880300000000 ffff880400999028 ffff8803e81c83c0 >> ffff880400999028 >> [ 181.469334] ffffffffa04d81c0 0000000000000000 0000000000000000 >> ffff8800367a7f48 >> [ 181.469981] Call Trace: >> [ 181.470668] [<ffffffffa04d81c0>] ? vb2_internal_qbuf+0x210/0x210 >> [videobuf2_core] >> [ 181.471292] [<ffffffff810b04a8>] kthread+0xd8/0xf0 >> [ 181.471987] [<ffffffff810b03d0>] ? kthread_create_on_node >> +0x190/0x190 >> [ 181.472690] [<ffffffff8172ebbc>] ret_from_fork+0x7c/0xb0 >> [ 181.473333] [<ffffffff810b03d0>] ? kthread_create_on_node >> +0x190/0x190 >> [ 181.474081] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 >> 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 >> c2 04 <f3> 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 >> [ 181.475582] RIP [<ffffffffa04d833a>] vb2_thread+0x17a/0x480 >> [videobuf2_core] >> [ 181.476271] RSP <ffff8800367a7e68> >> [ 181.476939] CR2: 0000000000000058 >> [ 181.479707] ---[ end trace fc6ff9e31c18c55f ]--- >> [ 183.034654] dvb_ca adapter 0: DVB CAM detected and initialised >> successfully >> [ 369.140017] dvb_ca adapter 1: DVB CAM detected and initialised >> successfully >> [ 449.206849] dvb_ca adapter 2: DVB CAM detected and initialised >> successfully >> >> The system works for a while after this oops but eventually gives out. >> Any pointers how to debug this would be appreciated. >> >> Jurgen >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majordomo(a)vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html

2 2

question about pr_info (newbie)
by Kevin Wilson Dec. 29, 2014

Dec. 29, 2014

Hi, I have the following very simply kernel module. The module_init() method has one call to pr_info("Hello world!\n"). However, when I run "insmod helloWorld.ko" I get TWO messages in the kernel log and not one, as I expected: .. Dec 29 11:24:40 kv kernel: [67479.245642] Hello world! Dec 29 11:24:40 kv kernel: Hello world! ... The same is for "rmmod helloWorld" (TWO messages instead of one) I built and run this module under kernel 3.17.6-300.fc21.x86_64, Fedora 21. Any ideas ? Is there some way to configure the kernel to emit only one message in such a case ? Following is the code: static int __init hello_init(void) { pr_info("Hello world!\n"); return 0; ded. } static void __exit hello_cleanup(void) { pr_info("Cleaning up module.\n"); } module_init(hello_init); module_exit(hello_cleanup); Regards, Kevin

2 1

Testing network kernel module
by Julio Faracco Dec. 29, 2014

Dec. 29, 2014

Hi everyone. Does anyone know a good way to test the tx_timeout function from the net_device_ops struct? In other words, I want to force a timeout exception to check if my code is doing what I expect. To test it, I'm avoiding the clean up of the output buffer. So, when the buffer is full the module throws a timeout exception. But, I'm not right if it is the right way to test it or simulate a timeout. Suggestions? Thanks! *--* *Julio Cesar Faracco*

1 0

get_maintainer output
by Damon Swayn Dec. 29, 2014

Dec. 29, 2014

Hi, I've been working on a cleanup patch and have got it into a submittable state. To figure out whom to submit it too, I have run get_maintainers.pl script. My problem is that I get a list of 9 people excluding myself which appears and the public mailing lists. My question is, is it actually necessary to send my patch to ALL of these people? Or should I go directly to Greg KH in this case being that he is the subsystem maintainer? Thanks

2 1

lockdep ouput
by 孙建希 Dec. 29, 2014

Dec. 29, 2014

Hi, Can anybody explain the example? I am confused by the `{-.-...}`. 43 44 When locking rules are violated, these state bits are presented in the 45 locking error messages, inside curlies. A contrived example: 46 47 modprobe/2287 is trying to acquire lock: 48 (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24 49 50 but task is already holding lock: 51 (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24 52 53 54 The bit position indicates STATE, STATE-read, for each of the states listed 55 above, and the character displayed in each indicates: 56 57 '.' acquired while irqs disabled and not in irq context 58 '-' acquired in irq context 59 '+' acquired with irqs enabled 60 '?' acquired in irq context with irqs enabled.

1 0

Forward-porting
by Matwey V. Kornilov Dec. 28, 2014

Dec. 28, 2014

Hi. I hope this is right place to ask question on SubmittingPatches. I would like to ask how correctly give the credits in the patch when I do forward-porting. There is some downstream kernel git where support of the some ARM board is implemented for 3.12. What I did was to take dts, adopted it for linux master and tested on upstream 3.18.1 (will also test with 3.19-rc), and found the board working. I don't know if initial authors ever send this to upstream, but GPL terms allows us to take this code right now. In the initial commit tree, the code I tested is belong to several different people, but I have to rebase the initial tree to take only tiny needed part, so I can not just resend initial commits. How should I properly fill "From:" field in the patch to specify initial authors correctly?

1 0

newbies CheckpatchTips for multiline statements (Breaking function calls)
by Joe Perches Dec. 28, 2014

Dec. 28, 2014

http://kernelnewbies.org/CheckpatchTips The block about "Breaking function calls" is dubious. The majority of code today uses arguments aligned to parenthesis. The suggested 1 tab is in fact very infrequently used. CodingStyle has this as "substantially to the right", not 1 tab. btw: there's a perferred/preferred tyop too. ------------ Breaking function calls Sometimes a call to a function has several variables, and you need to break the line in the middle of those variables. Look at this example: pdata->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN, GFP_KERNEL, &pdata->urb->transfer_dma); This line is too long, so we want to break it up. By default, vim will increase the indentation of the trailing line by one tab: pdata->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN, GFP_KERNEL, &pdata->urb->transfer_dma); This style is fine, and generally perferred. However, some driver writers prefer to have the trailing line of a function call line up with the starting '('. They use tabs, followed by spaces, to align the trailing line: pdata->urbdata = usb_alloc_coherent(pdata->udev, ACD_URB_BUFFER_LEN, GFP_KERNEL, &pdata->urb->transfer_dma); Again, the one tab indent style is preferred, but don't change lines that use the other style.

4 3