linux-kernel - 2.6.33-rc7 problems

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-next>] [day] [month] [year] [list]

Message-Id: <201002092306.07449.st@iss.tu-darmstadt.de>
Date:	Tue, 9 Feb 2010 23:06:07 +0100
From:	ST <st@....tu-darmstadt.de>
To:	linux-kernel@...r.kernel.org
Subject: 2.6.33-rc7 problems

Hi

I am currently running the linus main git tree with the last commit beeing:
deb0c98c7f6035d47a247e548384517a955314a5 (2.6.33-rc7)

USB Cardreader:
Since i am now in my third attempt to get my usb flashreader going under this
kernel (damn this must be simple right?). I have my doubts if this is probably 
not a .config but a kernel problem. If i plug in the usb card reader i get the 
output as attached in the file "usb_problems". The .config will be also 
attached. So i thought "ok, no problem i messed up", what about the defconfig.
(arch/x86/configs/x86_64_defconfig).
The defconfig works slightly better by omitting the repeating thread 
awake/thread sleeping output but no device is found usable. The distribution 
is Debian/Sid. The hardware is working with the standard Debian kernel 2.6.30.
I had a similar error when i had an typo in the default codepage "utf-8" vs. 
"utf8". But this error is fixed now and USB Sticks are working fine.

Firmware loading:
Firmware loading seems to hang this machine. It can be worked arround by 
embedding the firmware for the device (radeon onboard gfx) into the kernel
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
The microcode firmware loading also hangs for quite some time.

Disk access:
This is the most annoying: When dooing a md raid 1 level resync the machine
is barely usable. I haven't testet it with the current configuration but even 
when "update-grub" from grub2 is called the slowdown is really still there.
There is a file attached "timeouts" which give a output of such a scenario.
And boy 120s starvation is quite bad, right? Besides it doesn't seem fair to 
me either.

I am happy to test any patches you throw at me. Any hints tips are also very 
welcome.

Thanks
ST

PS: This is whitebox hw with a ASUS M4A78T-E Mainboard and 8 Gigs of ECC 
Memory and two SAMSUNG HD103SI in MD Raid 1 configuration.

PPS: Please CC as im am not subscribed on the list.

View attachment "usb_problems.txt" of type "text/plain" (59573 bytes)

View attachment "timeouts" of type "text/plain" (59849 bytes)

View attachment "config" of type "text/x-mpsub" (69698 bytes)

View attachment "lspci" of type "text/plain" (2000 bytes)

View attachment "lsusb" of type "text/plain" (711 bytes)

View attachment "cpuinfo" of type "text/plain" (3341 bytes)