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]

Message-ID: <g2h74fd948d1004141820ladc1941eo732d059dd678df0a@mail.gmail.com>
Date:	Thu, 15 Apr 2010 02:20:27 +0100
From:	Pedro Ribeiro <pedrib@...il.com>
To:	Chris Wright <chrisw@...s-sol.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	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
Subject: Re: USB transfer_buffer allocations on 64bit systems

On 15 April 2010 00:37, Chris Wright <chrisw@...s-sol.org> wrote:
> * Pedro Ribeiro (pedrib@...il.com) wrote:
>> On 14 April 2010 23:25, Chris Wright <chrisw@...s-sol.org> wrote:
>> > * Pedro Ribeiro (pedrib@...il.com) wrote:
>> >> 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.
>> >
>> > [  316.360045] DMAR:[DMA Write] Request device [00:02.0] fault addr 23c00000
>> > [  316.360046] DMAR:[fault reason 05] PTE Write access is not set
>> >
>> > That's your video device.  Do you have CONFIG_DMAR_BROKEN_GFX_WA=y?
>>
>> Where do I find this option in make menuconfig? Doesn't seem to be available...
>
> It's hidden behind CONFIG_BROKEN.  The iommu=pt test puts all devices in
> a 1:1 mapping (the broken graphics workaround does that just for all
> graphics devices).
>
>> >> Enabling it with iommu=pt seemed to make no difference.
>> >
>> > It should (it should at least eliminate the video device problem).
>>
>> You are right, it does eliminate that problem. However I can't get any
>> of the USB devices to work, and the mouse is terribly slow. One more
>> dmesg attached.
>
> Thanks.  It works for me here.  I just booted 2.6.33-rt4 on my T400 w/
> iommu on, and an external USB mouse is working fine (I don't have the
> same number of devices plugged in as you do).  You are not seeing DMA
> faults which suggest that the IOMMU mappings are correct w.r.t. the DMA
> transactions that the controller is initiating.
>
> thanks,
> -chris
>

I enabled  CONFIG_DMAR_BROKEN_GFX_WA=y and the result is the same. A
delay in the boot process and usb devices don't work properly,
including my USB mouse.

Strange, since you have the same platform as me. The extra usb devices
you were seeing are because of my docking station - but it makes no
difference whether I'm docked or not for the purposes of the original
bug or this situation right now. The dmesg I'm attaching is without
the computer being docked.

Pedro

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