[patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Ingo Molnar]

i have released the -53-01 Real-Time Preemption patch, which can be 
downloaded from:

  http://redhat.com/~mingo/realtime-preempt/

there are two new features in this release, which justified the jump 
from .52 to .53:

 - the inclusion of the High Resolution Timers patch, written by
   George Anzinger, and ported/improved/cleaned-up by Thomas Gleixner.

 - the inclusion of the RCU tasklist_lock patch from Paul McKenney.

the HRT patch from George Anzinger is a crutial piece of real-time 
infrastructure. The version included in the -RT tree supports both PIT 
and local APIC timer driven variable-rate timer interrupts.

Thomas Glexiner, besides porting it to PREEMPT_RT, cleaning it up, 
adding the local APIC timer support has also added the 
CONFIG_HIGH_RES_TIMERS_DYN_PRIO feature, which pushes priority 
inheritance into the high-res timer space. Furthermore, Thomas has 
extended nanosleep to use HR timers, if the task is RT. This makes it 
easier to test HRT functionality.

NOTE: there's a new softirq, softirq-hrtimer (PID 8 on UP x86), which 
should be chrt-ed to higher than SCHED_FIFO-50 if HR timer interrupts 
are the most important latencies in the system. E.g.:

  chrt -f 90 -p 8

the RCU tasklist-lock patch is a small but important feature from Paul 
McKenney which enables good HRT latencies: the HRT patch, when using 
POSIX timers, would use a signal-sending codepath that depends on the 
tasklist_lock, and thus the (quite high) tasklist_lock latencies 
controlled the latency of HR timers - defeating much of the benefits of 
HR timers. With the RCU tasklist-lock the signal sending path is now 
RCU-read locked, with no locking dependency, and thus excellent 
worst-case latencies.

given these changes, some (mostly build-related) regressions are to be 
expected. Only the x86 architecture is expected to work for now.

to build a -V0.7.53-01 tree, the following patches should to be applied:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc4.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.13-rc4-RT-V0.7.53-01

patches, bugreports and any other feedback welcome,

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Lee Revell]

On Thu, 2005-08-11 at 13:00 +0200, Ingo Molnar wrote:
> i have released the -53-01 Real-Time Preemption patch, which can be 
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> there are two new features in this release, which justified the jump 
> from .52 to .53:
> 
>  - the inclusion of the High Resolution Timers patch, written by
>    George Anzinger, and ported/improved/cleaned-up by Thomas Gleixner.
> 

George,

Very nice to see this going in (via) the RT patch.

Can we get a real help text here:

Clock & Timer Selection
> 1. Legacy Timer Support (LEGACY_TIMER) (NEW)
  2. HPET Timer Support (HPET_TIMER)
  3. High Resolution Timer Support (HIGH_RES_TIMERS) (NEW)
choice[1-3?]: ?

You may have either HPET, High Resolution, or Legacy timer support.

This would be a great place to put some of your extensive docs about the
various timer sources and issues on x86.  I have always thought the HRT
docs were the best source on the net for this info, and I refer people
to it whenever someone has a question about timers on the linux audio
lists.

The docs for "High Resolution Timer clock source" are great.

Can we get more docs here:

HRT Softirg dynamic priority adjustment (HIGH_RES_TIMERS_DYN_PRIO) 
        ^^^ typo
[N/y/?] (NEW) ?

This option enables the dynamic priority adjustment of the
high resolution timer soft interrupt

No point documenting this one if it's expected to go away though.

Lee

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Lee Revell]

On Thu, 2005-08-11 at 23:07 -0400, Lee Revell wrote:
> Very nice to see this going in (via) the RT patch.
> 

Also, does not compile for me with ACPI PM timer selected:

  CC      arch/i386/kernel/timers/hrtimer_pm.o
In file included from include/asm/hrtime.h:220,
                 from include/linux/hrtime.h:58,
                 from arch/i386/kernel/timers/hrtimer_pm.c:11:
include/asm/hrtime-Macpi.h: In function 'stake_cpuctr':
include/asm/hrtime-Macpi.h:110: warning: no return statement in function
returning non-void
arch/i386/kernel/timers/hrtimer_pm.c: In function 'high_res_init_pm':
arch/i386/kernel/timers/hrtimer_pm.c:141: warning: format '%lu' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'
arch/i386/kernel/timers/hrtimer_pm.c:141: warning: format '%03lu'
expects type 'long unsigned int', but argument 3 has type 'unsigned int'
arch/i386/kernel/timers/hrtimer_pm.c:182: error: invalid lvalue in
assignment
make[2]: *** [arch/i386/kernel/timers/hrtimer_pm.o] Error 1
make[1]: *** [arch/i386/kernel/timers] Error 2
make: *** [arch/i386/kernel] Error 2

Lee

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2005-08-11 at 23:07 -0400, Lee Revell wrote:
> > Very nice to see this going in (via) the RT patch.
> > 
> 
> Also, does not compile for me with ACPI PM timer selected:

i fixed the build errors, but HIGH_RES_TIMER_ACPI_PM does not boot - so 
i've disabled it in the -53-03 patch for the time being.

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2005-08-11 at 13:00 +0200, Ingo Molnar wrote:
> > i have released the -53-01 Real-Time Preemption patch, which can be 
> > downloaded from:
> > 
> >   http://redhat.com/~mingo/realtime-preempt/
> > 
> > there are two new features in this release, which justified the jump 
> > from .52 to .53:
> > 
> >  - the inclusion of the High Resolution Timers patch, written by
> >    George Anzinger, and ported/improved/cleaned-up by Thomas Gleixner.
> > 
> 
> George,
> 
> Very nice to see this going in (via) the RT patch.
> 
> Can we get a real help text here:
> 
> Clock & Timer Selection
> > 1. Legacy Timer Support (LEGACY_TIMER) (NEW)
>   2. HPET Timer Support (HPET_TIMER)
>   3. High Resolution Timer Support (HIGH_RES_TIMERS) (NEW)
> choice[1-3?]: ?
> 
> You may have either HPET, High Resolution, or Legacy timer support.
> 
> This would be a great place to put some of your extensive docs about the
> various timer sources and issues on x86.  I have always thought the HRT
> docs were the best source on the net for this info, and I refer people
> to it whenever someone has a question about timers on the linux audio
> lists.
> 
> The docs for "High Resolution Timer clock source" are great.
> 
> Can we get more docs here:
> 
> HRT Softirg dynamic priority adjustment (HIGH_RES_TIMERS_DYN_PRIO) 
>         ^^^ typo
> [N/y/?] (NEW) ?
> 
> This option enables the dynamic priority adjustment of the
> high resolution timer soft interrupt
> 
> No point documenting this one if it's expected to go away though.

this feature is from Thomas - and most of the PREEMPT_RT integration 
work too (and hence all the bugs are purely his fault too! ;-).

In the -53-03 patch i've made HIGH_RES_TIMERS_DYN_PRIO always-on for 
PREEMPT_RT, but for other preemption models it's still selectable 
individually, so some more docs would indeed be useful.

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Thomas Gleixner]

On Thu, 2005-08-11 at 23:19 -0400, Lee Revell wrote:
> On Thu, 2005-08-11 at 23:07 -0400, Lee Revell wrote:
> > Very nice to see this going in (via) the RT patch.
> > 
> 
> Also, does not compile for me with ACPI PM timer selected:

I did not come around yet to adapt the PM timer to the overall changes I
made.

tglx

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Ryan Brown]

is there a patch available for -rc6?

On 8/11/05, Ingo Molnar <mingo@elte.hu> wrote:
> 
> i have released the -53-01 Real-Time Preemption patch, which can be
> downloaded from:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> there are two new features in this release, which justified the jump
> from .52 to .53:
> 
>  - the inclusion of the High Resolution Timers patch, written by
>    George Anzinger, and ported/improved/cleaned-up by Thomas Gleixner.
> 
>  - the inclusion of the RCU tasklist_lock patch from Paul McKenney.
> 
> the HRT patch from George Anzinger is a crutial piece of real-time
> infrastructure. The version included in the -RT tree supports both PIT
> and local APIC timer driven variable-rate timer interrupts.
> 
> Thomas Glexiner, besides porting it to PREEMPT_RT, cleaning it up,
> adding the local APIC timer support has also added the
> CONFIG_HIGH_RES_TIMERS_DYN_PRIO feature, which pushes priority
> inheritance into the high-res timer space. Furthermore, Thomas has
> extended nanosleep to use HR timers, if the task is RT. This makes it
> easier to test HRT functionality.
> 
> NOTE: there's a new softirq, softirq-hrtimer (PID 8 on UP x86), which
> should be chrt-ed to higher than SCHED_FIFO-50 if HR timer interrupts
> are the most important latencies in the system. E.g.:
> 
>   chrt -f 90 -p 8
> 
> the RCU tasklist-lock patch is a small but important feature from Paul
> McKenney which enables good HRT latencies: the HRT patch, when using
> POSIX timers, would use a signal-sending codepath that depends on the
> tasklist_lock, and thus the (quite high) tasklist_lock latencies
> controlled the latency of HR timers - defeating much of the benefits of
> HR timers. With the RCU tasklist-lock the signal sending path is now
> RCU-read locked, with no locking dependency, and thus excellent
> worst-case latencies.
> 
> given these changes, some (mostly build-related) regressions are to be
> expected. Only the x86 architecture is expected to work for now.
> 
> to build a -V0.7.53-01 tree, the following patches should to be applied:
> 
>    http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
>    http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc4.bz2
>    http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.13-rc4-RT-V0.7.53-01
> 
> patches, bugreports and any other feedback welcome,
> 
>         Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Lee Revell]

On Sat, 2005-08-13 at 12:28 +1200, Ryan Brown wrote:
> is there a patch available for -rc6?
> 

Not yet.  Whatever you see here:

http://people.redhat.com/mingo/realtime-preempt/

is the latest version.

Lee

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[George Anzinger]

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

Ingo, all

I, silly person that I am, configured an RT, SMP, PREEMPT_DEBUG system. 
  Someone put code in the NMI path to modify the preempt count which, 
often as not will generate a PREEMPT_DEBUG message as there is no tell 
what state the preempt count is in on an NMI interrupt.  I have sent the 
attached patch to Andrew on this, but meanwhile, if you want RT, SMP, 
PREEMPT_DEBUG you will be much better off with this.
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

