Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 05/01/2011 04:23 PM, Alexey Galakhov wrote:
> 2011/5/1 Gilles Chanteperdrix
>
>>
>> There is a bug in ipipe_tsc_update for decrementers. The all-in-one patch I
>> would like you to try is:
>>
>>
> This hangs ("infinite IRQs 30,37" symptom). It works fine after re-applying
> this:
> - set_irq_handler(irqno, handle_edge_irq);
> + set_irq_handler(irqno, handle_level_irq);
>
> Seems that handle_edge_irq is broken while handle_level_irq works just fine.
>
> Now the board seems to work. At least, there are no obvious hangups. Thanks!
Ok. I am going to merge the three changes. Thanks for your patience.
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/5/1 Gilles Chanteperdrix
>
> There is a bug in ipipe_tsc_update for decrementers. The all-in-one patch I
> would like you to try is:
>
>
This hangs ("infinite IRQs 30,37" symptom). It works fine after re-applying
this:
- set_irq_handler(irqno, handle_edge_irq);
+ set_irq_handler(irqno, handle_level_irq);
Seems that handle_edge_irq is broken while handle_level_irq works just fine.
Now the board seems to work. At least, there are no obvious hangups. Thanks!
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote:
> 2011/5/1 Gilles Chanteperdrix
>
>> Ok. Could you try only keeping the part with ipipe_handle_chained_irq,
>> leaving the handle_edge_irqs?
>>
>
> Sure. I'll do it tomorrow.
>
> There is another one issue: the board hangs after about 2-3 minutes running.
> I found that it is caused by a semi-permanent (order of 2^64 iterations)
> loop in (untouched) kernel timer code, most likely due to weird return value
> of __ipipe_tsc_get. I haven't found the source of this problem yet. I tried
> a small fix:
>
> --- time.c.org2011-04-26 20:52:00.0 +0600
> +++ time.c2011-05-01 02:03:33.0 +0600
> @@ -124,7 +124,7 @@
>
> static inline unsigned long timer_freerunning_getvalue(void)
> {
> -return __raw_readl(S3C2410_TCNTO(3));
> +return (unsigned long)__raw_readw(S3C2410_TCNTO(3));
> }
>
> static inline unsigned long timer_freerunning_getticksoffset(unsigned long
> tval)
> @@ -390,6 +390,6 @@
>
> unsigned long __ipipe_mach_get_dec(void)
> {
> -return __raw_readl(S3C2410_TCNTO(4));
> +return (unsigned long)__raw_readw(S3C2410_TCNTO(4));
> }
> #endif /* CONFIG_IPIPE */
>
> but it didn't work. (In fact, TCNTOs of S4C2440 are 16-bit, not 32-bit, and
> the datasheet does not guarantee that higher bits are read as zeroes; in
> fact they are, but I tried explicit conversion anyway just in case. No
> effect.).
There is a bug in ipipe_tsc_update for decrementers. The all-in-one patch I
would like you to try is:
diff --git a/arch/arm/kernel/ipipe_tsc.c b/arch/arm/kernel/ipipe_tsc.c
index a9de4f9..c5c2de0 100644
--- a/arch/arm/kernel/ipipe_tsc.c
+++ b/arch/arm/kernel/ipipe_tsc.c
@@ -104,8 +104,8 @@ void __ipipe_tsc_update(void)
int offset = ipipe_tsc_value->last_cnt - cnt;
if (offset < 0)
offset += 0x1;
- ipipe_tsc_value->last_tsc += offset + 1;
- ipipe_tsc_value->last_cnt = cnt - 1;
+ ipipe_tsc_value->last_tsc += offset;
+ ipipe_tsc_value->last_cnt = cnt;
return;
}
ipipe_tsc_value->last_tsc = __ipipe_tsc_get() - 1;
diff --git a/arch/arm/kernel/ipipe_tsc_asm.S b/arch/arm/kernel/ipipe_tsc_asm.S
index ca2..d3c833f 100644
--- a/arch/arm/kernel/ipipe_tsc_asm.S
+++ b/arch/arm/kernel/ipipe_tsc_asm.S
@@ -143,7 +143,7 @@ __ipipe_decrementer_16:
ldr ip, [r0]
ldr r2, .LCdec16_last_cnt
subsip, r2, ip
- addcs ip, ip, #0x1
+ addcc ip, ip, #0x1
myldrd r2, r3, r3, .LCdec16_last_tsc
cmp r1, r2
bne 1b
@@ -155,7 +155,7 @@ __ipipe_decrementer_16:
ldr ip, [r0]
ldr r2, .LCdec16_last_cnt
subsip, r2, ip
- addcs ip, ip, #0x1
+ addcc ip, ip, #0x1
myldrd r2, r3, r3, .LCdec16_last_tsc
cmp r1, r3
bne 1b
diff --git a/arch/arm/plat-samsung/irq-uart.c b/arch/arm/plat-samsung/irq-uart.c
index 4f8c102..1da5aff 100644
--- a/arch/arm/plat-samsung/irq-uart.c
+++ b/arch/arm/plat-samsung/irq-uart.c
@@ -88,13 +88,13 @@ static void s3c_irq_demux_uart(unsigned int irq, struct
irq_desc *desc)
int base = uirq->base_irq;
if (pend & (1 << 0))
- generic_handle_irq(base);
+ ipipe_handle_chained_irq(base);
if (pend & (1 << 1))
- generic_handle_irq(base + 1);
+ ipipe_handle_chained_irq(base + 1);
if (pend & (1 << 2))
- generic_handle_irq(base + 2);
+ ipipe_handle_chained_irq(base + 2);
if (pend & (1 << 3))
- generic_handle_irq(base + 3);
+ ipipe_handle_chained_irq(base + 3);
}
static struct irq_chip s3c_irq_uart = {
diff --git a/arch/arm/plat-samsung/time.c b/arch/arm/plat-samsung/time.c
index 3e9cef2..baf61f6 100644
--- a/arch/arm/plat-samsung/time.c
+++ b/arch/arm/plat-samsung/time.c
@@ -154,7 +154,7 @@ static inline unsigned long getticksoffset_tscupdate(void)
last_free_running_tcnt = tval;
__ipipe_tsc_update();
return ticks;
- }
+}
#else
static unsigned long s3c2410_gettimeoffset (void)
{
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > 2011/5/1 Gilles Chanteperdrix > >> Ok. Could you try only keeping the part with ipipe_handle_chained_irq, >> leaving the handle_edge_irqs? >> > > Sure. I'll do it tomorrow. > > There is another one issue: the board hangs after about 2-3 minutes running. > I found that it is caused by a semi-permanent (order of 2^64 iterations) > loop in (untouched) kernel timer code, most likely due to weird return value > of __ipipe_tsc_get. I haven't found the source of this problem yet. I tried > a small fix: So, there is an issue when the asm code wraps. I will try and reproduce this. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/5/1 Gilles Chanteperdrix
>
> Ok. Could you try only keeping the part with ipipe_handle_chained_irq,
> leaving the handle_edge_irqs?
>
Sure. I'll do it tomorrow.
There is another one issue: the board hangs after about 2-3 minutes running.
I found that it is caused by a semi-permanent (order of 2^64 iterations)
loop in (untouched) kernel timer code, most likely due to weird return value
of __ipipe_tsc_get. I haven't found the source of this problem yet. I tried
a small fix:
--- time.c.org2011-04-26 20:52:00.0 +0600
+++ time.c2011-05-01 02:03:33.0 +0600
@@ -124,7 +124,7 @@
static inline unsigned long timer_freerunning_getvalue(void)
{
-return __raw_readl(S3C2410_TCNTO(3));
+return (unsigned long)__raw_readw(S3C2410_TCNTO(3));
}
static inline unsigned long timer_freerunning_getticksoffset(unsigned long
tval)
@@ -390,6 +390,6 @@
unsigned long __ipipe_mach_get_dec(void)
{
-return __raw_readl(S3C2410_TCNTO(4));
+return (unsigned long)__raw_readw(S3C2410_TCNTO(4));
}
#endif /* CONFIG_IPIPE */
but it didn't work. (In fact, TCNTOs of S4C2440 are 16-bit, not 32-bit, and
the datasheet does not guarantee that higher bits are read as zeroes; in
fact they are, but I tried explicit conversion anyway just in case. No
effect.).
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote:
> 2011/4/30 Gilles Chanteperdrix
>
>> Please try the following patch:
>>
>> diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/plat-s3c24xx/irq.c
>> index c48d99a..8a29d9d 100644
>> --- a/arch/arm/plat-s3c24xx/irq.c
>> +++ b/arch/arm/plat-s3c24xx/irq.c
>> @@ -627,7 +627,7 @@ void __init s3c24xx_init_irq(void)
>>default:
>>//irqdbf("registering irq %d (s3c irq)\n", irqno);
>>set_irq_chip(irqno, &s3c_irq_chip);
>> - set_irq_handler(irqno, handle_edge_irq);
>> + set_irq_handler(irqno, handle_level_irq);
>>set_irq_flags(irqno, IRQF_VALID);
>>}
>>}
>> @@ -647,14 +647,14 @@ void __init s3c24xx_init_irq(void)
>>for (irqno = IRQ_EINT0; irqno <= IRQ_EINT3; irqno++) {
>>irqdbf("registering irq %d (ext int)\n", irqno);
>>set_irq_chip(irqno, &s3c_irq_eint0t4);
>> - set_irq_handler(irqno, handle_edge_irq);
>> + set_irq_handler(irqno, handle_level_irq);
>>set_irq_flags(irqno, IRQF_VALID);
>>}
>>
>>for (irqno = IRQ_EINT4; irqno <= IRQ_EINT23; irqno++) {
>>irqdbf("registering irq %d (extended s3c irq)\n", irqno);
>>set_irq_chip(irqno, &s3c_irqext_chip);
>> - set_irq_handler(irqno, handle_edge_irq);
>> + set_irq_handler(irqno, handle_level_irq);
>>set_irq_flags(irqno, IRQF_VALID);
>>}
>>
>> @@ -686,7 +686,7 @@ void __init s3c24xx_init_irq(void)
>>for (irqno = IRQ_TC; irqno <= IRQ_ADC; irqno++) {
>>irqdbf("registering irq %d (s3c adc irq)\n", irqno);
>>set_irq_chip(irqno, &s3c_irq_adc);
>> - set_irq_handler(irqno, handle_edge_irq);
>> + set_irq_handler(irqno, handle_level_irq);
>>set_irq_flags(irqno, IRQF_VALID);
>>}
>>
>> diff --git a/arch/arm/plat-samsung/irq-uart.c
>> b/arch/arm/plat-samsung/irq-uart.c
>> index 4f8c102..1da5aff 100644
>> --- a/arch/arm/plat-samsung/irq-uart.c
>> +++ b/arch/arm/plat-samsung/irq-uart.c
>> @@ -88,13 +88,13 @@ static void s3c_irq_demux_uart(unsigned int irq, struct
>> irq_desc *desc)
>>int base = uirq->base_irq;
>>
>>if (pend & (1 << 0))
>> - generic_handle_irq(base);
>> + ipipe_handle_chained_irq(base);
>>if (pend & (1 << 1))
>> - generic_handle_irq(base + 1);
>> + ipipe_handle_chained_irq(base + 1);
>>if (pend & (1 << 2))
>> - generic_handle_irq(base + 2);
>> + ipipe_handle_chained_irq(base + 2);
>>if (pend & (1 << 3))
>> - generic_handle_irq(base + 3);
>> + ipipe_handle_chained_irq(base + 3);
>> }
>>
>> static struct irq_chip s3c_irq_uart = {
>>
>>
>> It works!! Thank you!
Ok. Could you try only keeping the part with ipipe_handle_chained_irq,
leaving the handle_edge_irqs?
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/30 Alexey Galakhov > > H... It seems to be unstable, it generally works but with random > hangups. Trying to debug. > Looks like now it's not IRQ related. Seems to be kind of overflow in logarithmic_accumulation (), probably due to changes in timer code. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/30 Alexey Galakhov > > It works!! Thank you! > > -- > Alex > > H... It seems to be unstable, it generally works but with random hangups. Trying to debug. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/30 Gilles Chanteperdrix
>
> Please try the following patch:
>
> diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/plat-s3c24xx/irq.c
> index c48d99a..8a29d9d 100644
> --- a/arch/arm/plat-s3c24xx/irq.c
> +++ b/arch/arm/plat-s3c24xx/irq.c
> @@ -627,7 +627,7 @@ void __init s3c24xx_init_irq(void)
>default:
>//irqdbf("registering irq %d (s3c irq)\n", irqno);
>set_irq_chip(irqno, &s3c_irq_chip);
> - set_irq_handler(irqno, handle_edge_irq);
> + set_irq_handler(irqno, handle_level_irq);
>set_irq_flags(irqno, IRQF_VALID);
>}
>}
> @@ -647,14 +647,14 @@ void __init s3c24xx_init_irq(void)
>for (irqno = IRQ_EINT0; irqno <= IRQ_EINT3; irqno++) {
>irqdbf("registering irq %d (ext int)\n", irqno);
>set_irq_chip(irqno, &s3c_irq_eint0t4);
> - set_irq_handler(irqno, handle_edge_irq);
> + set_irq_handler(irqno, handle_level_irq);
>set_irq_flags(irqno, IRQF_VALID);
>}
>
>for (irqno = IRQ_EINT4; irqno <= IRQ_EINT23; irqno++) {
>irqdbf("registering irq %d (extended s3c irq)\n", irqno);
>set_irq_chip(irqno, &s3c_irqext_chip);
> - set_irq_handler(irqno, handle_edge_irq);
> + set_irq_handler(irqno, handle_level_irq);
>set_irq_flags(irqno, IRQF_VALID);
>}
>
> @@ -686,7 +686,7 @@ void __init s3c24xx_init_irq(void)
>for (irqno = IRQ_TC; irqno <= IRQ_ADC; irqno++) {
>irqdbf("registering irq %d (s3c adc irq)\n", irqno);
>set_irq_chip(irqno, &s3c_irq_adc);
> - set_irq_handler(irqno, handle_edge_irq);
> + set_irq_handler(irqno, handle_level_irq);
>set_irq_flags(irqno, IRQF_VALID);
>}
>
> diff --git a/arch/arm/plat-samsung/irq-uart.c
> b/arch/arm/plat-samsung/irq-uart.c
> index 4f8c102..1da5aff 100644
> --- a/arch/arm/plat-samsung/irq-uart.c
> +++ b/arch/arm/plat-samsung/irq-uart.c
> @@ -88,13 +88,13 @@ static void s3c_irq_demux_uart(unsigned int irq, struct
> irq_desc *desc)
>int base = uirq->base_irq;
>
>if (pend & (1 << 0))
> - generic_handle_irq(base);
> + ipipe_handle_chained_irq(base);
>if (pend & (1 << 1))
> - generic_handle_irq(base + 1);
> + ipipe_handle_chained_irq(base + 1);
>if (pend & (1 << 2))
> - generic_handle_irq(base + 2);
> + ipipe_handle_chained_irq(base + 2);
>if (pend & (1 << 3))
> - generic_handle_irq(base + 3);
> + ipipe_handle_chained_irq(base + 3);
> }
>
> static struct irq_chip s3c_irq_uart = {
>
>
> It works!! Thank you!
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Gilles Chanteperdrix wrote:
> Alexey Galakhov wrote:
>> On 04/29/2011 01:32 AM, Gilles Chanteperdrix wrote:
>>> Maybe you can try booting with MMC disabled, to see if the I-pipe is
>>> working? Not permanently, just to confirm that you are not chasing the
>>> wrong bug.
>> Thank you for the root image!
>>
>> Just did some simple checks.
>>
>> It works with the same kernel, just with MMC card removed (heartbeat
>> blinks, "Waiting for root").
>> It STOPS working (heartbeat stops blinking) immediately after inserting
>> either MMC or USB flash. So it is not exactly MMC related, any interrupt
>> source (both MMC and USB) results in lockup.
>>
>> The lockup is not immediate, it works for some short time (enough to
>> print kind of "new device found" to dmesg).
>>
>> It does not depend on drivers actually compiled in, it depends on
>> devices being initialized. It stops working as soon as some hardware
>> starts sending frequent interrupts.
>>
>> Now going to try your asm patch.
>
> Ok. Two things to check:
> - if the irqs are handled by handle_edge, try using handle_level instead;
> - if the irqs are demuxed gpios, check that ipipe_handle_chained_irq is
> used instead of generic_handle_irq.
>
> I will check on my side tonight.
Please try the following patch:
diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/plat-s3c24xx/irq.c
index c48d99a..8a29d9d 100644
--- a/arch/arm/plat-s3c24xx/irq.c
+++ b/arch/arm/plat-s3c24xx/irq.c
@@ -627,7 +627,7 @@ void __init s3c24xx_init_irq(void)
default:
//irqdbf("registering irq %d (s3c irq)\n", irqno);
set_irq_chip(irqno, &s3c_irq_chip);
- set_irq_handler(irqno, handle_edge_irq);
+ set_irq_handler(irqno, handle_level_irq);
set_irq_flags(irqno, IRQF_VALID);
}
}
@@ -647,14 +647,14 @@ void __init s3c24xx_init_irq(void)
for (irqno = IRQ_EINT0; irqno <= IRQ_EINT3; irqno++) {
irqdbf("registering irq %d (ext int)\n", irqno);
set_irq_chip(irqno, &s3c_irq_eint0t4);
- set_irq_handler(irqno, handle_edge_irq);
+ set_irq_handler(irqno, handle_level_irq);
set_irq_flags(irqno, IRQF_VALID);
}
for (irqno = IRQ_EINT4; irqno <= IRQ_EINT23; irqno++) {
irqdbf("registering irq %d (extended s3c irq)\n", irqno);
set_irq_chip(irqno, &s3c_irqext_chip);
- set_irq_handler(irqno, handle_edge_irq);
+ set_irq_handler(irqno, handle_level_irq);
set_irq_flags(irqno, IRQF_VALID);
}
@@ -686,7 +686,7 @@ void __init s3c24xx_init_irq(void)
for (irqno = IRQ_TC; irqno <= IRQ_ADC; irqno++) {
irqdbf("registering irq %d (s3c adc irq)\n", irqno);
set_irq_chip(irqno, &s3c_irq_adc);
- set_irq_handler(irqno, handle_edge_irq);
+ set_irq_handler(irqno, handle_level_irq);
set_irq_flags(irqno, IRQF_VALID);
}
diff --git a/arch/arm/plat-samsung/irq-uart.c b/arch/arm/plat-samsung/irq-uart.c
index 4f8c102..1da5aff 100644
--- a/arch/arm/plat-samsung/irq-uart.c
+++ b/arch/arm/plat-samsung/irq-uart.c
@@ -88,13 +88,13 @@ static void s3c_irq_demux_uart(unsigned int irq, struct
irq_desc *desc)
int base = uirq->base_irq;
if (pend & (1 << 0))
- generic_handle_irq(base);
+ ipipe_handle_chained_irq(base);
if (pend & (1 << 1))
- generic_handle_irq(base + 1);
+ ipipe_handle_chained_irq(base + 1);
if (pend & (1 << 2))
- generic_handle_irq(base + 2);
+ ipipe_handle_chained_irq(base + 2);
if (pend & (1 << 3))
- generic_handle_irq(base + 3);
+ ipipe_handle_chained_irq(base + 3);
}
static struct irq_chip s3c_irq_uart = {
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/29/2011 06:14 PM, Gilles Chanteperdrix wrote: > Alexey Galakhov wrote: >> On 04/29/2011 05:32 PM, Gilles Chanteperdrix wrote: >>> Alexey Galakhov wrote: >>> Now going to try your asm patch. >>> Ok. Two things to check: >>> - if the irqs are handled by handle_edge, try using handle_level instead; >>> - if the irqs are demuxed gpios, check that ipipe_handle_chained_irq is >>> used instead of generic_handle_irq. >>> >>> I will check on my side tonight. >> Same with the patch. > The patch was supposed to fix the hang at "Switching to ipipe_tsc > source". Does your kernel still hang there? > Sorry, my mistake, used an incorrect uImage to boot. The "ipipe_tsc clocksource" bug is FIXED now. Thank you very much! Now chasing the first bug, mmc interrupt flood... -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > On 04/29/2011 05:32 PM, Gilles Chanteperdrix wrote: >> Alexey Galakhov wrote: >> Now going to try your asm patch. >> Ok. Two things to check: >> - if the irqs are handled by handle_edge, try using handle_level instead; >> - if the irqs are demuxed gpios, check that ipipe_handle_chained_irq is >> used instead of generic_handle_irq. >> >> I will check on my side tonight. > Same with the patch. The patch was supposed to fix the hang at "Switching to ipipe_tsc source". Does your kernel still hang there? -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/29/2011 05:32 PM, Gilles Chanteperdrix wrote: > Alexey Galakhov wrote: > Now going to try your asm patch. > Ok. Two things to check: > - if the irqs are handled by handle_edge, try using handle_level instead; > - if the irqs are demuxed gpios, check that ipipe_handle_chained_irq is > used instead of generic_handle_irq. > > I will check on my side tonight. Same with the patch. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > On 04/29/2011 01:32 AM, Gilles Chanteperdrix wrote: >> Maybe you can try booting with MMC disabled, to see if the I-pipe is >> working? Not permanently, just to confirm that you are not chasing the >> wrong bug. > Thank you for the root image! > > Just did some simple checks. > > It works with the same kernel, just with MMC card removed (heartbeat > blinks, "Waiting for root"). > It STOPS working (heartbeat stops blinking) immediately after inserting > either MMC or USB flash. So it is not exactly MMC related, any interrupt > source (both MMC and USB) results in lockup. > > The lockup is not immediate, it works for some short time (enough to > print kind of "new device found" to dmesg). > > It does not depend on drivers actually compiled in, it depends on > devices being initialized. It stops working as soon as some hardware > starts sending frequent interrupts. > > Now going to try your asm patch. Ok. Two things to check: - if the irqs are handled by handle_edge, try using handle_level instead; - if the irqs are demuxed gpios, check that ipipe_handle_chained_irq is used instead of generic_handle_irq. I will check on my side tonight. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/29/2011 01:32 AM, Gilles Chanteperdrix wrote: > Maybe you can try booting with MMC disabled, to see if the I-pipe is > working? Not permanently, just to confirm that you are not chasing the > wrong bug. Thank you for the root image! Just did some simple checks. It works with the same kernel, just with MMC card removed (heartbeat blinks, "Waiting for root"). It STOPS working (heartbeat stops blinking) immediately after inserting either MMC or USB flash. So it is not exactly MMC related, any interrupt source (both MMC and USB) results in lockup. The lockup is not immediate, it works for some short time (enough to print kind of "new device found" to dmesg). It does not depend on drivers actually compiled in, it depends on devices being initialized. It stops working as soon as some hardware starts sending frequent interrupts. Now going to try your asm patch. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Gilles Chanteperdrix wrote: > Alexey Galakhov wrote: >> 2011/4/29 Gilles Chanteperdrix >> >>> Maybe you can try booting with MMC disabled, to see if the I-pipe is >>> working? Not permanently, just to confirm that you are not chasing the >>> wrong bug. >>> >> Sure, that's exactly what I want to do. Unfortunately, I cannot boot to a >> working system in that mode since I have root on SD card, but "Kernel panic >> - unable to mount root fs" would indicate successful boot. I think also >> about moving root somewhere else to be able to run tests ans examine /proc >> and /sys under ipipe kernel. > > Just made a rootfs for s3c, you can find it as a tar archive here: > http://xenomai.org/~gch/rootfs-s3c.tar.bz2 > > or as a cpio archive to be used as an initramfs here: > http://xenomai.org/~gch/initramfs-s3c.tar.bz2 s/.bz2/.gz/ -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > 2011/4/29 Gilles Chanteperdrix > >> Maybe you can try booting with MMC disabled, to see if the I-pipe is >> working? Not permanently, just to confirm that you are not chasing the >> wrong bug. >> > > Sure, that's exactly what I want to do. Unfortunately, I cannot boot to a > working system in that mode since I have root on SD card, but "Kernel panic > - unable to mount root fs" would indicate successful boot. I think also > about moving root somewhere else to be able to run tests ans examine /proc > and /sys under ipipe kernel. Just made a rootfs for s3c, you can find it as a tar archive here: http://xenomai.org/~gch/rootfs-s3c.tar.bz2 or as a cpio archive to be used as an initramfs here: http://xenomai.org/~gch/initramfs-s3c.tar.bz2 -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Gilles Chanteperdrix wrote: > Alexey Galakhov wrote: >> On 04/27/2011 09:56 PM, Gilles Chanteperdrix wrote: >>> But I think your problem has more to do with the following commit, could >>> you try reverting it? >>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=6ab29d9c7a4b119f45ef4d93780e894fe1c0c6c6;hp=cd9c5e016092258d4450e137be2d0844d0fe8b38 >>> >>> The same issue was reported on ixp4xx. >> Just tried to revert this patch. Hangs. But now in a different way: it >> starts to initialize peripherals and stops on LED initialization. Looks >> like race conditions since it stops in slightly different place each >> time I try to boot (randomly at led3, led4 or "backlight" LED). Last >> lines of dmesg are, i.e.: >> >> [3.09] samsung-ts s3c2440-ts: driver attached, registering input >> device >> [3.10] input: S3C24XX TouchScreen as /devices/virtual/input/input0 >> [3.12] S3C24XX RTC, (c) 2004,2006 Simtec Electronics >> [3.12] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling >> [3.135000] s3c-rtc s3c2410-rtc: rtc core: registered s3c as rtc0 >> [3.135000] i2c /dev entries driver >> [3.155000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics >> [3.16] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset >> disabled, irq enabled >> [3.18] s3c-sdi s3c2440-sdi: powered down. >> [3.18] s3c-sdi s3c2440-sdi: mmc0 - using pio, sw SDIO IRQ >> [3.185000] s3c-sdi s3c2440-sdi: running at 0kHz (requested: 0kHz). >> [3.20] Registered led device: led1 >> [3.205000] Registered led device: led2 >> [3.21] s3c-sdi s3c2440-sdi: running at 398kHz (requested: 400kHz). >> [3.215000] Registered led device: led3 >> [3.22] Registered led device: led4 >> (hangs) >> >> Going to try kgdb over serial line. > > Ok. Better try without this patch first, then try reapplying the patch > when you are certain that everything else works correctly. The patch > enables some assembly code that was never actually tested. On my side, I > will try and test it separately. > With the following patch, the asm code looks fine to me: diff --git a/arch/arm/kernel/ipipe_tsc_asm.S b/arch/arm/kernel/ipipe_tsc_asm.S index ca2..d3c833f 100644 --- a/arch/arm/kernel/ipipe_tsc_asm.S +++ b/arch/arm/kernel/ipipe_tsc_asm.S @@ -143,7 +143,7 @@ __ipipe_decrementer_16: ldr ip, [r0] ldr r2, .LCdec16_last_cnt subsip, r2, ip - addcs ip, ip, #0x1 + addcc ip, ip, #0x1 myldrd r2, r3, r3, .LCdec16_last_tsc cmp r1, r2 bne 1b @@ -155,7 +155,7 @@ __ipipe_decrementer_16: ldr ip, [r0] ldr r2, .LCdec16_last_cnt subsip, r2, ip - addcs ip, ip, #0x1 + addcc ip, ip, #0x1 myldrd r2, r3, r3, .LCdec16_last_tsc cmp r1, r3 bne 1b -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/29 Gilles Chanteperdrix > > Maybe you can try booting with MMC disabled, to see if the I-pipe is > working? Not permanently, just to confirm that you are not chasing the > wrong bug. > Sure, that's exactly what I want to do. Unfortunately, I cannot boot to a working system in that mode since I have root on SD card, but "Kernel panic - unable to mount root fs" would indicate successful boot. I think also about moving root somewhere else to be able to run tests ans examine /proc and /sys under ipipe kernel. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > 2011/4/29 Gilles Chanteperdrix > >> >> So, have you tried reverting the timer3 patch? >> >> > Yes. After reverting, EVERYTHING stops working correctly (even with ipipe > off). It is really necessary. > > Now I'm trying to understand the MMC code. Looks like that timers do their > job correctly, and MMC/SD driver seems to be the source of irq flood. If so, > it depends on kernel version, not on ipipe version. That is, ipipe seems > just to trigger a bug in already buggy kernel. Trying to examine it more > closely. Not sure. Maybe you can try booting with MMC disabled, to see if the I-pipe is working? Not permanently, just to confirm that you are not chasing the wrong bug. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/29 Gilles Chanteperdrix > > > So, have you tried reverting the timer3 patch? > > Yes. After reverting, EVERYTHING stops working correctly (even with ipipe off). It is really necessary. Now I'm trying to understand the MMC code. Looks like that timers do their job correctly, and MMC/SD driver seems to be the source of irq flood. If so, it depends on kernel version, not on ipipe version. That is, ipipe seems just to trigger a bug in already buggy kernel. Trying to examine it more closely. Not sure. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > 2011/4/28 Gilles Chanteperdrix > >> Well, is not that an effect of kgdb? The timer tick occurs 100 or 1000 >> times per second, so, you can not keep up with gdb. The fact that a new >> interrupts may occur why handling another interrupt is normal with Adeos. >> >> It is not to say that there is no irq loop, but we can not conclude from >> the symptoms you are describing. >> >> > I understand this possibility. I did a simple test: just switched the > processor back and forth between "run" and "halt" many many times. I did it > on hardware (JTAG) level so I believe the CPU was running at full speed. And > it was catched in one of these interrupt handlers every time, I've never > seen it in any other function. Thus I believe it was doing nothing else. The > stack is suspicious as well: it has lots of IRQ stuff, nothing but IRQs, > even if I interrupt the CPU for the first time. > > > >> Is there an earlier version of the I-pipe patch which was working? >> >> > Unfortunately I've not tested earlier versions. I'll try. They say it worked > with linux 2.6.29 (ipipe version not mentioned, but it was just before the > mini2440 timer3 patch was submitted to mainstream): > http://www.friendlyarm.net/forum/topic/598 > > Seems that these guys have the same problem: > http://www.friendlyarm.net/forum/topic/1108 So, have you tried reverting the timer3 patch? -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/28 Gilles Chanteperdrix > > > Well, is not that an effect of kgdb? > I turned off kgdb completely. My gdb uses openocd and jtag cable, so the performance should not be affected. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
2011/4/28 Gilles Chanteperdrix > > Well, is not that an effect of kgdb? The timer tick occurs 100 or 1000 > times per second, so, you can not keep up with gdb. The fact that a new > interrupts may occur why handling another interrupt is normal with Adeos. > > It is not to say that there is no irq loop, but we can not conclude from > the symptoms you are describing. > > I understand this possibility. I did a simple test: just switched the processor back and forth between "run" and "halt" many many times. I did it on hardware (JTAG) level so I believe the CPU was running at full speed. And it was catched in one of these interrupt handlers every time, I've never seen it in any other function. Thus I believe it was doing nothing else. The stack is suspicious as well: it has lots of IRQ stuff, nothing but IRQs, even if I interrupt the CPU for the first time. > Is there an earlier version of the I-pipe patch which was working? > > Unfortunately I've not tested earlier versions. I'll try. They say it worked with linux 2.6.29 (ipipe version not mentioned, but it was just before the mini2440 timer3 patch was submitted to mainstream): http://www.friendlyarm.net/forum/topic/598 Seems that these guys have the same problem: http://www.friendlyarm.net/forum/topic/1108 -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: >> Ok. Better try without this patch first, then try reapplying the patch >> when you are certain that everything else works correctly. The patch >> enables some assembly code that was never actually tested. On my side, I >> will try and test it separately. > So I tried to trace the kernel using gdb and jtag. > > It enters the interrupt handler over and over again. If I set a > breakpoint at __ipipe_grab_irq, I see the following: > __ipipe_grab_irq (irq=37, regs=0xc3dd3f08) > __ipipe_grab_irq (irq=30, regs=0xc3dd3f08) > __ipipe_grab_irq (irq=37, regs=0xc3dd3f08) > __ipipe_grab_irq (irq=30, regs=0xc3dd3f08) > and so on. Note the strict order of IRQs 30 and 37. > > According to /proc/interrupts running vanilla kernel, these IRQs are: > 30: 36105 s3c S3C2410 Timer Tick > 37: 12464 s3c s3c-mci > > As far as I can see, these two IRQs are both handled by the same code in > ipipe. And they are both periodic and occur so frequently that they > interrupt each other's handler. Looks like they aren't masked properly > for some reason. So the kernel loops infinitely in these two interrupt > handlers and does never exit them! Well, is not that an effect of kgdb? The timer tick occurs 100 or 1000 times per second, so, you can not keep up with gdb. The fact that a new interrupts may occur why handling another interrupt is normal with Adeos. It is not to say that there is no irq loop, but we can not conclude from the symptoms you are describing. Is there an earlier version of the I-pipe patch which was working? -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: > Ok. Better try without this patch first, then try reapplying the patch > when you are certain that everything else works correctly. The patch > enables some assembly code that was never actually tested. On my side, I > will try and test it separately. So I tried to trace the kernel using gdb and jtag. It enters the interrupt handler over and over again. If I set a breakpoint at __ipipe_grab_irq, I see the following: __ipipe_grab_irq (irq=37, regs=0xc3dd3f08) __ipipe_grab_irq (irq=30, regs=0xc3dd3f08) __ipipe_grab_irq (irq=37, regs=0xc3dd3f08) __ipipe_grab_irq (irq=30, regs=0xc3dd3f08) and so on. Note the strict order of IRQs 30 and 37. According to /proc/interrupts running vanilla kernel, these IRQs are: 30: 36105 s3c S3C2410 Timer Tick 37: 12464 s3c s3c-mci As far as I can see, these two IRQs are both handled by the same code in ipipe. And they are both periodic and occur so frequently that they interrupt each other's handler. Looks like they aren't masked properly for some reason. So the kernel loops infinitely in these two interrupt handlers and does never exit them! -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: >> Ok. Better try without this patch first, then try reapplying the patch >> when you are certain that everything else works correctly. The patch >> enables some assembly code that was never actually tested. On my side, I >> will try and test it separately. >> > I just got a couple of stack traces via JTAG (just stopped and restarted > the "hanging" processor multiple times and doing backtrace). It runs all > the time somewhere inside __ipipe_handle_irq or __ipipe_grab_irq(): > > #0 0xc00281b8 in __gnu_mcount_nc () > #1 0xc002f7ec in __ipipe_handle_irq () > #2 0xc002fb40 in __ipipe_grab_irq () > #3 0xc0027b8c in __irq_svc () > #4 0xc0027b8c in __irq_svc () > #5 0xc0027b8c in __irq_svc () > (a lot of __irq_svc() follows) > > #0 0xc0092ba4 in __ipipe_trace () > #1 0xc00937d4 in ipipe_trace_begin () > #2 0xc002fb34 in __ipipe_grab_irq () > #3 0xc0027b8c in __irq_svc () > #4 0xc0027b8c in __irq_svc () > (etc) > > #0 0xc002fae0 in __ipipe_grab_irq () > #1 0xc0027b8c in __irq_svc () > #2 0xc0027b8c in __irq_svc () > (etc) > > #0 0xc0092948 in __ipipe_trace () > #1 0xc0093448 in ipipe_trace_function () > #2 0xc0094a90 in ftrace_test_stop_func () > #3 0xc00281ec in gnu_trace () > #4 0xc00281ec in gnu_trace () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > and so on. Hope that helps. > Try disabling the I-pipe tracer. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: > Ok. Better try without this patch first, then try reapplying the patch > when you are certain that everything else works correctly. The patch > enables some assembly code that was never actually tested. On my side, I > will try and test it separately. > I just got a couple of stack traces via JTAG (just stopped and restarted the "hanging" processor multiple times and doing backtrace). It runs all the time somewhere inside __ipipe_handle_irq or __ipipe_grab_irq(): #0 0xc00281b8 in __gnu_mcount_nc () #1 0xc002f7ec in __ipipe_handle_irq () #2 0xc002fb40 in __ipipe_grab_irq () #3 0xc0027b8c in __irq_svc () #4 0xc0027b8c in __irq_svc () #5 0xc0027b8c in __irq_svc () (a lot of __irq_svc() follows) #0 0xc0092ba4 in __ipipe_trace () #1 0xc00937d4 in ipipe_trace_begin () #2 0xc002fb34 in __ipipe_grab_irq () #3 0xc0027b8c in __irq_svc () #4 0xc0027b8c in __irq_svc () (etc) #0 0xc002fae0 in __ipipe_grab_irq () #1 0xc0027b8c in __irq_svc () #2 0xc0027b8c in __irq_svc () (etc) #0 0xc0092948 in __ipipe_trace () #1 0xc0093448 in ipipe_trace_function () #2 0xc0094a90 in ftrace_test_stop_func () #3 0xc00281ec in gnu_trace () #4 0xc00281ec in gnu_trace () Backtrace stopped: previous frame identical to this frame (corrupt stack?) and so on. Hope that helps. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: >> Alexey Galakhov wrote: >>> Going to try kgdb over serial line. >> Ok. Better try without this patch first, then try reapplying the patch >> when you are certain that everything else works correctly. The patch >> enables some assembly code that was never actually tested. On my side, I >> will try and test it separately. > That's exactly what I want to do. > > Is there any documentation on ipipe's internals involved in time.c ? > Reading C code is certainly not the fastest way to understand how things > work :) http://www.xenomai.org/index.php/I-pipe:ArmPorting The parts about the tsc and gpio demuxing are outdated. But the part about the timer is still correct. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/28/2011 05:16 PM, Gilles Chanteperdrix wrote: > Alexey Galakhov wrote: >> Going to try kgdb over serial line. > Ok. Better try without this patch first, then try reapplying the patch > when you are certain that everything else works correctly. The patch > enables some assembly code that was never actually tested. On my side, I > will try and test it separately. That's exactly what I want to do. Is there any documentation on ipipe's internals involved in time.c ? Reading C code is certainly not the fastest way to understand how things work :) -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > On 04/27/2011 09:56 PM, Gilles Chanteperdrix wrote: >> But I think your problem has more to do with the following commit, could >> you try reverting it? >> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=6ab29d9c7a4b119f45ef4d93780e894fe1c0c6c6;hp=cd9c5e016092258d4450e137be2d0844d0fe8b38 >> >> The same issue was reported on ixp4xx. > Just tried to revert this patch. Hangs. But now in a different way: it > starts to initialize peripherals and stops on LED initialization. Looks > like race conditions since it stops in slightly different place each > time I try to boot (randomly at led3, led4 or "backlight" LED). Last > lines of dmesg are, i.e.: > > [3.09] samsung-ts s3c2440-ts: driver attached, registering input > device > [3.10] input: S3C24XX TouchScreen as /devices/virtual/input/input0 > [3.12] S3C24XX RTC, (c) 2004,2006 Simtec Electronics > [3.12] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling > [3.135000] s3c-rtc s3c2410-rtc: rtc core: registered s3c as rtc0 > [3.135000] i2c /dev entries driver > [3.155000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics > [3.16] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset > disabled, irq enabled > [3.18] s3c-sdi s3c2440-sdi: powered down. > [3.18] s3c-sdi s3c2440-sdi: mmc0 - using pio, sw SDIO IRQ > [3.185000] s3c-sdi s3c2440-sdi: running at 0kHz (requested: 0kHz). > [3.20] Registered led device: led1 > [3.205000] Registered led device: led2 > [3.21] s3c-sdi s3c2440-sdi: running at 398kHz (requested: 400kHz). > [3.215000] Registered led device: led3 > [3.22] Registered led device: led4 > (hangs) > > Going to try kgdb over serial line. Ok. Better try without this patch first, then try reapplying the patch when you are certain that everything else works correctly. The patch enables some assembly code that was never actually tested. On my side, I will try and test it separately. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
On 04/27/2011 09:56 PM, Gilles Chanteperdrix wrote: > But I think your problem has more to do with the following commit, could > you try reverting it? > http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=6ab29d9c7a4b119f45ef4d93780e894fe1c0c6c6;hp=cd9c5e016092258d4450e137be2d0844d0fe8b38 > > The same issue was reported on ixp4xx. Just tried to revert this patch. Hangs. But now in a different way: it starts to initialize peripherals and stops on LED initialization. Looks like race conditions since it stops in slightly different place each time I try to boot (randomly at led3, led4 or "backlight" LED). Last lines of dmesg are, i.e.: [3.09] samsung-ts s3c2440-ts: driver attached, registering input device [3.10] input: S3C24XX TouchScreen as /devices/virtual/input/input0 [3.12] S3C24XX RTC, (c) 2004,2006 Simtec Electronics [3.12] s3c-rtc s3c2410-rtc: rtc disabled, re-enabling [3.135000] s3c-rtc s3c2410-rtc: rtc core: registered s3c as rtc0 [3.135000] i2c /dev entries driver [3.155000] S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics [3.16] s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled [3.18] s3c-sdi s3c2440-sdi: powered down. [3.18] s3c-sdi s3c2440-sdi: mmc0 - using pio, sw SDIO IRQ [3.185000] s3c-sdi s3c2440-sdi: running at 0kHz (requested: 0kHz). [3.20] Registered led device: led1 [3.205000] Registered led device: led2 [3.21] s3c-sdi s3c2440-sdi: running at 398kHz (requested: 400kHz). [3.215000] Registered led device: led3 [3.22] Registered led device: led4 (hangs) Going to try kgdb over serial line. -- Alex ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: >> There was a bug some time ago, which was fixed for TIMER3, see commit: >> >> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=ebf2fac4298e25509ba47942b9fad408dcefce1e >> > > Oh, I know about this bug. That's the first thing I checked. I found that it > is already fixed in my case. However, it is still unclear for me where the > correct MUXes for timer4 and timer3 are initialized, seems to be kind of > magic. I didn't checked TCFGs against the datasheet, going to do it now. I > also think about making the free-running timer selectable from config since > some machines may have something wired to timer3's PWM. > > I forgot to say, it works with patched kernel if CONFIG_IPIPE=no. Timers are > the same in both cases. I don't quite understand, however, how the > non-working free-running timer may affect the system in that case. > Interrupts from timer4 are still generated, so the system may boot with > ipipe off even with broken free-running timer without any obvious problems, > am I right? I have absolutely no idea. Fabian Godehart sent the patch, saying that it fixed an issue, I merged it. That is all. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote:
>> There was a bug some time ago, which was fixed for TIMER3, see commit:
>>
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=ebf2fac4298e25509ba47942b9fad408dcefce1e
>>
>
> Oh, I know about this bug. That's the first thing I checked. I found that it
> is already fixed in my case. However, it is still unclear for me where the
> correct MUXes for timer4 and timer3 are initialized, seems to be kind of
> magic. I didn't checked TCFGs against the datasheet, going to do it now. I
> also think about making the free-running timer selectable from config since
> some machines may have something wired to timer3's PWM.
>
> I forgot to say, it works with patched kernel if CONFIG_IPIPE=no. Timers are
> the same in both cases. I don't quite understand, however, how the
> non-working free-running timer may affect the system in that case.
> Interrupts from timer4 are still generated, so the system may boot with
> ipipe off even with broken free-running timer without any obvious problems,
> am I right?
>
>
>> But I think your problem has more to do with the following commit, could
>> you try reverting it?
>>
>> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=6ab29d9c7a4b119f45ef4d93780e894fe1c0c6c6;hp=cd9c5e016092258d4450e137be2d0844d0fe8b38
>>
>> The same issue was reported on ixp4xx.
>>
>
> I'll give it a try tomorrow, thanks. A little question about this part of
> the patch:
> - if (!__ipipe_mach_timerstolen)
> + if (!__ipipe_mach_timerstolen) {
> + spin_lock(&timer_lock);
> getticksoffset_tscupdate();
> + spin_unlock(&timer_lock);
> + }
> Is it a bugfix (forgotten spinlock added) or is it due to change of
> getticksoffset_tscupdate() contents? (Just trying to understand how it
> works.)
Looks like a mistake... Not having an S3C platform, I modified this code
and only compile-tested it.
--
Gilles.
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
>
> There was a bug some time ago, which was fixed for TIMER3, see commit:
>
> http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=ebf2fac4298e25509ba47942b9fad408dcefce1e
>
Oh, I know about this bug. That's the first thing I checked. I found that it
is already fixed in my case. However, it is still unclear for me where the
correct MUXes for timer4 and timer3 are initialized, seems to be kind of
magic. I didn't checked TCFGs against the datasheet, going to do it now. I
also think about making the free-running timer selectable from config since
some machines may have something wired to timer3's PWM.
I forgot to say, it works with patched kernel if CONFIG_IPIPE=no. Timers are
the same in both cases. I don't quite understand, however, how the
non-working free-running timer may affect the system in that case.
Interrupts from timer4 are still generated, so the system may boot with
ipipe off even with broken free-running timer without any obvious problems,
am I right?
> But I think your problem has more to do with the following commit, could
> you try reverting it?
>
> http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=6ab29d9c7a4b119f45ef4d93780e894fe1c0c6c6;hp=cd9c5e016092258d4450e137be2d0844d0fe8b38
>
> The same issue was reported on ixp4xx.
>
I'll give it a try tomorrow, thanks. A little question about this part of
the patch:
- if (!__ipipe_mach_timerstolen)
+ if (!__ipipe_mach_timerstolen) {
+ spin_lock(&timer_lock);
getticksoffset_tscupdate();
+ spin_unlock(&timer_lock);
+ }
Is it a bugfix (forgotten spinlock added) or is it due to change of
getticksoffset_tscupdate() contents? (Just trying to understand how it
works.)
--
Alex
___
Adeos-main mailing list
Adeos-main@gna.org
https://mail.gna.org/listinfo/adeos-main
Re: [Adeos-main] Ipipe hangs on ARM MINI2440 after switching clocksource
Alexey Galakhov wrote: > Hi, > > I'm trying to run Xenomai on MINI2440 board. I use vanilla 2.6.35.9 > kernel patched with adeos-ipipe-2.6.35.9-arm-1.18-01.patch . In kernel > configuration Xenomai is disabled, the only option (except debug) I > turned on is CONFIG_IPIPE. It hangs. > > I suspect it is somehow related to TIMER3 which is used along with > TIMER4 on Samsung ARMs. Any suggestions? There was a bug some time ago, which was fixed for TIMER3, see commit: http://git.xenomai.org/?p=ipipe-gch.git;a=commit;h=ebf2fac4298e25509ba47942b9fad408dcefce1e But I think your problem has more to do with the following commit, could you try reverting it? http://git.xenomai.org/?p=ipipe-gch.git;a=commitdiff;h=6ab29d9c7a4b119f45ef4d93780e894fe1c0c6c6;hp=cd9c5e016092258d4450e137be2d0844d0fe8b38 The same issue was reported on ixp4xx. -- Gilles. ___ Adeos-main mailing list Adeos-main@gna.org https://mail.gna.org/listinfo/adeos-main
