Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, Jul 16, 2020 at 09:22:11PM +0300, Maxim Levitsky wrote: > On Thu, 2020-07-16 at 21:21 +0300, Andy Shevchenko wrote: > > On Thu, Jul 16, 2020 at 09:00:00PM +0300, Maxim Levitsky wrote: > > > On Thu, 2020-07-16 at 18:47 +0300, Andy Shevchenko wrote: ... > > > It works (no more oops) > > >

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, Jul 16, 2020 at 09:00:00PM +0300, Maxim Levitsky wrote: > On Thu, 2020-07-16 at 18:47 +0300, Andy Shevchenko wrote: > > On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > > > Hi! > > > > > > Few days ago I bisected a regression on 5.8 kernel: > > > > > > I have nvidia rtx

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, 2020-07-16 at 21:21 +0300, Andy Shevchenko wrote: > On Thu, Jul 16, 2020 at 09:00:00PM +0300, Maxim Levitsky wrote: > > On Thu, 2020-07-16 at 18:47 +0300, Andy Shevchenko wrote: > > > On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > > > > Hi! > > > > > > > > Few days ago

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, 2020-07-16 at 18:47 +0300, Andy Shevchenko wrote: > On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > > Hi! > > > > Few days ago I bisected a regression on 5.8 kernel: > > > > I have nvidia rtx 2070s and its USB type C port driver (which is open > > source) > > started

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, 2020-07-16 at 17:34 +0300, Andy Shevchenko wrote: > On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > > Hi! > > > > Few days ago I bisected a regression on 5.8 kernel: > > > > I have nvidia rtx 2070s and its USB type C port driver (which is open > > source) > > started

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > Hi! > > Few days ago I bisected a regression on 5.8 kernel: > > I have nvidia rtx 2070s and its USB type C port driver (which is open source) > started to crash on load: ... > Reverting the commit helped fix this oops. > > My

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > Hi! > > Few days ago I bisected a regression on 5.8 kernel: > > I have nvidia rtx 2070s and its USB type C port driver (which is open source) > started to crash on load: I'm looking at this, but I have questions: - any pointers

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, 2020-07-16 at 10:28 +0200, Greg KH wrote: > On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > > Hi! > > > > Few days ago I bisected a regression on 5.8 kernel: > > > > I have nvidia rtx 2070s and its USB type C port driver (which is open > > source) > > Is that driver

Re: kernel oops in 'typec_ucsi' due to commit 'drivers property: When no children in primary, try secondary'

On Thu, Jul 16, 2020 at 11:17:03AM +0300, Maxim Levitsky wrote: > Hi! > > Few days ago I bisected a regression on 5.8 kernel: > > I have nvidia rtx 2070s and its USB type C port driver (which is open source) Is that driver merged into the tree? If not, do you have a pointer to it somewhere?

Re: Kernel Oops on 4.8.0-rc8 while running trinity tests

The kernel oops is still reproducible on 4.8.0-rc8 on PowerPC bare metal While running trinity system call fuzzer, I see these kernel oops messages: Unable to handle kernel paging request for data at address 0xe45f7702 Faulting instruction address: 0xc0055380 Oops: Kernel

Re: Kernel Oops on 4.8.0-rc8 while running trinity tests

The kernel oops is still reproducible on 4.8.0-rc8 on PowerPC bare metal While running trinity system call fuzzer, I see these kernel oops messages: Unable to handle kernel paging request for data at address 0xe45f7702 Faulting instruction address: 0xc0055380 Oops: Kernel

Re: kernel OOPS in MM(?)

Hello, On 2016-03-10 12:31, Evgenii Lepikhin wrote: > We need help to understand the source of the problem and may be to create a > bugreport. Here is crash report: > > Mar 10 04:03:51 l28 kernel: [2075560.434445] BUG: unable to handle kernel > paging request at 40008021 > Mar 10

Re: kernel OOPS in MM(?)

Hello, On 2016-03-10 12:31, Evgenii Lepikhin wrote: > We need help to understand the source of the problem and may be to create a > bugreport. Here is crash report: > > Mar 10 04:03:51 l28 kernel: [2075560.434445] BUG: unable to handle kernel > paging request at 40008021 > Mar 10

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 19, 2015 at 08:58:27AM +0200, Kirill A. Shutemov wrote: > On Thu, Nov 19, 2015 at 11:12:21AM +0900, Minchan Kim wrote: > > On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > > > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 19, 2015 at 08:58:27AM +0200, Kirill A. Shutemov wrote: > On Thu, Nov 19, 2015 at 11:12:21AM +0900, Minchan Kim wrote: > > On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > > > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

> On Nov 19, 2015, at 14:58, Kirill A. Shutemov wrote: > > uncharged i also encounter this crash , also i encounter a crash like this in qemu: [2.703436] [] do_execveat_common.isra.36+0x4f0/0x630 [2.703624] [] do_execve+0x24/0x30 [2.703767] [] SyS_execve+0x1c/0x2c [2.703923]

Re: kernel oops on mmotm-2015-10-15-15-20

> On Nov 19, 2015, at 14:58, Kirill A. Shutemov wrote: > > uncharged i also encounter this crash , also i encounter a crash like this in qemu: [2.703436] [] do_execveat_common.isra.36+0x4f0/0x630 [2.703624] [] do_execve+0x24/0x30 [2.703767] []

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 19, 2015 at 11:12:21AM +0900, Minchan Kim wrote: > On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 19, 2015 at 11:12:21AM +0900, Minchan Kim wrote: > On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > > > On Mon, Nov 16, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > > > During the test with

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > > During the test with MADV_FREE on kernel I applied your patches, > > > I couldn't see any

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > During the test with MADV_FREE on kernel I applied your patches, > > I couldn't see any problem. > > > > However, in this round, I did another test which is same

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > During the test with MADV_FREE on kernel I applied your patches, > I couldn't see any problem. > > However, in this round, I did another test which is same one > I attached but a liitle bit different because it doesn't do > (memcg

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > During the test with MADV_FREE on kernel I applied your patches, > I couldn't see any problem. > > However, in this round, I did another test which is same one > I attached but a liitle bit different because it doesn't do > (memcg

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > During the test with MADV_FREE on kernel I applied your patches, > > I couldn't see any problem. > > > > However, in this round, I did another test which is same

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > > During the test with MADV_FREE on kernel I applied your patches, > > > I couldn't see any

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > > > During the test with

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 12, 2015 at 09:36:14AM +0900, Minchan Kim wrote: > > > mmotm-2015-10-15-15-20-no-madvise_free, IOW it means git head for > > > 54bad5da4834 arm64: add pmd_[dirty|mkclean] for THP so there is no > > > MADV_FREE code in there > > > + pte_mkdirty patch > > > + freeze/unfreeze patch >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 12, 2015 at 09:36:14AM +0900, Minchan Kim wrote: > > > mmotm-2015-10-15-15-20-no-madvise_free, IOW it means git head for > > > 54bad5da4834 arm64: add pmd_[dirty|mkclean] for THP so there is no > > > MADV_FREE code in there > > > + pte_mkdirty patch > > > + freeze/unfreeze patch >

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 09, 2015 at 12:55:22AM +0200, Kirill A. Shutemov wrote: > On Thu, Nov 05, 2015 at 09:19:22AM +0900, Minchan Kim wrote: > > On Wed, Nov 04, 2015 at 04:21:35PM +0200, Kirill A. Shutemov wrote: > > > On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > > > > On Tue, Nov 03, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Mon, Nov 09, 2015 at 12:55:22AM +0200, Kirill A. Shutemov wrote: > On Thu, Nov 05, 2015 at 09:19:22AM +0900, Minchan Kim wrote: > > On Wed, Nov 04, 2015 at 04:21:35PM +0200, Kirill A. Shutemov wrote: > > > On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > > > > On Tue, Nov 03, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 05, 2015 at 09:19:22AM +0900, Minchan Kim wrote: > On Wed, Nov 04, 2015 at 04:21:35PM +0200, Kirill A. Shutemov wrote: > > On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > > > On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > > > > On Tue, Nov 03, 2015 at

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Nov 05, 2015 at 09:19:22AM +0900, Minchan Kim wrote: > On Wed, Nov 04, 2015 at 04:21:35PM +0200, Kirill A. Shutemov wrote: > > On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > > > On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > > > > On Tue, Nov 03, 2015 at

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Nov 04, 2015 at 04:21:35PM +0200, Kirill A. Shutemov wrote: > On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > > On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > > > On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > > > > On Tue, Nov 03, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > > On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > > > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > > > Hello Kirill, > > > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Nov 04, 2015 at 04:21:35PM +0200, Kirill A. Shutemov wrote: > On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > > On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > > > On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > > > > On Tue, Nov 03, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Nov 04, 2015 at 12:20:19AM +0900, Minchan Kim wrote: > On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > > On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > > > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > > > Hello Kirill, > > > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > > Hello Kirill, > > > > > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: >

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 03, 2015 at 04:33:29PM +0900, Minchan Kim wrote: > On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > > Hello Kirill, > > > > > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: >

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > Hello Kirill, > > > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > > > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > Hello Kirill, > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

Hello Kirill, On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > > > On

Re: kernel oops on mmotm-2015-10-15-15-20

On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > > > On Thu, Oct 22, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > > > On Thu, Oct 22, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > Hello Kirill, > > > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > > > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > Hello Kirill, > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

Hello Kirill, On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > > > On

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > > On Thu, Oct 22, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > > On Thu, Oct 22, 2015

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > > Hello Hugh, > > > > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > > Hello Hugh, > > > > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > Hello Hugh, > > > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > Hello Hugh, > > > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > > Hello Hugh, > > > > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > > Hello Hugh, > > > > > > >

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > Hello Hugh, > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > I added the code to

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > Hello Hugh, > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > I added the code to

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, 21 Oct 2015, Hugh Dickins wrote: > On Wed, 21 Oct 2015, Hugh Dickins wrote: > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > Hello Hugh, > > > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > > > I added

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > Hello Hugh, > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > I added the code to check it and queued it again but I had another oops > > > in this time but

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > Hello Hugh, > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > I added the code to check it and queued it again but I had another oops > > > in this time but

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, 21 Oct 2015, Hugh Dickins wrote: > On Wed, 21 Oct 2015, Hugh Dickins wrote: > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > Hello Hugh, > > > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > > > I added

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, 21 Oct 2015, Hugh Dickins wrote: > On Thu, 22 Oct 2015, Minchan Kim wrote: > > Hello Hugh, > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > I added the code to check it and queued it again but I had

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, 22 Oct 2015, Minchan Kim wrote: > Hello Hugh, > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > I added the code to check it and queued it again but I had another oops > > > in this time but symptom is related to

Re: kernel oops on mmotm-2015-10-15-15-20

Hello Hugh, On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > I added the code to check it and queued it again but I had another oops > > in this time but symptom is related to anon_vma, too. > > (kernel is based on recent mmotm +

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, 22 Oct 2015, Minchan Kim wrote: > > I added the code to check it and queued it again but I had another oops > in this time but symptom is related to anon_vma, too. > (kernel is based on recent mmotm + unconditional mkdirty for bug fix) > It seems page_get_anon_vma returns NULL since the

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Oct 21, 2015 at 02:07:23PM +0300, Kirill A. Shutemov wrote: > On Wed, Oct 21, 2015 at 02:28:36PM +0900, Minchan Kim wrote: > > I detach this report from my patchset thread because I see below > > problem with removing MADV_FREE related code and I can reproduce > > same oops with MADV_FREE

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Oct 21, 2015 at 02:28:36PM +0900, Minchan Kim wrote: > I detach this report from my patchset thread because I see below > problem with removing MADV_FREE related code and I can reproduce > same oops with MADV_FREE + recent patches(both my SetPageDirty > and Kirill's pte_mkdirty) within 7

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, 22 Oct 2015, Minchan Kim wrote: > Hello Hugh, > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > I added the code to check it and queued it again but I had another oops > > > in this time but symptom is related to

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, 21 Oct 2015, Hugh Dickins wrote: > On Thu, 22 Oct 2015, Minchan Kim wrote: > > Hello Hugh, > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > I added the code to check it and queued it again but I had

Re: kernel oops on mmotm-2015-10-15-15-20

On Thu, 22 Oct 2015, Minchan Kim wrote: > > I added the code to check it and queued it again but I had another oops > in this time but symptom is related to anon_vma, too. > (kernel is based on recent mmotm + unconditional mkdirty for bug fix) > It seems page_get_anon_vma returns NULL since the

Re: kernel oops on mmotm-2015-10-15-15-20

Hello Hugh, On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > I added the code to check it and queued it again but I had another oops > > in this time but symptom is related to anon_vma, too. > > (kernel is based on recent mmotm +

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Oct 21, 2015 at 02:07:23PM +0300, Kirill A. Shutemov wrote: > On Wed, Oct 21, 2015 at 02:28:36PM +0900, Minchan Kim wrote: > > I detach this report from my patchset thread because I see below > > problem with removing MADV_FREE related code and I can reproduce > > same oops with MADV_FREE

Re: kernel oops on mmotm-2015-10-15-15-20

On Wed, Oct 21, 2015 at 02:28:36PM +0900, Minchan Kim wrote: > I detach this report from my patchset thread because I see below > problem with removing MADV_FREE related code and I can reproduce > same oops with MADV_FREE + recent patches(both my SetPageDirty > and Kirill's pte_mkdirty) within 7

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c >> > > Certainly looks like a plausible solution, will build kernel tonight to > confirm. Just to confirm; 4.2rc1 + above patch, and 4.2rc2 both function correctly and I no

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c Certainly looks like a plausible solution, will build kernel tonight to confirm. Just to confirm; 4.2rc1 + above patch, and 4.2rc2 both function correctly and I no longer see

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

> On 07/17/2015 08:14 AM, si...@mungewell.org wrote: >> So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. >>> >>> The

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

On 07/17/2015 08:14 AM, si...@mungewell.org wrote: So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

>> So in summary this problem is showing up now as the 'User Helper >> Fallback' >> is now forced on, obviously the underlying problem needs to be fixed - >> but >> I don't know when it crept in. >> > > The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware > data manually by

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

Hi Simon, On 7/17/2015 3:14 PM, si...@mungewell.org wrote: It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh.

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

> It looks like the firmware 'opt_flags' must be different, so this may be a > contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh. /boot/config-4.1.0-rc7+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware data manually by accessing

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh. /boot/config-4.1.0-rc7+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

Hi Simon, On 7/17/2015 3:14 PM, si...@mungewell.org wrote: It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh.

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

On 07/17/2015 08:14 AM, si...@mungewell.org wrote: So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

On 07/17/2015 08:14 AM, si...@mungewell.org wrote: So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

> [ 117.236007] [] device_del+0x18f/0x270 > [ 117.236007] [] ? wake_up_q+0x70/0x70 > [ 117.236007] [] _request_firmware+0x5aa/0xaf0 > [ 117.236007] [] request_firmware+0x35/0x50 > [ 117.236007] [] btbcm_setup_patchram+0x191/0x910 > [btbcm] > [ 117.236007] [] ? rpm_idle+0xc4/0x200 > [

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

[ 117.236007] [814d2ccf] device_del+0x18f/0x270 [ 117.236007] [8109b340] ? wake_up_q+0x70/0x70 [ 117.236007] [814e97da] _request_firmware+0x5aa/0xaf0 [ 117.236007] [814e9d55] request_firmware+0x35/0x50 [ 117.236007] [c00fb881]

Re: Kernel OOPS when reloading i915 after resume from suspend

Hi! > >>1) Shut down X, > >>2) Unbind the consoles: > >> > >>echo 0 > /sys/class/vtconsole/vtcon1/bind > >>echo 0 > /sys/class/vtconsole/vtcon0/bind > >> > >>3) Remove the i915 > >> > >>rmmod i915 > >> > >>4) Suspend the system > >> > >>pm-suspend > > > >Does it also break with plain echo mem >

Re: Kernel OOPS when reloading i915 after resume from suspend

Am 02.07.2014 23:22, schrieb Pavel Machek: Hi! still experimenting with the resume from suspend on the Fujitsu S6010. I can, however, still create a kernel oops. The kernel source comes from alm_fixes5, kernel 3.15.0-rc7+. For that, do the following: 1) Shut down X, 2) Unbind the consoles:

Re: Kernel OOPS when reloading i915 after resume from suspend

Am 02.07.2014 23:22, schrieb Pavel Machek: Hi! still experimenting with the resume from suspend on the Fujitsu S6010. I can, however, still create a kernel oops. The kernel source comes from alm_fixes5, kernel 3.15.0-rc7+. For that, do the following: 1) Shut down X, 2) Unbind the consoles:

