On 7/1/2019 10:48 AM, Christoph Hellwig wrote:
On Fri, Jun 14, 2019 at 03:47:10PM +0200, Christoph Hellwig wrote:
Switching to a slightly cleaned up alloc_pages_exact is pretty easy,
but it turns out that because we didn't filter valid gfp_t flags
on the DMA allocator, a bunch of drivers were
On 09/05/14 10:50, Johannes Berg wrote:
> From: Johannes Berg
>
> Many devices run firmware and/or complex hardware, and most of that
> can have bugs. When it misbehaves, however, it is often much harder
> to debug than software running on the host.
>
> Introduce a "device coredump" mechanism to al
On 01-07-14 12:57, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
It would help to use '-M' option with format-patch for this kind of rework.
Regards,
Arend
> ---
> Documentation/DocBook/device-drivers.tmpl |3
> MAINTAINERS |4
> drivers/Ma
I am getting used to getting a lockdep splat after every kernel merge
window. If I recall it I have seen this in -rc1 as well. The lockdep
warning in the attached log is seen upon shutting down the kernel and it
completes it so it probably just needs proper lockdep annotation.
Regards,
Arend
--
On 03/07/13 12:20, Arend van Spriel wrote:
> On 03/04/13 22:16, Borislav Petkov wrote:
>> New -rc1, so let the stabilization games begin.
>>
>> I see the following on rc1, let me know if you need more info.
>>
>>
>> [ 0.633617]
On 03/04/13 22:16, Borislav Petkov wrote:
> New -rc1, so let the stabilization games begin.
>
> I see the following on rc1, let me know if you need more info.
>
>
> [0.633617] =
> [0.633618] [ INFO: possible recursive locking detected ]
> [0.6
Maybe this one is already known, but I did not find a post about it. So
here it is.
Regards,
Arend
==
[9.422018] usb 1-1.2: new high-speed USB device number 4 using ehci-pci
[9.436177] [TTM] Zone kernel: Available gr
Maybe this one is already known, but I did not find a post about it. So
here it is.
Regards,
Arend
==
[9.422018] usb 1-1.2: new high-speed USB device number 4 using ehci-pci
[9.436177] [TTM] Zone kernel: Available gr
Not sure if it is a kernel issue or user-space. Truth is probably
somewhere in the middle. It popped up moving to 3.8-rc1 using nouveau.
Using nvidia's driver works fine. With nouveau, after entering login
credentials in lightDM the user session does not start and I am back at
the lightDM login scr
Not sure if it is a kernel issue or user-space. Truth is probably
somewhere in the middle. It popped up moving to 3.8-rc1 using nouveau.
Using nvidia's driver works fine. With nouveau, after entering login
credentials in lightDM the user session does not start and I am back at
the lightDM login scr
On 11/30/2012 09:25 PM, Luis R. Rodriguez wrote:
> On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez
> wrote:
>> On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel
>> wrote:
>>> So what is the rationale here. During mainlining our drivers we had to
>>> re
On 11/30/2012 09:25 PM, Luis R. Rodriguez wrote:
> On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez
> wrote:
>> On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel
>> wrote:
>>> So what is the rationale here. During mainlining our drivers we had to
>>> re
On 11/29/2012 09:45 PM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Turns out a few drivers have strayed away from using the
> spinlock_t typedef and decided to use struct spinlock
> directly. This series converts these drivers to use
> spinlock_t. Each change has been compile tested
On 11/29/2012 09:45 PM, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Turns out a few drivers have strayed away from using the
> spinlock_t typedef and decided to use struct spinlock
> directly. This series converts these drivers to use
> spinlock_t. Each change has been compile tested
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
> On 10/24/2012 01:14 PM, Arend van Spriel wrote:
>> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>>> I have this lockdep warning on wireless-testing tree based
>>> on 3.7-rc1 (no other p
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
> On 10/24/2012 01:14 PM, Arend van Spriel wrote:
>> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>>> I have this lockdep warning on wireless-testing tree based
>>> on 3.7-rc1 (no other p
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>> I have this lockdep warning on wireless-testing tree based
>> on 3.7-rc1 (no other patches except wireless bits).
>>
>> =
&
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
> I have this lockdep warning on wireless-testing tree based
> on 3.7-rc1 (no other patches except wireless bits).
>
> =
> Restarting tasks ... done.
> [ INFO: possible recursive locking detected ]
> 3.7.0-
On 01/17/2012 02:12 AM, Linus Torvalds wrote:
> 2012/1/16 Arend van Spriel :
>>
>> I build a new kernel with MCE enabled. Same issue. I did not load bcma
>> or brcmsmac yet. Attached is trace I could pull from the kernel log
>> (str-test-*).
>
> Oh well. Everyth
23 matches
Mail list logo