[-- Attachment #2: fix-nmi-enter.patch --]
[-- Type: text/plain, Size: 1296 bytes --]

Source: MontaVista Software, Inc. George Anzinger <george@mvista.com>
Type: Defect Fix 

Description:

    Modifying a word from NMI code runs the very real risk of loosing
    either then new or the old bits.  Remember, we can not prevent an
    NMI interrupt from ANYWHERE, inparticular between the read and the
    write of a read modify write sequence.

    This patch removes the update of the preempt count from the NMI
    path.

Signed-off-by: George Anzinger<george@mvista.com>

 hardirq.h |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

Index: linux-2.6.13-rc/include/linux/hardirq.h
===================================================================
--- linux-2.6.13-rc.orig/include/linux/hardirq.h
+++ linux-2.6.13-rc/include/linux/hardirq.h
@@ -98,9 +98,12 @@ extern void synchronize_irq(unsigned int
 #else
 # define synchronize_irq(irq)	barrier()
 #endif
-
-#define nmi_enter()		irq_enter()
-#define nmi_exit()		sub_preempt_count(HARDIRQ_OFFSET)
+/*
+ * Re think these.  NMI _must_not_ share data words with non-nmi code
+ * Meanwhile, just do a no-op.
+ */
+#define nmi_enter()	/*	irq_enter()  */
+#define nmi_exit()	/*	sub_preempt_count(HARDIRQ_OFFSET) */
 
 #ifndef CONFIG_VIRT_CPU_ACCOUNTING
 static inline void account_user_vtime(struct task_struct *tsk)

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Ingo Molnar]

* George Anzinger <george@mvista.com> wrote:

> Ingo, all
> 
> I, silly person that I am, configured an RT, SMP, PREEMPT_DEBUG system. 
>  Someone put code in the NMI path to modify the preempt count which, 
> often as not will generate a PREEMPT_DEBUG message as there is no tell 
> what state the preempt count is in on an NMI interrupt.  I have sent 
> the attached patch to Andrew on this, but meanwhile, if you want RT, 
> SMP, PREEMPT_DEBUG you will be much better off with this.

ah - thanks, applied. Might explain some of the recent SMP weirdnesses 
i'm seeing. Attributed them to the HRT patch ;-)

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * George Anzinger <george@mvista.com> wrote:
> 
> > Ingo, all
> > 
> > I, silly person that I am, configured an RT, SMP, PREEMPT_DEBUG system. 
> >  Someone put code in the NMI path to modify the preempt count which, 
> > often as not will generate a PREEMPT_DEBUG message as there is no tell 
> > what state the preempt count is in on an NMI interrupt.  I have sent 
> > the attached patch to Andrew on this, but meanwhile, if you want RT, 
> > SMP, PREEMPT_DEBUG you will be much better off with this.
> 
> ah - thanks, applied. Might explain some of the recent SMP weirdnesses 
> i'm seeing. Attributed them to the HRT patch ;-)

i'm still seeing weird crashes under SMP, which go away if i disable 
CONFIG_HIGH_RES_TIMERS. (this after i fixed a couple of other SMP bugs 
in the HRT code) It happens sometime during the bootup, after enabling 
the network but before users can log in. There's no good debug info, 
just a hang that comes from all CPUs trying to get some debug info out 
but crashing deeply.

	Ingo

[patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* Ryan Brown <some.nzguy@gmail.com> wrote:

> is there a patch available for -rc6?

yes, i've just uploaded the -53-11 release, which is against 2.6.13-rc6.

the -53-11 release includes a number of fixes, in particular a fix for 
hard lockups that occur mostly on SMP systems, but also might occur on 
UP systems.

to build a -53-11 tree, the following patches should to be applied:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc6.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.13-rc6-RT-V0.7.53-11

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Peter Zijlstra]

Hi Ingo,

two small buglets for my config. This is the first .53 kernel that
worked for me (admittedly -07 was the last I tried). It feels a bit odd
but that might be the lack of sleep.

two traces, two patches.

Peter Zijlstra

kernel: WARNING: swapper/1 changed soft IRQ-flags.
kernel:  [<c01046b3>] dump_stack+0x23/0x30 (20)
kernel:  [<c0147e2f>] illegal_API_call+0x4f/0x60 (20)
kernel:  [<c0147f31>] __local_irq_save+0x31/0x40 (8)
kernel:  [<c02d4a2e>] rh_call_control+0x16e/0x3e0 (88)
kernel:  [<c02d4f53>] rh_urb_enqueue+0x33/0x60 (20)
kernel:  [<c02d5c04>] hcd_submit_urb+0x194/0x1c0 (44)
kernel:  [<c02d6a01>] usb_submit_urb+0x1e1/0x2c0 (44)
kernel:  [<c02d6d1e>] usb_start_wait_urb+0x6e/0x120 (164)
kernel:  [<c02d6e69>] usb_internal_control_msg+0x99/0xb0 (32)
kernel:  [<c02d6f12>] usb_control_msg+0x92/0xb0 (56)
kernel:  [<c02d781a>] usb_get_descriptor+0x9a/0xe0 (76)
kernel:  [<c02d7cb5>] usb_get_device_descriptor+0x65/0xa0 (44)
kernel:  [<c02d5507>] register_root_hub+0x77/0x160 (44)
kernel:  [<c02d63c2>] usb_add_hcd+0x172/0x3b0 (56)
kernel:  [<c02dafec>] usb_hcd_pci_probe+0x27c/0x3b0 (56)
kernel:  [<c022ea26>] __pci_device_probe+0x56/0x70 (28)
kernel:  [<c022ea74>] pci_device_probe+0x34/0x60 (24)
kernel:  [<c028156e>] driver_probe_device+0x3e/0xc0 (36)
kernel:  [<c02816ef>] __driver_attach+0x4f/0x60 (24)
kernel:  [<c0280b12>] bus_for_each_dev+0x62/0x90 (48)
kernel:  [<c028172d>] driver_attach+0x2d/0x30 (24)
kernel:  [<c0281068>] bus_add_driver+0x88/0xf0 (36)
kernel:  [<c0281b4d>] driver_register+0x5d/0x70 (32)
kernel:  [<c022ed8a>] pci_register_driver+0x9a/0xc0 (28)
kernel:  [<c048c7a9>] ohci_hcd_pci_init+0x39/0x40 (16)
kernel:  [<c0471b02>] do_initcalls+0x32/0xf0 (36)
kernel:  [<c0471bea>] do_basic_setup+0x2a/0x30 (8)
kernel:  [<c01003fa>] init+0x8a/0x290 (24)
kernel:  [<c01015f9>] kernel_thread_helper+0x5/0xc (1049518108)
kernel: ---------------------------
kernel: | preempt count: 00000000 ]
kernel: | 0-level deep critical section nesting:
kernel: ----------------------------------------
kernel:
kernel: ------------------------------
kernel: | showing all locks held by: |  (swapper/1 [c171b4f0, 116]):
kernel: ------------------------------
kernel:
kernel: #001:             [c07f6a74] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #002:             [c07f75f4] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #003:             [c07f8174] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #004:             [c07f8cf4] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #005:             [c07f9874] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #006:             [c07fa3f4] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #007:             [c07faf74] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #008:             [c07fbaf4] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #009:             [c07fc674] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #010:             [c07fd1f4] {(struct semaphore *)(&hwif->gendev_rel_sem)}
kernel: ... acquired at:               init_hwif_data+0x94/0x190
kernel:
kernel: #011:             [efe6fa00] {(struct semaphore *)(&dev->sem)}
kernel: ... acquired at:               __driver_attach+0x21/0x60
kernel:
kernel: #012:             [c03dcfe4] {kernel_sem.lock}
kernel: ... acquired at:               __reacquire_kernel_lock+0x38/0x80
kernel:
kernel: #013:             [c0429144] {usb_bus_list_lock.lock}
kernel: ... acquired at:               register_root_hub+0x5b/0x160

--- linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c~ 2005-08-15 21:23:45.000000000 +0200
+++ linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c  2005-08-15 22:03:33.000000000 +0200
@@ -506,13 +506,11 @@ error:
        }

        /* any errors get returned through the urb completion */
-       local_irq_save (flags);
+       local_irq_save_nort (flags);
        spin_lock (&urb->lock);
        if (urb->status == -EINPROGRESS)
                urb->status = status;
        spin_unlock (&urb->lock);
        usb_hcd_giveback_urb (hcd, urb, NULL);
-       local_irq_restore (flags);
+       local_irq_restore_nort (flags);
        return 0;
 }


kernel: WARNING: softirq-timer/0/4 changed soft IRQ-flags.
kernel:  [<c01046b3>] dump_stack+0x23/0x30 (20)
kernel:  [<c0147e2f>] illegal_API_call+0x4f/0x60 (20)
kernel:  [<c0147f31>] __local_irq_save+0x31/0x40 (8)
kernel:  [<c02d4cda>] usb_hcd_poll_rh_status+0x5a/0x180 (48)
kernel:  [<c02d4e16>] rh_timer_func+0x16/0x20 (12)
kernel:  [<c0131b30>] run_timer_softirq+0x210/0x430 (64)
kernel:  [<c012d5af>] ksoftirqd+0xff/0x1f0 (48)
kernel:  [<c013f816>] kthread+0xb6/0xf0 (48)
kernel:  [<c01015f9>] kernel_thread_helper+0x5/0xc (268668956)
kernel: ---------------------------
kernel: | preempt count: 00000000 ]
kernel: | 0-level deep critical section nesting:
kernel: ----------------------------------------
kernel:
kernel: ------------------------------
kernel: | showing all locks held by: |  (softirq-timer/0/4 [effc5510,  98]):
kernel: ------------------------------
kernel:


similar fix, completions need not have irqs disabled on 
PREEMPT_RT right?

--- linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c~ 2005-08-15 22:03:33.000000000 +0200
+++ linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c  2005-08-15 22:32:54.000000000 +0200
@@ -538,7 +538,7 @@ void usb_hcd_poll_rh_status(struct usb_h
        if (length > 0) {

                /* try to complete the status urb */
-               local_irq_save (flags);
+               local_irq_save_nort (flags);
                spin_lock(&hcd_root_hub_lock);
                urb = hcd->status_urb;
                if (urb) {
@@ -562,7 +562,7 @@ void usb_hcd_poll_rh_status(struct usb_h
                        usb_hcd_giveback_urb (hcd, urb, NULL);
                else
                        hcd->poll_pending = 1;
-               local_irq_restore (flags);
+               local_irq_restore_nort (flags);
        }

        /* The USB 2.0 spec says 256 ms.  This is close enough and won't



-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[George Anzinger]

Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> 
>>* George Anzinger <george@mvista.com> wrote:
>>
>>
>>>Ingo, all
>>>
>>>I, silly person that I am, configured an RT, SMP, PREEMPT_DEBUG system. 
>>> Someone put code in the NMI path to modify the preempt count which, 
>>>often as not will generate a PREEMPT_DEBUG message as there is no tell 
>>>what state the preempt count is in on an NMI interrupt.  I have sent 
>>>the attached patch to Andrew on this, but meanwhile, if you want RT, 
>>>SMP, PREEMPT_DEBUG you will be much better off with this.
>>
>>ah - thanks, applied. Might explain some of the recent SMP weirdnesses 
>>i'm seeing. Attributed them to the HRT patch ;-)
> 
> 
> i'm still seeing weird crashes under SMP, which go away if i disable 
> CONFIG_HIGH_RES_TIMERS. (this after i fixed a couple of other SMP bugs 
> in the HRT code) It happens sometime during the bootup, after enabling 
> the network but before users can log in. There's no good debug info, 
> just a hang that comes from all CPUs trying to get some debug info out 
> but crashing deeply.
> 
I haven't looked at this new code all that closely as yet.  One thing I 
did notice is that there is an assumption that the "timer being 
delivered flag" can be shared between LR timers and HR timers.  I 
suspect this is wrong as the delivery code is in seperate threads (I 
assume).  This could lead to del_timer_async missing a timer.

In the prior patch we just ignored the del_timer_async issue for HR 
timers (code I plan to do soon).  This WAS taken care of in earlier 
kernels by a reuse of one of the list link fields, but Andrew convince 
me that this was _not_ good.

So, my guess, a nanosleep for an RT task (I think you said these are 
promoted to HR) is completing and over writing the deliver in progress 
flag for a LR timer which just happens to have a del_timer_sync going on 
at the same time.
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> --- linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c~ 2005-08-15 21:23:45.000000000 +0200
> +++ linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c  2005-08-15 22:03:33.000000000 +0200
> @@ -506,13 +506,11 @@ error:
>         }
> 
>         /* any errors get returned through the urb completion */
> -       local_irq_save (flags);
> +       local_irq_save_nort (flags);
>         spin_lock (&urb->lock);
>         if (urb->status == -EINPROGRESS)
>                 urb->status = status;
>         spin_unlock (&urb->lock);
>         usb_hcd_giveback_urb (hcd, urb, NULL);
> -       local_irq_restore (flags);
> +       local_irq_restore_nort (flags);
>         return 0;
>  }

i'm wondering whether we could/should also fix this upstream - and 
whether this [making the IRQ flags disabling a NOP on -RT] is the right 
fix. Why does the USB hcd.c code do this in the first place? Disabling 
interrupts during usb_hcd_giveback_urb() [but not holding the urb->lock] 
might serialize on UP, but it has no serialization effect on SMP and is 
hence potentially buggy. Is there something i'm missing about this code?

the normal way of using urb->lock would be spin_lock_irqsave() and 
spin_lock_irqrestore(), not the 'detached' method seen above.

> similar fix, completions need not have irqs disabled on PREEMPT_RT 
> right?

correct, PREEMPT_RT is very strict about the use of the interrupt flags.  
A fair portion of the now-illegal API uses are also SMP bugs on 
upstream, so these details are worth pursuing.

> --- linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c~ 2005-08-15 22:03:33.000000000 +0200
> +++ linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c  2005-08-15 22:32:54.000000000 +0200
> @@ -538,7 +538,7 @@ void usb_hcd_poll_rh_status(struct usb_h
>         if (length > 0) {
> 
>                 /* try to complete the status urb */
> -               local_irq_save (flags);
> +               local_irq_save_nort (flags);
>                 spin_lock(&hcd_root_hub_lock);
>                 urb = hcd->status_urb;
>                 if (urb) {
> @@ -562,7 +562,7 @@ void usb_hcd_poll_rh_status(struct usb_h
>                         usb_hcd_giveback_urb (hcd, urb, NULL);
>                 else
>                         hcd->poll_pending = 1;
> -               local_irq_restore (flags);
> +               local_irq_restore_nort (flags);

same question: why are interrupts being kept disabled longer, and why is 
usb_hcd_giveback_urb() called with interrupts disabled? (I tried to use 
spin_lock_irqsave/irqrestore() in earlier -RT versions, but people 
reported hangs and USB misbehavior, which might be related. I'm worried 
that your _nort patch could cause similar misbehavior.)

how about (naively) extending the urb->lock to cover 
usb_hcd_giveback_urb() calls too - does that cause a deadlock or is it 
unsafe in some other way?

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.53-01, High Resolution Timers & RCU-tasklist features

[Thomas Gleixner]

On Mon, 2005-08-15 at 16:39 -0700, George Anzinger wrote:
> I haven't looked at this new code all that closely as yet.  One thing I 
> did notice is that there is an assumption that the "timer being 
> delivered flag" can be shared between LR timers and HR timers.  I 
> suspect this is wrong as the delivery code is in seperate threads (I 
> assume).  This could lead to del_timer_async missing a timer.

You're right, I found this yesterday night. Silly me.

This happened when I moved the hr timers into the tvec_t_base_s
structure due to Olegs  changes to the timer_list and the deletion code.

tglx

2.6.13-rc6-rt1

[Ingo Molnar]

i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the 
usual place:

  http://redhat.com/~mingo/realtime-preempt/

as the name already suggests, i've switched to a new, simplified naming 
scheme, which follows the usual naming convention of trees tracking the 
mainline kernel. The numbering will be restarted for every new upstream 
kernel the -RT tree is merged to.

the 2.6.13-rc6-rt1 release includes a number of fixes. Changes since 
-53-11:

 - more HRT fixes (Thomas Gleixner)

 - more RCU-tasklist-lock fixes (Paul E. McKenney)

 - IPC message-queue and IPC messages wakeup fixes (Daniel Walker)

 - VIA VT8237 southbridge quirks to fix IOAPIC issues (Karsten Wiese)

 - NMI preemption-count fix (George Anzinger)

 - various latency tracer fixes: lost trace entries, SMP weirdnesses (me)

to build a 2.6.13-rc6-rt1 tree, the following patches should to be 
applied:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.13-rc6.bz2
   http://redhat.com/~mingo/realtime-preempt/patch-2.6.13-rc6-rt1

	Ingo

Re: 2.6.13-rc6-rt1

[Milan Svoboda]

Hello,

HRT are really very cool, but my test program indicates a bug:

4612304528077750272
4612304528077750272
4612304528077750272
4612304528077750272
4612304528077750272
...

When CLOCK_MONOTONIC_HR is changed to CLOCK_MONOTONIC
the numbers are OK. Problem is with clock_gettime (I haven't tried clock_settime yet),
both CLOCK_MONOTONIC_HR and CLOCK_REALTIME_HR are broken.
(timer_* functions works fine)

Thanks,
 Milan Svoboda


#define _POSIX_TIMERS

#include <posix_time.h>
#include <signal.h>
#include <stdlib.h>

volatile int i;

void sighandle(int signum)
{
    struct timespec tv;
    clock_gettime(CLOCK_MONOTONIC_HR, &tv);

    printf("%lld\n", tv.tv_sec*1000000+tv.tv_nsec/1000);

    i++;
}

int main(int argc, char** argv)
{
    int preset;
    struct itimerspec timeout;
    struct sigevent event;
    timer_t timer;

    preset = 1000;

    if (argc == 2)
        preset = atoi(argv[1]);

    timeout.it_value.tv_sec = 0;
    timeout.it_value.tv_nsec = preset*1000;
    timeout.it_interval.tv_sec = 0;
    timeout.it_interval.tv_nsec = preset*1000;

    event.sigev_signo = __SIGRTMIN + 10;
    event.sigev_notify = SIGEV_SIGNAL;

    signal(__SIGRTMIN + 10, &sighandle);

    timer_create(CLOCK_MONOTONIC_HR, &event, &timer);
    timer_settime(timer, 0, &timeout, NULL);

    while (i<1000);

    return 0;
}

My .config:

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.13-rc6-rt1
# Tue Aug 16 10:57:59 2005
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
# CONFIG_AUDIT is not set
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
# CONFIG_IKCONFIG is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_LEGACY_TIMER is not set
# CONFIG_HPET_TIMER is not set
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HIGH_RES_TIMER_TSC=y
CONFIG_HIGH_RES_TIMERS_DYN_PRIO=y
CONFIG_HIGH_RES_RESOLUTION=1000
# CONFIG_SMP is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT_DESKTOP is not set
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_STATS is not set
CONFIG_RCU_TORTURE_TEST=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_IOAPIC_FAST=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y
# CONFIG_REGPARM is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x100000
# CONFIG_KEXEC is not set

#
# Power management options (ACPI, APM)
#
# CONFIG_PM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
# CONFIG_PCI_DEBUG is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
CONFIG_INET_TUNNEL=m
CONFIG_IP_TCPDIAG=y
# CONFIG_IP_TCPDIAG_IPV6 is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_IPV6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
# CONFIG_IP_NF_CT_ACCT is not set
# CONFIG_IP_NF_CONNTRACK_MARK is not set
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
# CONFIG_IP_NF_MATCH_IPRANGE is not set
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
# CONFIG_IP_NF_MATCH_RECENT is not set
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_OWNER=m
# CONFIG_IP_NF_MATCH_PHYSDEV is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
# CONFIG_IP_NF_MATCH_REALM is not set
# CONFIG_IP_NF_MATCH_SCTP is not set
# CONFIG_IP_NF_MATCH_COMMENT is not set
# CONFIG_IP_NF_MATCH_HASHLIMIT is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_TARGET_NETMAP is not set
# CONFIG_IP_NF_TARGET_SAME is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
# CONFIG_IP_NF_TARGET_CLASSIFY is not set
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_ARP_MANGLE is not set

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
# CONFIG_IP6_NF_MATCH_PHYSDEV is not set
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
# CONFIG_IP6_NF_RAW is not set

#
# Bridge: Netfilter Configuration
#
# CONFIG_BRIDGE_NF_EBTABLES is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
CONFIG_ATM_CLIP_NO_ICMP=y
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
# CONFIG_NET_CLS_ROUTE is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_LBD is not set
# CONFIG_CDROM_PKTCDVD is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_ATA_OVER_ETH is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI Transport Attributes
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_ISCSI_ATTRS is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=32
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA24XX is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SKGE is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set

#
# Ethernet (10000 Mbit)
#
CONFIG_IXGB=m
# CONFIG_IXGB_NAPI is not set
# CONFIG_S2IO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
# CONFIG_ATM_TCP is not set
# CONFIG_ATM_LANAI is not set
# CONFIG_ATM_ENI is not set
# CONFIG_ATM_FIRESTREAM is not set
# CONFIG_ATM_ZATM is not set
# CONFIG_ATM_NICSTAR is not set
# CONFIG_ATM_IDT77252 is not set
# CONFIG_ATM_AMBASSADOR is not set
# CONFIG_ATM_HORIZON is not set
# CONFIG_ATM_IA is not set
# CONFIG_ATM_FORE200E_MAYBE is not set
# CONFIG_ATM_HE is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_RTC_HISTOGRAM=y
CONFIG_BLOCKER=m
CONFIG_LPPTEST=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# TPM devices
#
# CONFIG_TCG_TPM is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
CONFIG_I2C_SAVAGE4=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
# CONFIG_I2C_PCA_ISA is not set
CONFIG_I2C_SENSOR=m

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
# CONFIG_SENSORS_PCA9539 is not set
CONFIG_SENSORS_PCF8591=m
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
CONFIG_HWMON=y
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
CONFIG_SENSORS_DS1621=m
# CONFIG_SENSORS_FSCHER is not set
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_IT87=m
# CONFIG_SENSORS_LM63 is not set
CONFIG_SENSORS_LM75=m
# CONFIG_SENSORS_LM77 is not set
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
# CONFIG_SENSORS_LM83 is not set
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
# CONFIG_SENSORS_LM90 is not set
CONFIG_SENSORS_LM92=m
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_SMSC47M1=m
# CONFIG_SENSORS_SMSC47B397 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_W83781D=m
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_VERBOSE_PRINTK=y
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# PCI devices
#
CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_HDA_INTEL is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m
# CONFIG_USB_BLUETOOTH_TTY is not set
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
# CONFIG_USB_STORAGE_USBAT is not set
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_MTOUCH is not set
# CONFIG_USB_ITMTOUCH is not set
# CONFIG_USB_EGALAX is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#
# CONFIG_USB_ATM is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# SN Devices
#

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y

#
# XFS support
#
# CONFIG_XFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=852
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-2"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_PROC_KCORE is not set
CONFIG_SYSFS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp852"
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-2"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
CONFIG_NLS_CODEPAGE_852=m
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=m
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=y

#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
# CONFIG_PRINTK_IGNORE_LOGLEVEL is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_DETECT_SOFTLOCKUP is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_WAKEUP_TIMING is not set
# CONFIG_CRITICAL_PREEMPT_TIMING is not set
# CONFIG_CRITICAL_IRQSOFF_TIMING is not set
# CONFIG_RT_DEADLOCK_DETECT is not set
# CONFIG_DEBUG_RT_LOCKING_MODE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_USE_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_KPROBES is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=m
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
# CONFIG_CRC_CCITT is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_PC=y

Re: 2.6.13-rc6-rt1

[Michal Schmidt]

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

Ingo Molnar wrote:
> i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the 
> usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 
> as the name already suggests, i've switched to a new, simplified naming 
> scheme, which follows the usual naming convention of trees tracking the 
> mainline kernel. The numbering will be restarted for every new upstream 
> kernel the -RT tree is merged to.

Great! With this naming scheme it is easy to teach Matt Mackall's 
ketchup script about the -RT tree.
The modified ketchup script can be downloaded from:
http://www.uamt.feec.vutbr.cz/rizeni/pom/ketchup-0.9+rt

Matt, would you release a new ketchup version with this support for 
Ingo's tree?

Michal

[-- Attachment #2: ketchup-rt.diff --]
[-- Type: text/plain, Size: 648 bytes --]

--- ketchup-0.9	2005-08-16 14:06:20.000000000 +0200
+++ ketchup-0.9+rt	2005-08-16 14:24:05.000000000 +0200
@@ -307,7 +307,11 @@ version_info = {
     '2.6-mjb': (latest_mjb,
                  kernel_url + "/people/mbligh/%(prebase)s/patch-%(full)s.bz2",
                  r'patch-(2.6.*?).bz2',
-                 1, "Martin Bligh's random collection 'o crap")
+                 1, "Martin Bligh's random collection 'o crap"),
+    '2.6-rt': (latest_dir,
+                "http://people.redhat.com/mingo/realtime-preempt/patch-%(full)s",
+		r'patch-(2.6.*?)',
+		0, "Ingo Molnar's realtime-preempt kernel")
     }
 
 def version_url(ver, sign = 0):

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Alan Stern]

On Tue, 16 Aug 2005, Ingo Molnar wrote:

> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > --- linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c~ 2005-08-15 21:23:45.000000000 +0200
> > +++ linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c  2005-08-15 22:03:33.000000000 +0200
> > @@ -506,13 +506,11 @@ error:
> >         }
> > 
> >         /* any errors get returned through the urb completion */
> > -       local_irq_save (flags);
> > +       local_irq_save_nort (flags);
> >         spin_lock (&urb->lock);
> >         if (urb->status == -EINPROGRESS)
> >                 urb->status = status;
> >         spin_unlock (&urb->lock);
> >         usb_hcd_giveback_urb (hcd, urb, NULL);
> > -       local_irq_restore (flags);
> > +       local_irq_restore_nort (flags);
> >         return 0;
> >  }
> 
> i'm wondering whether we could/should also fix this upstream - and 
> whether this [making the IRQ flags disabling a NOP on -RT] is the right 
> fix. Why does the USB hcd.c code do this in the first place? Disabling 
> interrupts during usb_hcd_giveback_urb() [but not holding the urb->lock] 
> might serialize on UP, but it has no serialization effect on SMP and is 
> hence potentially buggy. Is there something i'm missing about this code?
> 
> the normal way of using urb->lock would be spin_lock_irqsave() and 
> spin_lock_irqrestore(), not the 'detached' method seen above.

I don't know much about the real-time preemption work, but I can explain 
what the code was supposed to be doing.

Interrupts are disabled during usb_hcd_giveback_urb because that's how it
was done originally and nobody has made an effort to remove this
assumption from the USB device drivers.  There's no real reason for it
other than historical inertia.  It's not done for serialization -- there's
no need for serialization since an URB can't be resubmitted before the
previous callback occurs (unless a driver is badly broken).  The
"detached" method is used simply to avoid an extra pair of enable/disable
instructions.

Personally I think it would be an improvement if we changed things to
allow callbacks with interrupts enabled.  This would require a lot of 
auditing of USB drivers, but in the end it should prove worthwhile.

> > similar fix, completions need not have irqs disabled on PREEMPT_RT 
> > right?
> 
> correct, PREEMPT_RT is very strict about the use of the interrupt flags.  
> A fair portion of the now-illegal API uses are also SMP bugs on 
> upstream, so these details are worth pursuing.
> 
> > --- linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c~ 2005-08-15 22:03:33.000000000 +0200
> > +++ linux-2.6.13-rc6-git7-RT-V0.7.53-11/drivers/usb/core/hcd.c  2005-08-15 22:32:54.000000000 +0200
> > @@ -538,7 +538,7 @@ void usb_hcd_poll_rh_status(struct usb_h
> >         if (length > 0) {
> > 
> >                 /* try to complete the status urb */
> > -               local_irq_save (flags);
> > +               local_irq_save_nort (flags);
> >                 spin_lock(&hcd_root_hub_lock);
> >                 urb = hcd->status_urb;
> >                 if (urb) {
> > @@ -562,7 +562,7 @@ void usb_hcd_poll_rh_status(struct usb_h
> >                         usb_hcd_giveback_urb (hcd, urb, NULL);
> >                 else
> >                         hcd->poll_pending = 1;
> > -               local_irq_restore (flags);
> > +               local_irq_restore_nort (flags);
> 
> same question: why are interrupts being kept disabled longer, and why is 
> usb_hcd_giveback_urb() called with interrupts disabled? (I tried to use 
> spin_lock_irqsave/irqrestore() in earlier -RT versions, but people 
> reported hangs and USB misbehavior, which might be related. I'm worried 
> that your _nort patch could cause similar misbehavior.)

Same answer as above: The call is done with interrupts disabled because 
it was always done that way.

> how about (naively) extending the urb->lock to cover 
> usb_hcd_giveback_urb() calls too - does that cause a deadlock or is it 
> unsafe in some other way?

It would cause a deadlock.  Not to mention that this is not what urb->lock
is intended for (protection of urb->status).

Alan Stern

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* Alan Stern <stern@rowland.harvard.edu> wrote:

> Interrupts are disabled during usb_hcd_giveback_urb because that's how 
> it was done originally and nobody has made an effort to remove this 
> assumption from the USB device drivers.  There's no real reason for it 
> other than historical inertia.  It's not done for serialization -- 
> there's no need for serialization since an URB can't be resubmitted 
> before the previous callback occurs (unless a driver is badly broken).  
> The "detached" method is used simply to avoid an extra pair of 
> enable/disable instructions.

so we can remove it altogether, via the patch below? (If there's any 
unsafe driver, it should already be unsafe on SMP, and with the 
proliferation of HT and dual-core CPUs, SMP will be the norm within a 
year or so - so the sooner we trigger any breakages, the better i 
guess.)

i'll give it a whirl in the -RT tree.

	Ingo

----

remove unnecessarily irqs-off sections from hcd.c.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Index: linux/drivers/usb/core/hcd.c
===================================================================
--- linux.orig/drivers/usb/core/hcd.c
+++ linux/drivers/usb/core/hcd.c
@@ -506,13 +506,11 @@ error:
 	}
 
 	/* any errors get returned through the urb completion */
-	local_irq_save (flags);
-	spin_lock (&urb->lock);
+	spin_lock_irqsave(&urb->lock, flags);
 	if (urb->status == -EINPROGRESS)
 		urb->status = status;
-	spin_unlock (&urb->lock);
+	spin_unlock_irqrestore(&urb->lock, flags);
 	usb_hcd_giveback_urb (hcd, urb, NULL);
-	local_irq_restore (flags);
 	return 0;
 }
 
@@ -540,8 +538,7 @@ void usb_hcd_poll_rh_status(struct usb_h
 	if (length > 0) {
 
 		/* try to complete the status urb */
-		local_irq_save (flags);
-		spin_lock(&hcd_root_hub_lock);
+		spin_lock_irqsave(&hcd_root_hub_lock, flags);
 		urb = hcd->status_urb;
 		if (urb) {
 			spin_lock(&urb->lock);
@@ -557,14 +554,13 @@ void usb_hcd_poll_rh_status(struct usb_h
 			spin_unlock(&urb->lock);
 		} else
 			length = 0;
-		spin_unlock(&hcd_root_hub_lock);
+		spin_unlock_irqrestore(&hcd_root_hub_lock, flags);
 
 		/* local irqs are always blocked in completions */
 		if (length > 0)
 			usb_hcd_giveback_urb (hcd, urb, NULL);
 		else
 			hcd->poll_pending = 1;
-		local_irq_restore (flags);
 	}
 
 	/* The USB 2.0 spec says 256 ms.  This is close enough and won't
@@ -647,17 +643,15 @@ static int usb_rh_urb_dequeue (struct us
 	} else {				/* Status URB */
 		if (!hcd->uses_new_polling)
 			del_timer_sync (&hcd->rh_timer);
-		local_irq_disable ();
-		spin_lock (&hcd_root_hub_lock);
+		spin_lock_irq(&hcd_root_hub_lock);
 		if (urb == hcd->status_urb) {
 			hcd->status_urb = NULL;
 			urb->hcpriv = NULL;
 		} else
 			urb = NULL;		/* wasn't fully queued */
-		spin_unlock (&hcd_root_hub_lock);
+		spin_unlock_irq(&hcd_root_hub_lock);
 		if (urb)
 			usb_hcd_giveback_urb (hcd, urb, NULL);
-		local_irq_enable ();
 	}
 
 	return 0;
@@ -1367,15 +1361,13 @@ hcd_endpoint_disable (struct usb_device 
 	WARN_ON (!HC_IS_RUNNING (hcd->state) && hcd->state != HC_STATE_HALT &&
 			udev->state != USB_STATE_NOTATTACHED);
 
-	local_irq_disable ();
-
 	/* FIXME move most of this into message.c as part of its
 	 * endpoint disable logic
 	 */
 
 	/* ep is already gone from udev->ep_{in,out}[]; no more submits */
 rescan:
-	spin_lock (&hcd_data_lock);
+	spin_lock_irq(&hcd_data_lock);
 	list_for_each_entry (urb, &ep->urb_list, urb_list) {
 		int	tmp;
 
@@ -1388,13 +1380,13 @@ rescan:
 		if (urb->status != -EINPROGRESS)
 			continue;
 		usb_get_urb (urb);
-		spin_unlock (&hcd_data_lock);
+		spin_unlock_irq(&hcd_data_lock);
 
-		spin_lock (&urb->lock);
+		spin_lock_irq(&urb->lock);
 		tmp = urb->status;
 		if (tmp == -EINPROGRESS)
 			urb->status = -ESHUTDOWN;
-		spin_unlock (&urb->lock);
+		spin_unlock_irq(&urb->lock);
 
 		/* kick hcd unless it's already returning this */
 		if (tmp == -EINPROGRESS) {
@@ -1417,8 +1409,7 @@ rescan:
 		/* list contents may have changed */
 		goto rescan;
 	}
-	spin_unlock (&hcd_data_lock);
-	local_irq_enable ();
+	spin_unlock_irq(&hcd_data_lock);
 
 	/* synchronize with the hardware, so old configuration state
 	 * clears out immediately (and will be freed).

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Alan Stern]

On Tue, 16 Aug 2005, Ingo Molnar wrote:

> * Alan Stern <stern@rowland.harvard.edu> wrote:
> 
> > Interrupts are disabled during usb_hcd_giveback_urb because that's how 
> > it was done originally and nobody has made an effort to remove this 
> > assumption from the USB device drivers.  There's no real reason for it 
> > other than historical inertia.  It's not done for serialization -- 
> > there's no need for serialization since an URB can't be resubmitted 
> > before the previous callback occurs (unless a driver is badly broken).  
> > The "detached" method is used simply to avoid an extra pair of 
> > enable/disable instructions.
> 
> so we can remove it altogether, via the patch below? (If there's any 
> unsafe driver, it should already be unsafe on SMP, and with the 
> proliferation of HT and dual-core CPUs, SMP will be the norm within a 
> year or so - so the sooner we trigger any breakages, the better i 
> guess.)
> 
> i'll give it a whirl in the -RT tree.

In general yes, the patch should be okay.  But there are a few things to
check for.  Perhaps most of the USB drivers don't care whether interrupts
are enabled or not in their completion routines.  However I know of at
least one where it does matter.  The current code _is_ SMP-safe, but it
won't remain UP-safe unless you add this patch in addition to your own.

Alan Stern

P.S.: Another routine worth examining is async_completed() in 
drivers/usb/core/devio.c.



Index: usb-2.6/drivers/usb/core/message.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -224,8 +224,9 @@ static void sg_clean (struct usb_sg_requ
 static void sg_complete (struct urb *urb, struct pt_regs *regs)
 {
 	struct usb_sg_request	*io = (struct usb_sg_request *) urb->context;
+	unsigned long flags;
 
-	spin_lock (&io->lock);
+	spin_lock_irqsave (&io->lock, flags);
 
 	/* In 2.5 we require hcds' endpoint queues not to progress after fault
 	 * reports, until the completion callback (this!) returns.  That lets
@@ -259,7 +260,7 @@ static void sg_complete (struct urb *urb
 		 * unlink pending urbs so they won't rx/tx bad data.
 		 * careful: unlink can sometimes be synchronous...
 		 */
-		spin_unlock (&io->lock);
+		spin_unlock_irqrestore (&io->lock, flags);
 		for (i = 0, found = 0; i < io->entries; i++) {
 			if (!io->urbs [i] || !io->urbs [i]->dev)
 				continue;
@@ -272,7 +273,7 @@ static void sg_complete (struct urb *urb
 			} else if (urb == io->urbs [i])
 				found = 1;
 		}
-		spin_lock (&io->lock);
+		spin_lock_irqsave (&io->lock, flags);
 	}
 	urb->dev = NULL;
 
@@ -282,7 +283,7 @@ static void sg_complete (struct urb *urb
 	if (!io->count)
 		complete (&io->complete);
 
-	spin_unlock (&io->lock);
+	spin_unlock_irqrestore (&io->lock, flags);
 }
 
 

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* Alan Stern <stern@rowland.harvard.edu> wrote:

> In general yes, the patch should be okay.  But there are a few things 
> to check for.  Perhaps most of the USB drivers don't care whether 
> interrupts are enabled or not in their completion routines.  However I 
> know of at least one where it does matter.  The current code _is_ 
> SMP-safe, but it won't remain UP-safe unless you add this patch in 
> addition to your own.

ah, indeed. I've added this to the -RT tree too.

	Ingo

[patch] KGDB for Real-Time Preemption systems

[George Anzinger]

I have put a version of KGDB for x86 RT kernels here:
http://source.mvista.com/~ganzinger/

The common_kgdb_cfi_.... stuff creates debug records for entry.S and 
friends so that you can "bt" through them.  Apply in this order:
Ingo's patch
kgdb-ga-rt.patch
common_kgdb_cfi_annotations.patch

This is, more or less, the same kgdb that is in Andrew's mm tree changed 
to fix the RT issues.
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[David Brownell]

> > > Interrupts are disabled during usb_hcd_giveback_urb because that's how 
> > > it was done originally and nobody has made an effort to remove this 
> > > assumption from the USB device drivers.

Also Host Controller Drivers (HCDs).  You do sort of have to
remember who's calling this routine.  It's normally an HCD in
the middle of its IRQ processing, tending hardware.

I'd actually say the reason that has IRQs disabled is because
of the amount of work that would have been involved in changing
that assumption ...  I actually did look at what it'd take to
let IRQs be enabled during USB completion callbacks a while back,
and concluded it'd be a lot of work for hardly any return.


> > > 			There's no real reason for it 
> > > other than historical inertia.  It's not done for serialization -- 
> > > there's no need for serialization since an URB can't be resubmitted 
> > > before the previous callback occurs (unless a driver is badly broken).  
> > > The "detached" method is used simply to avoid an extra pair of 
> > > enable/disable instructions.
> > 
> > so we can remove it altogether, via the patch below?

Sounds dangerous to me.


> > 					(If there's any 
> > unsafe driver, it should already be unsafe on SMP, and with the 
> > proliferation of HT and dual-core CPUs, SMP will be the norm within a 
> > year or so - so the sooner we trigger any breakages, the better i 
> > guess.)
> > 
> > i'll give it a whirl in the -RT tree.
>
> In general yes, the patch should be okay.  But there are a few things to
> check for.  Perhaps most of the USB drivers don't care whether interrupts
> are enabled or not in their completion routines.

And in general, all drivers have been _allowed_ to know that IRQs are
disabled in completion handlers ever since the earliest 2.2 kernels
that included USB support.

Changes like that -- interactions between at least three obvious
subsystems (usbcore, usb drivers, hcds) and lots of unobvious ones
(whoever the drivers talk to) -- sound rather error prone to me.
Worth taking very cautiously, with lots of regression testing of
stress loads on some of the funkier hardware.


Not that I'm deeply opposed to such changes, you understand, but
there seem to be three choices here:

  1 ALWAYS complete() with IRQs disabled

  2 NEVER complete() with them disabled

  3 SOMETIMEs complete() with them disabled.

Right now we're with #1 which is simple, consistent and guaranteed.

We couldn't switch to #2 with patches that simple.  They'd in fact
be rather involved, because there is logic like "If the endpoint's
queue is empty when the completion handler returns, then deschedule
that queueue" inside IRQ handlers.  Basic things, like correctness,
for periodic scheduling depend on such logic.

And I don't see much point to #3.  It's got all the DIS-advantages
of #1 and #2 and the advantages of neither ...

- Dave

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* Alan Stern <stern@rowland.harvard.edu> wrote:

> P.S.: Another routine worth examining is async_completed() in 
> drivers/usb/core/devio.c.

i've added the patch below to be on the safe side.

	Ingo

Index: linux/drivers/usb/core/devio.c
===================================================================
--- linux.orig/drivers/usb/core/devio.c
+++ linux/drivers/usb/core/devio.c
@@ -274,10 +274,11 @@ static void async_completed(struct urb *
         struct async *as = (struct async *)urb->context;
         struct dev_state *ps = as->ps;
 	struct siginfo sinfo;
+	unsigned long flags;
 
-        spin_lock(&ps->lock);
-        list_move_tail(&as->asynclist, &ps->async_completed);
-        spin_unlock(&ps->lock);
+	spin_lock_irqsave(&ps->lock, flags);
+	list_move_tail(&as->asynclist, &ps->async_completed);
+	spin_unlock_irqrestore(&ps->lock, flags);
 	if (as->signr) {
 		sinfo.si_signo = as->signr;
 		sinfo.si_errno = as->urb->status;

Re: [patch] KGDB for Real-Time Preemption systems

[Ingo Molnar]

* George Anzinger <george@mvista.com> wrote:

> I have put a version of KGDB for x86 RT kernels here:
> http://source.mvista.com/~ganzinger/
> 
> The common_kgdb_cfi_.... stuff creates debug records for entry.S and 
> friends so that you can "bt" through them.  Apply in this order: 
> Ingo's patch kgdb-ga-rt.patch common_kgdb_cfi_annotations.patch
> 
> This is, more or less, the same kgdb that is in Andrew's mm tree 
> changed to fix the RT issues.

great. For the time being i wont add it to the -RT tree (because KGDB is 
not destined for upstream merging it seems), but it sure is a useful 
development/debugging add-on.

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Alan Stern]

On Tue, 16 Aug 2005, David Brownell wrote:

> > > > Interrupts are disabled during usb_hcd_giveback_urb because that's how 
> > > > it was done originally and nobody has made an effort to remove this 
> > > > assumption from the USB device drivers.
> 
> Also Host Controller Drivers (HCDs).  You do sort of have to
> remember who's calling this routine.  It's normally an HCD in
> the middle of its IRQ processing, tending hardware.
> 
> I'd actually say the reason that has IRQs disabled is because
> of the amount of work that would have been involved in changing
> that assumption ...  I actually did look at what it'd take to
> let IRQs be enabled during USB completion callbacks a while back,
> and concluded it'd be a lot of work for hardly any return.

Maybe Ingo's priorities are sufficiently different that he thinks the
return _will_ be worthwhile.  We've already mentioned the work involved in
auditing all the USB drivers.  You bring up the point that the HCDs may
need adjustments also.


>   1 ALWAYS complete() with IRQs disabled
> 
>   2 NEVER complete() with them disabled
> 
>   3 SOMETIMEs complete() with them disabled.
> 
> Right now we're with #1 which is simple, consistent and guaranteed.
> 
> We couldn't switch to #2 with patches that simple.  They'd in fact
> be rather involved, because there is logic like "If the endpoint's
> queue is empty when the completion handler returns, then deschedule
> that queueue" inside IRQ handlers.  Basic things, like correctness,
> for periodic scheduling depend on such logic.

I'm in favor of #2 on general principle.  The issue you mention,
maintaining bandwidth reservations (and hardware data structures) for
periodic endpoint queues, is not all that difficult to handle.  Are there
any other parts of the HCDs you can think of that would be affected by
such a change?  (I can't think of any for uhci-hcd, although I haven't
looked through the code to make sure.)

Alan Stern

Re: [patch] KGDB for Real-Time Preemption systems

[George Anzinger]

Ingo Molnar wrote:
> * George Anzinger <george@mvista.com> wrote:
> 
> 
>>I have put a version of KGDB for x86 RT kernels here:
>>http://source.mvista.com/~ganzinger/
>>
>>The common_kgdb_cfi_.... stuff creates debug records for entry.S and 
>>friends so that you can "bt" through them.  Apply in this order: 
>>Ingo's patch kgdb-ga-rt.patch common_kgdb_cfi_annotations.patch
>>
>>This is, more or less, the same kgdb that is in Andrew's mm tree 
>>changed to fix the RT issues.
> 
> 
> great. For the time being i wont add it to the -RT tree (because KGDB is 
> not destined for upstream merging it seems), but it sure is a useful 
> development/debugging add-on.

I agree on not adding it.  Tom Rini is working on a version the Andrew 
seems inclined to merge.  When that happens I will most likely put 
together enhancements to it to bring it up to what this one does. 
Meanwhile I am trying to capture some of Tom's changes in this one. 
Also, it is MUCH easier for me to maintain as a seperate patch.


-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[David Brownell]

> > > > > Interrupts are disabled during usb_hcd_giveback_urb because that's
> > > > > how it was done originally and nobody has made an effort to remove
> > > > > this assumption from the USB device drivers.
> > 
> > Also Host Controller Drivers (HCDs).  You do sort of have to
> > remember who's calling this routine.  It's normally an HCD in
> > the middle of its IRQ processing, tending hardware.
> > 
> > I'd actually say the reason that has IRQs disabled is because
> > of the amount of work that would have been involved in changing
> > that assumption ...  I actually did look at what it'd take to
> > let IRQs be enabled during USB completion callbacks a while back,
> > and concluded it'd be a lot of work for hardly any return.
>
> Maybe Ingo's priorities are sufficiently different that he thinks the
> return _will_ be worthwhile.

Maybe.  I think I didn't catch all the discussion either; what
I saw was questioning the USB-specific changes related to the
interrupt thread work.  That touches on a lot of other things
too, more than a few of which raise interesting issues.  :)


>		We've already mentioned the work involved in
> auditing all the USB drivers.  You bring up the point that the HCDs may
> need adjustments also.

Yes, both HCDs and usbcore.


> >   1 ALWAYS complete() with IRQs disabled
> > 
> >   2 NEVER complete() with them disabled
> > 
> >   3 SOMETIMEs complete() with them disabled.
> > 
> > Right now we're with #1 which is simple, consistent and guaranteed.
> > 
> > We couldn't switch to #2 with patches that simple.  They'd in fact
> > be rather involved ...
>
> I'm in favor of #2 on general principle.

Which principle would that be, though?  :)

I think "Keep It Simple, Stupid" argues strongly against #3,
and also -- at least for now -- against #2 as well.


>		The issue you mention,
> maintaining bandwidth reservations (and hardware data structures) for
> periodic endpoint queues, is not all that difficult to handle.

There were other places I remember logic that relied on such
API guarantees, but I couldn't list them all now.

In any case, I'm not going to invest time to rewrite any HCDs to
help make that happen.  I'm sure there are other people competent
to do that though, and some of them would surely bring some new 
insights into how the USB stack can be improved.

In fact I think this sort of thing might usefully be looked at
along with other performance related issues.  That whole stack
seems functional enough now that it might well be time to look
at thing that slow it down, or which it slows down.

- Dave

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* David Brownell <david-b@pacbell.net> wrote:

> > >   1 ALWAYS complete() with IRQs disabled
> > > 
> > >   2 NEVER complete() with them disabled
> > > 
> > >   3 SOMETIMEs complete() with them disabled.
> > > 
> > > Right now we're with #1 which is simple, consistent and guaranteed.
> > > 
> > > We couldn't switch to #2 with patches that simple.  They'd in fact
> > > be rather involved ...
> >
> > I'm in favor of #2 on general principle.
> 
> Which principle would that be, though?  :)

it's the basic Linux kernel principle of never disabling interrupts, 
unless really, really necessary.

but the main issue isnt with disabling interrupts in general, the issue 
is with "naked" (i.e. lock-less) disabling of interrupts. Let me try to 
explain. Stuff like:

	spin_lock_irq(&lock);
	stuff1();
	spin_unlock(&lock);
	stuff2();
	local_irq_enable();

is outright dangerous, because it could hide SMP bugs that do not 
trigger on UP. SMP systems are becoming the norm these days, so we 
cannot hide behind "most people use UP" arguments anymore. IRQ flags 
management needs to be tightened up. (The good news is that it can be 
done gradually and i'm doing it, so it's no extra work for you.)

so in the process of identifying naked IRQ-flags use i asked why the USB 
code was doing it, and i'm happy that the answer is "no good reason, 
mostly historic". (naked IRQ flags use also happens to be a problem for 
PREEMPT_RT, where i also have a debug warning about such IRQ flags 
assymetries, but you need not worry about that one.)

the only logistical problem with "unifying" the IRQ flags operations 
with their respective spin_lock functions is their transitive nature, 
e.g. in the above example, if stuff2() does:

	stuff2()
	{
		spin_lock(&lock2);
		stuff3();
		spin_unlock(&lock2);
	}

then the irqs-off condition needs to be propagated into the function:

	stuff2()
	{
		spin_lock_irq(&lock2);
		stuff3();
		spin_unlock_irq(&lock2);
	}

IFF 'lock2' can be used from an interrupt or softirq context. Obviously 
the latter code form is much more preferred, because it self-documents 
that lock2 is irq-safe. Nested, implicit irqs-off assumptions are 
another common source of locking bugs.

but fortunately this is a relatively straightforward process, and it 
seems Alan has identified most of the affected functions. I'd be happy 
if you could point out more candidates. In the worst-case, if any 
function is missed by accident then it's easy to debug it. I'm now 
testing the patches posted in this thread in the -RT tree, they are 
looking good so far.

to make such cleanups of irq-flags use easier i'm also thinking about 
automating the process of checking for the irq-safety of spinlocks, by 
adding a new spinlock type via:

	DEFINE_SPINLOCK_IRQSAFE(lock2);

(and a spin_lock_init_irqsafe() function too)

this will be useful for the whole kernel, not properly managing the irq 
flags is a common locking mistake. With this new debug feature enabled, 
the kernel will warn if an irq-safe lock is taken with interrupts still 
enabled.

furthermore, the debug feature will also warn if a spinlock _not_ marked 
irqsafe is used from an interrupt context. This is another common type 
of locking mistake.

the spinlock-consolidation patch currently cooking in -mm (to be merged 
to 2.6.14) makes it easy to add such new spinlock debugging features 
without having to change assembly code in 22 architectures.

[ we could even take this one step further and completely automate 
  irq-safe locks - i.e. not manage irq-flags at all and only have 
  spin_lock() and spin_unlock(). That would cause some minimal runtime 
  overhead for irqsafe locks though. But i digress. ]

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[David Brownell]

> > > > We couldn't switch to #2 with patches that simple.  They'd in fact
> > > > be rather involved ...
> > >
> > > I'm in favor of #2 on general principle.
> > 
> > Which principle would that be, though?  :)
>
> it's the basic Linux kernel principle of never disabling interrupts, 
> unless really, really necessary.

And "really, really" depends on context.  I know that you're
working in some contexts where "really, really" means "virtually
never", but that's not the only context folk work with.

Of course, "never ... unless really really necessary" can fight
against the principle of "as simple as practical".  Tradeoffs
somehow never seem far away in engineering, somehow.


> but the main issue isnt with disabling interrupts in general, the issue 
> is with "naked" (i.e. lock-less) disabling of interrupts. Let me try to 
> explain. Stuff like:
>
> 	spin_lock_irq(&lock);
> 	stuff1();
> 	spin_unlock(&lock);
> 	stuff2();
> 	local_irq_enable();
>
> is outright dangerous, because it could hide SMP bugs that do not 
> trigger on UP.

Sure, but NONE of the code in question started out that way.  And last
time I audited USB locking code, there was none like that.  So I don't
know where that pseudocode came from; if any code is like that today, it
could be hiding non-SMP bugs too.  The only cases where "local_irq_enable"
is used, it's paired with "local_irq_disable".

And the only places either is used relate to some tricky lock hierarchy
games that need to be played when canceling URBs ...  where usbcore has to
account for the fact that the URB being canceled may _at that instant_
be in the middle of being given back to the device driver (from the
HCD, via usbcore) by an IRQ handler on another CPU.  There's no "naked
disabling" at all; it's used exclusively when two different irq-safe
locks need to be coordinated.


> so in the process of identifying naked IRQ-flags use i asked why the USB 
> code was doing it, and i'm happy that the answer is "no good reason, 
> mostly historic". (naked IRQ flags use also happens to be a problem for 
> PREEMPT_RT, where i also have a debug warning about such IRQ flags 
> assymetries, but you need not worry about that one.)

But as I pointed out, that answer was incomplete.  Or maybe it
only addressed some of the code paths, not all of them.  Not
all the issues are "mostly historic".


> to make such cleanups of irq-flags use easier i'm also thinking about 
> automating the process of checking for the irq-safety of spinlocks, by 
> adding a new spinlock type via:
>
> 	DEFINE_SPINLOCK_IRQSAFE(lock2);
>
> (and a spin_lock_init_irqsafe() function too)

I think all the locks inside usbcore and the HCDs will end up
being "irqsafe"... 


> this will be useful for the whole kernel, not properly managing the irq 
> flags is a common locking mistake. With this new debug feature enabled, 
> the kernel will warn if an irq-safe lock is taken with interrupts still 
> enabled.
>
> furthermore, the debug feature will also warn if a spinlock _not_ marked 
> irqsafe is used from an interrupt context. This is another common type 
> of locking mistake.

That seems like a good idea.  New Linux developers have often gotten
confused about the rules associated with a given spinlock; and even
when something starts out with good comments, it likely doesn't stay
that way.  Automatic warning about simple mistakes will be a big win.

- Dave

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Alan Stern]

On Thu, 18 Aug 2005, Ingo Molnar wrote:

> but fortunately this is a relatively straightforward process, and it
> seems Alan has identified most of the affected functions. 

Ooh...  Don't assume that!  I only identified the two that occurred to me 
at the moment.  There could be plenty of others -- I haven't looked.


On Wed, 17 Aug 2005, David Brownell wrote:

> Of course, "never ... unless really really necessary" can fight
> against the principle of "as simple as practical".  Tradeoffs
> somehow never seem far away in engineering, somehow.

I don't think making this change will involve any loss of simplicity.  See 
below.

> And the only places either is used relate to some tricky lock hierarchy
> games that need to be played when canceling URBs ...  where usbcore has to
> account for the fact that the URB being canceled may _at that instant_
> be in the middle of being given back to the device driver (from the
> HCD, via usbcore) by an IRQ handler on another CPU.  There's no "naked
> disabling" at all; it's used exclusively when two different irq-safe
> locks need to be coordinated.

Are you two talking about the same thing?  I gather that by "naked 
disabling" Ingo means something like (see hcd_endpoint_disable):

	local_irq_disable ();

whereas Dave appears to be talking about nested spinlocks (see 
hcd_unlink_urb):

	spin_lock_irqsave (&urb->lock, flags);
	spin_lock (&hcd_data_lock);

There's no question that nested locking is important and necessary.  The
calls to local_irq_disable are more dubious.  AFAICT each place they
occur in hcd.c, it is solely to fulfill the guarantee that
usb_hcd_giveback_urb calls the completion handler with local interrupts
disabled.  It has no bearing at all on matters of concurrency, such as
cancelling an URB that is at that instant being given back -- the
spinlocks take care of that.  (Or more accurately, they would if the
local_irq_{dis,en}enable calls were removed and the corresponding
outermost calls to spin_lock were replaced by spin_lock_irq.)

> But as I pointed out, that answer was incomplete.  Or maybe it
> only addressed some of the code paths, not all of them.  Not
> all the issues are "mostly historic".

It's true that I haven't examined all the code paths.  Leaving aside the 
completion handlers themselves, however, I don't think there is anything 
in usbcore or the HCDs that would really be affected by enabling local 
interrupts during the callbacks.  If there is, it's almost certainly a 
bug.

Take for example the issue you mentioned before, about descheduling empty 
endpoint queues when the completion handler returns.  By enabling local 
interrupts, we would allow the possibility that an unrelated IRQ routine 
might enqueue or dequeue an entry while the handler was running.  But that 
possibility has always existed, since the unrelated IRQ routine could in 
any case be running on a different CPU.

Alan Stern

Re: [patch] Real-Time Preemption, -RT-2.6.13-rc6-V0.7.53-11

[Ingo Molnar]

* David Brownell <david-b@pacbell.net> wrote:

> > > > > We couldn't switch to #2 with patches that simple.  They'd in fact
> > > > > be rather involved ...
> > > >
> > > > I'm in favor of #2 on general principle.
> > > 
> > > Which principle would that be, though?  :)
> >
> > it's the basic Linux kernel principle of never disabling interrupts, 
> > unless really, really necessary.
> 
> And "really, really" depends on context.  I know that you're
> working in some contexts where "really, really" means "virtually
> never", but that's not the only context folk work with.
> 
> Of course, "never ... unless really really necessary" can fight 
> against the principle of "as simple as practical".  Tradeoffs somehow 
> never seem far away in engineering, somehow.

do you imply that in the USB case the code and the locking somehow gets 
simpler? It doesnt. Explicit management of the IRQ flags when combined 
with spinlocks is _never_ good, for multiple reasons. We do it only very 
rarely in the core kernel code, and even then we comment it thickly.  
E.g. we used to have a single case of such code in do_exit() and we got 
rid of it.

> > but the main issue isnt with disabling interrupts in general, the issue 
> > is with "naked" (i.e. lock-less) disabling of interrupts. Let me try to 
> > explain. Stuff like:
> >
> > 	spin_lock_irq(&lock);
> > 	stuff1();
> > 	spin_unlock(&lock);
> > 	stuff2();
> > 	local_irq_enable();
> >
> > is outright dangerous, because it could hide SMP bugs that do not 
> > trigger on UP.
> 
> Sure, but NONE of the code in question started out that way.  And last 
> time I audited USB locking code, there was none like that.  So I don't 
> know where that pseudocode came from; if any code is like that today, 
> it could be hiding non-SMP bugs too.  The only cases where 
> "local_irq_enable" is used, it's paired with "local_irq_disable".
> 
> And the only places either is used relate to some tricky lock 
> hierarchy games that need to be played when canceling URBs ... where 
> usbcore has to account for the fact that the URB being canceled may 
> _at that instant_ be in the middle of being given back to the device 
> driver (from the HCD, via usbcore) by an IRQ handler on another CPU.  
> There's no "naked disabling" at all; it's used exclusively when two 
> different irq-safe locks need to be coordinated.

the simple solution is to always save/restore irq flags when taking the 
irq-safe lock.

> > so in the process of identifying naked IRQ-flags use i asked why the USB 
> > code was doing it, and i'm happy that the answer is "no good reason, 
> > mostly historic". (naked IRQ flags use also happens to be a problem for 
> > PREEMPT_RT, where i also have a debug warning about such IRQ flags 
> > assymetries, but you need not worry about that one.)
> 
> But as I pointed out, that answer was incomplete.  Or maybe it only 
> addressed some of the code paths, not all of them.  Not all the issues 
> are "mostly historic".

