Created attachment 62782 [details] Processor information (from /proc/cpuinfo) [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): crypto padlock_aes [4.] Kernel version (from /proc/version): Linux version 2.6.26-2-686 (Debian 2.6.26-26lenny2) (dannf@debian.org) (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. [7.] Environment 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. The problem 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.
Created attachment 62792 [details] Dump of /proc/crypto
Created attachment 62802 [details] dmesg with Oops.. message
Created attachment 62812 [details] Loaded driver and hardware information (/proc/iomem)
Created attachment 62822 [details] Loaded driver and hardware information (/proc/ioports)
Created attachment 62832 [details] PCI information ('lspci -vvv' as root)
Created attachment 62842 [details] Module information (from /proc/modules)
Created attachment 62852 [details] Output of the ver_linux script
(In reply to comment #0) > Created an attachment (id=62782) [details] > Processor information (from /proc/cpuinfo) > > [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): > crypto padlock_aes > > [4.] Kernel version (from /proc/version): > Linux version 2.6.26-2-686 (Debian 2.6.26-26lenny2) (dannf@debian.org) (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. > > [7.] Environment > 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. > > > > The problem 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.
Reply-To: herbert@gondor.hengli.com.au 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. Thanks,
That is interesting, on http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=history;f=drivers/crypto that particular patch is included but on https://github.com/mirrors/linux-2.6/commits/v2.6.26/drivers/crypto it isn't. Anyway, my distro's kernel source package has the patch applied. I will try to use the latest kernel, but in the very near future I won't be able to test on that system. In that case, I will try to get a colleague working on this.
Reply-To: herbert@gondor.hengli.com.au On Thu, Jul 28, 2011 at 09:20:13AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=37862 > > > > > > --- Comment #10 from Jethro Beekman <kernel@jbeekman.nl> 2011-07-28 09:20:13 > --- > That is interesting, on > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.26.y.git;a=history;f=drivers/crypto > that particular patch is included but on > https://github.com/mirrors/linux-2.6/commits/v2.6.26/drivers/crypto > it isn't. > > Anyway, my distro's kernel source package has the patch applied. OK, it does seem that it was applied. Suresh, any ideas what might be wrong here? The crash looks eerily like the one that was fixed by your patch. > I will try to use the latest kernel, but in the very near future I won't be > able to test on that system. In that case, I will try to get a colleague > working on this. Please do. Thanks,