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)
> >
>
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 2
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 I
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 to
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 to
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 .c
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 to
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 me
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?
th
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 acces
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 04:03:
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
> 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]
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
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
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
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
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 problem
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 o
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 thin
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
>
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
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 09:1
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
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,
> > > >
> > >
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:
>
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:
> > >
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:
> > > > On
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 Thu
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
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
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,
> > > >
> > > >
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,
> > > >
> > > >
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:
> > > > On
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 check
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 t
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 sympt
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 another
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 anon
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 + unco
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 pa
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 +
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 ho
>> 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 longe
> 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_US
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
>> 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 accessi
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.
/boot/config-4.1.0-
> 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
C
> [ 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
> [
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 > /s
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:
ec
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 > /sys/class/vtconsole/
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
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 (MAINTAINER
I didn't get any reply, is this mailing list still valid, or should I
ask elsewhere? (this is a ping message)
Javier Domingo
2013/5/2 Javier Domingo :
> Hi,
>
> I am currently having problems with the cpu scaling (something is
> touching the /sys/devices/system/cpu/cpu?/cpufreq/scaling_max_freq)
On Thu, Mar 14, 2013 at 09:38:02AM +0800, Hillf Danton wrote:
> [cc Russell]
> On Wed, Mar 13, 2013 at 11:04 PM, Mark Jackson wrote:
> > Can any help diagnose what my userspace task is doing to get the followings
> > oops ?
> >
> > [ 42.587772] Unable to handle kernel paging request at virtual
[cc Russell]
On Wed, Mar 13, 2013 at 11:04 PM, Mark Jackson wrote:
> Can any help diagnose what my userspace task is doing to get the followings
> oops ?
>
> [ 42.587772] Unable to handle kernel paging request at virtual address
> bfac6004
> [ 42.595431] pgd = cf748000
> [ 42.598291] [bfac
Sorry guys I was away due to personal emergency, however now I am back
and will check the reply ASAP.
On 28 July 2012 21:49, Alan Stern wrote:
> On Sat, 28 Jul 2012, Daniel Mack wrote:
>
>> Hmm, interesting. Thanks for sharing this. I personally never saw this
>> bug kicking in, but if I understa
On Sat, 28 Jul 2012, Daniel Mack wrote:
> Hmm, interesting. Thanks for sharing this. I personally never saw this
> bug kicking in, but if I understand your findings correctly, we would
> need something like the following patch for snd-usb and the storage driver?
>
> Sarbojit, could you give this
On 28.07.2012 15:25, Bjørn Mork wrote:
> Daniel Mack writes:
>> On 28.07.2012 14:27, Bjørn Mork wrote:
>>
>>> The reason is this change:
>>>
>>> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
>>>
>>>
>>> It will make bugs like this suddenly 100% reproducible. But the bugs
>
Daniel Mack writes:
> On 28.07.2012 14:27, Bjørn Mork wrote:
>
>> The reason is this change:
>>
>> 0998d0631 device-core: Ensure drvdata = NULL when no driver is bound
>>
>>
>> It will make bugs like this suddenly 100% reproducible. But the bugs
>> *are* in the drivers, and may have been ther
On 28.07.2012 14:27, Bjørn Mork wrote:
> Daniel Mack writes:
>> On 23.07.2012 16:47, Alan Stern wrote:
>>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
That is why I provided two stacks,
1st one is when I tried to remove the USB hub (which connects a webcam
+ microphone)
2
Daniel Mack writes:
> On 23.07.2012 16:47, Alan Stern wrote:
>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>>> That is why I provided two stacks,
>>>
>>> 1st one is when I tried to remove the USB hub (which connects a webcam
>>> + microphone)
>>> 2nd one is when I tried to remove an USB powered
On 23.07.2012 17:04, Sarbojit Ganguly wrote:
> On 23 July 2012 20:17, Alan Stern wrote:
>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>>
>>> Hello Daniel,
>>>
>>> That is why I provided two stacks,
>>>
>>> 1st one is when I tried to remove the USB hub (which connects a webcam
>>> + microphone)
>
On 23.07.2012 17:04, Sarbojit Ganguly wrote:
> On 23 July 2012 20:17, Alan Stern wrote:
> Yes the issue is in evict() api which gets called when USB disconnect
> is triggered.
>>
>> Alan Stern
>>
>
> Even I was confused in the beginning but after thorough check I
> confirmed its presence. I reve
On 23 July 2012 20:24, Daniel Mack wrote:
> On 23.07.2012 16:47, Alan Stern wrote:
>> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>>> That is why I provided two stacks,
>>>
>>> 1st one is when I tried to remove the USB hub (which connects a webcam
>>> + microphone)
>>> 2nd one is when I tried to
On 23 July 2012 20:17, Alan Stern wrote:
> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>
>> Hello Daniel,
>>
>> That is why I provided two stacks,
>>
>> 1st one is when I tried to remove the USB hub (which connects a webcam
>> + microphone)
>> 2nd one is when I tried to remove an USB powered exte
On 23.07.2012 16:47, Alan Stern wrote:
> On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
>> That is why I provided two stacks,
>>
>> 1st one is when I tried to remove the USB hub (which connects a webcam
>> + microphone)
>> 2nd one is when I tried to remove an USB powered external HDD.
>>
>> Just to m
On Mon, 23 Jul 2012, Sarbojit Ganguly wrote:
> Hello Daniel,
>
> That is why I provided two stacks,
>
> 1st one is when I tried to remove the USB hub (which connects a webcam
> + microphone)
> 2nd one is when I tried to remove an USB powered external HDD.
>
> Just to make sure whether the probl
-- Original message --
From: Marcel Holtmann <[EMAIL PROTECTED]>
> Hi Quel,
>
> > Bad news: I still cannot use the device.
> >
> > hcitool inq, hcitool scan, hcitool name and hcitool info
> >
> > commands work.
> >
> > hcitool cc , sdptool , rfcomm connect comm
Hi Quel,
-- Original message --
From: Thomas Gleixner <[EMAIL PROTECTED]>
On Fri, 22 Feb 2008, David Woodhouse wrote:
On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
+ del_timer(&conn->info_timer);
+
hcon->l2cap_data = NULL;
kfre
-- Original message --
From: Thomas Gleixner <[EMAIL PROTECTED]>
> On Fri, 22 Feb 2008, David Woodhouse wrote:
>
> > On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
> > >
> > > + del_timer(&conn->info_timer);
> > > +
> > > hcon->l2cap_data
On Fri, 22 Feb 2008, David Woodhouse wrote:
> On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
> >
> > + del_timer(&conn->info_timer);
> > +
> > hcon->l2cap_data = NULL;
> > kfree(conn);
>
> Shouldn't that be del_timer_sync() ?
Hmm, probably yes.
tglx
--
To
On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
>
> + del_timer(&conn->info_timer);
> +
> hcon->l2cap_data = NULL;
> kfree(conn);
Shouldn't that be del_timer_sync() ?
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
Quel,
On Fri, 22 Feb 2008, Quel Qun wrote:
> $ addr2line -e vmlinux c012d51d
> /usr/src/linux-2.6.25-rc2-git5kk1/kernel/timer.c:770
>
> Crap, that is on the next list_for_each_entry in timer.c :(
>
> I tried to make a similar test loop as you did a few lines above:
Cool.
> I thought I got it
On Fri, Feb 22, 2008 at 02:40:41AM +, Quel Qun wrote:
>
> -- Original message --
> From: Thomas Gleixner <[EMAIL PROTECTED]>
> > On Thu, 21 Feb 2008, Quel Qun wrote:
> > > > > > Not that I'm aware off, but this might as well be some old use
> > > > > after
>
-- Original message --
From: Thomas Gleixner <[EMAIL PROTECTED]>
> On Thu, 21 Feb 2008, Quel Qun wrote:
> > > > > Not that I'm aware off, but this might as well be some old use after
> > > > > free bug which got exposed by some unrelated change. The good news is
On Thu, 21 Feb 2008, Quel Qun wrote:
> > > > Not that I'm aware off, but this might as well be some old use after
> > > > free bug which got exposed by some unrelated change. The good news is
> > > > that it is reproducible. I'll hack up some nasty debug patch which
> > > > lets us - hopefully
-- Original message --
From: "Dave Young" <[EMAIL PROTECTED]>
> On Wed, Feb 20, 2008 at 4:11 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > On Wed, 20 Feb 2008, Thomas Gleixner wrote:
> > > On Tue, 19 Feb 2008, Marcel Holtmann wrote:
> >
> > > > I don't really
On Wed, Feb 20, 2008 at 4:11 PM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Feb 2008, Thomas Gleixner wrote:
> > On Tue, 19 Feb 2008, Marcel Holtmann wrote:
>
> > > I don't really have any idea. Nothing has been changed in this area for a
> > > couple of years. The command TX timeout
On Wed, 20 Feb 2008, Thomas Gleixner wrote:
> On Tue, 19 Feb 2008, Marcel Holtmann wrote:
> > I don't really have any idea. Nothing has been changed in this area for a
> > couple of years. The command TX timeout is the timeout that indicates a
> > missing answer to a command sent down to the Blueto
On Tue, 19 Feb 2008, Marcel Holtmann wrote:
> > > hci_cmd_task: hci0 command tx timeout
> > > BUG: unable to handle kernel paging request at 6b6b6b6b
> >
> > We got some more info ---
> > #define POISON_FREE 0x6b/* for use-after-free poisoning */
> >
> > S
Hi Thomas,
Can you please enable CONFIG_SLUB_DEBUG=y and CONFIG_SLUB_DEBUG_ON=y
and give it another try?
If we can not catch it that way, I'll whip up a patch which points
us
to the code which added the offending timer.
Hi,
Note: I switched to 2.6.25-rc2. The only new thing I see is this
On Mon, 18 Feb 2008, Quel Qun wrote:
Added bluetooth wizards to CC
> > Can you please enable CONFIG_SLUB_DEBUG=y and CONFIG_SLUB_DEBUG_ON=y
> > and give it another try?
> >
> > If we can not catch it that way, I'll whip up a patch which points us
> > to the code which added the offending timer.
* Quel Qun | 2008-02-18 00:01:21 [+]:
Please send me your .config file and process list (ps uax > ps_list)
after the crash. I have a dongle with the same usb id as yours and I
can't reproduce the crash. So it is either some .config magic or one of
your programs is accessing the dongle.
Sebast
-- Original message --
From: Thomas Gleixner <[EMAIL PROTECTED]>
> On Sat, 16 Feb 2008, Quel Qun wrote:
> Unfortunately we only see that the list is corrupted but not which
> code caused it. This looks like something forgot to delete the timer
> before freeing the d
On Sat, 16 Feb 2008, Quel Qun wrote:
> > Please also enable CONFIG_DEBUG_LIST=y, which should catch the place
> > where a list corruption happens.
>
> Thank you for the hand holding. I must admit I do not anything
> about kernel debugging.
>
> With or without nohz=off, the crashes are very similar.
-- Original message --
From: Thomas Gleixner <[EMAIL PROTECTED]>
> On Sat, 16 Feb 2008, Jiri Kosina wrote:
> > [ Ingo and Thomas added to CC, as this is apparently nohz stuff ]
>
> Well, it explodes there :) I can not exactly decode the source line,
> but it's eith
On Sat, 16 Feb 2008, Jiri Kosina wrote:
> [ Ingo and Thomas added to CC, as this is apparently nohz stuff ]
Well, it explodes there :) I can not exactly decode the source line,
but it's either list corruption or something is fiddling with an
enqueued timer.
> Quel, does the problem go away when y
[ Ingo and Thomas added to CC, as this is apparently nohz stuff ]
Quel, does the problem go away when you boot with nohz=off?
Original message left below for reference.
On Sat, 16 Feb 2008, Quel Qun wrote:
> Hi,
>
> Since the rc's of 2.6.24, my machine crashes when I try to use the USB
> dong
On Tuesday 05 February 2008 07:57, Andrej Hocevar wrote:
> this has occured a couple of times. i was editing a unicode file with
> vim in the console. after a reboot, i immediately tried to do just that
> again and it crashed. it might have occured upon trying to select some
> text with the mouse (
On 09/01/2008, Stoyan Gaydarov <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 9:02 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > Except this time when rebooting the machine i got a kernel oops
> > > message and it didn't boot completely. I could not copy it but I did
> > > take a picture and now I hav
On Jan 8, 2008 9:02 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > Except this time when rebooting the machine i got a kernel oops
> > message and it didn't boot completely. I could not copy it but I did
> > take a picture and now I have re-written the screen here(sorry about
>
> That is interesting -
> Except this time when rebooting the machine i got a kernel oops
> message and it didn't boot completely. I could not copy it but I did
> take a picture and now I have re-written the screen here(sorry about
That is interesting - that sort of error usually points at memory
corruption and early on
On Jan 7, 2008 5:30 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2008 17:15:01 -0600
> "Stoyan Gaydarov" <[EMAIL PROTECTED]> wrote:
>
> > Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> > 30 minutes I have had to restart my computer twice.
> > I believe its a kern
On 08/01/2008, Stoyan Gaydarov <[EMAIL PROTECTED]> wrote:
> Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> 30 minutes I have had to restart my computer twice.
> I believe its a kernel oops or a kernel panic because when the
> computer freezes it blinks the caps and scroll l
On Mon, 7 Jan 2008 17:15:01 -0600
"Stoyan Gaydarov" <[EMAIL PROTECTED]> wrote:
> Today I upgraded my kernel from 2.6.23.9 to 2.6.23.12 and in the past
> 30 minutes I have had to restart my computer twice.
> I believe its a kernel oops or a kernel panic because when the
> computer freezes it blinks
--- Raman Gupta <[EMAIL PROTECTED]> wrote:
> I just found this bug:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8198
>
> This seems to indicate the problem was resolved in 2.6.21.2.
>
> However, I also found this, where you reported the problem was back in
> 2.6.22.9 (which is what I am curr
> We've come across an Oops, in what appears to NFS.
>
> 2.6.22.6 vanilla + realtime-lsm
> RHEL4 over PXE/NFS_ROOT
>
>
> Oct 9 14:26:13 WS15 gdm(pam_unix)[6038]: session opened for
> user mockj by (uid=0) Oct 9 14:26:48 WS15 gconfd
> (mockj-7583): starting (version 2.8.1), pid
> 7583 user 'm
1 - 100 of 208 matches
Mail list logo
