All of lore.kernel.org
 help / color / mirror / Atom feed
* Anyone brought up 9984 NIC on x86-64?
@ 2016-07-13 17:01 Ben Greear
  2016-07-13 17:22 ` Ben Greear
  2016-07-13 17:26 ` Manoharan, Rajkumar
  0 siblings, 2 replies; 7+ messages in thread
From: Ben Greear @ 2016-07-13 17:01 UTC (permalink / raw)
  To: ath10k

I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
but it immediately crashes due to IOMMU error when trying to allocate
memory.

I'm building the latest linux-ath tree now and will test that when it
is done, but I am curious to know if anyone has successfully booted
9984 on x86-64?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Anyone brought up 9984 NIC on x86-64?
  2016-07-13 17:01 Anyone brought up 9984 NIC on x86-64? Ben Greear
@ 2016-07-13 17:22 ` Ben Greear
  2016-07-13 17:26 ` Manoharan, Rajkumar
  1 sibling, 0 replies; 7+ messages in thread
From: Ben Greear @ 2016-07-13 17:22 UTC (permalink / raw)
  To: ath10k

On 07/13/2016 10:01 AM, Ben Greear wrote:
> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
> but it immediately crashes due to IOMMU error when trying to allocate
> memory.
>
> I'm building the latest linux-ath tree now and will test that when it
> is done, but I am curious to know if anyone has successfully booted
> 9984 on x86-64?
>
> Thanks,
> Ben
>

Today's stock linux-ath and stock 9984 firmware with 9984 NIC crashes on bootup as well :(

How completely frustrating!

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Anyone brought up 9984 NIC on x86-64?
  2016-07-13 17:01 Anyone brought up 9984 NIC on x86-64? Ben Greear
  2016-07-13 17:22 ` Ben Greear
@ 2016-07-13 17:26 ` Manoharan, Rajkumar
  2016-07-13 17:54   ` Ben Greear
  2016-07-13 23:12   ` Sebastian Gottschall
  1 sibling, 2 replies; 7+ messages in thread
From: Manoharan, Rajkumar @ 2016-07-13 17:26 UTC (permalink / raw)
  To: Ben Greear, ath10k

> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
> but it immediately crashes due to IOMMU error when trying to allocate
> memory.
> 
> I'm building the latest linux-ath tree now and will test that when it
> is done, but I am curious to know if anyone has successfully booted
> 9984 on x86-64?
> 
Ben,

Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with

https://patchwork.kernel.org/patch/9175029/

But increase WMI_MAX_MEM_CHUNK_SIZE to 512.

-Rajkumar

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Anyone brought up 9984 NIC on x86-64?
  2016-07-13 17:26 ` Manoharan, Rajkumar
@ 2016-07-13 17:54   ` Ben Greear
  2016-07-13 19:17     ` Adrian Chadd
  2016-07-13 21:14     ` Ben Greear
  2016-07-13 23:12   ` Sebastian Gottschall
  1 sibling, 2 replies; 7+ messages in thread
From: Ben Greear @ 2016-07-13 17:54 UTC (permalink / raw)
  To: Manoharan, Rajkumar, ath10k

On 07/13/2016 10:26 AM, Manoharan, Rajkumar wrote:
>> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
>> but it immediately crashes due to IOMMU error when trying to allocate
>> memory.
>>
>> I'm building the latest linux-ath tree now and will test that when it
>> is done, but I am curious to know if anyone has successfully booted
>> 9984 on x86-64?
>>
> Ben,
>
> Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with

My BIDIRECTIONAL patch is in my 4.7, and that did not fix the issue.

It is more for the IOMMU access failures that I saw and the redhat user reported.

I would appreciate it if you could roll that patch into your testing set and
make sure you don't see regressions on your systems.  That way maybe it can go
upstream.



For reference, this is today's un-patched linux-ath:

DMA: Out of SW-IOMMU space for 770224 bytes at device 0000:05:00.0
Kernel panic - not syncing: DMA: Random memory could be DMA read

CPU: 5 PID: 288 Comm: kworker/u16:3 Not tainted 4.7.0-rc7-wt-ath+ #34
Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
  0000000000000000 ffff8800d3edfbf0 ffffffff8140abd1 ffffffff81c88b78
  ffff8800d3edfc80 ffff8800d3edfc70 ffffffff811ea260 ffff880000000008
  ffff8800d3edfc80 ffff8800d3edfc18 ffffffff811ea591 ffff88021e34db68
Call Trace:
  [<ffffffff8140abd1>] dump_stack+0x63/0x82
  [<ffffffff811ea260>] panic+0xca/0x216
  [<ffffffff811ea591>] ? printk+0x43/0x4b
  [<ffffffff814382a2>] swiotlb_map_page+0x1a2/0x1d0
  [<ffffffffa07ea1a9>] ath10k_wmi_event_service_ready_work+0x3f9/0x750 [ath10k_core]
  [<ffffffff8113667a>] ? dequeue_entity+0x26a/0xba0
  [<ffffffff8111aebd>] process_one_work+0x15d/0x4b0
  [<ffffffff8111b253>] worker_thread+0x43/0x4e0
  [<ffffffff8111b210>] ? process_one_work+0x4b0/0x4b0
  [<ffffffff81120a34>] kthread+0xc4/0xe0
  [<ffffffff81853e9f>] ret_from_fork+0x1f/0x40
  [<ffffffff81120970>] ? kthread_worker_fn+0x180/0x180
Kernel Offset: disabled
---[ end Kernel panic - not syncing: DMA: Random memory could be DMA read

I tried with your patch set to 512 block size, but that fails with
similar DMA error and reboots.

Your original patch with 256 block size boots up the firmware OK on my
system.

I guess I'll do more testing with your original 256k chunk patch and see
how that works.


Thanks,
Ben

>
> https://patchwork.kernel.org/patch/9175029/
>
> But increase WMI_MAX_MEM_CHUNK_SIZE to 512.
>
> -Rajkumar
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Anyone brought up 9984 NIC on x86-64?
  2016-07-13 17:54   ` Ben Greear
