From: Yang Wei
In RT kernel, I ran into the following calltrace, so PMU interrupts cannot
be threaded
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
INFO: lockdep is turned off.
Call Trace:
[] dump_stack+0x1c/0x50
[] __might_sleep+0x13c/0x148
[] rt_spin_lock+0x3c/0xb0
[]
From: Yang Wei wei.y...@windriver.com
In RT kernel, I ran into the following calltrace, so PMU interrupts cannot
be threaded
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
INFO: lockdep is turned off.
Call Trace:
[8088595c] dump_stack+0x1c/0x50
[801a958c]
From: Yang Wei
Since there is not indirection page in crash type, so the vaule of the head
field of kimage structure is not equal to the address of indirection page but
IND_DONE. so we have to set kexec_indirection_page variable to the address of
the head field of image structure.
From: Yang Wei wei.y...@windriver.com
Since there is not indirection page in crash type, so the vaule of the head
field of kimage structure is not equal to the address of indirection page but
IND_DONE. so we have to set kexec_indirection_page variable to the address of
the head field of image
From: Yang Wei
The pair read/write of accessing pci confiuration space function
has already protected by pci_lock. so remove nano_lock.
Signed-off-by: Yang Wei
---
arch/arm/mach-sa1100/pci-nanoengine.c |9 -
1 file changed, 9 deletions(-)
diff --git
From: Yang Wei wei.y...@windriver.com
The pair read/write of accessing pci confiuration space function
has already protected by pci_lock. so remove nano_lock.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
arch/arm/mach-sa1100/pci-nanoengine.c |9 -
1 file changed, 9
From: Yang Wei
The commit b02d735bf was to rearrange the device-tree entries, and
assumed that these entries are sorted in the ascending order. but
acctually when I was validating kexec and kdump, the order of
serial node still is changed. We should not only compare the length
of directory name,
From: Yang Wei wei.y...@windriver.com
The commit b02d735bf was to rearrange the device-tree entries, and
assumed that these entries are sorted in the ascending order. but
acctually when I was validating kexec and kdump, the order of
serial node still is changed. We should not only compare the
From: Yang Wei
While loading g_mass_storage module, the following warning
is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104)
From: Yang Wei wei.y...@windriver.com
While loading g_mass_storage module, the following warning
is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[800179cc]
From: Yang Wei
The commit b02d735bf was to rearrange the device-tree entries, and
assumed that these entries are sorted in the ascending order. but
acctually when I was validating kexec and kdump, the order of
serial node still is changed. We should not only compare the length
of directory name,
From: Yang Wei wei.y...@windriver.com
The commit b02d735bf was to rearrange the device-tree entries, and
assumed that these entries are sorted in the ascending order. but
acctually when I was validating kexec and kdump, the order of
serial node still is changed. We should not only compare the
From: Yang Wei
While loading g_mass_storage module, the following warning
is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104)
From: Yang Wei wei.y...@windriver.com
While loading g_mass_storage module, the following warning
is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[800179cc]
From: Yang Wei
While loading g_mass_storage module, the following warning is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104)
From: Yang Wei
While loading g_mass_storage module, the following warning is triggered.
In fact, it is more easy to reproduce it with RT kernel.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1
From: Yang Wei wei.y...@windriver.com
While loading g_mass_storage module, the following warning is triggered.
In fact, it is more easy to reproduce it with RT kernel.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix
From: Yang Wei wei.y...@windriver.com
While loading g_mass_storage module, the following warning is triggered.
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[800179cc]
From: Yang Wei
kernel always invokes a pair of rtnl_lock adn rtnl_unlock to
protect dev_ethtool(), so its not neccessary to invoke spin_lock/unlock
in ethtool_ops.
Signed-off-by: Yang Wei
---
Hi David,
I regenerate this patch based on net/next repo in v2.
Wei
From: Yang Wei wei.y...@windriver.com
kernel always invokes a pair of rtnl_lock adn rtnl_unlock to
protect dev_ethtool(), so its not neccessary to invoke spin_lock/unlock
in ethtool_ops.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
Hi David,
I regenerate this patch based on net/next
From: Yang Wei
kernel always invokes a pair of rtnl_lock adn rtnl_unlock to
protect dev_ethtool(), so its not neccessary to invoke spin_lock/unlock
in ethtool_ops.
Signed-off-by: Yang Wei
---
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c |8
1 file changed, 8 deletions(-)
From: Yang Wei wei.y...@windriver.com
kernel always invokes a pair of rtnl_lock adn rtnl_unlock to
protect dev_ethtool(), so its not neccessary to invoke spin_lock/unlock
in ethtool_ops.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c |
From: Yang Wei
We do not need to trace read_sched_clock function,
so add notrace attribute for this function.
Signed-off-by: Yang Wei
---
drivers/clocksource/dw_apb_timer_of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/dw_apb_timer_of.c
From: Yang Wei
We do not need to trace read_sched_clock function,
so add notrace attribute for this function.
Signed-off-by: Yang Wei
---
drivers/clocksource/dw_apb_timer_of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/dw_apb_timer_of.c
From: Yang Wei wei.y...@windriver.com
We do not need to trace read_sched_clock function,
so add notrace attribute for this function.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
drivers/clocksource/dw_apb_timer_of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Yang Wei wei.y...@windriver.com
We do not need to trace read_sched_clock function,
so add notrace attribute for this function.
Signed-off-by: Yang Wei wei.y...@windriver.com
---
drivers/clocksource/dw_apb_timer_of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Wei Yang
Upon enabling the call-graph functionality of oprofile, A few minutes
later the following calltrace will always occur.
BUG: unable to handle kernel paging request at 656d6153
IP: [] print_context_stack+0x55/0x110
*pde =
Oops: [#1] PREEMPT SMP
Modules linked in:
Pid:
From: Wei Yang wei.y...@windriver.com
Upon enabling the call-graph functionality of oprofile, A few minutes
later the following calltrace will always occur.
BUG: unable to handle kernel paging request at 656d6153
IP: [c10050f5] print_context_stack+0x55/0x110
*pde =
Oops: [#1]
28 matches
Mail list logo
