diff for duplicates of <20140108034453.GA8664@kroah.com> diff --git a/a/1.txt b/N1/1.txt index e3daa9f..472a674 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -12,15 +12,15 @@ Then why did you? :) > The main issue is the use of systemd causes the serial driver to somehow get > out of sync on startups randomly. i.e. on one bootup it's fine, and on other -> it'll kernel panic. +> it'll kernel panic.? > It occurs because systemd causes the startup and shutdown driver ops to be -> fired in rapid succession. +> fired in rapid succession.? How does systemd cause this? Is this when the serial port is being used as a console or something else? > Every single service start message causes the _startup callback first, then the -> message prints and _shutdown callbacks fires. +> message prints and _shutdown callbacks fires.? So something is opening and closing the port quickly? That should be easy to test without systemd. @@ -29,7 +29,7 @@ Any console involved? > And a kernel panic always occurs somewhere during the service status output, > never before when it's just the kernel startup and never after once systemd -> finishes and getty for example takes over. +> finishes and getty for example takes over.? > > The stacktrace looked like this: > Unable to handle kernel NULL pointer dereference at virtual address 00000088 @@ -37,7 +37,7 @@ Any console involved? > [00000088] *pgd=00000000 > Internal error: Oops: 17 [#1] ARM > Modules linked in: autofs4 -> CPU: 0 Not tainted (3.6.9-yocto-standard #1) +> CPU: 0 ? ?Not tainted ?(3.6.9-yocto-standard #1) 3.6.9 is _very_ old, loads of things have happened in the tty layer since then, can you duplicate this on 3.12 or 3.13-rc? @@ -45,16 +45,16 @@ since then, can you duplicate this on 3.12 or 3.13-rc? > PC is at tty_wakeup+0x8/0x58 > LR is at atmel_tasklet_func+0x238/0x80c -> pc : [<c01efd84>] lr : [<c0208fc0>] psr: a00f0013 -> sp : df84ff28 ip : 00000000 fp : 00000100 -> r10: c05d1ec0 r9 : 04208040 r8 : c05d1e80 -> r7 : 0000000a r6 : 00000000 r5 : dedf7c00 r4 : 00000000 -> r3 : dedf7c00 r2 : 00000000 r1 : 600f0013 r0 : 00000000 -> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel -> Control: 10c53c7d Table: 3fb0c059 DAC: 00000015 +> pc : [<c01efd84>] ? ?lr : [<c0208fc0>] ? ?psr: a00f0013 +> sp : df84ff28 ?ip : 00000000 ?fp : 00000100 +> r10: c05d1ec0 ?r9 : 04208040 ?r8 : c05d1e80 +> r7 : 0000000a ?r6 : 00000000 ?r5 : dedf7c00 ?r4 : 00000000 +> r3 : dedf7c00 ?r2 : 00000000 ?r1 : 600f0013 ?r0 : 00000000 +> Flags: NzCv ?IRQs on ?FIQs on ?Mode SVC_32 ?ISA ARM ?Segment kernel +> Control: 10c53c7d ?Table: 3fb0c059 ?DAC: 00000015 > Process ksoftirqd/0 (pid: 3, stack limit = 0xdf84e2f0) > Stack: (0xdf84ff28 to 0xdf850000) -> ff20: c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0 +> ff20: ? ? ? ? ? ? ? ? ? c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0 > ff40: df849680 c05aa458 df8496b0 c00394a8 c0039420 c05a8d04 00000000 00000000 > ff60: 0000000a c05d1e80 04208040 c05d1ec0 00000100 c001fd34 00000009 00000018 > ff80: df84e000 c001f60c df84ffbc c03f8e60 00000013 00000006 00000000 c05d1e80 @@ -77,7 +77,7 @@ since then, can you duplicate this on 3.12 or 3.13-rc? > > Testing wise I originally used a BUG_ON statement in atmel_tasklet_func to > panic before the null deference hit. BUG_ON confirmed that tty was NULL at the -> very start of the tasklet being called. +> very start of the tasklet being called.? And did you test that this patch actually fixed it? diff --git a/a/content_digest b/N1/content_digest index 98689ff..ea003ff 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,17 +2,10 @@ "ref\069b33ebdc9427b5c036b4ba09151ae88c14a30f4.1389090437.git.nicolas.ferre@atmel.com\0" "ref\020140108011137.GA13590@kroah.com\0" "ref\0CAJjB1qLDd6JFb4LwD5iokg5=O8Bwp5MkKsrr45QDodZkZrx75g@mail.gmail.com\0" - "From\0Greg KH <gregkh@linuxfoundation.org>\0" - "Subject\0Re: [PATCH 3/4] tty/serial: at91: prevent null dereference in tasklet function\0" + "From\0gregkh@linuxfoundation.org (Greg KH)\0" + "Subject\0[PATCH 3/4] tty/serial: at91: prevent null dereference in tasklet function\0" "Date\0Tue, 7 Jan 2014 19:44:53 -0800\0" - "To\0Mark Roszko <mark.roszko@gmail.com>\0" - "Cc\0Nicolas Ferre <nicolas.ferre@atmel.com>" - Leilei Zhao <leilei.zhao@atmel.com> - mdeneen@gmail.com - linux-arm-kernel@lists.infradead.org - linux-kernel@vger.kernel.org - linux-serial@vger.kernel.org - " stable@vger.kernel.org\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "\n" @@ -29,15 +22,15 @@ "\n" "> The main issue is the use of systemd causes the serial driver to somehow get\n" "> out of sync on startups randomly. i.e. on one bootup it's fine, and on other\n" - "> it'll kernel panic.\302\240\n" + "> it'll kernel panic.?\n" "> It occurs because systemd causes the startup and shutdown driver ops to be\n" - "> fired in rapid succession.\302\240\n" + "> fired in rapid succession.?\n" "\n" "How does systemd cause this? Is this when the serial port is being used\n" "as a console or something else?\n" "\n" "> Every single service start message causes the _startup callback first, then the\n" - "> message prints and _shutdown callbacks fires.\302\240\n" + "> message prints and _shutdown callbacks fires.?\n" "\n" "So something is opening and closing the port quickly? That should be\n" "easy to test without systemd.\n" @@ -46,7 +39,7 @@ "\n" "> And a kernel panic always occurs somewhere during the service status output,\n" "> never before when it's just the kernel startup and never after once systemd\n" - "> finishes and getty for example takes over.\302\240\n" + "> finishes and getty for example takes over.?\n" "> \n" "> The stacktrace looked like this:\n" "> Unable to handle kernel NULL pointer dereference at virtual address 00000088\n" @@ -54,7 +47,7 @@ "> [00000088] *pgd=00000000\n" "> Internal error: Oops: 17 [#1] ARM\n" "> Modules linked in: autofs4\n" - "> CPU: 0 \302\240 \302\240Not tainted \302\240(3.6.9-yocto-standard #1)\n" + "> CPU: 0 ? ?Not tainted ?(3.6.9-yocto-standard #1)\n" "\n" "3.6.9 is _very_ old, loads of things have happened in the tty layer\n" "since then, can you duplicate this on 3.12 or 3.13-rc?\n" @@ -62,16 +55,16 @@ "\n" "> PC is at tty_wakeup+0x8/0x58\n" "> LR is at atmel_tasklet_func+0x238/0x80c\n" - "> pc : [<c01efd84>] \302\240 \302\240lr : [<c0208fc0>] \302\240 \302\240psr: a00f0013\n" - "> sp : df84ff28 \302\240ip : 00000000 \302\240fp : 00000100\n" - "> r10: c05d1ec0 \302\240r9 : 04208040 \302\240r8 : c05d1e80\n" - "> r7 : 0000000a \302\240r6 : 00000000 \302\240r5 : dedf7c00 \302\240r4 : 00000000\n" - "> r3 : dedf7c00 \302\240r2 : 00000000 \302\240r1 : 600f0013 \302\240r0 : 00000000\n" - "> Flags: NzCv \302\240IRQs on \302\240FIQs on \302\240Mode SVC_32 \302\240ISA ARM \302\240Segment kernel\n" - "> Control: 10c53c7d \302\240Table: 3fb0c059 \302\240DAC: 00000015\n" + "> pc : [<c01efd84>] ? ?lr : [<c0208fc0>] ? ?psr: a00f0013\n" + "> sp : df84ff28 ?ip : 00000000 ?fp : 00000100\n" + "> r10: c05d1ec0 ?r9 : 04208040 ?r8 : c05d1e80\n" + "> r7 : 0000000a ?r6 : 00000000 ?r5 : dedf7c00 ?r4 : 00000000\n" + "> r3 : dedf7c00 ?r2 : 00000000 ?r1 : 600f0013 ?r0 : 00000000\n" + "> Flags: NzCv ?IRQs on ?FIQs on ?Mode SVC_32 ?ISA ARM ?Segment kernel\n" + "> Control: 10c53c7d ?Table: 3fb0c059 ?DAC: 00000015\n" "> Process ksoftirqd/0 (pid: 3, stack limit = 0xdf84e2f0)\n" "> Stack: (0xdf84ff28 to 0xdf850000)\n" - "> ff20: \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0\n" + "> ff20: ? ? ? ? ? ? ? ? ? c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0\n" "> ff40: df849680 c05aa458 df8496b0 c00394a8 c0039420 c05a8d04 00000000 00000000\n" "> ff60: 0000000a c05d1e80 04208040 c05d1ec0 00000100 c001fd34 00000009 00000018\n" "> ff80: df84e000 c001f60c df84ffbc c03f8e60 00000013 00000006 00000000 c05d1e80\n" @@ -94,7 +87,7 @@ "> \n" "> Testing wise I originally used a BUG_ON statement in atmel_tasklet_func to\n" "> panic before the null deference hit. BUG_ON confirmed that tty was NULL at the\n" - "> very start of the tasklet being called.\302\240\n" + "> very start of the tasklet being called.?\n" "\n" "And did you test that this patch actually fixed it?\n" "\n" @@ -108,4 +101,4 @@ "\n" greg k-h -a97f308bc8846524c23469211cc05ea6a83bce1b5a50e49d31d63db60a261cd2 +29ae31b013058e1fc0503c725ed5a4722201a312bc778e8146febd7c43559e47
diff --git a/a/1.txt b/N2/1.txt index e3daa9f..47cd980 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -12,15 +12,15 @@ Then why did you? :) > The main issue is the use of systemd causes the serial driver to somehow get > out of sync on startups randomly. i.e. on one bootup it's fine, and on other -> it'll kernel panic. +> it'll kernel panic.� > It occurs because systemd causes the startup and shutdown driver ops to be -> fired in rapid succession. +> fired in rapid succession.� How does systemd cause this? Is this when the serial port is being used as a console or something else? > Every single service start message causes the _startup callback first, then the -> message prints and _shutdown callbacks fires. +> message prints and _shutdown callbacks fires.� So something is opening and closing the port quickly? That should be easy to test without systemd. @@ -29,7 +29,7 @@ Any console involved? > And a kernel panic always occurs somewhere during the service status output, > never before when it's just the kernel startup and never after once systemd -> finishes and getty for example takes over. +> finishes and getty for example takes over.� > > The stacktrace looked like this: > Unable to handle kernel NULL pointer dereference at virtual address 00000088 @@ -37,7 +37,7 @@ Any console involved? > [00000088] *pgd=00000000 > Internal error: Oops: 17 [#1] ARM > Modules linked in: autofs4 -> CPU: 0 Not tainted (3.6.9-yocto-standard #1) +> CPU: 0 � �Not tainted �(3.6.9-yocto-standard #1) 3.6.9 is _very_ old, loads of things have happened in the tty layer since then, can you duplicate this on 3.12 or 3.13-rc? @@ -45,16 +45,16 @@ since then, can you duplicate this on 3.12 or 3.13-rc? > PC is at tty_wakeup+0x8/0x58 > LR is at atmel_tasklet_func+0x238/0x80c -> pc : [<c01efd84>] lr : [<c0208fc0>] psr: a00f0013 -> sp : df84ff28 ip : 00000000 fp : 00000100 -> r10: c05d1ec0 r9 : 04208040 r8 : c05d1e80 -> r7 : 0000000a r6 : 00000000 r5 : dedf7c00 r4 : 00000000 -> r3 : dedf7c00 r2 : 00000000 r1 : 600f0013 r0 : 00000000 -> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel -> Control: 10c53c7d Table: 3fb0c059 DAC: 00000015 +> pc : [<c01efd84>] � �lr : [<c0208fc0>] � �psr: a00f0013 +> sp : df84ff28 �ip : 00000000 �fp : 00000100 +> r10: c05d1ec0 �r9 : 04208040 �r8 : c05d1e80 +> r7 : 0000000a �r6 : 00000000 �r5 : dedf7c00 �r4 : 00000000 +> r3 : dedf7c00 �r2 : 00000000 �r1 : 600f0013 �r0 : 00000000 +> Flags: NzCv �IRQs on �FIQs on �Mode SVC_32 �ISA ARM �Segment kernel +> Control: 10c53c7d �Table: 3fb0c059 �DAC: 00000015 > Process ksoftirqd/0 (pid: 3, stack limit = 0xdf84e2f0) > Stack: (0xdf84ff28 to 0xdf850000) -> ff20: c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0 +> ff20: � � � � � � � � � c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0 > ff40: df849680 c05aa458 df8496b0 c00394a8 c0039420 c05a8d04 00000000 00000000 > ff60: 0000000a c05d1e80 04208040 c05d1ec0 00000100 c001fd34 00000009 00000018 > ff80: df84e000 c001f60c df84ffbc c03f8e60 00000013 00000006 00000000 c05d1e80 @@ -77,7 +77,7 @@ since then, can you duplicate this on 3.12 or 3.13-rc? > > Testing wise I originally used a BUG_ON statement in atmel_tasklet_func to > panic before the null deference hit. BUG_ON confirmed that tty was NULL at the -> very start of the tasklet being called. +> very start of the tasklet being called.� And did you test that this patch actually fixed it? diff --git a/a/content_digest b/N2/content_digest index 98689ff..b279fa3 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -29,15 +29,15 @@ "\n" "> The main issue is the use of systemd causes the serial driver to somehow get\n" "> out of sync on startups randomly. i.e. on one bootup it's fine, and on other\n" - "> it'll kernel panic.\302\240\n" + "> it'll kernel panic.\303\257\302\277\302\275\n" "> It occurs because systemd causes the startup and shutdown driver ops to be\n" - "> fired in rapid succession.\302\240\n" + "> fired in rapid succession.\303\257\302\277\302\275\n" "\n" "How does systemd cause this? Is this when the serial port is being used\n" "as a console or something else?\n" "\n" "> Every single service start message causes the _startup callback first, then the\n" - "> message prints and _shutdown callbacks fires.\302\240\n" + "> message prints and _shutdown callbacks fires.\303\257\302\277\302\275\n" "\n" "So something is opening and closing the port quickly? That should be\n" "easy to test without systemd.\n" @@ -46,7 +46,7 @@ "\n" "> And a kernel panic always occurs somewhere during the service status output,\n" "> never before when it's just the kernel startup and never after once systemd\n" - "> finishes and getty for example takes over.\302\240\n" + "> finishes and getty for example takes over.\303\257\302\277\302\275\n" "> \n" "> The stacktrace looked like this:\n" "> Unable to handle kernel NULL pointer dereference at virtual address 00000088\n" @@ -54,7 +54,7 @@ "> [00000088] *pgd=00000000\n" "> Internal error: Oops: 17 [#1] ARM\n" "> Modules linked in: autofs4\n" - "> CPU: 0 \302\240 \302\240Not tainted \302\240(3.6.9-yocto-standard #1)\n" + "> CPU: 0 \303\257\302\277\302\275 \303\257\302\277\302\275Not tainted \303\257\302\277\302\275(3.6.9-yocto-standard #1)\n" "\n" "3.6.9 is _very_ old, loads of things have happened in the tty layer\n" "since then, can you duplicate this on 3.12 or 3.13-rc?\n" @@ -62,16 +62,16 @@ "\n" "> PC is at tty_wakeup+0x8/0x58\n" "> LR is at atmel_tasklet_func+0x238/0x80c\n" - "> pc : [<c01efd84>] \302\240 \302\240lr : [<c0208fc0>] \302\240 \302\240psr: a00f0013\n" - "> sp : df84ff28 \302\240ip : 00000000 \302\240fp : 00000100\n" - "> r10: c05d1ec0 \302\240r9 : 04208040 \302\240r8 : c05d1e80\n" - "> r7 : 0000000a \302\240r6 : 00000000 \302\240r5 : dedf7c00 \302\240r4 : 00000000\n" - "> r3 : dedf7c00 \302\240r2 : 00000000 \302\240r1 : 600f0013 \302\240r0 : 00000000\n" - "> Flags: NzCv \302\240IRQs on \302\240FIQs on \302\240Mode SVC_32 \302\240ISA ARM \302\240Segment kernel\n" - "> Control: 10c53c7d \302\240Table: 3fb0c059 \302\240DAC: 00000015\n" + "> pc : [<c01efd84>] \303\257\302\277\302\275 \303\257\302\277\302\275lr : [<c0208fc0>] \303\257\302\277\302\275 \303\257\302\277\302\275psr: a00f0013\n" + "> sp : df84ff28 \303\257\302\277\302\275ip : 00000000 \303\257\302\277\302\275fp : 00000100\n" + "> r10: c05d1ec0 \303\257\302\277\302\275r9 : 04208040 \303\257\302\277\302\275r8 : c05d1e80\n" + "> r7 : 0000000a \303\257\302\277\302\275r6 : 00000000 \303\257\302\277\302\275r5 : dedf7c00 \303\257\302\277\302\275r4 : 00000000\n" + "> r3 : dedf7c00 \303\257\302\277\302\275r2 : 00000000 \303\257\302\277\302\275r1 : 600f0013 \303\257\302\277\302\275r0 : 00000000\n" + "> Flags: NzCv \303\257\302\277\302\275IRQs on \303\257\302\277\302\275FIQs on \303\257\302\277\302\275Mode SVC_32 \303\257\302\277\302\275ISA ARM \303\257\302\277\302\275Segment kernel\n" + "> Control: 10c53c7d \303\257\302\277\302\275Table: 3fb0c059 \303\257\302\277\302\275DAC: 00000015\n" "> Process ksoftirqd/0 (pid: 3, stack limit = 0xdf84e2f0)\n" "> Stack: (0xdf84ff28 to 0xdf850000)\n" - "> ff20: \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0\n" + "> ff20: \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 \303\257\302\277\302\275 c05e4378 dedf7c00 00000000 c0208fc0 c05aa458 df8496b0\n" "> ff40: df849680 c05aa458 df8496b0 c00394a8 c0039420 c05a8d04 00000000 00000000\n" "> ff60: 0000000a c05d1e80 04208040 c05d1ec0 00000100 c001fd34 00000009 00000018\n" "> ff80: df84e000 c001f60c df84ffbc c03f8e60 00000013 00000006 00000000 c05d1e80\n" @@ -94,7 +94,7 @@ "> \n" "> Testing wise I originally used a BUG_ON statement in atmel_tasklet_func to\n" "> panic before the null deference hit. BUG_ON confirmed that tty was NULL at the\n" - "> very start of the tasklet being called.\302\240\n" + "> very start of the tasklet being called.\303\257\302\277\302\275\n" "\n" "And did you test that this patch actually fixed it?\n" "\n" @@ -108,4 +108,4 @@ "\n" greg k-h -a97f308bc8846524c23469211cc05ea6a83bce1b5a50e49d31d63db60a261cd2 +31bed00491017679caa1f69e80bb24023e94a49169657017dc780c8c7aa6b13f
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.