@ 2016-07-13 19:17     ` Adrian Chadd
  2016-07-13 21:14     ` Ben Greear
  1 sibling, 0 replies; 7+ messages in thread
From: Adrian Chadd @ 2016-07-13 19:17 UTC (permalink / raw)
  To: Ben Greear; +Cc: Manoharan, Rajkumar, ath10k

On 13 July 2016 at 10:54, Ben Greear <greearb@candelatech.com> wrote:

>
>
> For reference, this is today's un-patched linux-ath:
>
> DMA: Out of SW-IOMMU space for 770224 bytes at device 0000:05:00.0
> Kernel panic - not syncing: DMA: Random memory could be DMA read
>

Hi,

So I looked at this code in a bit more detail. Ideally for large
requests you shouldn't be asking for separate bounce buffers, you'd
just allocate memory that was within the 32 bit physmem boundary so
you don't /need/ a bounce buffer.

That's likely what's tripping things up.

Now, on freebsd I'd just request memory that was under 32 bit and the
memory allocator would fail the allocation if it wasn't available.
Bounce buffers get used for general system things like mbufs (our
skbs), disk buffers, etc that can come from any memory and need a
temporary mapping. This kind of stuff isn't temporary.

So to save me having to dig into what the linux kernel allocator
provides (since I'm really a freebsd developer at heart!), what's the
"right" way to maintain large, non-ephermal memory allocation that may
have to do DMA? eg, like descriptor rings, etc.



-adrian

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Anyone brought up 9984 NIC on x86-64?
  2016-07-13 17:54   ` Ben Greear
  2016-07-13 19:17     ` Adrian Chadd
@ 2016-07-13 21:14     ` Ben Greear
  1 sibling, 0 replies; 7+ messages in thread
From: Ben Greear @ 2016-07-13 21:14 UTC (permalink / raw)
  To: Manoharan, Rajkumar, ath10k

On 07/13/2016 10:54 AM, Ben Greear wrote:
> On 07/13/2016 10:26 AM, Manoharan, Rajkumar wrote:
>>> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
>>> but it immediately crashes due to IOMMU error when trying to allocate
>>> memory.
>>>
>>> I'm building the latest linux-ath tree now and will test that when it
>>> is done, but I am curious to know if anyone has successfully booted
>>> 9984 on x86-64?
>>>
>> Ben,
>>
>> Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with
>
> My BIDIRECTIONAL patch is in my 4.7, and that did not fix the issue.
>
> It is more for the IOMMU access failures that I saw and the redhat user reported.
>
> I would appreciate it if you could roll that patch into your testing set and
> make sure you don't see regressions on your systems.  That way maybe it can go
> upstream.
>
>
>
> For reference, this is today's un-patched linux-ath:
>
> DMA: Out of SW-IOMMU space for 770224 bytes at device 0000:05:00.0
> Kernel panic - not syncing: DMA: Random memory could be DMA read
>
> CPU: 5 PID: 288 Comm: kworker/u16:3 Not tainted 4.7.0-rc7-wt-ath+ #34
> Hardware name: To be filled by O.E.M. To be filled by O.E.M./ChiefRiver, BIOS 4.6.5 06/07/2013
> Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
>   0000000000000000 ffff8800d3edfbf0 ffffffff8140abd1 ffffffff81c88b78
>   ffff8800d3edfc80 ffff8800d3edfc70 ffffffff811ea260 ffff880000000008
>   ffff8800d3edfc80 ffff8800d3edfc18 ffffffff811ea591 ffff88021e34db68
> Call Trace:
>   [<ffffffff8140abd1>] dump_stack+0x63/0x82
>   [<ffffffff811ea260>] panic+0xca/0x216
>   [<ffffffff811ea591>] ? printk+0x43/0x4b
>   [<ffffffff814382a2>] swiotlb_map_page+0x1a2/0x1d0
>   [<ffffffffa07ea1a9>] ath10k_wmi_event_service_ready_work+0x3f9/0x750 [ath10k_core]
>   [<ffffffff8113667a>] ? dequeue_entity+0x26a/0xba0
>   [<ffffffff8111aebd>] process_one_work+0x15d/0x4b0
>   [<ffffffff8111b253>] worker_thread+0x43/0x4e0
>   [<ffffffff8111b210>] ? process_one_work+0x4b0/0x4b0
>   [<ffffffff81120a34>] kthread+0xc4/0xe0
>   [<ffffffff81853e9f>] ret_from_fork+0x1f/0x40
>   [<ffffffff81120970>] ? kthread_worker_fn+0x180/0x180
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: DMA: Random memory could be DMA read
>
> I tried with your patch set to 512 block size, but that fails with
> similar DMA error and reboots.
>
> Your original patch with 256 block size boots up the firmware OK on my
> system.
>
> I guess I'll do more testing with your original 256k chunk patch and see
> how that works.

I just realized that I was booting with "intel_iommu=off", that is probably why
I had to enable the 256k chunk patch.

And FYI, at least my 9984 firmware appears to blow up when passed multiple
chunks...I'm still trying to figure out exactly why.

That said, would be nice if ath10k worked on systems w/out intel-iommu too...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Anyone brought up 9984 NIC on x86-64?
  2016-07-13 17:26 ` Manoharan, Rajkumar
  2016-07-13 17:54   ` Ben Greear
@ 2016-07-13 23:12   ` Sebastian Gottschall
  1 sibling, 0 replies; 7+ messages in thread
From: Sebastian Gottschall @ 2016-07-13 23:12 UTC (permalink / raw)
  To: ath10k

Am 13.07.2016 um 19:26 schrieb Manoharan, Rajkumar:
>> I added a few patches to my 4.7 kernel to enable ath10k to load for 9984,
>> but it immediately crashes due to IOMMU error when trying to allocate
>> memory.
>>
>> I'm building the latest linux-ath tree now and will test that when it
>> is done, but I am curious to know if anyone has successfully booted
>> 9984 on x86-64?
>>
> Ben,
>
> Are you seeing IOMMU error even after wtih your DMA_BIDIRECTIONAL change? Could you please try with
>
> https://patchwork.kernel.org/patch/9175029/
>
> But increase WMI_MAX_MEM_CHUNK_SIZE to 512.
while debugging i found out that it will allocate up to 800 kb here on 
99xx chipsets. truncating  this value in any way will definitly cause 
out of bound access conditions.
so i assume the code is wrong. the firmware requests the size, so it 
should get it. otherwise unexpected behaviour is guaranteed

Sebastian
>
> -Rajkumar
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2016-07-13 23:12 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-13 17:01 Anyone brought up 9984 NIC on x86-64? Ben Greear
2016-07-13 17:22 ` Ben Greear
2016-07-13 17:26 ` Manoharan, Rajkumar
2016-07-13 17:54   ` Ben Greear
2016-07-13 19:17     ` Adrian Chadd
2016-07-13 21:14     ` Ben Greear
2016-07-13 23:12   ` Sebastian Gottschall

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.