linux-kernel - Re: amd5536udc interrupts bug

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: <496904E4.2000701@arcor.de>
Date:	Sat, 10 Jan 2009 21:28:20 +0100
From:	Thomas Dahlmann <dahlmann.thomas@...or.de>
To:	Vadim Lobanov <vlobanov@...akeasy.net>
CC:	linux-kernel@...r.kernel.org
Subject: Re: amd5536udc interrupts bug

Vadim Lobanov schrieb:
> On Friday 09 January 2009 03:41:21 Thomas Dahlmann wrote:
>   
>> Vadim Lobanov schrieb:
>>     
>>> Alas, the hardware doesn't work. When I try plugging in the other end of
>>> the USB cable, absolutely nothing happens. Not even an interrupt:
>>> /proc/interrupts for the amd5536udc line stays at zero. Any thoughts on
>>> possible ways to tackle this / what could be going wrong / etc?
>>>       
>
> Just realized that I forgot to mention that I do also have g_zero sitting on 
> top of amd5536udc, so there should at least be a dummy USB device to 
> enumerate.
>
>   
Right, g_zero should enumerate. It also provides data sink/source and 
loopback functionality.
If you want to test data traffic then g_file_storage would be a good 
choice as it behaves as a mass storage
device.

Example:
dd bs=1M count=64 if=/dev/zero of=/tmp/image_file
modrobe g_file_storage file=/tmp/image_file
(create partition and file system from host side)

>> Is there any output in the kernel messages on the host side complaining
>> about that device is
>> not answering? If not than USB device port is probably not connected to
>> UDC PHY. Please
>> check in BIOS setup that port 4 is assigned to UDC.
>>     
>
> Nope, nothing at all shows up in the logs or the interrupt counts when the 
> cable is plugged, neither for the host drivers nor the device drivers. (The 
> quickest test I have is to hook the device up to itself - one A port and one B 
> port.)
>
> The BIOS is configured "correctly" if the manuals are to be trusted. Here are 
> the relevant settings
> 	OHCI: Enabled
> 	EHCI: Enabled
> 	UDC: Enabled
> 	UOC: Disabled
> 	Overcurrent reporting: Disabled
> 	Port 4 assignment: Device
>   
UOC has to be enabled. This controller switches the UDC PHY to port 4 
and owns the mentioned
PAD_EN and APU bits. These bits live in the memory mapped register space 
of UOC. I use a
company intern tools to look at memory spaces of PCI devices. Lets 
forget these bits so far as I am
pretty sure that enabling UOC fixes the problem.

Thomas
--
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/