lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 6 Jul 2018 08:16:29 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Vinod <vkoul@...nel.org>
Cc:     Angelo Dureghello <angelo@...am.it>,
        Stefan Agner <stefan@...er.ch>, dmaengine@...r.kernel.org,
        Dan Williams <dan.j.williams@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [BUG] Serial/dma stall/failure after "dmaengine: fsl-edma:
 extract common fsl-edma code (no changes in behavior intended)"

On 6 July 2018 at 08:05, Vinod <vkoul@...nel.org> wrote:
> On 05-07-18, 18:23, Angelo Dureghello wrote:
>> Hi Stafan,
>>
>> On Thu, Jul 05, 2018 at 05:55:31PM +0200, Stefan Agner wrote:
>> > Hi Vinod, Hi Angelo,
>> >
>> > On 05.07.2018 14:45, Angelo Dureghello wrote:
>> > > Hi Vinod,
>> > >
>> > > On Thu, Jul 05, 2018 at 10:12:53AM +0200, Angelo Dureghello wrote:
>> > >> Hi Vinod,
>> > >>
>> > >> On Thu, Jul 05, 2018 at 01:05:52PM +0530, Vinod wrote:
>> > >> > On 04-07-18, 10:54, Krzysztof Kozlowski wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > The commit 6ad069123f03bebe4315dea13d44845854ca6043 ("dmaengine:
>> > >> > > fsl-edma: extract common fsl-edma code (no changes in behavior
>> > >> > > intended)"), even though marked as no changes in behavior intended...
>> > >> > > make serial console with DMA broken after boot. The console just hangs
>> > >> > > - is not responsive even to SysRq. Usually after finishing boot -
>> > >> > > before or after login prompt. Sometimes login is allowed and then it
>> > >> > > hangs during printing dmesg.
>> > >> > >
>> > >> > > Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial configured
>> > >> > > with DMA) on Iris Carrier.
>> > >> >
>> > >> > Angelo ?
>> > >> >
>> > >> sorry for this. As said i couldn't test it in any of those arm boards
>> > >> but i take a look.
>> > >>
>> > >> The only code part that changes is the initial setting up of the registers.
>> > >> I am checking that.
>> > >>
>> > >> Regards,
>> > >> Angelo
>> > >>
>> > >
>> > > I cannot find anything obviously wrong.
>> > > And i cannot test on Vybrid.
>> > > I will try to get a Vybrid V50 board to test this issue. It would
>> > > require some days and also i wil be 3 weeks off on July.
>> > >
>> > > So please revert my patch.
>> >
>> > I did not found the issue quickly. But I must say that I gave up pretty
>> > quickly. There are too many changes in a single patch which makes it
>> > hard to figure out what could be wrong. I'd rather prefer if we could
>> > drop that patch again and go through another review phase.
>> >
>> > Angelo, as far as I can see the patch has not been sent to LKML or the
>> > ARM mailing list. Especially since you do not have such a device it
>> > would have been nice to also send it to the ARM mailing list...
>> >
>> > Can you resend your last revision with CC to me/ARM mailing list?
>> >
>>
>> Thanks for looking into it.
>>
>> I have spent a lot of time on this patch and really would have
>> dma for Coldfire available. So, have ordered a Colibri / v50 board.
>>
>> Should receive it in few days and should be able to debug this issue,
>> but as said, i will be off for some weeks so looks like it is probably
>> better to revert the patch.
>>
>> My initial submit was a separate driver, to avoid such issues where
>> i cannot test, but it resulted in too much duplicated code.
>>
>> Sure, i can send the full patch to you/arm with all the fixes included
>> until now.
>
> Okay dropped now from -next. I still keeping topic/fsl around and
> collect other fixes for you guys to check.
>
> One way would be to split to common patch into multiple patch and check
> regression. That should help quickly identify the issue.

Even with show -C20% -M20% I gave up when trying to spot possible
differences in the commit. I understand that logically it is one
change and it makes sense... but it touches, moves and adds too much
making review extremely difficult. I think the splitting into smaller
chunks would be beneficial anyway.

Today's next boots fine.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