[patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

i've released the -S1 VP patch:

  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1

NOTE: this patch is against Andrew's -mm tree and the VP patchset will
stay based on -mm until the merging process has been finished.

to get a 2.6.9-rc2-mm1-VP-S1 kernel, the patching order is:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
 + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc2.bz2
 + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm1/2.6.9-rc2-mm1.bz2
 + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1

Changes relative to -S0:

- lots of merging. A good chunk of the VP patch latency breakers and
  support patches are in -mm already.

- integrated my 'preemptible big kernel lock' patch into VP. This makes 
  all BKL code preemptible while keeping correctness. A new debugging 
  infrastructure has been added to catch code that might use the BKL
  in an unsafe way. If the debugging check triggers it will print 
  messages like:

    using smp_processor_id() in preemptible code: bash/1020

  please report such messages and backtraces to me. Most of the messages 
  i've fixed so far were false positives, but one bug has been caught 
  already via this.

  Also, this BKL patch allowed the removal of two questionable 
  latency breakers: the tty.c and the DRM BKL relaxation hack.

- fixed an SMP hardirq redirection bug - IRQ threads could be bound to 
  multiple CPUs resulting in potentially illegal preemption of hardirq
  contexts.

- temporarily dropped the ppc/ppc64 GENERIC_HARDIRQS changes, they broke
  and i cannot test them.

Reports, comments welcome,

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Felipe Alfaro Solana]

On Sep 19, 2004, at 14:26, Ingo Molnar wrote:
>
> i've released the -S1 VP patch:
...
> Reports, comments welcome,

I've been running 2.6.9-rc2-mm1-VP-S1 for some time now and it seems to 
be performing well.

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Karsten Wiese]

Hi Ingo,

things improved here after having applied 
swapspace-layout-improvements-2.6.9-rc1-bk12-A1.
I'm happily running jackd and clients realtime now without any dropouts even 
under heavy swapping pressure.
(Machine is a PIII@600MHz with 256MB RAM)
Could you please include the swapspace-layout-improvements in the 
voluntary-preempt patches?

