I got the following dump during startup (4.11.0 stable):
[1.353688] registered taskstats version 1
[1.353974] Loading compiled-in X.509 certificates
[1.354582] [ cut here ]
[1.354904] kernel BUG at crypto/asymmetric_keys/public_key.c:96!
[1.355319] inval
sure if the QEMU reboot itself or not
--
Regards,
Peter Teoh
https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso.c
/* kuser helpers */
memcpy((void *)vpage + 0x1000 - kuser_sz, __kuser_helper_start,
kuser_sz);
/* sigreturn code */
memcpy((void *)vpage + AARCH32_KERN_SIGRET_CODE_OFFSET,
__aarch32_sigret_code_start, sigret_sz);
I am just cu
((width & (32/bpp-1)) == 0) &&
bpp >= 8 && bpp <= 32)
fast_imageblit(image, p, dst1, fgcolor, bgcolor);
else
slow_imageblit(image, p, dst1, fgcolor, bgcolor,
Discovered by Coccinelle. Removed the use of variable for storing
returning values, which is un-modified / un-used throughout.
Signed-off-by: Peter Teoh dfsentry->txstatlog;
- ssize_t count = 0;
int i, idx;
struct b43_txstatus *stat;
@@ -401,7 +400,7 @@ static ssiz
Discovered by Coccinelle. Removed the use of variable for storing
returning values, which is un-modified / un-used throughout.
Signed-off-by: Peter Teoh
diff -u -p a/drivers/net/irda/mcs7780.c b/drivers/net/irda/mcs7780.c
--- a/drivers/net/irda/mcs7780.c
+++ b/drivers/net/irda/mcs7780.c
Discovered by Coccinelle. Removed the use of variable for storing
returning values, which is un-modified / un-used throughout.
Signed-off-by: Peter Teoh http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Discovered by Coccinelle. Removed the use of variable for storing
returning values, which is un-modified / un-used throughout.
Signed-off-by: Peter Teoh wlc;
/* enter the MAC addr into the RXE match registers */
@@ -3785,7 +3784,7 @@ static int brcms_c_set_mac(struct brcms_
Discovered by Coccinelle. Removed the use of variable for storing
returning values, which is un-modified / un-used throughout.
Signed-off-by: Peter Teoh band != band)
- return ret_code;
+ return 0;
upd_stf_ss = (wlc->stf->txs
cripts/kconfig/lxdialog/util.o
HOSTCC scripts/kconfig/lxdialog/inputbox.o
The patch is provided below, to put in the extra checks for jump, and
it also added extra brackets to make the logical expression less
cryptic.
Signed-off-by: Peter Teoh
diff --git a/scripts/kconfig/menu.c b/scripts/k
Sorry, it is a toolchain bug. Instead of using the one from ELDK,
now I used the
http://download.ronetix.info/toolchains/powerpc/powerpc-eabi-4.3.3.tar.bz2
and everything went smoothly. Thanks.
On Sat, Jun 15, 2013 at 3:14 PM, Peter Teoh wrote:
>
> Compiling the latest linus-git ima
ard input}:82: Error: Unrecognized opcode: `mfdcrx'
make[1]: *** [arch/powerpc/boot/treeboot-currituck.o] Error 1
make: *** [uImage] Error 2
Question:
a. why is the "mkdir -p arch/powerpc/boot/" repeated so many times?
b. what is the cause of error "mfdcrx"?
Any idea wh
On 2/18/08, Sergio Luis <[EMAIL PROTECTED]> wrote:
> Peter Teoh wrote:
> > On 2/17/08, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> >> On Sun, 17 Feb 2008 08:58:39 +0800 Peter Teoh wrote:
> >>
> >>> Can some explain the cause of this error (it has
On 2/17/08, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Sun, 17 Feb 2008 08:58:39 +0800 Peter Teoh wrote:
>
> > Can some explain the cause of this error (it has been like this for the
> > last two git pull from linus tree):
> >
> > Kernel: arch/x86/boot/b
On 2/13/08, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 13, 2008 at 03:40:32PM +0800, Peter Teoh wrote:
> > some questions:
> >
> > a. the list of parameters can presumably be extracted from existing
> > file via "procname" search.not sure if i
On 2/13/08, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 13, 2008 at 12:59:43AM -0500, Scott Lovenberg wrote:
> > Randy Dunlap wrote:
> >> On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote:
> >>
> >>
> >>> Hi all...
> >>>
> >>> Here's my idea: what if we collaborate to extend and make th
On 2/13/08, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Feb 2008 09:08:12 +0700 Mulyadi Santosa wrote:
>
> > Hi all...
> >
> > Here's my idea: what if we collaborate to extend and make the kernel
> > documentation better? I have done (slow) start by editing profile=
> > kernel param. It's
On Feb 12, 2008 2:17 PM, Scott Lovenberg <[EMAIL PROTECTED]> wrote:
>
> On Feb 12, 2008 12:23 AM, Peter Teoh <[EMAIL PROTECTED]> wrote:
> >
> > I was looking for documentation on the kstack_depth_to_print under
> /proc/sys/kernel, and I found it in Documenta
I was looking for documentation on the kstack_depth_to_print under
/proc/sys/kernel, and I found it in Documentation/sysctl.txt (written
by Rik).
How about /proc/sys/net? or all other directories under /sys or /proc fs?
Wouldn't it be useful to have a centralized store located in
Documentation
the function __cpuinit relay_hotcpu_callback()
If the reference is valid then annotate the
variable with __init* (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Peter Teoh <[EMAIL PROTECTED]>
--- relay.
compilation.
Based on my "elementary" analysis, as it is called from other
non-__init functions, this function cannot be declared as __devinit(),
correct? Please comment. Thanks :-).
Signed-off-by: Peter Teoh <[EMAIL PROTECTED]>
--- workqueue.c.orig2008-02-04 10:47:03
function can reincarnate as two different
section naming If not possible, then the following is the fix to
correct all the above warning:
Signed-off-by: Peter Teoh <[EMAIL PROTECTED]>
--- cpu.c.orig 2008-02-04 09:36:35.0 +0800
+++ cpu.c 2008-02-04 10:04:35.0 +0800
@@
In kernel/cpu.c, there exists API that is declared as __cpuinit, and
at the same time exported via EXPORT_SYMBOL().
Can these two attribute coexists at the same time? I mean, when it
is declared with EXPORT_SYMBOL, according to include/linux/module.h,
it is placed in a __ksymtab section, and whe
() references
the function __devinit sis190_get_mac_addr_from_eeprom().
This is often because sis190_get_mac_addr lacks a __devinit
annotation or the annotation of sis190_get_mac_addr_from_eeprom is wrong.
The following patch is to fix the above problems - please comment:
Signed-off-by: Peter Teoh
On 2/3/08, Peter Teoh <[EMAIL PROTECTED]> wrote:
> On 2/3/08, Wenji Huang <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Found compilation error in 2.6.24-git12/git13:
> >
> > CC [M] drivers/scsi/lpfc/lpfc_mem.o
> > CC [M] drivers/scsi/lpfc/l
On 2/3/08, Wenji Huang <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Found compilation error in 2.6.24-git12/git13:
>
> CC [M] drivers/scsi/lpfc/lpfc_mem.o
> CC [M] drivers/scsi/lpfc/lpfc_sli.o
> CC [M] drivers/scsi/lpfc/lpfc_ct.o
> CC [M] drivers/scsi/lpfc/lpfc_els.o
> CC [M] drivers/scsi/l
the
non-debug symbol disappearing, but not the debug version. Am I
correct?
Signed-off-by: Peter Teoh <[EMAIL PROTECTED]>
--- scripts/mod/modpost.c.orig 2008-02-02 15:18:04.0 +0800
+++ scripts/mod/modpost.c 2008-02-02 15:18:47.0 +0800
@@ -1942,7 +1942,7 @@ int main(in
put in by everyone - I
apologized for that :-(. Please comment - I am just correcting it
syntactically to overcome all the section mismatches errors I am
encountering. But logic-wise it may be wrong.
Thanks.
Signed-off-by: Peter Teoh <[EMAIL PROTECTED]>
--- arch/x86/kernel/cpuid.c.ori
In include/linux/init.h, it is documented that all __xxxinitdata
declaration must not have constant, as show below:
*
* static int init_variable __initdata = 0;
* static char linux_logo[] __initdata = { 0x32, 0x36, ... };
*
* Don't forget to initialize data not at file scope, i.e. within a fu
The following errors during compilation is corrected by the following
patch (against the latest linus tree):
WARNING: arch/x86/kernel/microcode.o(.exit.text+0x6): Section mismatch
in reference from the function cleanup_module() to the variable
.cpuinit.data:mc_cpu_notifier
Please comment. Thank
the
non-debug symbol disappearing, but not the debug version. Am I
correct?
Signed-off-by: Peter Teoh <[EMAIL PROTECTED]>
--- scripts/mod/modpost.c.orig 2008-02-02 15:18:04.0 +0800
+++ scripts/mod/modpost.c 2008-02-02 15:18:47.0 +0800
@@ -1942,7 +1942,7 @@ int main(in
On Nov 13, 2007 10:52 AM, Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007 09:23:12 Rusty Russell wrote:
> > Better might be to put in a waitqueue and wake it up whenever a module is
> > deleted or changes status. Then use_module() can wait if
> > strong_try_module_get() retu
32 matches
Mail list logo
