[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CBDDDC2F-34FC-42B3-84EF-5F3BEA5AC480@rocketmail.com>
Date: Fri, 19 Jul 2024 17:40:59 +0200
From: Max Dubois <makemehappy@...ketmail.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
ilpo.jarvinen@...ux.intel.com, gregkh@...uxfoundation.org,
Dan Carpenter <error27@...il.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Bug related with a 6.6.24 platform/x86 commit signed by you - Enormous memory leak
I’m sorry, yes that file i called ‘working’ contain multiple kernels instances becouae I had to do a path to find out the crash happened at 6.6.24 level and that the last working kernel was 6.6.23. So I did a try to a lot of kernels over and under 6.6.24 to isolate the problem to 6.6.24 and everything after.
If needed I can try to isolate the instance of the working 6.6.23 and I can’t confirm it does NO ERRORS at all like the kernels before it.
Buggy 6.6.24 log it is corrrext, the real 6.6.24 log with buga on vmalloc.
If needed I can confirm I can test any possible fix and/or patch against 6.6.24.
Thank you
MD
Inviato da iPhone
> Il giorno 19 lug 2024, alle ore 17:12, Dan Carpenter <dan.carpenter@...aro.org> ha scritto:
>
> On Fri, Jul 19, 2024 at 10:01:14AM -0500, Dan Carpenter wrote:
>>
>> The interesting thing about that is the working kernel had tons of these
>> allocation failures as well.
>> https://bugzilla.kernel.org/show_bug.cgi?id=219061
>> See the attachment which called "This is a session with the last WORKING
>> KERNEL 6.6.23, NO ERRORS, everything fine".
>
> Never mind. There are a bunch of different reboots in that file with
> different kernels.
>
> regards,
> dan carpenter
>
Powered by blists - more mailing lists