so could you give me some other than "mostly historic" explanation? It 
seems there's some spin_lock() use within the USB code - if most of the 
USB locks are irq-safe, then all those spin_lock()s should be converted 
to use spin_lock_irqsave/restore. Depending on an external 
local_irq_disable() to have interrupts disabled is extremely fragile. It 
might easily be code that works fine right now, but it's an extremely 
unrobust concept.

> > to make such cleanups of irq-flags use easier i'm also thinking about 
> > automating the process of checking for the irq-safety of spinlocks, by 
> > adding a new spinlock type via:
> >
> > 	DEFINE_SPINLOCK_IRQSAFE(lock2);
> >
> > (and a spin_lock_init_irqsafe() function too)
> 
> I think all the locks inside usbcore and the HCDs will end up being 
> "irqsafe"...

great - then the solution is to use irq save/restore for all of them, 
and dont manage irq flags explicitly. I'll cook up a patch.

	Ingo

Re: 2.6.13-rc6-rt1

[Matt Mackall]

On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote:
> Ingo Molnar wrote:
> >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the 
> >usual place:
> >
> >  http://redhat.com/~mingo/realtime-preempt/
> >
> >as the name already suggests, i've switched to a new, simplified naming 
> >scheme, which follows the usual naming convention of trees tracking the 
> >mainline kernel. The numbering will be restarted for every new upstream 
> >kernel the -RT tree is merged to.
> 
> Great! With this naming scheme it is easy to teach Matt Mackall's 
> ketchup script about the -RT tree.
> The modified ketchup script can be downloaded from:
> http://www.uamt.feec.vutbr.cz/rizeni/pom/ketchup-0.9+rt
> 
> Matt, would you release a new ketchup version with this support for 
> Ingo's tree?

