linux-kernel - Re: USB transfer_buffer allocations on 64bit systems

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:	Wed, 14 Apr 2010 22:12:03 +0100
From:	Pedro Ribeiro <pedrib@...il.com>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Daniel Mack <daniel@...aq.de>,
	USB list <linux-usb@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, iommu@...ts.linux-foundation.org,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: USB transfer_buffer allocations on 64bit systems

On 14 April 2010 19:36, David Woodhouse <dwmw2@...radead.org> wrote:
> On Wed, 2010-04-14 at 14:15 -0400, Alan Stern wrote:
>>
>> Since using mem=4096M or GFP_DMA stopped the symptoms, it seems very
>> likely that a buffer is getting allocated above the 4 GB line and not
>> bounced or IOMMU-mapped correctly.
>>
>> David, do you have anything to suggest?  Any ways to check for IOMMU
>> or related errors?
>>
>> The problem, in short, is that USB audio doesn't work properly when
>> Pedro boots a 64-bit kernel on his 4-GB machine.  With a 32-bit kernel
>> it works okay, and it also works if we use dma_alloc_coherent().  The
>> host controller is limited to 32-bit DMA, and the DMA addresses
>> generated by dma_map_single() appear to be normal.
>>
>> At the moment we don't even know if this is caused by a bug in the
>> kernel or a bug in Pedro's hardware.  But he has observed the same
>> problem on two different machines, both using the ICH9 chipset.
>
> Pedro's dmesg suggests that his machine has an IOMMU, but his kernel
> isn't built to support it. So he'll be using swiotlb.
>
> Would be interesting to enable CONFIG_DMAR and check whether the problem
> goes away. If so, we can start looking harder at the swiotlb code.
>
> --
> David Woodhouse                            Open Source Technology Centre
> David.Woodhouse@...el.com                              Intel Corporation
>
>

Turns out CONFIG_DMAR was disabled because of PREEMPT_RT. I disabled
the later and enabled _DMAR. It took a long time to boot, something
wrong with the usb ports. You can see it in the appended dmesg from
time 11s to 100s.

 Then after it booted, I could barely move my USB mouse and lots of
errors appeared on dmesg. I tried to connect the DVB card but it
wouldn't even initialize.

Enabling it with iommu=pt seemed to make no difference.

Thanks,
Pedro

Download attachment "dmesg.dmar.tar.bz2" of type "application/x-bzip2" (22398 bytes)