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: <t2r74fd948d1004191716l49dedc2p25a27da39bcc614a@mail.gmail.com>
Date:	Tue, 20 Apr 2010 01:16:58 +0100
From:	Pedro Ribeiro <pedrib@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>,
	Daniel Mack <daniel@...aq.de>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	David Woodhouse <dwmw2@...radead.org>,
	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 16:20, Alan Stern <stern@...land.harvard.edu> wrote:
> On Thu, 15 Apr 2010, Pedro Ribeiro wrote:
>
>> 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.
>
> It's not possible to determine the reason for the timeout errors
> between timestamps 16 and 53 from the small amount of debugging
> information in the log.  Clearly something is going wrong with the
> communication between the computer and the EHCI controller.  And
> clearly the kernel config changes are responsible.
>
> But I don't know what to do to track it down any farther.
>
> Alan Stern
>
>

I guess this is pretty much a dead end until anyone else can reproduce it!

I'll continue to use Daniel's patches privately.

Daniel, should I use the big initial patch or the GFP_DMA one? Which
one is better for a system which is only rebooted every week or so (I
usually hibernate)?

Regards,
Pedro
--
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/