Thanks. I've put this in my version, which is now exported as a
Mercurial repo at:

 http://selenic.com/repo/ketchup

This version also has -git support, finally.

-- 
Mathematics is the supreme nostalgia of our time.

Re: 2.6.13-rc6-rt1

[Esben Nielsen]

On Fri, 26 Aug 2005, Matt Mackall wrote:

> On Tue, Aug 16, 2005 at 02:32:01PM +0200, Michal Schmidt wrote:
> > Ingo Molnar wrote:
> > >i've released the 2.6.13-rc6-rt1 tree, which can be downloaded from the 
> > >usual place:
> > >
> > >  http://redhat.com/~mingo/realtime-preempt/
> > >
> > >as the name already suggests, i've switched to a new, simplified naming 
> > >scheme, which follows the usual naming convention of trees tracking the 
> > >mainline kernel. The numbering will be restarted for every new upstream 
> > >kernel the -RT tree is merged to.
> > 
> > Great! With this naming scheme it is easy to teach Matt Mackall's 
> > ketchup script about the -RT tree.
> > The modified ketchup script can be downloaded from:
> > http://www.uamt.feec.vutbr.cz/rizeni/pom/ketchup-0.9+rt
> > 
> > Matt, would you release a new ketchup version with this support for 
> > Ingo's tree?
> 
> Thanks. I've put this in my version, which is now exported as a
> Mercurial repo at:
> 
>  http://selenic.com/repo/ketchup
> 
> This version also has -git support, finally.
> 
I added the line in the patch below to be able to get Ingo's older
patches.