Just 1 small correction:
>>>>
--- kernel/time.c~      2004-09-19 15:09:38.000000000 +0200
+++ kernel/time.c       2004-09-19 17:02:35.000000000 +0200
@@ -96,8 +96,10 @@
 asmlinkage long sys_gettimeofday(struct timeval __user *tv, struct timezone 
__user *tz)
 {
 #ifdef CONFIG_LATENCY_TRACE
-       if (!tv && ((long)tz == 1))
+       if (!tv && ((long)tz == 1)) {
                user_trace_start();
+               tz = NULL;
+       }
        if (!tv && !tz)
                user_trace_stop();
 #endif
<<<<

thanks for your splendid patches,
Karsten

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> Just 1 small correction:
> >>>>
> --- kernel/time.c~      2004-09-19 15:09:38.000000000 +0200
> +++ kernel/time.c       2004-09-19 17:02:35.000000000 +0200
> @@ -96,8 +96,10 @@
>  asmlinkage long sys_gettimeofday(struct timeval __user *tv, struct timezone 
> __user *tz)
>  {
>  #ifdef CONFIG_LATENCY_TRACE
> -       if (!tv && ((long)tz == 1))
> +       if (!tv && ((long)tz == 1)) {
>                 user_trace_start();
> +               tz = NULL;
> +       }
>         if (!tv && !tz)
>                 user_trace_stop();

The point is to let gettimeofday(0,1) start tracing and
gettimeofday(0,0) stop tracing - a system-call-controlled tracing
facility (if trace_enabled=2). This was used to trace weird latencies
before, but it's not the normal mode of operation.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Karsten Wiese]

Am Sonntag 19 September 2004 22:48 schrieb Ingo Molnar:
>
> The point is to let gettimeofday(0,1) start tracing and
> gettimeofday(0,0) stop tracing - a system-call-controlled tracing
> facility (if trace_enabled=2). This was used to trace weird latencies
> before, but it's not the normal mode of operation.
>
Ok. The other point is a page_fault being generated later on in 
sys_gettimeofday() if tz is not reset:
>>>>
	if (unlikely(tz != NULL)) {
                     ^^
		if (copy_to_user(tz, &sys_tz, sizeof(sys_tz)))
			return -EFAULT;
	}
<<<<

What do you think about including the swapspace-layout-improvements in the 
voluntary-preempt patches?

best regards,
Karsten

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> Hi Ingo,
> 
> things improved here after having applied
> swapspace-layout-improvements-2.6.9-rc1-bk12-A1. I'm happily running
> jackd and clients realtime now without any dropouts even under heavy
> swapping pressure. (Machine is a PIII@600MHz with 256MB RAM) Could you
> please include the swapspace-layout-improvements in the
> voluntary-preempt patches?

only if Andrew agrees that the patch has a chance for -mm inclusion and
possible upstream merging.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> Am Sonntag 19 September 2004 22:48 schrieb Ingo Molnar:
> >
> > The point is to let gettimeofday(0,1) start tracing and
> > gettimeofday(0,0) stop tracing - a system-call-controlled tracing
> > facility (if trace_enabled=2). This was used to trace weird latencies
> > before, but it's not the normal mode of operation.
> >
> Ok. The other point is a page_fault being generated later on in 
> sys_gettimeofday() if tz is not reset:
> >>>>
> 	if (unlikely(tz != NULL)) {
>                      ^^
> 		if (copy_to_user(tz, &sys_tz, sizeof(sys_tz)))
> 			return -EFAULT;
> 	}
> <<<<

yeah - it's a bit ugly. The right thing is to return from that branch.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
>  > Could you
>  > please include the swapspace-layout-improvements in the
>  > voluntary-preempt patches?
> 
>  only if Andrew agrees that the patch has a chance for -mm inclusion and
>  possible upstream merging.

It needs more work - from the (brief) testing I did, it didn't seem to
improve that which it was intended to improve: swap I/O performance.  Not
sure why, really.

The latency improvements were serendipitous.

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[K.R. Foley]

Ingo Molnar wrote:
> i've released the -S1 VP patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1
> 
> NOTE: this patch is against Andrew's -mm tree and the VP patchset will
> stay based on -mm until the merging process has been finished.
> 
> to get a 2.6.9-rc2-mm1-VP-S1 kernel, the patching order is:
> 
>    http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.8.tar.bz2
>  + http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.9-rc2.bz2
>  + http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm1/2.6.9-rc2-mm1.bz2
>  + http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1
> 
> Changes relative to -S0:
> 
> - lots of merging. A good chunk of the VP patch latency breakers and
>   support patches are in -mm already.
> 
> - integrated my 'preemptible big kernel lock' patch into VP. This makes 
>   all BKL code preemptible while keeping correctness. A new debugging 
>   infrastructure has been added to catch code that might use the BKL
>   in an unsafe way. If the debugging check triggers it will print 
>   messages like:
> 
>     using smp_processor_id() in preemptible code: bash/1020
> 
>   please report such messages and backtraces to me. Most of the messages 
>   i've fixed so far were false positives, but one bug has been caught 
>   already via this.
> 
>   Also, this BKL patch allowed the removal of two questionable 
>   latency breakers: the tty.c and the DRM BKL relaxation hack.
> 
> - fixed an SMP hardirq redirection bug - IRQ threads could be bound to 
>   multiple CPUs resulting in potentially illegal preemption of hardirq
>   contexts.
> 
> - temporarily dropped the ppc/ppc64 GENERIC_HARDIRQS changes, they broke
>   and i cannot test them.
> 
> Reports, comments welcome,
> 
> 	Ingo
> -

Is anyone else having trouble getting this to build on x86 smp? I am 
getting undefined references to smp_processor_id within most, if not 
all, modules.

kr

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Magnus Määttä]

Hello Ingo,

On Sunday 19 September 2004 14.26, Ingo Molnar wrote:
> i've released the -S1 VP patch:
>
>  
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-
>S1
>
> NOTE: this patch is against Andrew's -mm tree and the VP patchset will
> stay based on -mm until the merging process has been finished.
>

I got this trace on my laptop (first time I'm testing VP):

preemption latency trace v1.0.7 on 2.6.9-rc2-mm1-VP-S1
-------------------------------------------------------
 latency: 1658 us, entries: 150 (150)   |   [VP:1 KP:1 SP:1 HP:1 #CPUS:1]
    -----------------
    | task: powersaved/3542, uid:0 nice:10 policy:0 rt_prio:0
    -----------------
 => started at: acpi_ec_write+0x62/0x1c9
 => ended at:   acpi_ec_write+0x19a/0x1c9
=======>
00000001 0.000ms (+0.000ms): acpi_ec_write (acpi_ec_space_handler)
00000001 0.000ms (+0.000ms): acpi_hw_low_level_write (acpi_ec_write)
00000001 0.000ms (+0.001ms): acpi_os_write_port (acpi_hw_low_level_write)
00000001 0.001ms (+0.000ms): acpi_ec_wait (acpi_ec_write)
00000001 0.002ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 0.002ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
00000001 0.003ms (+0.000ms): __const_udelay (acpi_ec_wait)
00000001 0.004ms (+0.000ms): __delay (acpi_ec_wait)
00000001 0.004ms (+0.099ms): delay_pmtmr (__delay)
00000001 0.103ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 0.103ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
...
00000001 1.320ms (+0.000ms): __const_udelay (acpi_ec_wait)
00000001 1.320ms (+0.000ms): __delay (acpi_ec_wait)
00000001 1.321ms (+0.099ms): delay_pmtmr (__delay)
00000001 1.420ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 1.420ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
00000001 1.422ms (+0.000ms): acpi_hw_low_level_write (acpi_ec_write)
00000001 1.422ms (+0.001ms): acpi_os_write_port (acpi_hw_low_level_write)
00000001 1.423ms (+0.000ms): acpi_ec_wait (acpi_ec_write)
00000001 1.423ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 1.424ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
00000001 1.425ms (+0.000ms): __const_udelay (acpi_ec_wait)
00000001 1.425ms (+0.000ms): __delay (acpi_ec_wait)
00000001 1.425ms (+0.099ms): delay_pmtmr (__delay)
00000001 1.525ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 1.525ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
00000001 1.526ms (+0.000ms): acpi_hw_low_level_write (acpi_ec_write)
00000001 1.527ms (+0.001ms): acpi_os_write_port (acpi_hw_low_level_write)
00000001 1.528ms (+0.000ms): acpi_ec_wait (acpi_ec_write)
00000001 1.528ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 1.529ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
00000001 1.530ms (+0.000ms): __const_udelay (acpi_ec_wait)
00000001 1.530ms (+0.000ms): __delay (acpi_ec_wait)
00000001 1.530ms (+0.099ms): delay_pmtmr (__delay)
00000001 1.630ms (+0.000ms): acpi_hw_low_level_read (acpi_ec_wait)
00000001 1.630ms (+0.001ms): acpi_os_read_port (acpi_hw_low_level_read)
00000001 1.632ms (+0.000ms): smp_apic_timer_interrupt (acpi_ec_write)
00010001 1.632ms (+0.000ms): profile_tick (smp_apic_timer_interrupt)
00010001 1.632ms (+0.000ms): profile_hook (profile_tick)
00010002 1.632ms (+0.000ms): notifier_call_chain (profile_hook)
00010001 1.633ms (+0.001ms): profile_hit (smp_apic_timer_interrupt)
00010001 1.634ms (+0.000ms): do_IRQ (acpi_ec_write)
00010001 1.634ms (+0.000ms): do_IRQ (<00000000>)
00010002 1.635ms (+0.002ms): mask_and_ack_8259A (do_IRQ)
00010002 1.637ms (+0.000ms): redirect_hardirq (do_IRQ)
00010001 1.638ms (+0.000ms): handle_IRQ_event (do_IRQ)
00010001 1.638ms (+0.000ms): timer_interrupt (handle_IRQ_event)
00010002 1.638ms (+0.002ms): mark_offset_pmtmr (timer_interrupt)
00010002 1.641ms (+0.000ms): do_timer (timer_interrupt)
00010002 1.641ms (+0.000ms): update_process_times (do_timer)
00010002 1.641ms (+0.000ms): update_one_process (update_process_times)
00010002 1.642ms (+0.000ms): run_local_timers (update_process_times)
00010002 1.642ms (+0.000ms): raise_softirq (update_process_times)
00010002 1.642ms (+0.000ms): scheduler_tick (update_process_times)
00010002 1.643ms (+0.000ms): task_timeslice (scheduler_tick)
00010002 1.643ms (+0.000ms): update_wall_time (do_timer)
00010002 1.643ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
00010002 1.644ms (+0.000ms): note_interrupt (do_IRQ)
00010002 1.644ms (+0.000ms): end_8259A_irq (do_IRQ)
00010002 1.644ms (+0.001ms): enable_8259A_irq (do_IRQ)
00000002 1.645ms (+0.000ms): do_softirq (do_IRQ)
00000002 1.646ms (+0.000ms): __do_softirq (do_softirq)
00000002 1.646ms (+0.000ms): wake_up_process (do_softirq)
00000002 1.646ms (+0.000ms): try_to_wake_up (wake_up_process)
00000002 1.646ms (+0.000ms): task_rq_lock (try_to_wake_up)
00000003 1.647ms (+0.000ms): activate_task (try_to_wake_up)
00000003 1.647ms (+0.000ms): sched_clock (activate_task)
00000003 1.647ms (+0.000ms): task_priority (activate_task)
00000003 1.648ms (+0.000ms): task_sleep_avg (task_priority)
00000003 1.648ms (+0.000ms): enqueue_task (activate_task)
00000002 1.648ms (+0.001ms): preempt_schedule (try_to_wake_up)
00010001 1.650ms (+0.000ms): do_IRQ (acpi_ec_write)
00010001 1.650ms (+0.000ms): do_IRQ (<00000009>)
00010002 1.650ms (+0.003ms): mask_and_ack_8259A (do_IRQ)
00010002 1.654ms (+0.000ms): preempt_schedule (do_IRQ)
00010002 1.654ms (+0.000ms): redirect_hardirq (do_IRQ)
00010002 1.654ms (+0.000ms): wake_up_process (redirect_hardirq)
00010002 1.654ms (+0.000ms): try_to_wake_up (wake_up_process)
00010002 1.655ms (+0.000ms): task_rq_lock (try_to_wake_up)
00010003 1.655ms (+0.000ms): activate_task (try_to_wake_up)
00010003 1.655ms (+0.000ms): sched_clock (activate_task)
00010003 1.655ms (+0.000ms): task_priority (activate_task)
00010003 1.656ms (+0.000ms): task_sleep_avg (task_priority)
00010003 1.656ms (+0.000ms): enqueue_task (activate_task)
00010002 1.656ms (+0.000ms): preempt_schedule (try_to_wake_up)
00010001 1.657ms (+0.000ms): preempt_schedule (do_IRQ)
00000002 1.657ms (+0.000ms): do_softirq (do_IRQ)
00000002 1.657ms (+0.000ms): __do_softirq (do_softirq)
00000001 1.658ms (+0.000ms): sub_preempt_count (acpi_ec_write)
00000001 1.658ms (+0.000ms): update_max_trace (check_preempt_timing)


I don't know if anything can be done about it, but I get lots of them.
The computer is a Intel P-M 1.5GHz with 512MB RAM.


/Magnus Määttä

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

* K.R. Foley <kr@cybsft.com> wrote:

> Is anyone else having trouble getting this to build on x86 smp? I am
> getting undefined references to smp_processor_id within most, if not
> all, modules.

add EXPORT_SYMBOL(smp_processor_id) to the end of sched.c.

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Shane Shrybman]

I am having what appears to be IDE DMA problems with 2.6.9-rc2-mm1-S1.
2.6.9-rc2-mm1 does not show this problem and runs fine. Before this I
was happily using 2.6.8-rc3-O5.

I tried booting with acpi=off but was unable to enter my user name at
the login prompt, it just hung with no response to sysreq. I also tried
turning off irq threading for that irq but it made no difference.

There is one drive on the secondary channel of this Promise TX133. This
is what appears in the log after a minute or two of using the drive.

hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
hdg: DMA interrupt recovery
hdg: lost interrupt
hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
hdg: DMA interrupt recovery
hdg: lost interrupt
hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
[..many repeats..]

It sometimes recovers but it immediately happens again. This leaves apps
touching that drive stuck in an un-killable D state and eventually I
have to reboot.

Linux video capture interface: v1.00
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
PDC20269: IDE controller at PCI slot 0000:00:0d.0
ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 16
PDC20269: chipset revision 2
PDC20269: 100% native mode on irq 16
    ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio
hdg: MAXTOR 6L080J4, ATA DISK drive
requesting new irq thread for IRQ16...
ide3 at 0xa800-0xa807,0xa402 on irq 16
VP_IDE: IDE controller at PCI slot 0000:00:0f.1
ACPI: PCI interrupt 0000:00:0f.1[A] -> GSI 20 (level, low) -> IRQ 20
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
    ide0: BM-DMA at 0x7400-0x7407, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x7408-0x740f, BIOS settings: hdc:DMA, hdd:pio
hdc: HL-DT-ST DVDRAM GSA-4082B, ATAPI CD/DVD-ROM drive
requesting new irq thread for IRQ15...
ide1 at 0x170-0x177,0x376 on irq 15
hdg: max request size: 128KiB
IRQ#16 thread started up.
hdg: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=65535/16/63,
UDMA(133)
hdg: hdg1
IRQ#15 thread started up.
hdc: ATAPI 63X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 19 (level, low) -> IRQ 19

Regards,

Shane

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Svetoslav Slavtchev]

sorry for the scrambled reply,
i'm not subscribed
(please add me to the CC list)

in reply to:
-----------------------
List:       linux-kernel
Subject:    Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1
From:       Shane Shrybman <shrybman () aei ! ca>
Date:       2004-09-20 21:16:07
Message-ID: <1095714967.3646.14.camel () mars>
[Download message RAW]

I am having what appears to be IDE DMA problems with 2.6.9-rc2-mm1-S1.
2.6.9-rc2-mm1 does not show this problem and runs fine. Before this I
was happily using 2.6.8-rc3-O5.

I tried booting with acpi=off but was unable to enter my user name at
the login prompt, it just hung with no response to sysreq. I also tried
turning off irq threading for that irq but it made no difference.

There is one drive on the secondary channel of this Promise TX133. This
is what appears in the log after a minute or two of using the drive.

hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
hdg: DMA interrupt recovery
hdg: lost interrupt
hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
hdg: DMA interrupt recovery
hdg: lost interrupt
hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
[..many repeats..]

......
---------------------------------------

i'm getting the same problem
(although not sure if the dma status was the same)
if i enable hardirq preemption
turning acpi on/off doesn't change anything
io/up apic is on (haven't tried disabling it)

with hardirq preemption disabled in .config
everything looks fine sofar (~5h )


-----------------------------
  666 root      16 -10     0    0    0 S  0.0  0.0   0:00.00 IRQ 17
  670 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 IRQ 14
  673 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 IRQ 15
  711 root      25   0     0    0    0 S  0.0  0.0   0:00.23 khubd
  712 root      16 -10     0    0    0 S  0.0  0.0   0:00.00 IRQ 21

----------------------------
this puzzles me a bit
aren't those hardirqs ?
why are they listed as threads, in case i compiled
with 
----------------
[svetljo@svetljo rc2mm1]$ grep PREEMPT .config
# CONFIG_PREEMPT_TIMING is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_VOLUNTARY=y
CONFIG_PREEMPT_SOFTIRQS=y
# CONFIG_PREEMPT_HARDIRQS is not set
----------------

best,

svetljo
PS.

PC is up amd xp 2700 KT400 VT8235 (Epox 8k9A3+)
[svetljo@svetljo rc2mm1]$ cat /proc/interrupts
           CPU0
  0:   20809263    IO-APIC-edge  timer
  2:          0          XT-PIC  cascade
 14:        516    IO-APIC-edge  ide4
 15:        478    IO-APIC-edge  ide5
 16:    1763130   IO-APIC-level  radeon@pci:0000:01:00.0
 17:     894337   IO-APIC-level  ide0, ide2, ide3, eth0
 18:      59771   IO-APIC-level  EMU10K1
 21:    1120812   IO-APIC-level  uhci_hcd, uhci_hcd, uhci_hcd, ehci_hcd
 23:    2395783   IO-APIC-level  eth1
NMI:          0
LOC:   20810017
ERR:          0
MIS:        485

-- 
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[K.R. Foley]

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Is anyone else having trouble getting this to build on x86 smp? I am
>>getting undefined references to smp_processor_id within most, if not
>>all, modules.
> 
> 
> add EXPORT_SYMBOL(smp_processor_id) to the end of sched.c.
> 
> 	Ingo
> 

Thanks. That did the trick along with the afs patch Andrew posted.

kr

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]


* Shane Shrybman <shrybman@aei.ca> wrote:

> I am having what appears to be IDE DMA problems with 2.6.9-rc2-mm1-S1.
> 2.6.9-rc2-mm1 does not show this problem and runs fine. Before this I
> was happily using 2.6.8-rc3-O5.
> 
> I tried booting with acpi=off but was unable to enter my user name at
> the login prompt, it just hung with no response to sysreq. I also
> tried turning off irq threading for that irq but it made no
> difference.

does undoing (patch -R) the attached patch fix this IDE problem?

	Ingo

[-- Attachment #2: 1 --]
[-- Type: text/plain, Size: 745 bytes --]

--- linux/drivers/ide/ide-io.c.orig	
+++ linux/drivers/ide/ide-io.c	
@@ -114,6 +114,9 @@ static int __ide_end_request(ide_drive_t
 	int ret = 1;
 
 	BUG_ON(!(rq->flags & REQ_STARTED));
+	spin_unlock(&ide_lock);
+	if (drive->unmask)
+		local_irq_enable();
 
 	/*
 	 * if failfast is set on a request, override number of sectors and
@@ -135,6 +138,7 @@ static int __ide_end_request(ide_drive_t
 	}
 
 	if (!end_that_request_first(rq, uptodate, nr_sectors)) {
+		spin_lock_irq(&ide_lock);
 		add_disk_randomness(rq->rq_disk);
 
 		if (blk_rq_tagged(rq))
@@ -144,7 +148,8 @@ static int __ide_end_request(ide_drive_t
 		HWGROUP(drive)->rq = NULL;
 		end_that_request_last(rq);
 		ret = 0;
-	}
+	} else
+		spin_lock_irq(&ide_lock);
 	return ret;
 }
 

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Shane Shrybman]

On Tue, 2004-09-21 at 03:32, Ingo Molnar wrote:
> * Shane Shrybman <shrybman@aei.ca> wrote:
> 
> > I am having what appears to be IDE DMA problems with 2.6.9-rc2-mm1-S1.
> > 2.6.9-rc2-mm1 does not show this problem and runs fine. Before this I
> > was happily using 2.6.8-rc3-O5.
> > 
> > I tried booting with acpi=off but was unable to enter my user name at
> > the login prompt, it just hung with no response to sysreq. I also
> > tried turning off irq threading for that irq but it made no
> > difference.
> 
> does undoing (patch -R) the attached patch fix this IDE problem?
> 

Yes, backing out that patch seems to have fixed that problem. Thanks.

> 	Ingo

Regards,

Shane

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Shane Shrybman]

On Tue, 2004-09-21 at 03:32, Ingo Molnar wrote:
> * Shane Shrybman <shrybman@aei.ca> wrote:
> 
> > I am having what appears to be IDE DMA problems with 2.6.9-rc2-mm1-S1.
> > 2.6.9-rc2-mm1 does not show this problem and runs fine. Before this I
> > was happily using 2.6.8-rc3-O5.
> > 
> > I tried booting with acpi=off but was unable to enter my user name at
> > the login prompt, it just hung with no response to sysreq. I also
> > tried turning off irq threading for that irq but it made no
> > difference.
> 
> does undoing (patch -R) the attached patch fix this IDE problem?
> 

Oh, I spoke too soon. A few minutes after I sent the last email the
problem re-appeared.

IRQ#22 thread started up.
hdg: dma_timer_expiry: dma status == 0x24
ALSA sound/core/pcm_native.c:1330: playback drain error (DMA or IRQ
trouble?)
PDC202XX: Secondary channel reset.
hdg: DMA interrupt recovery
hdg: lost interrupt
hdg: dma_timer_expiry: dma status == 0x24
PDC202XX: Secondary channel reset.
hdg: DMA interrupt recovery
hdg: lost interrupt

> 	Ingo

Regards,

Shane

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[K.R. Foley]

Ingo Molnar wrote:
> i've released the -S1 VP patch:
> 
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1
> 

Two separate oopses this morning running that above patch. One appears 
to happen in locks_delete_lock. The log output follows. Unfortunately I 
am not sure what is relevant to the oops and whats not so I am sending 
it all. Also the trace that was generated when this happened can be 
found here:

http://www.cybsft.com/testresults/2.6.9-rc2-mm1-VP-S0/lat_trace22.txt

log output:

http://www.cybsft.com/testresults/2.6.9-rc2-mm1-VP-S0/dump1.txt

The other appears to happen in __posix_lock_file.

Trace here:

http://www.cybsft.com/testresults/2.6.9-rc2-mm1-VP-S0/lat_trace23.txt

log output here:

http://www.cybsft.com/testresults/2.6.9-rc2-mm1-VP-S0/dump2.txt

If there is anything else that I can provide on these, or if there is a 
better way to post this, please let me know.

kr

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[Ingo Molnar]

* K.R. Foley <kr@cybsft.com> wrote:

> Ingo Molnar wrote:
> >i've released the -S1 VP patch:
> >
> >  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1
> >
> 
> Two separate oopses this morning running that above patch. One appears
> to happen in locks_delete_lock. [...]

i too got this one today. Seems to be related to the BKL changes -
locks.c is a heavy user of the BKL. You have an SMP system, right? Does
the oops happen if you boot with maxcpus=1?

	Ingo

Re: [patch] voluntary-preempt-2.6.9-rc2-mm1-S1

[K.R. Foley]

Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>Ingo Molnar wrote:
>>
>>>i've released the -S1 VP patch:
>>>
>>> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc2-mm1-S1
>>>
>>
>>Two separate oopses this morning running that above patch. One appears
>>to happen in locks_delete_lock. [...]
> 
> 
> i too got this one today. Seems to be related to the BKL changes -
> locks.c is a heavy user of the BKL. You have an SMP system, right? Does
> the oops happen if you boot with maxcpus=1?
> 
> 	Ingo
> 
This was on my SMP system. I can try the maxcpus=1. However, the trouble 
may be reproducing the oops. This happened at ~5:35 this morning (~9 
hrs. ago). Hadn't happened again as of an hour ago when I booted S2. I 
will give it a try though.

kr