linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [patch] voluntary-preempt-2.6.8-rc2-O2
@ 2004-08-02 15:08 Shane Shrybman
  2004-08-03  9:19 ` Ingo Molnar
  2004-08-03 14:19 ` Ingo Molnar
  0 siblings, 2 replies; 27+ messages in thread
From: Shane Shrybman @ 2004-08-02 15:08 UTC (permalink / raw)
  To: mingo, linux-kernel

I was unable to boot -O2. It seemed to hang up when it got to the
aic7xxx(29160) scsi controller.

Boot messages copied by hand:

IRQ #16 thread started up.
delay 5 -10 secs
IRQ #19 thread started up.
delay 5 -10 secs
ahc_intr: HOST_MSG_LOOP bad phase 0x0
(repeats every 10-20 secs)
Waited a few minutes here before giving up and hitting reset.

Here is /proc/interrupts in 2.6.7-mm7
           CPU0       
  0:     740456    IO-APIC-edge  timer
  1:       1417    IO-APIC-edge  i8042
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:         14    IO-APIC-edge  ide0
 15:         14    IO-APIC-edge  ide1
 16:        178   IO-APIC-level  ide3, EMU10K1
 17:       2491   IO-APIC-level  eth0
 19:      10335   IO-APIC-level  aic7xxx, bttv0, Bt87x audio
 21:      29074   IO-APIC-level  uhci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
 22:          0   IO-APIC-level  VIA8233
NMI:          0 
LOC:     740415 
ERR:          0
MIS:          0

Also, had to turn of parport in the config to get it to compile.

drivers/parport/share.c:77: unknown field `generic_enable_irq' specified
in initializer
drivers/parport/share.c:78: unknown field `generic_disable_irq'
specified in initializer

Regards,

Shane


^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: [patch] voluntary-preempt-2.6.8-rc2-O2
@ 2004-08-04 18:46 David M
  0 siblings, 0 replies; 27+ messages in thread
From: David M @ 2004-08-04 18:46 UTC (permalink / raw)
  To: linux-kernel


Hello 

the xruns below happen pretty regular, however i dont think this is just 
related to the 02 patch, this happens with standard 2.6.7 kernel.  I assume 
it has something to do with drm and mga? 

Dave

XRUN: pcmC0D0p
 [<d48ef1f7>] snd_pcm_period_elapsed+0x2d7/0x430 [snd_pcm]
 [<c011046a>] scheduler_tick+0x20a/0x450
 [<d48a175a>] snd_ice1712_interrupt+0x1da/0x270 [snd_ice1712]
 [<c0118079>] generic_handle_IRQ_event+0x49/0x80
 [<c0105b0b>] do_IRQ+0x9b/0x140
 [<c0104234>] common_interrupt+0x18/0x20
 [<c010d734>] delay_tsc+0x14/0x20
 [<c01934c2>] __delay+0x12/0x20
 [<d4925218>] mga_do_dma_flush+0x48/0x1c0 [mga]
 [<d49262d9>] mga_dma_flush+0x109/0x130 [mga]
 [<d4921004>] mga_ioctl+0xe4/0x160 [mga]
 [<c015cce0>] sys_ioctl+0x100/0x270
 [<c01040c7>] syscall_call+0x7/0xb
