Re: [linux-sunxi] Re: [PATCH v2 1/5] ARM: dts: sun8i: Add SID node
On Monday, November 23, 2015 at 17:32 UTC+8, Maxime Ripard wrote:
> On Mon, Nov 23, 2015 at 10:51:15PM -0800, Sugar Wu wrote:
>> On Monday, November 23, 2015 at 8:43:59 PM UTC+8, Maxime Ripard wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Nov 23, 2015 at 09:02:48AM +0100, Josef Gajdusek wrote:
Add a node describing the Security ID memory to the
Allwinner H3 .dtsi file.
Signed-off-by: Josef Gajdusek >
---
arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
index 0faa38a..58de718 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -359,6 +359,13 @@
#size-cells = <0>;
};
+sid: eeprom@01c14000 {
+compatible = "allwinner,sun4i-a10-sid";
+reg = <0x01c14000 0x400>;
>>>
>>> The datasheet says it's 256 bytes wide, while the size here is of 1kB,
>>> is it intentional?
>>
>> SID memory map is 0x01c14000 ~ 0x01c143FF, include 2048bits efuse space.
>> H3 efuse space is SID_SRAM, its range is 0x01c14200 ~ +0x100.
>
> Interesting, what is below the 0x200 registers?
>
Some control register about SID.
offset: 0x40 SID Program/Read Control Register
offset: 0x50 SID Program Key Value Register
offset: 0x60 SID Read Key Value Register
offset: 0x70 \
offset: 0x80 SJTAG Attribute 0 Register
offset: 0x84 SJTAG Attribute 1 Register
offset: 0x88 SJTAG Select Register
offset: 0x90 SID Program Ctrol register for burned timing
>
> Thanks!
> Maxime
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG]: when printk too more through serial, cpu up is failed.
于 2013年03月14日 22:05, Greg KH 写道:
On Thu, Mar 14, 2013 at 09:51:34PM +0800, Shuge wrote:
Hi all,
When the kernel printk too many log, the cpu is failed to come online.
The problem is this:
For example, cpu0 bring up cpu1:
a. cpu0 call cpu_up:
cpu_up()
->_cpu_up()
->__cpu_notify(CPU_UP_PREPARE)
->__cpu_up()
->boot_secondary()
# ->wait_for_completion_timeout(&cpu_running, msecs_to_jiffires(1000))
-> if (!cpu_online(cpu)) {
pr_crit("CPU%u: failed to come online\n", cpu);
ret = -EIO;
}
->cpu_notify(CPU_ONLINE)
b. cpu1 enter kernel:
secondary_start_kernel()
@ ->printk("CPU%u: Booted secondary processor\n", cpu)
* ->calibrate_delay()
->set_cpu_online()
->complete(cpu_running)
->cpumask_set_cpu()
While cpu0 run to mark #, which wait that cpu1 complete
cpu_running, and set online.
Generally, cpu0 can get it. But if the __log_buf is too large or
other threads write
it unceasing, then cpu1 come to mark @ or * in this moment. Cpu1 is
busy outputing
buffer, which cost time more than 1s, and cpu1 have not join in
sched, so cpu0 wait it timeout.
By reading printk.c, I found that can_use_console() always return
true, which be called by
console_trylock_for_printk(). Because, have_callable_console()
return ture always, if the console
driver set CON_ANYTIME flag. I think that cpu should not output the
__log_buf in coming online,
even though have_callable_console() is true.
/*
* Can we actually use the console at this time on this cpu?
*
* Console drivers may assume that per-cpu resources have
* been allocated. So unless they're explicitly marked as
* being able to cope (CON_ANYTIME) don't call them until
* this CPU is officially up.
*/
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
In can_use_console, why not is &&, but ||?
Kernel Version: 3.3.0
Why such an old and obsolete kernel version? Please try this on 3.8,
lots of work have gone into the printk area that should have solved this
issue.
greg k-h
I saw the printk.c in version 3.9, it still check
console_trylock_for_printk() to decide to call console_unlock. In
vprintk_emit(), cpu1 also have the opportunity to execute
console_unlock() at coming online time.
Once cpu which is coming online can output buffer, nothing can interrupt
it until buffer is empty.But we can't ensure that none always write the
__log_buf. It is danger! I think, the solution is that we should prevent
to use console at coming online.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG]: when printk too more through serial, cpu up is failed.
Hi all,
When the kernel printk too many log, the cpu is failed to come online.
The problem is this:
For example, cpu0 bring up cpu1:
a. cpu0 call cpu_up:
cpu_up()
->_cpu_up()
->__cpu_notify(CPU_UP_PREPARE)
->__cpu_up()
->boot_secondary()
# ->wait_for_completion_timeout(&cpu_running, msecs_to_jiffires(1000))
-> if (!cpu_online(cpu)) {
pr_crit("CPU%u: failed to come online\n", cpu);
ret = -EIO;
}
->cpu_notify(CPU_ONLINE)
b. cpu1 enter kernel:
secondary_start_kernel()
@ ->printk("CPU%u: Booted secondary processor\n", cpu)
* ->calibrate_delay()
->set_cpu_online()
->complete(cpu_running)
->cpumask_set_cpu()
While cpu0 run to mark #, which wait that cpu1 complete
cpu_running, and set online.
Generally, cpu0 can get it. But if the __log_buf is too large or other
threads write
it unceasing, then cpu1 come to mark @ or * in this moment. Cpu1 is busy
outputing
buffer, which cost time more than 1s, and cpu1 have not join in sched,
so cpu0 wait it timeout.
By reading printk.c, I found that can_use_console() always return
true, which be called by
console_trylock_for_printk(). Because, have_callable_console() return
ture always, if the console
driver set CON_ANYTIME flag. I think that cpu should not output the
__log_buf in coming online,
even though have_callable_console() is true.
/*
* Can we actually use the console at this time on this cpu?
*
* Console drivers may assume that per-cpu resources have
* been allocated. So unless they're explicitly marked as
* being able to cope (CON_ANYTIME) don't call them until
* this CPU is officially up.
*/
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
In can_use_console, why not is &&, but ||?
Kernel Version: 3.3.0
Arch: arm
This problem trace:
[ 1722.150286] CPU1: Booted secondary processor
[ 1722.154613] Calibrating delay loop (skipped) already calibrated this CPU
.
[ 1725.134687] CPU1: failed to come online
.
[ 1728.055547] [ cut here ]
[ 1728.060219] kernel BUG at kernel/workqueue.c:3332!
[ 1728.065010] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 1728.070503] Modules linked in: cdc_ether rtl8150 mcs7830 qf9700 asix
usbnet mma7660 sw_keyboard gt9xx g2d_33 sunxi_csi1 gc2035 ov5640
videobuf_dma_contig videobuf_core dc_sunxi(O) pvrsrvkm(O) nand(O)
[ 1728.088474] CPU: 0Tainted: G O (3.3.0 #9)
[ 1728.093796] PC is at trustee_thread+0x24/0x514
[ 1728.098239] LR is at trustee_thread+0x1c/0x514
[ 1728.102683] pc : []lr : []psr: 2013
[ 1728.102690] sp : ec05bf68 ip : ec05bf68 fp : ec05bfb4
[ 1728.114161] r10: r9 : r8 :
[ 1728.119383] r7 : 0013 r6 : c059c72c r5 : 0001 r4 : e5e162c0
[ 1728.125906] r3 : r2 : 0001 r1 : ec05bf40 r0 :
[ 1728.132432] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 1728.139736] Control: 10c53c7d Table: 6e35c06a DAC: 0015
.
[ 1728.709566] Process workqueue_trust (pid: 22196, stack limit =
0xec05a2f8)
[ 1728.716436] Stack: (0xec05bf68 to 0xec05c000)
[ 1728.720796] bf60: c05a6c3c c007f98c c07ed100
c07ed100 c05a788c ed089de0
[ 1728.728973] bf80: e5e162c0 c059c72c 0013 ed089de0 e5e162c0
c059c72c 0013
[ 1728.737148] bfa0: ec05bff4 ec05bfb8 c00732fc
c059c738
[ 1728.745324] bfc0: e5e162c0 ec05bfd0
ec05bfd0 ed089de0
[ 1728.753501] bfe0: c0073260 c0057d50 ec05bff8 c0057d50
c007326c 00d851b1 da280100
[ 1728.761669] Backtrace:
[ 1728.764140] [] (trustee_thread+0x0/0x514) from []
(kthread+0x9c/0xa8)
[ 1728.772321] [] (kthread+0x0/0xa8) from []
(do_exit+0x0/0x764)
[ 1728.779797] r6:c0057d50 r5:c0073260 r4:ed089de0
[ 1728.784457] Code: e1a04000 ebf36dbd e155 0a00 (e7f001f2)
[ 1729.130494] ---[ end trace 3deba094f67f9e11 ]---
[ 1729.140018] Kernel panic - not syncing: Fatal exception
[ 1730.355119] SMP: failed to stop secondary CPUs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bounce:fix bug, avoid to flush dcache on slab page from jbd2.
Hi all The bounce accept slab pages from jbd2, and flush dcache on them. When enabling VM_DEBUG, it will tigger VM_BUG_ON in page_mapping(). So, check PageSlab to avoid it in __blk_queue_bounce(). Bug URL: http://lkml.org/lkml/2013/3/7/56 ... .. That sure is strange. I didn't see any obvious reasons why we'd end up with a .. Well, this problem not only appear in arm64, but also arm32. And my kernel version is 3.3.0, arch is arm32. Following the newest kernel, the problem shoulde be exist. I agree with Darrick's modification. Hum, if CONFIG_NEED_BOUNCE_POOL is not set, it also flush dcahce on the pages of b_frozen_data, some of them are allocated by kmem_cache_alloc. As we know, jbd2_alloc allocate a buffer from jbd2_xk slab pool, when the size is smaller than PAGE_SIZE. The b_frozen_data is not mapped to usrspace, not aliasing cache. It cat be lazy flush or other. Is it right? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] bounce:fix bug, avoid to flush dcache on slab page from jbd2.
The bounce accept slab pages from jbd2, and flush dcache on them.
When enabling VM_DEBUG, it will tigger VM_BUG_ON in page_mapping().
So, check PageSlab to avoid it in __blk_queue_bounce().
Bug URL: http://lkml.org/lkml/2013/3/7/56
Signed-off-by: shuge
---
mm/bounce.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/bounce.c b/mm/bounce.c
index 4e9ae72..f352c03 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -214,7 +214,8 @@ static void __blk_queue_bounce(struct request_queue
*q, struct bio **bio_orig,
if (rw == WRITE) {
char *vto, *vfrom;
- flush_dcache_page(from->bv_page);
+ if (unlikely(!PageSlab(from->bv_page)))
+ flush_dcache_page(from->bv_page);
vto = page_address(to->bv_page) + to->bv_offset;
vfrom = kmap(from->bv_page) + from->bv_offset;
memcpy(vto, vfrom, to->bv_len);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[jbd2 or mm BUG]: crash while flush JBD2's the pages, that owned Slab flag.
Hi all,
When I debug the file system, I get a problem as follows:
Arch: arm (4 processors)
Kernel version: 3.3.0
The "b_frozen_data" which is defined as a member of "struct
journal_head" (linux/fs/jbd2/transaction.c Line 785),
it's memory is allocated by "jbd2_alloc". When the memory size is
larger than a PAGE SIZE, the memory is got by "
__get_free_pages", otherwise, is got by "kmem_cache_alloc". The
memory will be used by the "__blk_queue_bounce"(linux/mm/bounce.c).
In this function, the program flow is:
__blk_queue_bounce() -> flush_dcache_page() -> page_mapping() ->
VM_BUG_ON(PageSlab(page))
If the memory is got by "kmem_cache_alloc", it will trigger on a bug.
Kernel panic:
[ 34.683049] [ cut here ]
[ 34.687686] kernel BUG at include/linux/mm.h:791!
[ 34.692388] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 34.697869] Modules linked in: screen_print(O) nand(O)
[ 34.703049] CPU: 1Tainted: G O (3.3.0 #6)
[ 34.708370] PC is at flush_dcache_page+0x34/0xb0
[ 34.712992] LR is at blk_queue_bounce+0x16c/0x300
[ 34.717697] pc : []lr : []psr: 2013
[ 34.717703] sp : ee7a7d48 ip : ee7a7d60 fp : ee7a7d5c
[ 34.729176] r10: ee228804 r9 : ee228804 r8 : eea979c8
[ 34.734397] r7 : r6 : ee228890 r5 : d5333840 r4 :
[ 34.740920] r3 : 0001 r2 : fff5 r1 : 0011 r0 : d5333840
[ 34.747446] Flags: nzCv IRQs on FIQs on Mon SVC_32 ISA ARM
Segment kernel
[ 34.754749] Control: 10c53c7d Table: 6e05806a DAC: 0015
..
[ 35.726529] Backtrace:
[ 35.729000] [] (flush_dcache_page+0x0/0xb0) from
[] (blk_queue_bounce+0x16c/0x300)
[ 35.738297] r5:ee7a7dac r4:ee2287c0
[ 35.741905] [] (blk_queue_bounce+0x0/0x300) from
[] (blk_queue_bio+0x28/0x2c0)
[ 35.750862] [] (blk_queue_bio+0x0/0x2c0) from []
(generic_make_request+0x94/0xcc)
[ 35.760078] [] (generic_make_request+0x0/0xcc) from
[] (submit_bio+0x100/0x124)
[ 35.769114] r6:0002 r5:eecb8f08 r4:ee228840
[ 35.773774] [] (submit_bio+0x0/0x124) from []
(submit_bh+0x130/0x150)
[ 35.781942] r8:0009 r7:d60f6c5c r6:0211 r5:eecb8f08 r4:ee228840
[ 35.788713] [] (submit_bh+0x0/0x150) from []
(jbd2_journal_commit_transaction+0x7d0/0x11cc)
[ 35.798790] r6:ef253380 r5:eecb8f08 r4:eeac5800 r3:0001
[ 35.804505] [] (jbd2_journal_commit_transaction+0x0/0x11cc)
from [] (kjournald2+0xb4/0x248)
[ 35.814591] [] (kjournald2+0x0/0x248) from []
(kthread+0x94/0xa0)
[ 35.822422] [] (kthread+0x0/0xa0) from []
(do_exit+0x0/0x6a4)
[ 35.829897] r6:c005472c r5:c006a9fc r4:eea9bce0
[ 35.834556] Code: e5904004 e7e033d3 e353 0a00 (e7f001f2)
[ 35.840733] ---[ end trace c2a29bf063d3670f ]---
So, I modify the mm/bounce.c. Details are as follows:
diff --git a/mm/bounce.c b/mm/bounce.c
index 4e9ae72..e3f6b53 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -214,7 +214,8 @@ static void __blk_queue_bounce(struct request_queue
*q, struct bio **bio_orig,
if (rw == WRITE) {
char *vto, *vfrom;
- flush_dcache_page(from->bv_page);
+ if (!PageSlab(from->bv_page))
+ flush_dcache_page(from->bv_page);
vto = page_address(to->bv_page) + to->bv_offset;
vfrom = kmap(from->bv_page) + from->bv_offset;
memcpy(vto, vfrom, to->bv_len);
Who can give some suggestions to me.
Thanks
Shuge
NOTICE: This e-mail and any included attachments are intended only for the sole
use of named and intended recipient (s) only. If you are the named and intended
recipient, please note that the information contained in this email and its
embedded files are confidential and privileged. If you are neither the intended
nor named recipient, you are hereby notified that any unauthorized review, use,
disclosure, dissemination, distribution, or copying of this communication, or
any of its contents, is strictly prohibited. Please reply to the sender and
destroy the original message and all your records of this message (whether
electronic or otherwise). Furthermore, you should not disclose to any other
person, use, copy or disseminate the contents of this e-mail and/or the
documents accompanying it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