Esben

diff -r 1342be306020 ketchup
--- a/ketchup   Sat Aug 27 01:12:42 2005
+++ b/ketchup   Tue Aug 30 00:30:23 2005
@@ -367,6 +367,7 @@
 
     # the jgarzik memorial hack
     url2 = re.sub("/snapshots/", "/snapshots/old/", url)
+    url2 = re.sub("/realtime-preempt/", "/realtime-preempt/older/", url2)    
     if url2 != url:
         if download(url2, file): return file

Re: [patch] KGDB for Real-Time Preemption systems

[Serge Noiraud]

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

mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
> I have put a version of KGDB for x86 RT kernels here:
> http://source.mvista.com/~ganzinger/
>
> The common_kgdb_cfi_.... stuff creates debug records for entry.S and
> friends so that you can "bt" through them.  Apply in this order:
> Ingo's patch
> kgdb-ga-rt.patch
> common_kgdb_cfi_annotations.patch
>
> This is, more or less, the same kgdb that is in Andrew's mm tree changed
> to fix the RT issues.

Hi, everybody

I found two bugs in kgdb-ga-rt patch.

The first one : if CONFIG_SMP is not set, we have a compile error
The second one : if CONFIG_KGDB is not set, we have a link error 
I send you a diff patch to correct this. I am not sure the last patch is 
correct, but it works.