XRUN: pcmC0D0p
 [<d48ef1f7>] snd_pcm_period_elapsed+0x2d7/0x430 [snd_pcm]
 [<c011c764>] update_process_times+0x44/0x50
 [<d48a175a>] snd_ice1712_interrupt+0x1da/0x270 [snd_ice1712]
 [<c011ca40>] do_timer+0xe0/0xf0
 [<c0118079>] generic_handle_IRQ_event+0x49/0x80
 [<c0105b0b>] do_IRQ+0x9b/0x140
 [<c0104234>] common_interrupt+0x18/0x20
 [<c010d734>] delay_tsc+0x14/0x20
 [<c01934c2>] __delay+0x12/0x20
 [<d4925218>] mga_do_dma_flush+0x48/0x1c0 [mga]
 [<d49262d9>] mga_dma_flush+0x109/0x130 [mga]
 [<d4921004>] mga_ioctl+0xe4/0x160 [mga]
 [<c015cce0>] sys_ioctl+0x100/0x270
 [<c01040c7>] syscall_call+0x7/0xb

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: preempt-timing-2.6.8-rc1
@ 2004-07-13 14:39 William Lee Irwin III
  2004-07-25  5:15 ` preempt-timing-2.6.8-rc1 Lee Revell
  0 siblings, 1 reply; 27+ messages in thread
From: William Lee Irwin III @ 2004-07-13 14:39 UTC (permalink / raw)
  To: Lenar L?hmus; +Cc: linux-kernel

On Tue, Jul 13, 2004 at 05:24:32PM +0300, Lenar L?hmus wrote:
> My first results with 2.6.8-rc1 + preempt-timing:
> Boot-time:
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at kmap_atomic+0x13/0x70 and ending at kunmap_atomic+0x5/0x20
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at buffered_rmqueue+0xea/0x190 and ending at 
> buffered_rmqueue+0x144/0x190
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at search_by_key+0xe3/0xf70 and ending at do_IRQ+0xec/0x130
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at copy_mm+0x2e6/0x3b0 and ending at copy_mm+0x331/0x3b0
> 11ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at ohci_hub_resume+0x3c/0x350 [ohci_hcd] and ending at 
> ohci_hub_resume+0x79/0x350 [ohci_hcd]
> 14ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at schedule+0x36/0x480 and ending at schedule+0x291/0x480
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at new_inode+0x1a/0x80 and ending at new_inode+0x58/0x80
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at kmap_atomic+0x13/0x70 and ending at kunmap_atomic+0x5/0x20
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at kmap_atomic+0x13/0x70 and ending at kunmap_atomic+0x5/0x20

Boot-time stuff is unlikely to have much done about it. I highly suspect
this is the kmap_atomic() trick for pagecache writes. 1ms is probably
more than your box can handle if so.


On Tue, Jul 13, 2004 at 05:24:32PM +0300, Lenar L?hmus wrote:
> Normal use (logging in, browsing, playing video with mplayer, moving 
> windows around, etc):
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at search_by_key+0xe3/0xf70 and ending at 
> smp_apic_timer_interrupt+0x9a/0xe0
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at do_munmap+0xd2/0x140 and ending at do_munmap+0xeb/0x140
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at kmap_atomic+0x13/0x70 and ending at kunmap_atomic+0x5/0x20
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at __d_lookup+0x66/0x170 and ending at __d_lookup+0x9c/0x170
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at kmap_atomic+0x13/0x70 and ending at kunmap_atomic+0x5/0x20
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at copy_mm+0x2e6/0x3b0 and ending at copy_mm+0x331/0x3b0
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at find_get_page+0x14/0x60 and ending at find_get_page+0x2f/0x60
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at dev_queue_xmit+0x7f/0x320 and ending at 
> dev_queue_xmit+0x27f/0x320
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at dev_queue_xmit+0x7f/0x320 and ending at 
> dev_queue_xmit+0x27f/0x320
> 49ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at snd_pcm_action_lock_irq+0x1b/0x1d0 [snd_pcm] and ending at 
> snd_pcm_action_lock_irq+0x65/0x1d0 [snd_pcm]
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at do_no_page+0xd5/0x310 and ending at do_no_page+0x178/0x310
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at fget+0x28/0x70 and ending at fget+0x41/0x70
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at sys_ioctl+0x42/0x270 and ending at do_IRQ+0xec/0x130
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at dnotify_parent+0x27/0xc0 and ending at dnotify_parent+0x85/0xc0
> 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at buffered_rmqueue+0xea/0x190 and ending at 
> buffered_rmqueue+0x144/0x190

If you're getting these in find_get_page() and buffered_rmqueue() either
your box is definitely too slow to handle 1ms or sched_clock()'s results
are questionable on your machine. cpufreq?

On Tue, Jul 13, 2004 at 05:24:32PM +0300, Lenar L?hmus wrote:
> What I've excluded (happens all the time):
> 1) 2ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at schedule+0x36/0x480 and ending at do_IRQ+0xec/0x130
> it's 2ms 98%. This really happens all the time. Bogus?

Wild guess is that you took an IRQ in dec_preempt_count() and that threw
your results off. Let me know if the patch below helps at all. My guess
is it'll cause more apparent problems than it solves.


On Tue, Jul 13, 2004 at 05:24:32PM +0300, Lenar L?hmus wrote:
> 2) 49ms non-preemptible critical section violated 1 ms preempt threshold 
> starting at sys_ioctl+0x42/0x270 and ending at sys_ioctl+0xbd/0x270
> 40-50 ms most of the time, 12 ms couple of times.
> Let me now if you need those traces for some of these (I've built kernel 
> with 8K stacks).

ioctl() is typically grossly inefficient and even involves the BKL.


-- wli

Index: timing-2.6.8-rc1/kernel/sched.c
===================================================================
--- timing-2.6.8-rc1.orig/kernel/sched.c
+++ timing-2.6.8-rc1/kernel/sched.c
@@ -4069,22 +4069,33 @@
 
 void touch_preempt_timing(void)
 {
+	unsigned long flags;
+
+	local_irq_save(flags);
 	if (preempt_count() > 0 && system_state == SYSTEM_RUNNING &&
 						__get_cpu_var(preempt_entry))
 		__touch_preempt_timing(__builtin_return_address(0));
+	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(touch_preempt_timing);
 
 void inc_preempt_count(void)
 {
+	unsigned long flags;
+
+	local_irq_save(flags);
 	preempt_count()++;
 	if (preempt_count() == 1 && system_state == SYSTEM_RUNNING)
 		__touch_preempt_timing(__builtin_return_address(0));
+	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(inc_preempt_count);
 
 void dec_preempt_count(void)
 {
+	unsigned long flags;
+
+	local_irq_save(flags);
 	if (preempt_count() == 1 && system_state == SYSTEM_RUNNING &&
 					__get_cpu_var(preempt_entry)) {
 		u64 hold;
@@ -4108,6 +4119,7 @@
 		__get_cpu_var(preempt_entry) = 0;
 	}
 	preempt_count()--;
+	local_irq_restore(flags);
 }
 EXPORT_SYMBOL(dec_preempt_count);
 #endif

^ permalink raw reply	[flat|nested] 27+ messages in thread
end of thread, other threads:[~2004-08-06 18:44 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-02 15:08 [patch] voluntary-preempt-2.6.8-rc2-O2 Shane Shrybman
2004-08-03  9:19 ` Ingo Molnar
2004-08-03 14:05   ` Shane Shrybman
2004-08-03 14:09     ` Ingo Molnar
2004-08-03 14:45       ` Shane Shrybman
2004-08-03 16:29         ` Ingo Molnar
2004-08-03 17:43           ` Shane Shrybman
2004-08-03 14:19 ` Ingo Molnar
2004-08-04 11:22   ` Rudo Thomas
2004-08-04 11:54     ` Ingo Molnar
2004-08-04 16:05       ` Rudo Thomas
2004-08-04 14:32     ` Peter Zijlstra
2004-08-04 14:34     ` [patch] voluntary-preempt-2.6.8-rc2-mm2-O3 Peter Zijlstra
2004-08-06 18:08   ` [patch] voluntary-preempt-2.6.8-rc2-O2 Thomas Charbonnel
2004-08-06 18:44     ` Paulo Marques
  -- strict thread matches above, loose matches on Subject: below --
2004-08-04 18:46 David M
2004-07-13 14:39 preempt-timing-2.6.8-rc1 William Lee Irwin III
2004-07-25  5:15 ` preempt-timing-2.6.8-rc1 Lee Revell
2004-07-25 22:49   ` preempt-timing-2.6.8-rc1 Lee Revell
2004-07-26  8:23     ` preempt-timing-2.6.8-rc1 Ingo Molnar
2004-07-26  8:29       ` preempt-timing-2.6.8-rc1 Lee Revell
2004-07-26  8:35         ` [patch] voluntary-preempt-2.6.8-rc2-J3 Ingo Molnar
2004-07-26  9:00           ` Lee Revell
2004-07-26 12:40             ` Ingo Molnar
2004-07-26 20:47               ` [patch] voluntary-preempt-2.6.8-rc2-J7 Ingo Molnar
2004-07-29 22:26                 ` [patch] voluntary-preempt-2.6.8-rc2-M5 Ingo Molnar
2004-08-01 19:30                   ` [patch] voluntary-preempt-2.6.8-rc2-O2 Ingo Molnar
2004-08-01 22:40                     ` Felipe Alfaro Solana
2004-08-01 23:20                     ` Daniel Schmitt
2004-08-02  6:21                       ` Felipe Alfaro Solana
2004-08-01 23:44                     ` Matt Heler
2004-08-02  6:26                       ` Felipe Alfaro Solana
2004-08-02  7:47                         ` Ingo Molnar
2004-08-02  1:45                     ` Lee Revell
2004-08-02  2:14                       ` Lee Revell
2004-08-02  7:56                         ` Ingo Molnar
2004-08-02 13:42                     ` Lenar Lõhmus

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).