I'm running into a problem with what I think is the padlock_aes driver. It seems
to be related to the fix of commit faf996d6cdc3a8e6205ae5226f667aa7d1f5f6c2
(crypto: padlock - fix VIA PadLock instruction usage with
irq_ts_save/restore()), but I'm pretty sure that that fix is already in my
kernel. So here's a copy of the bugzilla report (
[1.] One line summary of the problem:
BUG: unable to handle kernel NULL pointer dereference at 000001f0
[2.] Full description of the problem/report:
I'm trying to netboot with NFS over IPsec on a VIA EPIA EN15000G board. I have
modified initramfs to make this possible. Somewhere after setting up IPsec but
before the root is mounted, the kernel crashes. When I don't load padlock_aes,
the machine boots just fine.
[3.] Keywords (i.e., modules, networking, kernel):
[4.] Kernel version (from /proc/version):
Linux version 2.6.26-2-686 (Debian 2.6.26-26lenny2) ([email protected]) (gcc
version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Jan 27
00:28:05 UTC 2011
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
See attached 'dmesg'
[6.] A small shell script or example program which triggers the
problem (if possible)
On request, I can provide a kernel and ram image that can be netbooted to create
the problem, but there are a lot of environment-specific configurations.
Note that all attached files are created after I've booted the system without
using IPsec, and thus may not represent the system state properly.
[7.1.] Software (add the output of the ver_linux script here)
See attached 'ver_linux'.
[7.2.] Processor information (from /proc/cpuinfo):
See attached 'cpuinfo'.
[7.3.] Module information (from /proc/modules):
See attached 'modules'.
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
See attached 'ioports', 'iomem'.
[7.5.] PCI information ('lspci -vvv' as root)
See attached 'lspci'.
[7.6.] SCSI information (from /proc/scsi/scsi)
No SCSI devices.
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
See attached 'crypto', which is a dump of /proc/crypto, again after I've booted
the system without using IPsec.
Please let me know if you need any more information, and I will see what I can
On Sun, Jun 19, 2011 at 03:08:34PM +0000, Jethro Beekman - E.T.S.V. Scintilla wrote:
> I'm running into a problem with what I think is the padlock_aes driver.
> It seems to be related to the fix of commit
> faf996d6cdc3a8e6205ae5226f667aa7d1f5f6c2 (crypto: padlock - fix VIA
> PadLock instruction usage with irq_ts_save/restore()), but I'm pretty
> sure that that fix is already in my kernel. So here's a copy of the
> bugzilla report ( https://bugzilla.kernel.org/show_bug.cgi?id=37862 ):
Hmm, why do you think that patch is in your 2.6.26 kernel when
it was added in 2.6.27?
In any case, please try to reproduce this with the latest upstream
kernel instead of an ancient distro kernel.
If for whatever reason you're stuck with your distro kernel then
please seek advice from your distribution maker.
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt