Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1491073 > unrolled thread

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) khalasa@piap.pl (Krzysztof Hałasa) - 2016-09-26 07:40 +0200
    Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) Andrey Utkin <andrey_utkin@fastmail.com> - 2016-09-26 11:20 +0200
      Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) khalasa@piap.pl (Krzysztof Hałasa) - 2016-09-27 07:30 +0200
        Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) Andrey Utkin <andrey_utkin@fastmail.com> - 2016-09-27 09:50 +0200
          Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) khalasa@piap.pl (Krzysztof Hałasa) - 2016-09-27 13:40 +0200
            Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) Andrey Utkin <andrey_utkin@fastmail.com> - 2016-09-27 16:30 +0200
              Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) khalasa@piap.pl (Krzysztof Hałasa) - 2016-09-28 07:30 +0200

#1491073 — Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin <andrey_utkin@fastmail.com> writes:

> On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote:
>> I wonder if the following fixes the problem (completely untested).
>
> I have given this a run, and it still hangs.

Does (only) adding the

	pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);

in solo_reg_write() help?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[toc] | [next] | [standalone]

#1491171

On Mon, Sep 26, 2016 at 07:38:05AM +0200, Krzysztof Hałasa wrote:
> Andrey Utkin <andrey_utkin@fastmail.com> writes:
> 
> > On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote:
> >> I wonder if the following fixes the problem (completely untested).
> >
> > I have given this a run, and it still hangs.
> 
> Does (only) adding the
> 
> 	pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
> 
> in solo_reg_write() help?

Yes.
I have posted a patch with this change few days ago, I thought you have
noticed it.

[toc] | [prev] | [next] | [standalone]

#1491693

Andrey Utkin <andrey_utkin@fastmail.com> writes:

>> Does (only) adding the
>> 
>> 	pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
>> 
>> in solo_reg_write() help?
>
> Yes.
> I have posted a patch with this change few days ago, I thought you have
> noticed it.

Well, I think you haven't sent me a copy. Anyway, it would be great to
determine where exactly writes need a flush. Adding it everywhere is a
bit suboptimal, one would think.

Can you share some details about the machine you are experiencing the
problems on? CPU, chipset? I'd try to see if I can recreate the problem.

Alternatively, you could investigate yourself - at first you could put
pci_read_config_word() at the end of subroutines (including return
statements) using solo_reg_write(). And in that solo_p2m_dma_desc(),
before wait_for_completion_timeout(). Then eliminate them using some
sort of binary search to see which ones are required.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[toc] | [prev] | [next] | [standalone]

#1491725

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 27, 2016 at 07:27:53AM +0200, Krzysztof Hałasa wrote:
> Andrey Utkin <andrey_utkin@fastmail.com> writes:
> 
> >> Does (only) adding the
> >> 
> >> 	pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
> >> 
> >> in solo_reg_write() help?
> >
> > Yes.
> > I have posted a patch with this change few days ago, I thought you have
> > noticed it.
> 
> Well, I think you haven't sent me a copy. Anyway, it would be great to
> determine where exactly writes need a flush. Adding it everywhere is a
> bit suboptimal, one would think.

Oh, I'm terribly sorry, I really meant to send you a copy.
Actual posting is:
lkml.kernel.org/r/20160922000331.4193-1-andrey.utkin@corp.bluecherry.net

> Can you share some details about the machine you are experiencing the
> problems on? CPU, chipset? I'd try to see if I can recreate the problem.

See solo.txt.gz attached.

> Alternatively, you could investigate yourself - at first you could put
> pci_read_config_word() at the end of subroutines (including return
> statements) using solo_reg_write(). And in that solo_p2m_dma_desc(),
> before wait_for_completion_timeout(). Then eliminate them using some
> sort of binary search to see which ones are required.

Sorry, but I've got no time for this long-lasting debug session right
now, and except for this issue, users enjoy their mainline kernel
driver. So I'd just fix that in mainline kernels as quickly as possible.
Now I'm even considering submitting that to longterm 4.4 branch.

[toc] | [prev] | [next] | [standalone]

#1491837

Andrey Utkin <andrey_utkin@fastmail.com> writes:

>> Can you share some details about the machine you are experiencing the
>> problems on? CPU, chipset? I'd try to see if I can recreate the problem.
>
> See solo.txt.gz attached.

Thanks. I can see you have quite a set of video devices there.
I will see what I can do with this.

BTW does the lookup occur on SOLO6010, 6110, or both?
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[toc] | [prev] | [next] | [standalone]

#1491947

On Tue, Sep 27, 2016 at 01:33:49PM +0200, Krzysztof Hałasa wrote:
> Thanks. I can see you have quite a set of video devices there.
> I will see what I can do with this.

Yeah, I have got also 4-chip tw5864 board here :)
Bluecherry decided to switch to it because they are available for retail
purchase, unlike solo* which must be ordered in large batch. It was huge
reverse-engineering effort to make it work, though, and there are still
issues with H.264 encoding functionality, and audio functionality is not
done yet.

> BTW does the lookup occur on SOLO6010, 6110, or both?

Lockup happens only on 6010. In provided log you can see that 6110
passes just fine right before 6010. Also if 6010 PCI ID is removed from
solo6x10 driver's devices list, the freeze doesn't happen.

[toc] | [prev] | [next] | [standalone]

#1492268

Andrey Utkin <andrey_utkin@fastmail.com> writes:

> Lockup happens only on 6010. In provided log you can see that 6110
> passes just fine right before 6010. Also if 6010 PCI ID is removed from
> solo6x10 driver's devices list, the freeze doesn't happen.

Probably explains why I don't see lockups :-)

I will have a look.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web