[-- Attachment #2: diff.kgdb-ga-rt --]
[-- Type: text/x-diff, Size: 1233 bytes --]

--- kgdb-ga-rt.patch.org	2005-09-05 12:00:17.103019648 +0200
+++ kgdb-ga-rt.patch	2005-09-05 12:08:04.561955088 +0200
@@ -1861,11 +1861,11 @@
 +	gdb_i386errcode = err_code;
 +	kgdb_info.called_from = __builtin_return_address(0);
 +	kgdb_info.why = str;
++#ifdef CONFIG_SMP
 +	kgdb_info.cpus_waiting[trap_cpu].regs = linux_regs;
 +	kgdb_info.cpus_waiting[trap_cpu].task = current;
 +	kgdb_info.cpus_waiting[trap_cpu].pid = 
 +		(current->pid) ? : (PID_MAX + trap_cpu);
-+#ifdef CONFIG_SMP
 +	/*
 +	 * OK, we can now communicate, lets tell gdb about the sync.
 +	 * but only if we had a problem.
@@ -5078,7 +5078,7 @@
 ===================================================================
 --- /dev/null
 +++ linux-2.6.13-rc/include/asm-i386/kgdb_local.h
-@@ -0,0 +1,174 @@
+@@ -0,0 +1,178 @@
 +#ifndef __KGDB_LOCAL
 +#define ___KGDB_LOCAL
 +#include <linux/config.h>
@@ -5248,7 +5248,11 @@
 +#endif
 +#define INIT_KDEBUG putDebugChar("+");
 +extern struct  notifier_block kgdb_notify_struct;
++#ifdef CONFIG_KGDB 
 +#define KGDB_NOTIFY {&kgdb_notify_struct}
++#else				/* CONFIG_KGDB */
++#define KGDB_NOTIFY {NULL}
++#endif				/* CONFIG_KGDB */
 +#else
 +#define KGDB_NOTIFY {NULL}
 +#endif                          /* __ASSEMBLY__ */

Re: [patch] KGDB for Real-Time Preemption systems

[Serge Noiraud]

mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
> I have put a version of KGDB for x86 RT kernels here:
> http://source.mvista.com/~ganzinger/
>
> The common_kgdb_cfi_.... stuff creates debug records for entry.S and
> friends so that you can "bt" through them.  Apply in this order:
> Ingo's patch
> kgdb-ga-rt.patch
> common_kgdb_cfi_annotations.patch
>
> This is, more or less, the same kgdb that is in Andrew's mm tree changed
> to fix the RT issues.

I'm trying this kgdb patch with 2.6.13 and I get the following errors.
Is there something I forgot ?

...
  INSTALL sound/usb/snd-usb-audio.ko
  INSTALL sound/usb/snd-usb-lib.ko
  INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 
-b /var/tmp/kernel-2.6.13-rt4-root -r 2.6.13-rt4; fi
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/net/sunrpc/sunrpc.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/net/appletalk/appletalk.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/reiserfs/reiserfs.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/ntfs/ntfs.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/nfs/nfs.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/minix/minix.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/jbd/jbd.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/ext3/ext3.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/cifs/cifs.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/affs/affs.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/scsi/libata.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/scsi/ide-scsi.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/scsi/gdth.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/md/raid6.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/md/raid5.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/ide/ide-floppy.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/block/pktcdvd.ko 
needs unknown symbol preempt_locks
WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/block/loop.ko 
needs unknown symbol preempt_locks
make[3]: *** [_modinst_post] Erreur 1
erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.51405 (%install)


Erreur de construction de RPM:
    Mauvais status de sortie pour /var/tmp/rpm-tmp.51405 (%install)
make[2]: *** [rpm] Erreur 1
make[1]: *** [rpm] Erreur 2
make: *** [rpm] Erreur 2

Re: [patch] KGDB for Real-Time Preemption systems

[George Anzinger]

Serge Noiraud wrote:
> mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
> 
>>I have put a version of KGDB for x86 RT kernels here:
>>http://source.mvista.com/~ganzinger/
>>
>>The common_kgdb_cfi_.... stuff creates debug records for entry.S and
>>friends so that you can "bt" through them.  Apply in this order:
>>Ingo's patch
>>kgdb-ga-rt.patch
>>common_kgdb_cfi_annotations.patch
>>
>>This is, more or less, the same kgdb that is in Andrew's mm tree changed
>>to fix the RT issues.
> 
> 
> I'm trying this kgdb patch with 2.6.13 and I get the following errors.
> Is there something I forgot ?

This related to kgdb?  I.e. does it go away if you either turn off kgdb 
at configure time or just don't patch with kgdb?  (It sure seems 
unrelated, but...)

George
> 
> ...
>   INSTALL sound/usb/snd-usb-audio.ko
>   INSTALL sound/usb/snd-usb-lib.ko
>   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
> if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 
> -b /var/tmp/kernel-2.6.13-rt4-root -r 2.6.13-rt4; fi
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/net/sunrpc/sunrpc.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/net/appletalk/appletalk.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/reiserfs/reiserfs.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/ntfs/ntfs.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/nfs/nfs.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/minix/minix.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/jbd/jbd.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/ext3/ext3.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/cifs/cifs.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/fs/affs/affs.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/scsi/libata.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/scsi/ide-scsi.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/scsi/gdth.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/md/raid6.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/md/raid5.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/ide/ide-floppy.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/block/pktcdvd.ko 
> needs unknown symbol preempt_locks
> WARNING: /var/tmp/kernel-2.6.13-rt4-root/lib/modules/2.6.13-rt4/kernel/drivers/block/loop.ko 
> needs unknown symbol preempt_locks
> make[3]: *** [_modinst_post] Erreur 1
> erreur: Mauvais status de sortie pour /var/tmp/rpm-tmp.51405 (%install)
> 
> 
> Erreur de construction de RPM:
>     Mauvais status de sortie pour /var/tmp/rpm-tmp.51405 (%install)
> make[2]: *** [rpm] Erreur 1
> make[1]: *** [rpm] Erreur 2
> make: *** [rpm] Erreur 2
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [patch] KGDB for Real-Time Preemption systems

[George Anzinger]

Serge Noiraud wrote:
> mercredi 17 Août 2005 02:53, George Anzinger wrote/a écrit :
> 
>>I have put a version of KGDB for x86 RT kernels here:
>>http://source.mvista.com/~ganzinger/
>>
>>The common_kgdb_cfi_.... stuff creates debug records for entry.S and
>>friends so that you can "bt" through them.  Apply in this order:
>>Ingo's patch
>>kgdb-ga-rt.patch
>>common_kgdb_cfi_annotations.patch
>>
>>This is, more or less, the same kgdb that is in Andrew's mm tree changed
>>to fix the RT issues.
> 
> 
> Hi, everybody
> 
> I found two bugs in kgdb-ga-rt patch.
> 
> The first one : if CONFIG_SMP is not set, we have a compile error
> The second one : if CONFIG_KGDB is not set, we have a link error 
> I send you a diff patch to correct this. I am not sure the last patch is 
> correct, but it works.

The reported bugs are now rolled into the kgdb patch.  Also, there is a 
new README.txt.  I also included, in the kgdb patch, an updated gdb 
macro file (Documentation/i386/kgdb/gdbinit.hw) which has a per_cpu 
macro to:

	given a per_cpu structure name and the cpu number returns the
	address of that structure, properly typed.

I am also putting my current version of time_stamp_tool.  This is the 
replacement for kgdb_ts() which I have removed from the kgdb patch. 
Still a little rough but it has promise of being arch independent.

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

Re: [patch] KGDB for Real-Time Preemption systems

[Serge Noiraud]

mercredi 7 Septembre 2005 23:16, George Anzinger wrote/a écrit :
> Serge Noiraud wrote:
...
> >
> > I'm trying this kgdb patch with 2.6.13 and I get the following errors.
> > Is there something I forgot ?
>
> This related to kgdb?  I.e. does it go away if you either turn off kgdb
> at configure time or just don't patch with kgdb?  (It sure seems
> unrelated, but...)
I don't get those errors with CONFIG_KGDB=n
bellow I put the diff between a working . config and a non working .config
>
> George
>
> > ...
> >   INSTALL sound/usb/snd-usb-audio.ko
> >   INSTALL sound/usb/snd-usb-lib.ko
> >   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
> > if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
> > System.map -b /var/tmp/kernel-2.6.13-rt4-root -r 2.6.13-rt4; fi
> > WARNING:
...
If I redo the make command only ( not make rpm ) I obtain the following :
# make
  CHK     include/linux/version.h
make[1]: « arch/i386/kernel/asm-offsets.s » est à jour.
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
Kernel: arch/i386/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST
*** Warning: "preempt_locks" [net/sunrpc/sunrpc.ko] undefined!
*** Warning: "preempt_locks" [net/appletalk/appletalk.ko] undefined!
*** Warning: "preempt_locks" [fs/reiserfs/reiserfs.ko] undefined!
*** Warning: "preempt_locks" [fs/ntfs/ntfs.ko] undefined!
*** Warning: "preempt_locks" [fs/nfs/nfs.ko] undefined!
*** Warning: "preempt_locks" [fs/minix/minix.ko] undefined!
*** Warning: "preempt_locks" [fs/jbd/jbd.ko] undefined!
*** Warning: "preempt_locks" [fs/ext3/ext3.ko] undefined!
*** Warning: "preempt_locks" [fs/cifs/cifs.ko] undefined!
*** Warning: "preempt_locks" [fs/affs/affs.ko] undefined!
*** Warning: "preempt_locks" [drivers/scsi/libata.ko] undefined!
*** Warning: "preempt_locks" [drivers/scsi/ide-scsi.ko] undefined!
*** Warning: "preempt_locks" [drivers/scsi/gdth.ko] undefined!
*** Warning: "preempt_locks" [drivers/md/raid6.ko] undefined!
*** Warning: "preempt_locks" [drivers/md/raid5.ko] undefined!
*** Warning: "preempt_locks" [drivers/ide/ide-floppy.ko] undefined!
*** Warning: "preempt_locks" [drivers/block/pktcdvd.ko] undefined!
*** Warning: "preempt_locks" [drivers/block/loop.ko] undefined!
#

