Re: [2.6.23-rt3] NMI watchdog trace of deadlock
-- On Sat, 27 Oct 2007, Mike Galbraith wrote: > > Hm. Looking at the change to mm/bounce.c, perhaps I should do this > instead? > > --- ./fs/ntfs/aops.c.org 2007-10-27 10:16:40.0 +0200 > +++ ./fs/ntfs/aops.c 2007-10-27 12:11:07.0 +0200 > @@ -139,13 +139,13 @@ static void ntfs_end_buffer_async_read(s > recs = PAGE_CACHE_SIZE / rec_size; > /* Should have been verified before we got here... */ > BUG_ON(!recs); > - local_irq_save(flags); > + local_irq_save_nort(flags); > kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ); > for (i = 0; i < recs; i++) > post_read_mst_fixup((NTFS_RECORD*)(kaddr + > i * rec_size), rec_size); > kunmap_atomic(kaddr, KM_BIO_SRC_IRQ); > - local_irq_restore(flags); > + local_irq_restore_nort(flags); > flush_dcache_page(page); > if (likely(page_uptodate && !PageError(page))) > SetPageUptodate(page); > Thanks, applied. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
-- On Sat, 27 Oct 2007, Jaswinder Singh wrote: > Hello Ingo, > > On 10/27/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > it's not atomic interrupt context but irq thread context - and -rt > > remaps kmap_atomic() to kmap() internally. > > > > the problem seems to be what Mike's patch works around: fiddling with > > irq flags in the ntfs code. That fiddling seems quite unnecessary at > > first sight. > > > > Is this a nice idea to go inside device drivers and filesystem and > make changes in kernel source code to enable RT. Actually the question is, is it a nice idea for drivers to disable interrupts for no obvious reason. I'm sure you have a reason, but it's not obvious to me why. What does it protect? Is it SMP safe? When tuning a RT system for the customer, the first thing we recommend is to check to make sure all the drivers in use do not disable interrupts. > > RT related change should be in header files, so that we don't need to > make changes for drivers or filesystem source files. > > And when user will disable RT then these patches will again make problems. > > We need to find some better alternative. We do have the local_irq_save_nort that Mike has posted. This is a simple wrapper around local_irq_save that enables it when RT is not configured, and is a nop when RT is configured. Thanks, -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
* Mike Galbraith <[EMAIL PROTECTED]> wrote: > > it's not atomic interrupt context but irq thread context - and -rt > > remaps kmap_atomic() to kmap() internally. > > Hm. Looking at the change to mm/bounce.c, perhaps I should do this > instead? yeah, this looks better. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Sat, 2007-10-27 at 11:44 +0200, Ingo Molnar wrote: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > [10138.175796] [] show_trace+0x12/0x14 > > > [10138.180291] [] dump_stack+0x16/0x18 > > > [10138.184769] [] native_smp_call_function_mask+0x138/0x13d > > > [10138.191117] [] smp_call_function+0x1e/0x24 > > > [10138.196210] [] on_each_cpu+0x25/0x50 > > > [10138.200807] [] flush_tlb_all+0x1e/0x20 > > > [10138.205553] [] kmap_high+0x1b6/0x417 > > > [10138.210118] [] kmap+0x4d/0x4f > > > [10138.214102] [] ntfs_end_buffer_async_read+0x228/0x2f9 > > > [10138.220163] [] end_bio_bh_io_sync+0x26/0x3f > > > [10138.225352] [] bio_endio+0x42/0x6d > > > [10138.229769] [] __end_that_request_first+0x115/0x4ac > > > [10138.235682] [] end_that_request_chunk+0x8/0xa > > > [10138.241052] [] ide_end_request+0x55/0x10a > > > [10138.246058] [] ide_dma_intr+0x6f/0xac > > > [10138.250727] [] ide_intr+0x93/0x1e0 > > > [10138.255125] [] handle_IRQ_event+0x5c/0xc9 > > > > Looks like ntfs is kmap()ing from interrupt context. Should be using > > kmap_atomic instead, I think. > > it's not atomic interrupt context but irq thread context - and -rt > remaps kmap_atomic() to kmap() internally. Hm. Looking at the change to mm/bounce.c, perhaps I should do this instead? --- ./fs/ntfs/aops.c.org2007-10-27 10:16:40.0 +0200 +++ ./fs/ntfs/aops.c2007-10-27 12:11:07.0 +0200 @@ -139,13 +139,13 @@ static void ntfs_end_buffer_async_read(s recs = PAGE_CACHE_SIZE / rec_size; /* Should have been verified before we got here... */ BUG_ON(!recs); - local_irq_save(flags); + local_irq_save_nort(flags); kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ); for (i = 0; i < recs; i++) post_read_mst_fixup((NTFS_RECORD*)(kaddr + i * rec_size), rec_size); kunmap_atomic(kaddr, KM_BIO_SRC_IRQ); - local_irq_restore(flags); + local_irq_restore_nort(flags); flush_dcache_page(page); if (likely(page_uptodate && !PageError(page))) SetPageUptodate(page); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
Hello Ingo, On 10/27/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > it's not atomic interrupt context but irq thread context - and -rt > remaps kmap_atomic() to kmap() internally. > > the problem seems to be what Mike's patch works around: fiddling with > irq flags in the ntfs code. That fiddling seems quite unnecessary at > first sight. > Is this a nice idea to go inside device drivers and filesystem and make changes in kernel source code to enable RT. RT related change should be in header files, so that we don't need to make changes for drivers or filesystem source files. And when user will disable RT then these patches will again make problems. We need to find some better alternative. Thank you, Jaswinder Singh. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
* Nick Piggin <[EMAIL PROTECTED]> wrote: > > [10138.175796] [] show_trace+0x12/0x14 > > [10138.180291] [] dump_stack+0x16/0x18 > > [10138.184769] [] native_smp_call_function_mask+0x138/0x13d > > [10138.191117] [] smp_call_function+0x1e/0x24 > > [10138.196210] [] on_each_cpu+0x25/0x50 > > [10138.200807] [] flush_tlb_all+0x1e/0x20 > > [10138.205553] [] kmap_high+0x1b6/0x417 > > [10138.210118] [] kmap+0x4d/0x4f > > [10138.214102] [] ntfs_end_buffer_async_read+0x228/0x2f9 > > [10138.220163] [] end_bio_bh_io_sync+0x26/0x3f > > [10138.225352] [] bio_endio+0x42/0x6d > > [10138.229769] [] __end_that_request_first+0x115/0x4ac > > [10138.235682] [] end_that_request_chunk+0x8/0xa > > [10138.241052] [] ide_end_request+0x55/0x10a > > [10138.246058] [] ide_dma_intr+0x6f/0xac > > [10138.250727] [] ide_intr+0x93/0x1e0 > > [10138.255125] [] handle_IRQ_event+0x5c/0xc9 > > Looks like ntfs is kmap()ing from interrupt context. Should be using > kmap_atomic instead, I think. it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. the problem seems to be what Mike's patch works around: fiddling with irq flags in the ntfs code. That fiddling seems quite unnecessary at first sight. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Sat, 2007-10-27 at 19:15 +1000, Nick Piggin wrote: > On Saturday 27 October 2007 15:21, Mike Galbraith wrote: > > Greetings, > > > > For quite a while now, RT kernels have been locking up on me > > occasionally while my back is turned. Yesterday, the little bugger > > finally pounced while my serial console box was up and waiting. > > > > [10138.162953] WARNING: at arch/i386/kernel/smp.c:581 > > native_smp_call_function_mask() [10138.170583] [] > > show_trace_log_lvl+0x1a/0x30 > > [10138.175796] [] show_trace+0x12/0x14 > > [10138.180291] [] dump_stack+0x16/0x18 > > [10138.184769] [] native_smp_call_function_mask+0x138/0x13d > > [10138.191117] [] smp_call_function+0x1e/0x24 > > [10138.196210] [] on_each_cpu+0x25/0x50 > > [10138.200807] [] flush_tlb_all+0x1e/0x20 > > [10138.205553] [] kmap_high+0x1b6/0x417 > > [10138.210118] [] kmap+0x4d/0x4f > > [10138.214102] [] ntfs_end_buffer_async_read+0x228/0x2f9 > > [10138.220163] [] end_bio_bh_io_sync+0x26/0x3f > > [10138.225352] [] bio_endio+0x42/0x6d > > [10138.229769] [] __end_that_request_first+0x115/0x4ac > > [10138.235682] [] end_that_request_chunk+0x8/0xa > > [10138.241052] [] ide_end_request+0x55/0x10a > > [10138.246058] [] ide_dma_intr+0x6f/0xac > > [10138.250727] [] ide_intr+0x93/0x1e0 > > [10138.255125] [] handle_IRQ_event+0x5c/0xc9 > > Looks like ntfs is kmap()ing from interrupt context. Should > be using kmap_atomic instead, I think. > > But the ntfs code I have seems to do just that... The ntfs code does use kmap_atomic(), bit RT turns that into a wrapper for kmap(). I fed it a local_irq_enable(), and am waiting for it to tell me why that was stoopid ;-) thanks, -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Sat, 2007-10-27 at 07:21 +0200, Mike Galbraith wrote: > Greetings, > > For quite a while now, RT kernels have been locking up on me > occasionally while my back is turned. Yesterday, the little bugger > finally pounced while my serial console box was up and waiting. > > [10138.162953] WARNING: at arch/i386/kernel/smp.c:581 > native_smp_call_function_mask() > [10138.170583] [] show_trace_log_lvl+0x1a/0x30 > [10138.175796] [] show_trace+0x12/0x14 > [10138.180291] [] dump_stack+0x16/0x18 > [10138.184769] [] native_smp_call_function_mask+0x138/0x13d > [10138.191117] [] smp_call_function+0x1e/0x24 > [10138.196210] [] on_each_cpu+0x25/0x50 > [10138.200807] [] flush_tlb_all+0x1e/0x20 > [10138.205553] [] kmap_high+0x1b6/0x417 > [10138.210118] [] kmap+0x4d/0x4f > [10138.214102] [] ntfs_end_buffer_async_read+0x228/0x2f9 > [10138.220163] [] end_bio_bh_io_sync+0x26/0x3f > [10138.225352] [] bio_endio+0x42/0x6d > [10138.229769] [] __end_that_request_first+0x115/0x4ac > [10138.235682] [] end_that_request_chunk+0x8/0xa > [10138.241052] [] ide_end_request+0x55/0x10a > [10138.246058] [] ide_dma_intr+0x6f/0xac > [10138.250727] [] ide_intr+0x93/0x1e0 > [10138.255125] [] handle_IRQ_event+0x5c/0xc9 > [10138.260113] [] do_irqd+0x1fc/0x2ef > [10138.264514] [] kthread+0x39/0x5b > [10138.268740] [] kernel_thread_helper+0x7/0x14 > [10138.274006] === (box may recommend that i go figure out why interrupts are disabled instead;) --- ./fs/ntfs/aops.c.org2007-10-27 10:16:40.0 +0200 +++ ./fs/ntfs/aops.c2007-10-27 10:30:52.0 +0200 @@ -140,6 +140,7 @@ static void ntfs_end_buffer_async_read(s /* Should have been verified before we got here... */ BUG_ON(!recs); local_irq_save(flags); + local_irq_enable(); kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ); for (i = 0; i < recs; i++) post_read_mst_fixup((NTFS_RECORD*)(kaddr + - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Saturday 27 October 2007 15:21, Mike Galbraith wrote: > Greetings, > > For quite a while now, RT kernels have been locking up on me > occasionally while my back is turned. Yesterday, the little bugger > finally pounced while my serial console box was up and waiting. > > [10138.162953] WARNING: at arch/i386/kernel/smp.c:581 > native_smp_call_function_mask() [10138.170583] [] > show_trace_log_lvl+0x1a/0x30 > [10138.175796] [] show_trace+0x12/0x14 > [10138.180291] [] dump_stack+0x16/0x18 > [10138.184769] [] native_smp_call_function_mask+0x138/0x13d > [10138.191117] [] smp_call_function+0x1e/0x24 > [10138.196210] [] on_each_cpu+0x25/0x50 > [10138.200807] [] flush_tlb_all+0x1e/0x20 > [10138.205553] [] kmap_high+0x1b6/0x417 > [10138.210118] [] kmap+0x4d/0x4f > [10138.214102] [] ntfs_end_buffer_async_read+0x228/0x2f9 > [10138.220163] [] end_bio_bh_io_sync+0x26/0x3f > [10138.225352] [] bio_endio+0x42/0x6d > [10138.229769] [] __end_that_request_first+0x115/0x4ac > [10138.235682] [] end_that_request_chunk+0x8/0xa > [10138.241052] [] ide_end_request+0x55/0x10a > [10138.246058] [] ide_dma_intr+0x6f/0xac > [10138.250727] [] ide_intr+0x93/0x1e0 > [10138.255125] [] handle_IRQ_event+0x5c/0xc9 Looks like ntfs is kmap()ing from interrupt context. Should be using kmap_atomic instead, I think. But the ntfs code I have seems to do just that... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Saturday 27 October 2007 15:21, Mike Galbraith wrote: Greetings, For quite a while now, RT kernels have been locking up on me occasionally while my back is turned. Yesterday, the little bugger finally pounced while my serial console box was up and waiting. [10138.162953] WARNING: at arch/i386/kernel/smp.c:581 native_smp_call_function_mask() [10138.170583] [c01051da] show_trace_log_lvl+0x1a/0x30 [10138.175796] [c0105de3] show_trace+0x12/0x14 [10138.180291] [c0105dfb] dump_stack+0x16/0x18 [10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d [10138.191117] [c0117606] smp_call_function+0x1e/0x24 [10138.196210] [c012f85c] on_each_cpu+0x25/0x50 [10138.200807] [c0115c74] flush_tlb_all+0x1e/0x20 [10138.205553] [c016caaf] kmap_high+0x1b6/0x417 [10138.210118] [c011ec88] kmap+0x4d/0x4f [10138.214102] [c026a9d8] ntfs_end_buffer_async_read+0x228/0x2f9 [10138.220163] [c01a0e9e] end_bio_bh_io_sync+0x26/0x3f [10138.225352] [c01a2b09] bio_endio+0x42/0x6d [10138.229769] [c02c2a08] __end_that_request_first+0x115/0x4ac [10138.235682] [c02c2da7] end_that_request_chunk+0x8/0xa [10138.241052] [c0365943] ide_end_request+0x55/0x10a [10138.246058] [c036dae3] ide_dma_intr+0x6f/0xac [10138.250727] [c0366d83] ide_intr+0x93/0x1e0 [10138.255125] [c015afb4] handle_IRQ_event+0x5c/0xc9 Looks like ntfs is kmap()ing from interrupt context. Should be using kmap_atomic instead, I think. But the ntfs code I have seems to do just that... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Sat, 2007-10-27 at 07:21 +0200, Mike Galbraith wrote: Greetings, For quite a while now, RT kernels have been locking up on me occasionally while my back is turned. Yesterday, the little bugger finally pounced while my serial console box was up and waiting. [10138.162953] WARNING: at arch/i386/kernel/smp.c:581 native_smp_call_function_mask() [10138.170583] [c01051da] show_trace_log_lvl+0x1a/0x30 [10138.175796] [c0105de3] show_trace+0x12/0x14 [10138.180291] [c0105dfb] dump_stack+0x16/0x18 [10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d [10138.191117] [c0117606] smp_call_function+0x1e/0x24 [10138.196210] [c012f85c] on_each_cpu+0x25/0x50 [10138.200807] [c0115c74] flush_tlb_all+0x1e/0x20 [10138.205553] [c016caaf] kmap_high+0x1b6/0x417 [10138.210118] [c011ec88] kmap+0x4d/0x4f [10138.214102] [c026a9d8] ntfs_end_buffer_async_read+0x228/0x2f9 [10138.220163] [c01a0e9e] end_bio_bh_io_sync+0x26/0x3f [10138.225352] [c01a2b09] bio_endio+0x42/0x6d [10138.229769] [c02c2a08] __end_that_request_first+0x115/0x4ac [10138.235682] [c02c2da7] end_that_request_chunk+0x8/0xa [10138.241052] [c0365943] ide_end_request+0x55/0x10a [10138.246058] [c036dae3] ide_dma_intr+0x6f/0xac [10138.250727] [c0366d83] ide_intr+0x93/0x1e0 [10138.255125] [c015afb4] handle_IRQ_event+0x5c/0xc9 [10138.260113] [c015bcfd] do_irqd+0x1fc/0x2ef [10138.264514] [c013cdb2] kthread+0x39/0x5b [10138.268740] [c0104e33] kernel_thread_helper+0x7/0x14 [10138.274006] === (box may recommend that i go figure out why interrupts are disabled instead;) --- ./fs/ntfs/aops.c.org2007-10-27 10:16:40.0 +0200 +++ ./fs/ntfs/aops.c2007-10-27 10:30:52.0 +0200 @@ -140,6 +140,7 @@ static void ntfs_end_buffer_async_read(s /* Should have been verified before we got here... */ BUG_ON(!recs); local_irq_save(flags); + local_irq_enable(); kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ); for (i = 0; i recs; i++) post_read_mst_fixup((NTFS_RECORD*)(kaddr + - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Sat, 2007-10-27 at 19:15 +1000, Nick Piggin wrote: On Saturday 27 October 2007 15:21, Mike Galbraith wrote: Greetings, For quite a while now, RT kernels have been locking up on me occasionally while my back is turned. Yesterday, the little bugger finally pounced while my serial console box was up and waiting. [10138.162953] WARNING: at arch/i386/kernel/smp.c:581 native_smp_call_function_mask() [10138.170583] [c01051da] show_trace_log_lvl+0x1a/0x30 [10138.175796] [c0105de3] show_trace+0x12/0x14 [10138.180291] [c0105dfb] dump_stack+0x16/0x18 [10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d [10138.191117] [c0117606] smp_call_function+0x1e/0x24 [10138.196210] [c012f85c] on_each_cpu+0x25/0x50 [10138.200807] [c0115c74] flush_tlb_all+0x1e/0x20 [10138.205553] [c016caaf] kmap_high+0x1b6/0x417 [10138.210118] [c011ec88] kmap+0x4d/0x4f [10138.214102] [c026a9d8] ntfs_end_buffer_async_read+0x228/0x2f9 [10138.220163] [c01a0e9e] end_bio_bh_io_sync+0x26/0x3f [10138.225352] [c01a2b09] bio_endio+0x42/0x6d [10138.229769] [c02c2a08] __end_that_request_first+0x115/0x4ac [10138.235682] [c02c2da7] end_that_request_chunk+0x8/0xa [10138.241052] [c0365943] ide_end_request+0x55/0x10a [10138.246058] [c036dae3] ide_dma_intr+0x6f/0xac [10138.250727] [c0366d83] ide_intr+0x93/0x1e0 [10138.255125] [c015afb4] handle_IRQ_event+0x5c/0xc9 Looks like ntfs is kmap()ing from interrupt context. Should be using kmap_atomic instead, I think. But the ntfs code I have seems to do just that... The ntfs code does use kmap_atomic(), bit RT turns that into a wrapper for kmap(). I fed it a local_irq_enable(), and am waiting for it to tell me why that was stoopid ;-) thanks, -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
* Nick Piggin [EMAIL PROTECTED] wrote: [10138.175796] [c0105de3] show_trace+0x12/0x14 [10138.180291] [c0105dfb] dump_stack+0x16/0x18 [10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d [10138.191117] [c0117606] smp_call_function+0x1e/0x24 [10138.196210] [c012f85c] on_each_cpu+0x25/0x50 [10138.200807] [c0115c74] flush_tlb_all+0x1e/0x20 [10138.205553] [c016caaf] kmap_high+0x1b6/0x417 [10138.210118] [c011ec88] kmap+0x4d/0x4f [10138.214102] [c026a9d8] ntfs_end_buffer_async_read+0x228/0x2f9 [10138.220163] [c01a0e9e] end_bio_bh_io_sync+0x26/0x3f [10138.225352] [c01a2b09] bio_endio+0x42/0x6d [10138.229769] [c02c2a08] __end_that_request_first+0x115/0x4ac [10138.235682] [c02c2da7] end_that_request_chunk+0x8/0xa [10138.241052] [c0365943] ide_end_request+0x55/0x10a [10138.246058] [c036dae3] ide_dma_intr+0x6f/0xac [10138.250727] [c0366d83] ide_intr+0x93/0x1e0 [10138.255125] [c015afb4] handle_IRQ_event+0x5c/0xc9 Looks like ntfs is kmap()ing from interrupt context. Should be using kmap_atomic instead, I think. it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. the problem seems to be what Mike's patch works around: fiddling with irq flags in the ntfs code. That fiddling seems quite unnecessary at first sight. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
Hello Ingo, On 10/27/07, Ingo Molnar [EMAIL PROTECTED] wrote: it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. the problem seems to be what Mike's patch works around: fiddling with irq flags in the ntfs code. That fiddling seems quite unnecessary at first sight. Is this a nice idea to go inside device drivers and filesystem and make changes in kernel source code to enable RT. RT related change should be in header files, so that we don't need to make changes for drivers or filesystem source files. And when user will disable RT then these patches will again make problems. We need to find some better alternative. Thank you, Jaswinder Singh. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
On Sat, 2007-10-27 at 11:44 +0200, Ingo Molnar wrote: * Nick Piggin [EMAIL PROTECTED] wrote: [10138.175796] [c0105de3] show_trace+0x12/0x14 [10138.180291] [c0105dfb] dump_stack+0x16/0x18 [10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d [10138.191117] [c0117606] smp_call_function+0x1e/0x24 [10138.196210] [c012f85c] on_each_cpu+0x25/0x50 [10138.200807] [c0115c74] flush_tlb_all+0x1e/0x20 [10138.205553] [c016caaf] kmap_high+0x1b6/0x417 [10138.210118] [c011ec88] kmap+0x4d/0x4f [10138.214102] [c026a9d8] ntfs_end_buffer_async_read+0x228/0x2f9 [10138.220163] [c01a0e9e] end_bio_bh_io_sync+0x26/0x3f [10138.225352] [c01a2b09] bio_endio+0x42/0x6d [10138.229769] [c02c2a08] __end_that_request_first+0x115/0x4ac [10138.235682] [c02c2da7] end_that_request_chunk+0x8/0xa [10138.241052] [c0365943] ide_end_request+0x55/0x10a [10138.246058] [c036dae3] ide_dma_intr+0x6f/0xac [10138.250727] [c0366d83] ide_intr+0x93/0x1e0 [10138.255125] [c015afb4] handle_IRQ_event+0x5c/0xc9 Looks like ntfs is kmap()ing from interrupt context. Should be using kmap_atomic instead, I think. it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. Hm. Looking at the change to mm/bounce.c, perhaps I should do this instead? --- ./fs/ntfs/aops.c.org2007-10-27 10:16:40.0 +0200 +++ ./fs/ntfs/aops.c2007-10-27 12:11:07.0 +0200 @@ -139,13 +139,13 @@ static void ntfs_end_buffer_async_read(s recs = PAGE_CACHE_SIZE / rec_size; /* Should have been verified before we got here... */ BUG_ON(!recs); - local_irq_save(flags); + local_irq_save_nort(flags); kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ); for (i = 0; i recs; i++) post_read_mst_fixup((NTFS_RECORD*)(kaddr + i * rec_size), rec_size); kunmap_atomic(kaddr, KM_BIO_SRC_IRQ); - local_irq_restore(flags); + local_irq_restore_nort(flags); flush_dcache_page(page); if (likely(page_uptodate !PageError(page))) SetPageUptodate(page); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
* Mike Galbraith [EMAIL PROTECTED] wrote: it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. Hm. Looking at the change to mm/bounce.c, perhaps I should do this instead? yeah, this looks better. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
-- On Sat, 27 Oct 2007, Jaswinder Singh wrote: Hello Ingo, On 10/27/07, Ingo Molnar [EMAIL PROTECTED] wrote: it's not atomic interrupt context but irq thread context - and -rt remaps kmap_atomic() to kmap() internally. the problem seems to be what Mike's patch works around: fiddling with irq flags in the ntfs code. That fiddling seems quite unnecessary at first sight. Is this a nice idea to go inside device drivers and filesystem and make changes in kernel source code to enable RT. Actually the question is, is it a nice idea for drivers to disable interrupts for no obvious reason. I'm sure you have a reason, but it's not obvious to me why. What does it protect? Is it SMP safe? When tuning a RT system for the customer, the first thing we recommend is to check to make sure all the drivers in use do not disable interrupts. RT related change should be in header files, so that we don't need to make changes for drivers or filesystem source files. And when user will disable RT then these patches will again make problems. We need to find some better alternative. We do have the local_irq_save_nort that Mike has posted. This is a simple wrapper around local_irq_save that enables it when RT is not configured, and is a nop when RT is configured. Thanks, -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-rt3] NMI watchdog trace of deadlock
-- On Sat, 27 Oct 2007, Mike Galbraith wrote: Hm. Looking at the change to mm/bounce.c, perhaps I should do this instead? --- ./fs/ntfs/aops.c.org 2007-10-27 10:16:40.0 +0200 +++ ./fs/ntfs/aops.c 2007-10-27 12:11:07.0 +0200 @@ -139,13 +139,13 @@ static void ntfs_end_buffer_async_read(s recs = PAGE_CACHE_SIZE / rec_size; /* Should have been verified before we got here... */ BUG_ON(!recs); - local_irq_save(flags); + local_irq_save_nort(flags); kaddr = kmap_atomic(page, KM_BIO_SRC_IRQ); for (i = 0; i recs; i++) post_read_mst_fixup((NTFS_RECORD*)(kaddr + i * rec_size), rec_size); kunmap_atomic(kaddr, KM_BIO_SRC_IRQ); - local_irq_restore(flags); + local_irq_restore_nort(flags); flush_dcache_page(page); if (likely(page_uptodate !PageError(page))) SetPageUptodate(page); Thanks, applied. -- Steve - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
