On Fri, Nov 13, 2020 at 2:56 PM David Hildenbrand wrote:
>
> On 13.11.20 14:36, wi nk wrote:
> > On Fri, Nov 13, 2020 at 1:52 PM Pavel Procopiuc
> > wrote:
> >>
> >> Op 13.11.2020 om 12:08 schreef Carl Huang:
> >>> Checked some logs. Looks when the error happens, the physical address are
> >>> ve
On 13.11.20 14:36, wi nk wrote:
On Fri, Nov 13, 2020 at 1:52 PM Pavel Procopiuc
wrote:
Op 13.11.2020 om 12:08 schreef Carl Huang:
Checked some logs. Looks when the error happens, the physical address are
very small. Its' between 20M - 30M.
So could you have a try to reserve the memory starti
On Fri, Nov 13, 2020 at 1:52 PM Pavel Procopiuc
wrote:
>
> Op 13.11.2020 om 12:08 schreef Carl Huang:
> > Checked some logs. Looks when the error happens, the physical address are
> > very small. Its' between 20M - 30M.
> >
> > So could you have a try to reserve the memory starting from 20M?
> > A
Op 13.11.2020 om 12:08 schreef Carl Huang:
Checked some logs. Looks when the error happens, the physical address are
very small. Its' between 20M - 30M.
So could you have a try to reserve the memory starting from 20M?
Add "memmap=10M\$20M" to your grub.cfg or edit in kernel parameters. so ath11k
On 2020-11-13 19:08, Carl Huang wrote:
On 2020-11-13 16:17, Pavel Procopiuc wrote:
Op 12.11.2020 om 11:48 schreef David Hildenbrand:
Trying to understand the code, it looks like there are always two
rounds of reqests. The first one always fails ("requesting one big
chunk of DMA memory"), the s
On 2020-11-13 16:17, Pavel Procopiuc wrote:
Op 12.11.2020 om 11:48 schreef David Hildenbrand:
Trying to understand the code, it looks like there are always two
rounds of reqests. The first one always fails ("requesting one big
chunk of DMA memory"), the second one (providing multiple chunks of
Op 12.11.2020 om 11:48 schreef David Hildenbrand:
Trying to understand the code, it looks like there are always two rounds of reqests. The first one always fails
("requesting one big chunk of DMA memory"), the second one (providing multiple chunks of DMA memory) is supposed to work
- and we do a
On 11.11.20 21:41, Pavel Procopiuc wrote:
Op 11.11.2020 om 20:23 schreef Kalle Valo:
Pavel, can you test with that patch on v5.10-rc2 and provide the ath11k
log messages? Preferably both before and after reverting commit
7fef431be9c9. Do note that I'm not expecting the debug patch to fix
anythin
Op 11.11.2020 om 20:23 schreef Kalle Valo:
Pavel, can you test with that patch on v5.10-rc2 and provide the ath11k
log messages? Preferably both before and after reverting commit
7fef431be9c9. Do note that I'm not expecting the debug patch to fix
anything, in your case it's just for providing mor
David Hildenbrand writes:
>> Am 05.11.2020 um 11:42 schrieb Vlastimil Babka :
>>
>> On 11/5/20 10:04 AM, Kalle Valo wrote:
>>> (changing the subject, adding more lists and people)
>>> Pavel Procopiuc writes:
Op 04.11.2020 om 10:12 schreef Kalle Valo:
> Yeah, it is unfortunately time c
On 06.11.20 18:32, Pavel Procopiuc wrote:
Op 05.11.2020 om 21:23 schreef David Hildenbrand:
So just to make sure I understand you correctly, you'd like to see if the
problem with ath11k driver on my hardware persists when I boot pristine
5.10-rc2 kernel (without reverting commit
7fef431be9c9a
Op 05.11.2020 om 21:23 schreef David Hildenbrand:
So just to make sure I understand you correctly, you'd like to see if the
problem with ath11k driver on my hardware persists when I boot pristine
5.10-rc2 kernel (without reverting commit
7fef431be9c9ac255838a9578331567b9dba4477) and with page_
> Am 05.11.2020 um 13:55 schrieb Pavel Procopiuc :
>
> Op 05.11.2020 om 12:13 schreef David Hildenbrand:
>> It depends in which order memory is exposed to MM, which might depend on
>> other factors in some configurations.
>> This smells like it exposes an existing bug. Can you reproduce also w
Op 05.11.2020 om 12:13 schreef David Hildenbrand:
It depends in which order memory is exposed to MM, which might depend on other
factors in some configurations.
This smells like it exposes an existing bug. Can you reproduce also with zone
shuffling enabled?
So just to make sure I understand
> Am 05.11.2020 um 11:42 schrieb Vlastimil Babka :
>
> On 11/5/20 10:04 AM, Kalle Valo wrote:
>> (changing the subject, adding more lists and people)
>> Pavel Procopiuc writes:
>>> Op 04.11.2020 om 10:12 schreef Kalle Valo:
Yeah, it is unfortunately time consuming but it is the best way t
Op 05.11.2020 om 11:42 schreef Vlastimil Babka:
Let me paste from the ath11k discussion:
* Relevant errors from the log:
# journalctl -b | grep -iP '05:00|ath11k'
Nov 02 10:41:26 razor kernel: pci :05:00.0: [17cb:1101] type 00 class
0x028000
Nov 02 10:41:26 razor kernel: pci :05:00.0:
On 11/5/20 10:04 AM, Kalle Valo wrote:
(changing the subject, adding more lists and people)
Pavel Procopiuc writes:
Op 04.11.2020 om 10:12 schreef Kalle Valo:
Yeah, it is unfortunately time consuming but it is the best way to get
bottom of this.
I have found the commit that breaks things f
Op 05.11.2020 om 10:04 schreef Kalle Valo:
Oh, very interesting. Thanks a lot for the bisection, otherwise we would
have never found out whats causing this.
David & mm folks: Pavel noticed that his QCA6390 Wi-Fi 6 device (driver
ath11k) failed on v5.10-rc1. After bisecting he found that the comm
(changing the subject, adding more lists and people)
Pavel Procopiuc writes:
> Op 04.11.2020 om 10:12 schreef Kalle Valo:
>> Yeah, it is unfortunately time consuming but it is the best way to get
>> bottom of this.
>
> I have found the commit that breaks things for me, it's
> 7fef431be9c9ac25583
19 matches
Mail list logo