If I apply the following patch to my .config, I get the errors :
I tried with and without LTT. I get the same problem.

--- .config.orig    2005-08-01 10:29:22.740759504 +0200
+++ .config_dbg 2005-08-01 10:40:30.534239464 +0200
@@ -35,15 +35,16 @@
 CONFIG_IKCONFIG_PROC=y
 # CONFIG_CPUSETS is not set
 CONFIG_EMBEDDED=y
-# CONFIG_KALLSYMS is not set
-# CONFIG_KALLSYMS_ALL is not set
-# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_KALLSYMS=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_PRINTK=y
 CONFIG_BUG=y
 CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_LTT=y
 CONFIG_SHMEM=y
 CONFIG_CC_ALIGN_FUNCTIONS=0
 CONFIG_CC_ALIGN_LABELS=0
@@ -283,7 +284,7 @@
 CONFIG_PCI_MSI=y
 CONFIG_PCI_LEGACY_PROC=y
 # CONFIG_PCI_NAMES is not set
-# CONFIG_PCI_DEBUG is not set
+CONFIG_PCI_DEBUG=y
 CONFIG_ISA_DMA_API=y
 CONFIG_ISA=y
 # CONFIG_EISA is not set
@@ -329,7 +330,7 @@
 # CONFIG_STANDALONE is not set
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=m
-# CONFIG_DEBUG_DRIVER is not set
+CONFIG_DEBUG_DRIVER=y
 CONFIG_NET=y

 #
@@ -2780,7 +2781,10 @@
 # CONFIG_HUGETLBFS is not set
 # CONFIG_HUGETLB_PAGE is not set
 CONFIG_RAMFS=y
-# CONFIG_RELAYFS_FS is not set
+CONFIG_RELAYFS_FS=y
+CONFIG_KLOG_CHANNEL=y
+CONFIG_KLOG_CHANNEL_AUTOENABLE=y
+CONFIG_KLOG_CHANNEL_SHIFT=21
 CONFIG_SUPERMOUNT=m
 # CONFIG_SUPERMOUNT_DEBUG is not set

@@ -2930,36 +2931,38 @@
 #
 # Kernel hacking
 #
-# CONFIG_PRINTK_TIME is not set
-# CONFIG_PRINTK_IGNORE_LOGLEVEL is not set 
-# CONFIG_DEBUG_KERNEL is not set
+CONFIG_PRINTK_TIME=y
+CONFIG_PRINTK_IGNORE_LOGLEVEL=y
+CONFIG_DEBUG_KERNEL=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_LOG_BUF_SHIFT=17
 CONFIG_DETECT_SOFTLOCKUP=y
-# CONFIG_SCHEDSTATS is not set
-# CONFIG_DEBUG_SLAB is not set
-CONFIG_DEBUG_PREEMPT=n
-CONFIG_DEBUG_IRQ_FLAGS=n
+CONFIG_SCHEDSTATS=y
+CONFIG_DEBUG_SLAB=y
+CONFIG_DEBUG_PREEMPT=y
+CONFIG_DEBUG_IRQ_FLAGS=y
 CONFIG_WAKEUP_TIMING=y
-CONFIG_WAKEUP_LATENCY_HIST=n
+CONFIG_WAKEUP_LATENCY_HIST=y
 CONFIG_PREEMPT_TRACE=y
-CONFIG_CRITICAL_PREEMPT_TIMING=n  
-CONFIG_CRITICAL_IRQSOFF_TIMING=n   
+CONFIG_CRITICAL_PREEMPT_TIMING=y   
+CONFIG_PREEMPT_OFF_HIST=y
+CONFIG_CRITICAL_IRQSOFF_TIMING=y   
+CONFIG_INTERRUPT_OFF_HIST=y
 CONFIG_CRITICAL_TIMING=y
 CONFIG_LATENCY_TIMING=y
-# CONFIG_LATENCY_TRACE is not set
-# CONFIG_RT_DEADLOCK_DETECT is not set
-# CONFIG_DEBUG_RT_LOCKING_MODE is not set
-# CONFIG_DEBUG_KOBJECT is not set
-# CONFIG_DEBUG_HIGHMEM is not set
-# CONFIG_DEBUG_BUGVERBOSE is not set
-# CONFIG_DEBUG_INFO is not set
-# CONFIG_DEBUG_FS is not set
-# CONFIG_USE_FRAME_POINTER is not set
-# CONFIG_EARLY_PRINTK is not set
-# CONFIG_DEBUG_STACKOVERFLOW is not set
+CONFIG_LATENCY_TRACE=y
+CONFIG_RT_DEADLOCK_DETECT=y
+CONFIG_DEBUG_RT_LOCKING_MODE=y
+CONFIG_DEBUG_KOBJECT=y
+CONFIG_DEBUG_HIGHMEM=y
+CONFIG_DEBUG_BUGVERBOSE=y
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_FS=y
+CONFIG_USE_FRAME_POINTER=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_DEBUG_STACKOVERFLOW=y
 # CONFIG_KPROBES is not set
-# CONFIG_DEBUG_STACK_USAGE is not set
+CONFIG_DEBUG_STACK_USAGE=y

 #
 # Page alloc debug is incompatible with Software Suspend on i386
@@ -2967,7 +2968,27 @@
 # CONFIG_4KSTACKS is not set
 CONFIG_X86_FIND_SMP_CONFIG=y
 CONFIG_X86_MPPARSE=y
-# CONFIG_KGDB is not set
+CONFIG_KGDB=y
+CONFIG_KGDB_9600BAUD=y
+# CONFIG_KGDB_19200BAUD is not set
+# CONFIG_KGDB_38400BAUD is not set
+# CONFIG_KGDB_57600BAUD is not set
+# CONFIG_KGDB_115200BAUD is not set
+CONFIG_KGDB_PORT=0x3f8
+CONFIG_KGDB_IRQ=4
+CONFIG_KGDB_MORE=y
+CONFIG_KGDB_OPTIONS="-O1"
+CONFIG_NO_KGDB_CPUS=8
+CONFIG_KGDB_TS=y
+# CONFIG_KGDB_TS_64 is not set
+CONFIG_KGDB_TS_128=y
+# CONFIG_KGDB_TS_256 is not set
+# CONFIG_KGDB_TS_512 is not set
+# CONFIG_KGDB_TS_1024 is not set
+CONFIG_STACK_OVERFLOW_TEST=y
+CONFIG_TRAP_BAD_SYSCALL_EXITS=y
+CONFIG_KGDB_CONSOLE=y
+CONFIG_KGDB_SYSRQ=y

 #

Re: [patch] KGDB for Real-Time Preemption systems

[George Anzinger]

Serge Noiraud wrote:
> mercredi 7 Septembre 2005 23:16, George Anzinger wrote/a écrit :
> 
>>Serge Noiraud wrote:
> 
> ...
> 
>>>I'm trying this kgdb patch with 2.6.13 and I get the following errors.
>>>Is there something I forgot ?

Where did you get the kgdb you are using?  It looks like kgdb_ts is in 
this version, but it it not in the one on my website 
http://source.mvista.com/~ganzinger/
>>
>>This related to kgdb?  I.e. does it go away if you either turn off kgdb
>>at configure time or just don't patch with kgdb?  (It sure seems
>>unrelated, but...)
> 
> I don't get those errors with CONFIG_KGDB=n
> bellow I put the diff between a working . config and a non working .config
> 
>>George
>>
>>
>>>...
>>>  INSTALL sound/usb/snd-usb-audio.ko
>>>  INSTALL sound/usb/snd-usb-lib.ko
>>>  INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
>>>if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F
>>>System.map -b /var/tmp/kernel-2.6.13-rt4-root -r 2.6.13-rt4; fi
>>>WARNING:
> 
> ...
> If I redo the make command only ( not make rpm ) I obtain the following :
> # make
>   CHK     include/linux/version.h
> make[1]: « arch/i386/kernel/asm-offsets.s » est à jour.
>   CHK     include/linux/compile.h
>   CHK     usr/initramfs_list
> Kernel: arch/i386/boot/bzImage is ready  (#1)
>   Building modules, stage 2.
>   MODPOST
> *** Warning: "preempt_locks" [net/sunrpc/sunrpc.ko] undefined!
> *** Warning: "preempt_locks" [net/appletalk/appletalk.ko] undefined!
> *** Warning: "preempt_locks" [fs/reiserfs/reiserfs.ko] undefined!
> *** Warning: "preempt_locks" [fs/ntfs/ntfs.ko] undefined!
> *** Warning: "preempt_locks" [fs/nfs/nfs.ko] undefined!
> *** Warning: "preempt_locks" [fs/minix/minix.ko] undefined!
> *** Warning: "preempt_locks" [fs/jbd/jbd.ko] undefined!
> *** Warning: "preempt_locks" [fs/ext3/ext3.ko] undefined!
> *** Warning: "preempt_locks" [fs/cifs/cifs.ko] undefined!
> *** Warning: "preempt_locks" [fs/affs/affs.ko] undefined!
> *** Warning: "preempt_locks" [drivers/scsi/libata.ko] undefined!
> *** Warning: "preempt_locks" [drivers/scsi/ide-scsi.ko] undefined!
> *** Warning: "preempt_locks" [drivers/scsi/gdth.ko] undefined!
> *** Warning: "preempt_locks" [drivers/md/raid6.ko] undefined!
> *** Warning: "preempt_locks" [drivers/md/raid5.ko] undefined!
> *** Warning: "preempt_locks" [drivers/ide/ide-floppy.ko] undefined!
> *** Warning: "preempt_locks" [drivers/block/pktcdvd.ko] undefined!
> *** Warning: "preempt_locks" [drivers/block/loop.ko] undefined!

preempt_locks is being accessed from a module but is not exported.  This 
is turned on with CONFIG_DEBUG_RT_LOCKING_MODE so change that and it 
should build.

> #
> 
~
> -# CONFIG_EARLY_PRINTK is not set
> -# CONFIG_DEBUG_STACKOVERFLOW is not set
> +CONFIG_LATENCY_TRACE=y
> +CONFIG_RT_DEADLOCK_DETECT=y
> +CONFIG_DEBUG_RT_LOCKING_MODE=y <--------------------- This one is doing it............
> +CONFIG_DEBUG_KOBJECT=y
> +CONFIG_DEBUG_HIGHMEM=y
~
> +CONFIG_KGDB=y
> +CONFIG_KGDB_9600BAUD=y
> +# CONFIG_KGDB_19200BAUD is not set
> +# CONFIG_KGDB_38400BAUD is not set
> +# CONFIG_KGDB_57600BAUD is not set
> +# CONFIG_KGDB_115200BAUD is not set
> +CONFIG_KGDB_PORT=0x3f8
> +CONFIG_KGDB_IRQ=4
> +CONFIG_KGDB_MORE=y
> +CONFIG_KGDB_OPTIONS="-O1"
> +CONFIG_NO_KGDB_CPUS=8

The following are not in the latest kgdb...............
> +CONFIG_KGDB_TS=y
> +# CONFIG_KGDB_TS_64 is not set
> +CONFIG_KGDB_TS_128=y
> +# CONFIG_KGDB_TS_256 is not set
> +# CONFIG_KGDB_TS_512 is not set
> +# CONFIG_KGDB_TS_1024 is not set
.....................................
> +CONFIG_STACK_OVERFLOW_TEST=y
> +CONFIG_TRAP_BAD_SYSCALL_EXITS=y  <--- I recommend against this one, see notes at front of kgdb patch
> +CONFIG_KGDB_CONSOLE=y            <--- Likewise use this only if you have only one serial port and no VGA
> +CONFIG_KGDB_SYSRQ=y
> 
>  #
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/