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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100414233713.GC25962@sequoia.sous-sol.org>
Date:	Wed, 14 Apr 2010 16:37:13 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	Pedro Ribeiro <pedrib@...il.com>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	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

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/