This breaks the build, tmreg_lock is only present in certain
configurations.
No, FEC have changed to check dramatically instead of static config.
You can look fec.h. tmreg_lock is always defined.
struct napi_struct napi;
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_caps;
unsigned long last_overflow_check;
spinlock_t tmreg_lock;
struct cyclecounter cc;
struct timecounter tc;
int rx_hwtstamp_filter;
u32 base_incval;
u32 cycle_speed;
int hwts_rx_en;
int hwts_tx_en;
struct timer_list time_keep;
best regards
Frank Li
Please excuse me, if I'm wrong. I would consider this as a very wrong
solution:
First, then the spin lock is initialised twice (first time in
fec_enet_init(), second time in fec_ptp_init()).
Then this patch actually hides the fact that PTP part of fec
is accessed from fec_ptp_start_cyclecounter() way before
than fec_ptp_init() is called to initialize PTP).
In my opinion the right patch should either move fec_ptp_init() call
before fec_restart(), or make fec_restart intelelctual about calling
fec_ptp_init()/fec_ptp_startcyclecounter() at proper time.
--
With best wishes
Dmitry
Please excuse me, if I'm wrong. I would consider this as a very wrong
solution:
First, then the spin lock is initialised twice (first time in
fec_enet_init(), second time in fec_ptp_init()).
Then this patch actually hides the fact that PTP part of fec
is accessed from fec_ptp_start_cyclecounter() way before
than fec_ptp_init() is called to initialize PTP).
In my opinion the right patch should either move fec_ptp_init() call
before fec_restart(), or make fec_restart intelelctual about calling
fec_ptp_init()/fec_ptp_startcyclecounter() at proper time.
Yes, you are right.
--
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you for you tested my patch.
Can you try my new patch?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(mark_lock+0x37c/0x628)
[ 10.658789] [<80068648>] (mark_lock+0x0/0x628) from [<8006928c>]
(__lock_acquire+0x61c/0x1998)
[ 10.667416] [<80068c70>] (__lock_acquire+0x0/0x1998) from [<8006ac20>]
(lock_acquire+0x124/0x148)
[ 10.676304] [<8006aafc>] (lock_acquire+0x0/0x148) from [<803de31c>]
(_raw_spin_lock+0x40/0x50)
[ 10.684931] [<803de2dc>] (_raw_spin_lock+0x0/0x50) from [<8029d154>]
(fec_enet_interrupt+0x74/0x600)
[ 10.694068] r5:ac74a500 r4:ac74a000
[ 10.697694] [<8029d0e0>] (fec_enet_interrupt+0x0/0x600) from [<800812f0>]
(handle_irq_event_percpu+0xbc/0x2a8)
[ 10.707711] [<80081234>] (handle_irq_event_percpu+0x0/0x2a8) from
[<80081520>] (handle_irq_event+0x44/0x64)
[ 10.717467] [<800814dc>] (handle_irq_event+0x0/0x64) from [<800842f8>]
(handle_fasteoi_irq+0xd0/0x11c)
[ 10.726778] r6:ffffffff r5:ac012290 r4:ac012240 r3:00000000
[ 10.732522] [<80084228>] (handle_fasteoi_irq+0x0/0x11c) from [<80080be8>]
(generic_handle_irq+0x28/0x38)
[ 10.742008] r5:00000000 r4:00000096
[ 10.745635] [<80080bc0>] (generic_handle_irq+0x0/0x38) from [<8000e298>]
(handle_IRQ+0x80/0xc0)
[ 10.754339] r4:00000096 r3:00000220
[ 10.757964] [<8000e218>] (handle_IRQ+0x0/0xc0) from [<8000850c>]
(gic_handle_irq+0x40/0x64)
[ 10.766321] r5:8057ff28 r4:f4000100
[ 10.769945] [<800084cc>] (gic_handle_irq+0x0/0x64) from [<803deec4>]
(__irq_svc+0x44/0x78)
[ 10.778216] Exception stack(0x8057ff28 to 0x8057ff70)
[ 10.783279] ff20: 00000001 00000004 00000000 00000000
00000001 00000002
[ 10.791469] ff40: ffffffff 80571fe4 81354b80 412fc09a 00000000 8057ff7c
8057ff40 8057ff70
[ 10.799655] ff60: 8006b574 8000e514 20000013 ffffffff
[ 10.804713] r5:20000013 r4:8000e514
[ 10.808339] [<8000e4e4>] (default_idle+0x0/0x38) from [<8000e748>]
(cpu_idle+0xb0/0x110)
[ 10.816447] [<8000e698>] (cpu_idle+0x0/0x110) from [<803cba2c>]
(rest_init+0xac/0xd4)
[ 10.824293] [<803cb980>] (rest_init+0x0/0xd4) from [<8054e830>]
(start_kernel+0x2bc/0x30c)
[ 10.832562] r5:805ce340 r4:80586df0
[ 10.836185] [<8054e574>] (start_kernel+0x0/0x30c) from [<10008044>]
(0x10008044)
INIT: version 2.86 booting
Have you seen this?
I am using the following configs:
CONFIG_KALLSYMS_ALL=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
Thank you for you tested my patch.
Can you try my new patch?
quoted
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you, I have tried your new patch, it fixes the boot deadlock but when I
run the ptp4l command I get another dead lock:
On client running "./ptp4l -S -i eth0 -s -m"
On the i.MX6:
root@mx6q35:~# ptp4l -H -m -i eth0 -p /dev/ptp0
ptp4l[98.894]: selected /dev/ptp0 as PTP clock
ptp4l[98.896]: failed to read out the clock frequency adjustment: Operation not
supported
ptp4l[98.900]: driver changed our HWTSTAMP options
ptp4l[98.900]: tx_type 1 not 1
ptp4l[98.900]: rx_filter 1 not 12
ptp4l[98.901]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[98.902]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[104.901]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
[ 111.161885] =================================
[ 111.166249] [ INFO: inconsistent lock state ]
[ 111.170616] 3.5.7.3-01268-g6696bd7-dirty #2 Not tainted
[ 111.175848] ---------------------------------
[ 111.180213] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 111.186230] ptp4l/335 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 111.191200] (&(&list->lock)->rlock#4){?.-...}, at: [<80328590>]
skb_queue_tail+0x20/0x50
[ 111.199484] {HARDIRQ-ON-W} state was registered at:
[ 111.204367] [<800688d8>] mark_lock+0x290/0x628
[ 111.209024] [<80069320>] __lock_acquire+0x6b0/0x1998
[ 111.214189] [<8006ac20>] lock_acquire+0x124/0x148
[ 111.219092] [<803de5c4>] _raw_spin_lock_bh+0x44/0x54
[ 111.224265] [<803a9eec>] packet_poll+0x24/0xdc
[ 111.228918] [<8032037c>] sock_poll+0x20/0x24
[ 111.233395] [<800fc4b4>] do_select+0x2ec/0x494
[ 111.238040] [<800fc8e0>] core_sys_select+0x284/0x354
[ 111.243203] [<800fca8c>] sys_select+0xdc/0x10c
[ 111.247844] [<8000d940>] ret_fast_syscall+0x0/0x3c
[ 111.252844] irq event stamp: 4858
[ 111.256165] hardirqs last enabled at (4857): [<80029a70>]
local_bh_enable+0xcc/0x100
[ 111.264032] hardirqs last disabled at (4858): [<8000d94c>]
ret_fast_syscall+0xc/0x3c
[ 111.271801] softirqs last enabled at (4856): [<80336768>]
dev_queue_xmit+0x73c/0x7c4
[ 111.279659] softirqs last disabled at (4852): [<80336048>]
dev_queue_xmit+0x1c/0x7c4
[ 111.287427]
[ 111.287427] other info that might help us debug this:
[ 111.293963] Possible unsafe locking scenario:
[ 111.293963]
[ 111.299889] CPU0
[ 111.302341] ----
[ 111.304792] lock(&(&list->lock)->rlock#4);
[ 111.309116] <Interrupt>
[ 111.311741] lock(&(&list->lock)->rlock#4);
[ 111.316238]
[ 111.316238] *** DEADLOCK ***
[ 111.316238]
[ 111.322170] 1 lock held by ptp4l/335:
[ 111.325838] #0: (&(&fep->hw_lock)->rlock){-.-...}, at: [<8029d470>]
fec_enet_interrupt+0x390/0x600
[ 111.335068]
[ 111.335068] stack backtrace:
[ 111.339433] Backtrace:
[ 111.341922] [<80011a58>] (dump_backtrace+0x0/0x10c) from [<803da940>]
(dump_stack+0x18/0x1c)
[ 111.350366] r6:806cfaa0 r5:806cfaa0 r4:acb62e40 r3:acb62e40
[ 111.356111] [<803da928>] (dump_stack+0x0/0x1c) from [<800685e0>]
(print_usage_bug+0x250/0x2b8)
[ 111.364739] [<80068390>] (print_usage_bug+0x0/0x2b8) from [<8006899c>]
(mark_lock+0x354/0x628)
[ 111.373365] [<80068648>] (mark_lock+0x0/0x628) from [<8006928c>]
(__lock_acquire+0x61c/0x1998)
[ 111.381993] [<80068c70>] (__lock_acquire+0x0/0x1998) from [<8006ac20>]
(lock_acquire+0x124/0x148)
[ 111.390882] [<8006aafc>] (lock_acquire+0x0/0x148) from [<803de414>]
(_raw_spin_lock_irqsave+0x4c/0x60)
[ 111.400203] [<803de3c8>] (_raw_spin_lock_irqsave+0x0/0x60) from [<80328590>]
(skb_queue_tail+0x20/0x50)
[ 111.409601] r6:acc54198 r5:ac9ebb40 r4:acc5418c
[ 111.414285] [<80328570>] (skb_queue_tail+0x0/0x50) from [<803286d8>]
(sock_queue_err_skb+0x118/0x164)
[ 111.423509] r6:00000056 r5:ac9ebb40 r4:acc54000 r3:00000000
[ 111.429254] [<803285c0>] (sock_queue_err_skb+0x0/0x164) from [<8032ac4c>]
(skb_tstamp_tx+0x84/0x9c)
[ 111.438305] r7:b0042280 r6:ac9ebb58 r5:acc54000 r4:ac9ebb40
[ 111.444049] [<8032abc8>] (skb_tstamp_tx+0x0/0x9c) from [<8029d5e4>]
(fec_enet_interrupt+0x504/0x600)
[ 111.453187] r6:00001c00 r5:ac780500 r4:ac780000
[ 111.457878] [<8029d0e0>] (fec_enet_interrupt+0x0/0x600) from [<800812f0>]
(handle_irq_event_percpu+0xbc/0x2a8)
[ 111.467894] [<80081234>] (handle_irq_event_percpu+0x0/0x2a8) from
[<80081520>] (handle_irq_event+0x44/0x64)
[ 111.477654] [<800814dc>] (handle_irq_event+0x0/0x64) from [<800842f8>]
(handle_fasteoi_irq+0xd0/0x11c)
[ 111.486965] r6:ffffffff r5:ac012290 r4:ac012240 r3:00000000
[ 111.492709] [<80084228>] (handle_fasteoi_irq+0x0/0x11c) from [<80080be8>]
(generic_handle_irq+0x28/0x38)
[ 111.502194] r5:00000000 r4:00000096
[ 111.505820] [<80080bc0>] (generic_handle_irq+0x0/0x38) from [<8000e298>]
(handle_IRQ+0x80/0xc0)
[ 111.514524] r4:00000096 r3:00000220
[ 111.518149] [<8000e218>] (handle_IRQ+0x0/0xc0) from [<8000850c>]
(gic_handle_irq+0x40/0x64)
[ 111.526505] r5:acc09fb0 r4:f4000100
[ 111.530132] [<800084cc>] (gic_handle_irq+0x0/0x64) from [<803df060>]
(__irq_usr+0x40/0x60)
[ 111.538404] Exception stack(0xacc09fb0 to 0xacc09ff8)
[ 111.543466] 9fa0: 00000018 00000269
00000000 00000000
[ 111.551656] 9fc0: 00000001 76f615f0 3e09c05c 00000007 00000000 76f62650
76f63dc8 01f04e02
[ 111.559843] 9fe0: 00000002 7ef6c218 76f4c55c 76f45aec 60000010 ffffffff
[ 111.566463] r5:60000010 r4:76f45aec
(mark_lock+0x37c/0x628)
[ 10.658789] [<80068648>] (mark_lock+0x0/0x628) from [<8006928c>]
(__lock_acquire+0x61c/0x1998)
[ 10.667416] [<80068c70>] (__lock_acquire+0x0/0x1998) from [<8006ac20>]
(lock_acquire+0x124/0x148)
[ 10.676304] [<8006aafc>] (lock_acquire+0x0/0x148) from [<803de31c>]
(_raw_spin_lock+0x40/0x50)
[ 10.684931] [<803de2dc>] (_raw_spin_lock+0x0/0x50) from [<8029d154>]
(fec_enet_interrupt+0x74/0x600)
[ 10.694068] r5:ac74a500 r4:ac74a000
[ 10.697694] [<8029d0e0>] (fec_enet_interrupt+0x0/0x600) from [<800812f0>]
(handle_irq_event_percpu+0xbc/0x2a8)
[ 10.707711] [<80081234>] (handle_irq_event_percpu+0x0/0x2a8) from
[<80081520>] (handle_irq_event+0x44/0x64)
[ 10.717467] [<800814dc>] (handle_irq_event+0x0/0x64) from [<800842f8>]
(handle_fasteoi_irq+0xd0/0x11c)
[ 10.726778] r6:ffffffff r5:ac012290 r4:ac012240 r3:00000000
[ 10.732522] [<80084228>] (handle_fasteoi_irq+0x0/0x11c) from [<80080be8>]
(generic_handle_irq+0x28/0x38)
[ 10.742008] r5:00000000 r4:00000096
[ 10.745635] [<80080bc0>] (generic_handle_irq+0x0/0x38) from [<8000e298>]
(handle_IRQ+0x80/0xc0)
[ 10.754339] r4:00000096 r3:00000220
[ 10.757964] [<8000e218>] (handle_IRQ+0x0/0xc0) from [<8000850c>]
(gic_handle_irq+0x40/0x64)
[ 10.766321] r5:8057ff28 r4:f4000100
[ 10.769945] [<800084cc>] (gic_handle_irq+0x0/0x64) from [<803deec4>]
(__irq_svc+0x44/0x78)
[ 10.778216] Exception stack(0x8057ff28 to 0x8057ff70)
[ 10.783279] ff20: 00000001 00000004 00000000 00000000
00000001 00000002
[ 10.791469] ff40: ffffffff 80571fe4 81354b80 412fc09a 00000000 8057ff7c
8057ff40 8057ff70
[ 10.799655] ff60: 8006b574 8000e514 20000013 ffffffff
[ 10.804713] r5:20000013 r4:8000e514
[ 10.808339] [<8000e4e4>] (default_idle+0x0/0x38) from [<8000e748>]
(cpu_idle+0xb0/0x110)
[ 10.816447] [<8000e698>] (cpu_idle+0x0/0x110) from [<803cba2c>]
(rest_init+0xac/0xd4)
[ 10.824293] [<803cb980>] (rest_init+0x0/0xd4) from [<8054e830>]
(start_kernel+0x2bc/0x30c)
[ 10.832562] r5:805ce340 r4:80586df0
[ 10.836185] [<8054e574>] (start_kernel+0x0/0x30c) from [<10008044>]
(0x10008044)
INIT: version 2.86 booting
Have you seen this?
I am using the following configs:
CONFIG_KALLSYMS_ALL=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
Thank you for you tested my patch.
Can you try my new patch?
quoted
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thank you, I have tried your new patch, it fixes the boot deadlock but when I
run the ptp4l command I get another dead lock:
On client running "./ptp4l -S -i eth0 -s -m"
On the i.MX6:
root@mx6q35:~# ptp4l -H -m -i eth0 -p /dev/ptp0
ptp4l[98.894]: selected /dev/ptp0 as PTP clock
ptp4l[98.896]: failed to read out the clock frequency adjustment: Operation not
supported
ptp4l[98.900]: driver changed our HWTSTAMP options
ptp4l[98.900]: tx_type 1 not 1
ptp4l[98.900]: rx_filter 1 not 12
ptp4l[98.901]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[98.902]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[104.901]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
[ 111.161885] =================================
[ 111.166249] [ INFO: inconsistent lock state ]
[ 111.170616] 3.5.7.3-01268-g6696bd7-dirty #2 Not tainted
[ 111.175848] ---------------------------------
[ 111.180213] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 111.186230] ptp4l/335 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 111.191200] (&(&list->lock)->rlock#4){?.-...}, at: [<80328590>]
skb_queue_tail+0x20/0x50
[ 111.199484] {HARDIRQ-ON-W} state was registered at:
[ 111.204367] [<800688d8>] mark_lock+0x290/0x628
[ 111.209024] [<80069320>] __lock_acquire+0x6b0/0x1998
[ 111.214189] [<8006ac20>] lock_acquire+0x124/0x148
[ 111.219092] [<803de5c4>] _raw_spin_lock_bh+0x44/0x54
[ 111.224265] [<803a9eec>] packet_poll+0x24/0xdc
[ 111.228918] [<8032037c>] sock_poll+0x20/0x24
[ 111.233395] [<800fc4b4>] do_select+0x2ec/0x494
[ 111.238040] [<800fc8e0>] core_sys_select+0x284/0x354
[ 111.243203] [<800fca8c>] sys_select+0xdc/0x10c
[ 111.247844] [<8000d940>] ret_fast_syscall+0x0/0x3c
[ 111.252844] irq event stamp: 4858
[ 111.256165] hardirqs last enabled at (4857): [<80029a70>]
local_bh_enable+0xcc/0x100
[ 111.264032] hardirqs last disabled at (4858): [<8000d94c>]
ret_fast_syscall+0xc/0x3c
[ 111.271801] softirqs last enabled at (4856): [<80336768>]
dev_queue_xmit+0x73c/0x7c4
[ 111.279659] softirqs last disabled at (4852): [<80336048>]
dev_queue_xmit+0x1c/0x7c4
[ 111.287427]
[ 111.287427] other info that might help us debug this:
[ 111.293963] Possible unsafe locking scenario:
[ 111.293963]
[ 111.299889] CPU0
[ 111.302341] ----
[ 111.304792] lock(&(&list->lock)->rlock#4);
[ 111.309116] <Interrupt>
[ 111.311741] lock(&(&list->lock)->rlock#4);
[ 111.316238]
[ 111.316238] *** DEADLOCK ***
[ 111.316238]
[ 111.322170] 1 lock held by ptp4l/335:
[ 111.325838] #0: (&(&fep->hw_lock)->rlock){-.-...}, at: [<8029d470>]
fec_enet_interrupt+0x390/0x600
[ 111.335068]
[ 111.335068] stack backtrace:
[ 111.339433] Backtrace:
[ 111.341922] [<80011a58>] (dump_backtrace+0x0/0x10c) from [<803da940>]
(dump_stack+0x18/0x1c)
[ 111.350366] r6:806cfaa0 r5:806cfaa0 r4:acb62e40 r3:acb62e40
[ 111.356111] [<803da928>] (dump_stack+0x0/0x1c) from [<800685e0>]
(print_usage_bug+0x250/0x2b8)
[ 111.364739] [<80068390>] (print_usage_bug+0x0/0x2b8) from [<8006899c>]
(mark_lock+0x354/0x628)
[ 111.373365] [<80068648>] (mark_lock+0x0/0x628) from [<8006928c>]
(__lock_acquire+0x61c/0x1998)
[ 111.381993] [<80068c70>] (__lock_acquire+0x0/0x1998) from [<8006ac20>]
(lock_acquire+0x124/0x148)
[ 111.390882] [<8006aafc>] (lock_acquire+0x0/0x148) from [<803de414>]
(_raw_spin_lock_irqsave+0x4c/0x60)
[ 111.400203] [<803de3c8>] (_raw_spin_lock_irqsave+0x0/0x60) from [<80328590>]
(skb_queue_tail+0x20/0x50)
[ 111.409601] r6:acc54198 r5:ac9ebb40 r4:acc5418c
[ 111.414285] [<80328570>] (skb_queue_tail+0x0/0x50) from [<803286d8>]
(sock_queue_err_skb+0x118/0x164)
[ 111.423509] r6:00000056 r5:ac9ebb40 r4:acc54000 r3:00000000
[ 111.429254] [<803285c0>] (sock_queue_err_skb+0x0/0x164) from [<8032ac4c>]
(skb_tstamp_tx+0x84/0x9c)
[ 111.438305] r7:b0042280 r6:ac9ebb58 r5:acc54000 r4:ac9ebb40
[ 111.444049] [<8032abc8>] (skb_tstamp_tx+0x0/0x9c) from [<8029d5e4>]
(fec_enet_interrupt+0x504/0x600)
[ 111.453187] r6:00001c00 r5:ac780500 r4:ac780000
[ 111.457878] [<8029d0e0>] (fec_enet_interrupt+0x0/0x600) from [<800812f0>]
(handle_irq_event_percpu+0xbc/0x2a8)
[ 111.467894] [<80081234>] (handle_irq_event_percpu+0x0/0x2a8) from
[<80081520>] (handle_irq_event+0x44/0x64)
[ 111.477654] [<800814dc>] (handle_irq_event+0x0/0x64) from [<800842f8>]
(handle_fasteoi_irq+0xd0/0x11c)
[ 111.486965] r6:ffffffff r5:ac012290 r4:ac012240 r3:00000000
[ 111.492709] [<80084228>] (handle_fasteoi_irq+0x0/0x11c) from [<80080be8>]
(generic_handle_irq+0x28/0x38)
[ 111.502194] r5:00000000 r4:00000096
[ 111.505820] [<80080bc0>] (generic_handle_irq+0x0/0x38) from [<8000e298>]
(handle_IRQ+0x80/0xc0)
[ 111.514524] r4:00000096 r3:00000220
[ 111.518149] [<8000e218>] (handle_IRQ+0x0/0xc0) from [<8000850c>]
(gic_handle_irq+0x40/0x64)
[ 111.526505] r5:acc09fb0 r4:f4000100
[ 111.530132] [<800084cc>] (gic_handle_irq+0x0/0x64) from [<803df060>]
(__irq_usr+0x40/0x60)
[ 111.538404] Exception stack(0xacc09fb0 to 0xacc09ff8)
[ 111.543466] 9fa0: 00000018 00000269
00000000 00000000
[ 111.551656] 9fc0: 00000001 76f615f0 3e09c05c 00000007 00000000 76f62650
76f63dc8 01f04e02
[ 111.559843] 9fe0: 00000002 7ef6c218 76f4c55c 76f45aec 60000010 ffffffff
[ 111.566463] r5:60000010 r4:76f45aec
It is not easy to fix. Need put tx to NAPI poll function.
I will work on that after China New year holiday
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Waskiewicz Jr, Peter P <hidden> Date: 2013-02-06 13:48:26
On 2/6/2013 1:50 AM, Frank Li wrote:
It is not easy to fix. Need put tx to NAPI poll function.
I will work on that after China New year holiday
Converting Tx to NAPI is the best solution, but you can put a temporary
fix in. Don't take a spin_lock() in fec_enet_tx(), rather take a
spin_lock_irqsave() since you're still in HARDIRQ context.
-PJ
It is not easy to fix. Need put tx to NAPI poll function.
I will work on that after China New year holiday
Converting Tx to NAPI is the best solution, but you can put a temporary fix
in. Don't take a spin_lock() in fec_enet_tx(), rather take a
spin_lock_irqsave() since you're still in HARDIRQ context.
That's not help.
skb_tx_timestamp function call some function using lock, which lock
used at the other place, just call spinlock_bh.
skb_tx_timestamp seem be called only in softirq context, not irq context.
From: Jim Baxter <hidden> Date: 2013-02-21 17:07:29
Is the general issue in this driver that the fec_probe function:
request_irq(irq, fec_enet_interrupt, IRQF_DISABLED, pdev->name, ndev);
is called before fec_ptp_init() and fec_enet_init() have been called so that
there is a chance the fec_enet_interrupt can occur before the hardware and data
structures are fully setup?
On Thu, Feb 21, 2013 at 2:07 PM, Jim Baxter [off-list ref] wrote:
Is the general issue in this driver that the fec_probe function:
request_irq(irq, fec_enet_interrupt, IRQF_DISABLED, pdev->name, ndev);
is called before fec_ptp_init() and fec_enet_init() have been called so that
there is a chance the fec_enet_interrupt can occur before the hardware and data
structures are fully setup?
From: Jim Baxter <hidden> Date: 2013-02-21 17:59:42
Fabio Estevam <festevam <at> gmail.com> writes:
On Thu, Feb 21, 2013 at 2:07 PM, Jim Baxter <jim_baxter <at> mentor.com> wrote:
quoted
Is the general issue in this driver that the fec_probe function:
request_irq(irq, fec_enet_interrupt, IRQF_DISABLED, pdev->name, ndev);
is called before fec_ptp_init() and fec_enet_init() have been called so that
there is a chance the fec_enet_interrupt can occur before the hardware and
That is a good patch that will stop interrupts occurring before request_irq is
called.
What about the problem of fec_enet_interrupt calling fec_ptp_start_cyclecounter
before fec_ptp_init has been called?
Should fec_enet_init and fec_ptp_init be setup before the request_irq is called?
From: David Miller <davem@davemloft.net> Date: 2013-02-21 18:03:20
From: Jim Baxter <redacted>
Date: Thu, 21 Feb 2013 17:59:23 +0000 (UTC)
Fabio Estevam <festevam <at> gmail.com> writes:
quoted
On Thu, Feb 21, 2013 at 2:07 PM, Jim Baxter <jim_baxter <at> mentor.com> wrote:
quoted
Is the general issue in this driver that the fec_probe function:
request_irq(irq, fec_enet_interrupt, IRQF_DISABLED, pdev->name, ndev);
is called before fec_ptp_init() and fec_enet_init() have been called so that
there is a chance the fec_enet_interrupt can occur before the hardware and
That is a good patch that will stop interrupts occurring before request_irq is
called.
What about the problem of fec_enet_interrupt calling fec_ptp_start_cyclecounter
before fec_ptp_init has been called?
Should fec_enet_init and fec_ptp_init be setup before the request_irq is called?
This is a reocurring theme, and there is only one answer.
All software state MUCH be completely, and fully, initialized before
request_irq() is invoked.
There is no other valid way to proceed in this area.
On Thu, Feb 21, 2013 at 2:59 PM, Jim Baxter [off-list ref] wrote:
That is a good patch that will stop interrupts occurring before request_irq is
called.
What about the problem of fec_enet_interrupt calling fec_ptp_start_cyclecounter
before fec_ptp_init has been called?
Should fec_enet_init and fec_ptp_init be setup before the request_irq is called?
On Thu, Feb 21, 2013 at 3:04 PM, Fabio Estevam [off-list ref] wrote:
On Thu, Feb 21, 2013 at 2:59 PM, Jim Baxter [off-list ref] wrote:
quoted
That is a good patch that will stop interrupts occurring before request_irq is
called.
What about the problem of fec_enet_interrupt calling fec_ptp_start_cyclecounter
before fec_ptp_init has been called?
Should fec_enet_init and fec_ptp_init be setup before the request_irq is called?
Yes, I think so. Care to submit a patch?
Ok, I prepared a patch with this fix and will submit shortly.
It is not easy to fix. Need put tx to NAPI poll function.
I will work on that after China New year holiday
Hi Frank,
Have you had time to have a look at this issues again?
Does it happen when run ptp4?
I am working on put xmit to NAPI and remove lock.
Jim
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Frank,
On Fri, Feb 22, 2013 at 9:46 PM, Frank Li [off-list ref] wrote:
Does it happen when run ptp4?
I am working on put xmit to NAPI and remove lock.
Jim reported the way to reproduce this issue in a previous post in this thread:
"Thank you, I have tried your new patch, it fixes the boot deadlock but when I
run the ptp4l command I get another dead lock:
On client running "./ptp4l -S -i eth0 -s -m"
On the i.MX6:
root@mx6q35:~# ptp4l -H -m -i eth0 -p /dev/ptp0
ptp4l[98.894]: selected /dev/ptp0 as PTP clock
ptp4l[98.896]: failed to read out the clock frequency adjustment: Operation not
supported
ptp4l[98.900]: driver changed our HWTSTAMP options
ptp4l[98.900]: tx_type 1 not 1
ptp4l[98.900]: rx_filter 1 not 12
ptp4l[98.901]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[98.902]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[104.901]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
[ 111.161885] =================================
[ 111.166249] [ INFO: inconsistent lock state ]
[ 111.170616] 3.5.7.3-01268-g6696bd7-dirty #2 Not tainted
[ 111.175848] ---------------------------------"