Re: Kernel OOPS when reloading i915 after resume from suspend

Hi! 1) Shut down X, 2) Unbind the consoles: echo 0 /sys/class/vtconsole/vtcon1/bind echo 0 /sys/class/vtconsole/vtcon0/bind 3) Remove the i915 rmmod i915 4) Suspend the system pm-suspend Does it also break with plain echo mem /sys/power/state? No. If the modules stay

Re: Kernel OOPS when reloading i915 after resume from suspend

Hi! > still experimenting with the resume from suspend on the Fujitsu > S6010. I can, however, still create a kernel oops. The kernel source > comes from alm_fixes5, kernel 3.15.0-rc7+. For that, do the > following: > > 1) Shut down X, > 2) Unbind the consoles: > > echo 0 >

Re: Kernel OOPS when reloading i915 after resume from suspend

Hi! still experimenting with the resume from suspend on the Fujitsu S6010. I can, however, still create a kernel oops. The kernel source comes from alm_fixes5, kernel 3.15.0-rc7+. For that, do the following: 1) Shut down X, 2) Unbind the consoles: echo 0

Re: Kernel oops without Backtrace

On Thu 27-03-14 13:47:21, Celestino Martinez Lopez wrote: > Hi All, > > I am running a SUSE linux 3.0.13-0.27 and after printing an opps the system > hangs (though it only happened once). > In the opps there is only Code: information, no stack trace or processor > registers. > Analyzing the

Re: Kernel oops without Backtrace

On Thu 27-03-14 13:47:21, Celestino Martinez Lopez wrote: Hi All, I am running a SUSE linux 3.0.13-0.27 and after printing an opps the system hangs (though it only happened once). In the opps there is only Code: information, no stack trace or processor registers. Analyzing the code most

Re: Kernel OOPS using auditd Debian 3.2 on a /sys file audit

On Tue 14-05-13 20:36:59, Javier Domingo wrote: > I didn't get any reply, is this mailing list still valid, or should I > ask elsewhere? (this is a ping message) This is a high traffic list so your message is likely to just go unnoticed. It is good to find maintainers of the subsystem

  1   2   3   4   5   >