Andrew Morton wrote :
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 9 Feb 2009 09:12:59 -0800 (PST)
bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=12680
Summary: Not having a VIA PadLock hardware incurs a long delay in
probing on modules insertion attempt.
Product: Drivers
Version: 2.5
KernelVersion: Any 2.6.29 release candidate
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: drivers_other@xxxxxxxxxxxxxxxxxxxx
hm, we don't seem to have a bugzilla category for crypto.
ReportedBy: v.quequet-techniques@xxxxxxxxx
Latest working kernel version: 2.6.28.4
Earliest failing kernel version: 2.6.29-rc1
I'll ask Rafael to track this as a post-2.6.28 regression.
Distribution:
Hardware Environment: IA32 i686 Athlon model 10
Software Environment: Pristine kernel 2.6.29-rc4-git1 + Debian Lenny/Sid
Problem Description: Not having a VIA PadLock hardware incurs a long delay in
probing on modules insertion attempt:
I can't say whether this abnormally long probe delay occurs on "padlock_aes"
or "padlock_sha" module insertion attempt or both.
I do not have such hardware indeed.
I've never observed this problem so far with Linux version <= 2.6.28.4 .
Steps to reproduce:
Power-on your system ;-)
In hope my report will prove useful.
Neither of those drivers have changed in six months, so the breakage
must be elsewhere.
Hello,
I fear you're right:
It's setting up an LVM volume which takes over 20 seconds, sometimes
more than 1 minute on my system when I run Linux 2.6.29-rcX... ; and no
problem with Linux <= 2.6.28.4 though.
I understand this is quite a vague description of the trouble, and I'm
considering more analysis in the near future.
This might be a Debian Lenny/Sid specific bug. I'm sorry for my
eagerness to fill in my initial bug report, because I wrongly considered
PadLock-related modules responsible for that delay.
I guess this should be easy for others to reproduce.
How long is the "long" delay?
Please do this:
add "log_buf_len=1M" to the kernel boot command line
reboot
dmesg -n 8
modprobe padlock_aes &
sleep 1
echo t > /prog/sysrq-trigger
dmesg -s 1000000 > foo
and then send us `foo'. Pleas avoid wordwrapping it.
This will permit us to see where `modprobe' is getting stuck.
No delay observed doing these commands ; I was wrong.
Thanks.
Thanks too.
On the Debian Lenny/Sid average user point of view, it is still a
post-2.6.28 regression, though. Note: I only did comparisons between
different Pristine kernel versions.
But I am sorry not having more accurate clues about that trouble.
In hope my report will prove useful.
Sincerely,
Valentin QUEQUET
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
