Re: 2.6.25-rc2 rcupreempt WARN after suspend to ram
Am Sonntag, 24. Februar 2008 schrieb Paul E. McKenney: > On Sun, Feb 24, 2008 at 04:38:15PM +0100, Karsten Wiese wrote: > > Am Samstag, 23. Februar 2008 schrieb Karsten Wiese: > > > Am Samstag, 23. Februar 2008 schrieb Paul E. McKenney: > > > > On Sat, Feb 23, 2008 at 01:41:02PM +0100, Karsten Wiese wrote: > > > > > Hi, > > > > > > > > > > This appeared in dmesg after > > > > > $ echo core > /sys/power/pm_test > > > > > followed by 3 cycles of > > > > > $ echo mem > /sys/power/state > > > > > . .config attached. > > > > > > > > > > dmesg excerpt (, full ~1MByte available): > > > > > > > > Does this tree have http://lkml.org/lkml/2008/1/29/208 applied? > > > > > > Yes. This tree was linus' git head as of yesterday or the day before. > > > > Updated to git-head of today, same test and .config, different symptoms > > like in this thread: http://lkml.org/lkml/2008/2/23/260 > > Later in this thread, Alan Cox said it looked like irq problems. > > Maybe also the rcupreemt related WARN_ON I saw are caused by irq problems. > > Might be, but am taking a closer look at the interaction between irq, > dynticks, and rcupreempt in any case. [Added Rafael, Thomas and Steven to CC] The "different symptoms" above are indeed unrelated and solved by reverting "commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2 power_state: get rid of write-only variable in SATA" The cpu_hotplug code used by suspend together with hr_timer and nohz looks suspicious: $ echo 0 > /sys/devices/system/cpu/cpu1/online $ echo 1 > /sys/devices/system/cpu/cpu1/online (repeat until dmesg|tail shows WARNs; here it took 2 iterations) causes symptoms like in 1st message of this thread again. Thanks, Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 rcupreempt WARN after suspend to ram
Am Samstag, 23. Februar 2008 schrieb Karsten Wiese: > Am Samstag, 23. Februar 2008 schrieb Paul E. McKenney: > > On Sat, Feb 23, 2008 at 01:41:02PM +0100, Karsten Wiese wrote: > > > Hi, > > > > > > This appeared in dmesg after > > > $ echo core > /sys/power/pm_test > > > followed by 3 cycles of > > > $ echo mem > /sys/power/state > > > . .config attached. > > > > > > dmesg excerpt (, full ~1MByte available): > > > > Does this tree have http://lkml.org/lkml/2008/1/29/208 applied? > > Yes. This tree was linus' git head as of yesterday or the day before. Updated to git-head of today, same test and .config, different symptoms like in this thread: http://lkml.org/lkml/2008/2/23/260 Later in this thread, Alan Cox said it looked like irq problems. Maybe also the rcupreemt related WARN_ON I saw are caused by irq problems. Thanks, Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 rcupreempt WARN after suspend to ram
Am Samstag, 23. Februar 2008 schrieb Paul E. McKenney: > On Sat, Feb 23, 2008 at 01:41:02PM +0100, Karsten Wiese wrote: > > Hi, > > > > This appeared in dmesg after > > $ echo core > /sys/power/pm_test > > followed by 3 cycles of > > $ echo mem > /sys/power/state > > . .config attached. > > > > dmesg excerpt (, full ~1MByte available): > > Does this tree have http://lkml.org/lkml/2008/1/29/208 applied? Yes. This tree was linus' git head as of yesterday or the day before. Thanks, Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] 2.6.24-rcx: Make sys_poll() wait at least timeout ms
Am Mittwoch, 19. Dezember 2007 schrieb Robert Hancock: > Karsten Wiese wrote: > > Am Mittwoch, 19. Dezember 2007 schrieb Robert Hancock: > >> That seems fishy. What is your value of HZ and what is the timeout value > >> that was passed in the bad case? > > > > HZ set to 250, timeout to 4ms. > > Time spent in poll() taken by clock_gettime(CLOCK_MONOTONIC, &time) > > before and after poll()call: i.e 62us. > > Time measured with hpet gave 166us once. > > msecs_to_jiffies (kernel/time.c) has this: > > #if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ) > /* >* HZ is equal to or smaller than 1000, and 1000 is a nice >* round multiple of HZ, divide with the factor between them, >* but round upwards: >*/ > return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ); > > With HZ=250 and m=4 this gives 7/4 or only 1 jiffy, which is not more > than 4ms, but if we are already at near the end of the current jiffy it > could be much less than that (potentially almost no time at all). > > Maybe we could convert poll to use a hrtimer for this instead? That wouldn't fix configs without hrtimers. The linux manpage reflects current behaviour: from man2/poll.2.gz "The timeout argument specifies an upper limit on the time for which poll() will block, in milliseconds." To achieve "at least" timeouts we'd have to add a jiffy's ms to the timeout in userspace. I'd like to let sys_poll() behave according to posix's manpage: from man3p/poll.3p.gz "poll() shall wait at least timeout milliseconds" Thats easier to specify in userspace. No need to know the running kernel's HZ. Above posix/linux difference also shows in select() manpages. epoll_wait() (linux only) manpage also says "maximum time of timeout" A more complete patch would tweek (p)poll (p)select and epoll_(p)wait. There are possibly more syscalls affected that I'm not aware off. Is there upstream interest? Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] 2.6.24-rcx: Make sys_poll() wait at least timeout ms
Am Mittwoch, 19. Dezember 2007 schrieb Robert Hancock: > > That seems fishy. What is your value of HZ and what is the timeout value > that was passed in the bad case? HZ set to 250, timeout to 4ms. Time spent in poll() taken by clock_gettime(CLOCK_MONOTONIC, &time) before and after poll()call: i.e 62us. Time measured with hpet gave 166us once. Karsten -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC/PATCH] 2.6.24-rcx: Make sys_poll() wait at least timeout ms
Hi,
while playing with jackd on 2.6.24-rcx, I found poll() timing out too early.
That is: earlier than its timeout argument specified.
Setting poll()'s timeout argument to "required timeout" + "1 jiffy in ms"
fixed it. Patch below should fix it too. Correct?
Untested.
Otherwise 2.6.24-rc5 ticks just fine here, thanks.
Karsten
->
Make sys_poll() wait at least timeout ms
schedule_timeout(jiffies) waits for at least jiffies - 1.
Add 1 jiffie to the timeout_jiffies calculated in sys_poll() to wait at least
timeout_msecs, like poll() manpage says.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
fs/select.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index 47f4792..5633fe9 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -739,7 +739,7 @@ asmlinkage long sys_poll(struct pollfd __user *ufds,
unsigned int nfds,
timeout_jiffies = -1;
else
#endif
- timeout_jiffies = msecs_to_jiffies(timeout_msecs);
+ timeout_jiffies = msecs_to_jiffies(timeout_msecs) + 1;
} else {
/* Infinite (< 0) or no (0) timeout */
timeout_jiffies = timeout_msecs;
--
1.5.3.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Pin-pointing the root of unusual application latencies
Am Mittwoch, 25. Juli 2007 schrieb John Sigler:
> Karsten Wiese wrote:
>
> > John Sigler wrote:
> >
> >> Is there some form of priority inheritance? Does the IRQ handler get a
> >> priority boost if a high priority task is waiting for it?
> >
> > No. But that would be "nice to have".
>
> No to the first question? to the second question? or to both? :-)
>
To the second.
I checked some soundcard drivers some time ago in -rt kernels, looking for
that "priority boosted by consuming process threaded interrupt handler".
Then there was no such.
> In kernel/futex.c does "PI" stand for Priority Inheritance?
>
I guess so, yes.
> e.g.
>
> /*
> * Priority Inheritance state:
> */
> struct futex_pi_state {
> /*
>* list of 'owned' pi_state instances - these have to be
>* cleaned up in do_exit() if the task exits prematurely:
>*/
> struct list_head list;
>
> /*
>* The PI object:
>*/
> struct rt_mutex pi_mutex;
>
> struct task_struct *owner;
> atomic_t refcount;
>
> union futex_key key;
> };
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Pin-pointing the root of unusual application latencies
Am Mittwoch, 25. Juli 2007 schrieb John Sigler: > > Is there some form of priority inheritance? Does the IRQ handler get a > priority boost if a high priority task is waiting for it? No. But that would be "nice to have". Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: where is the code for read system call?
Am Montag, 23. Juli 2007 schrieb Agarwal, Lomesh: > For future how do I trace a system call to a function in a kernel? strace. i.e: $ strace ls - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: where is the code for read system call?
Am Samstag, 21. Juli 2007 schrieb Agarwal, Lomesh: > My application reads from socket. I need to change the behavior of read > system call for an experiment. Can someone point me to code? fs/read_write.c: line 356 asmlinkage ssize_t sys_read(unsigned int fd, char __user * buf, size_t count) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.20-rt1, yum/rpm
Am Montag, 5. Februar 2007 07:56 schrieb Ingo Molnar: > i have released the v2.6.20-rt1 kernel, which can be downloaded from the after resuming from $ echo mem > /sys/power/state both lapic and pic are active, while only lapic should be. resuming from $ echo disk > /sys/power/state is fine. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm] Make rcupreempt.c compile with CONFIG_RCU_TRACE not set
RCU_TRACE is always defined.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
diff -pur rc6-mm2/kernel/rcupreempt.c rc6-mm2-kw/kernel/rcupreempt.c
--- rc6-mm2/kernel/rcupreempt.c 2007-01-30 00:08:21.0 +0100
+++ rc6-mm2-kw/kernel/rcupreempt.c 2007-01-29 11:07:43.0 +0100
@@ -619,7 +619,7 @@ void synchronize_kernel(void)
synchronize_rcu();
}
-#ifdef RCU_TRACE
+#ifdef CONFIG_RCU_TRACE
int *rcupreempt_flipctr(int cpu)
{
return &per_cpu(rcu_flipctr, cpu)[0];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm3
Am Donnerstag, 1. Februar 2007 11:44 schrieb Karsten Wiese: > I think the wait is caused by an interrupt starting somewhere under > sysdev_resume(void). > possibly lapic timer interrupt? Will try to trace that. Some evidence: [EMAIL PROTECTED] Desktop]# echo reboot > /sys/power/disk [EMAIL PROTECTED] Desktop]# cat /proc/interrupts; echo disk > /sys/power/state ; cat /proc/interrupts LOC:2215504 LOC:2216432 [EMAIL PROTECTED] Desktop]# cat /proc/interrupts; echo disk > /sys/power/state ; cat /proc/interrupts LOC:2225752 LOC:2238383 Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm3
Am Donnerstag, 1. Februar 2007 09:01 schrieb Ingo Molnar: > > and this means i'm having trouble reproducing this problem locally. > Maybe i tried it the wrong way: does it only occur with suspend-to-disk, > or suspend-to-ram too? Does it need ACPI suspend-to-disk, or > software-suspend? Haven't checked suspend-to-ram. I use pm-hibernate or "echo reboot > /sys/power/disk; echo disk > /sys/power/state". Thats software-suspend? I think the wait is caused by an interrupt starting somewhere under sysdev_resume(void). possibly lapic timer interrupt? Will try to trace that. 2.6.20-rc6-rt6 .config attached. Machine is AMD64 UP, VIA chipset desktop. Karsten # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc6-rt6 # Thu Feb 1 00:25:31 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=".dbg" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_UTS_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_TASK_XACCT is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set 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_PARAVIRT 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_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # 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_MGEODE_LX 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=6 CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set 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_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # 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_CLASSIC_RCU is not set CONFIG_PREEMPT_RCU=y CONFIG_RCU_TRACE=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_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set C
Re: 2.6.20-rc6-mm3
Am Mittwoch, 31. Januar 2007 14:22 schrieb Ingo Molnar: > > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > > Similar weirdness here on rc6-mm2 and rc6-rt*: resume from disk waits > > unduly long. > > i'm wondering whether the jiffies update fix from Thomas fixes this bug > for you. > > If not then do you have a serial console enabled? > > > Some waiting times from rc6-rt6 from memory: > > > > Config | HZ| NO_HZ + HRESTIMERS > > cmos clock unchanged| 2s| 6s > > cmos clock += 10min | | 2 minutes > > cmos clock += 2 month | 20s | > 4minutes, test > > interrupted > > i've seen something like this on -rt (and incorrectly attributed it to > -rt) when running on a system which has a serial port and which has a > kernel console on that serial port. What happens is that after resume > (and straight after console suspend) every serial character printed > takes /alot/ of time - and resume does print a number of kernel messages > to the console. I didnt get any further in debugging this though, but > disabling the serial console made the problem go away. > > a possibly related thing: the serial code is sensitive to jiffies > updates and timers, i saw that during early revisions of the dynticks > code - but the specifics escape me. > > the slowdown could also be something like the kernel somehow wrapping > around jiffies and thus doing /alot/ of jiffy ticks? Or it could be a > miscalculation in the amount of jiffies that need updating, resulting in > a similar number of loops in the jiffy update code. > > (i'll try to figure out this regression - but wanted to describe to you > the known things so far, maybe you'll figure it out faster than me.) Serial port console is off here and the jiffies update fix doesn't make a noticeable difference. I've just captured a dmesglog of 3 suspend/resume cycles with printk timestamps. Config has NO_HZ and HRESTIMERS. In the 1st 2 cycles, while in bios, I advanced the cmos clock by ~4minutes, In the last cycle by ~2minutes. After the lapic resume on CPU#0 entries there are roughly proportional timestamp differences of ~60s, ~60s and ~35s. Those equal the unexpected wait times. Will look into what happens between "lapic resume on CPU#0" and "pci :00:00.0: EARLY resume" next. Karsten [0.00] Linux version 2.6.20-rc6-rt6.dbg ([EMAIL PROTECTED]) (gcc-Version 4.1.1 20070105 (Red Hat 4.1.1-51)) #3 PREEMPT Wed Jan 31 14:25:07 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize end [0.00] copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 0009fc00 size: 0400 end: 000a type: 2 [0.00] copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 [0.00] copy_e820_map() start: 0010 size: 3fef end: 3fff type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 3fff size: 8000 end: 3fff8000 type: 3 [0.00] copy_e820_map() start: 3fff8000 size: 8000 end: 4000 type: 4 [0.00] copy_e820_map() start: fec0 size: 1000 end: fec01000 type: 2 [0.00] copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 [0.00] copy_e820_map() start: fff8 size: 0008 end: 0001 type: 2 [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fff (usable) [0.00] BIOS-e820: 3fff - 3fff8000 (ACPI data) [0.00] BIOS-e820: 3fff8000 - 4000 (ACPI NVS) [0.00] BIOS-e820: fec0 - fec01000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] 127MB HIGHMEM available. [0.00] 896MB LOWMEM available. [0.00] found SMP MP-table at 000fbfc0 [0.00] Entering add_active_range(0, 0, 262128) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 -> 229376 [0.00] HighMem229376 -> 262128 [0.00
Re: 2.6.20-rc6-mm3
Am Dienstag, 30. Januar 2007 23:27 schrieb Andrew Morton: > On Tue, 30 Jan 2007 23:18:42 +0100 > Maciej Rutecki <[EMAIL PROTECTED]> wrote: <...> > > I have two problems. First suspend to disk. > > > > After suspend to disk (before resume) I check time in bios, and it's > > correct, but during resume, I have this message: > > > > "Suspending console(s)" > > > > system wait 20 seconds (or more) until finish resume. Also system clock > > was slow about this 20 seconds. > > OK, thanks. That might be due to the time-management updates as well. > I'll see if I can reproduce this. > > If you're keen, you could test just 2.6.19-rc6+origin.patch+git-acpi.patch > from > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out > and see which of these problems remain. Similar weirdness here on rc6-mm2 and rc6-rt*: resume from disk waits unduly long. I played with bios clock setting after I wondered why susp/res wouldn't work overnight: the longer the (faked/real) suspend to disk time, the longer the (not seen on 2.6.18-rt) waiting past the incrementing % display, before things are running again. After turning time backwards in bios, console mouse handler gpm experiences "interrupted system call". Some waiting times from rc6-rt6 from memory: Config | HZ| NO_HZ + HRESTIMERS cmos clock unchanged| 2s| 6s cmos clock += 10min | | 2 minutes cmos clock += 2 month | 20s | > 4minutes, test interrupted Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] on 2.6.20-rc5-rt10
Am Dienstag, 30. Januar 2007 15:30 schrieb Remy Bohmer: > Hello All, > > Once in a while we see the following stacktrace. > We do not know yet the exact condition that generates this, but is > there anyone that recognises this oops? > > Kind Regards, > > Remy Bohmer > > > Jan 30 14:09:20 localhost kernel: BUG: unable to handle kernel paging > request at virtual address 2e3277e5 > Jan 30 14:09:20 localhost kernel: printing eip: > Jan 30 14:09:20 localhost kernel: c0140214 > Jan 30 14:09:20 localhost kernel: *pde = > Jan 30 14:09:20 localhost kernel: stopped custom tracer. > Jan 30 14:09:20 localhost kernel: Oops: 0002 [#1] > Jan 30 14:09:20 localhost kernel: PREEMPT SMP > Jan 30 14:09:20 localhost kernel: Modules linked in: cap_over > commoncap i2c_dev uhci_hcd i2c_i801 i2c_core ehci_hcd > Jan 30 14:09:20 localhost kernel: CPU:0 > Jan 30 14:09:20 localhost kernel: EIP:0060:[]Not tainted VLI > Jan 30 14:09:20 localhost kernel: EFLAGS: 00010246 (2.6.20-rc5-rt10 #1) > Jan 30 14:09:20 localhost kernel: EIP is at module_put+0x24/0x60 > Jan 30 14:09:20 localhost kernel: eax: 2e3277e5 ebx: f774da00 ecx: > c1df40a0 edx: 2e327665 > Jan 30 14:09:20 localhost kernel: esi: f6e93af0 edi: 2e327665 ebp: > f4a1bf40 esp: f4a1bf40 > Jan 30 14:09:20 localhost kernel: ds: 007b es: 007b ss: 0068 > preempt: 0002 > Jan 30 14:09:20 localhost kernel: Process udevd (pid: 11594, > ti=f4a1a000 task=f6014710 task.ti=f4a1a000) > Jan 30 14:09:20 localhost kernel: Stack: f4a1bf54 c01a360e 0010 > f5882ac0 f7e3f9c4 f4a1bf78 c01684f1 > Jan 30 14:09:20 localhost kernel: f43d5c14 f7dc3c40 > f5882ac0 c1f60680 f4a1bf80 c0168629 > Jan 30 14:09:20 localhost kernel:f4a1bf98 c01656f7 f4a1bfb0 > c1f60680 c1f60700 0003 f4a1bfb0 c01669d9 > Jan 30 14:09:20 localhost kernel: Call Trace: > Jan 30 14:09:20 localhost kernel: [] show_trace_log_lvl+0x1a/0x30 > Jan 30 14:09:20 localhost kernel: [] show_stack_log_lvl+0xbb/0x100 > Jan 30 14:09:20 localhost kernel: [] show_registers+0x1e0/0x300 > Jan 30 14:09:20 localhost kernel: [] die+0x125/0x250 > Jan 30 14:09:20 localhost kernel: [] do_page_fault+0x145/0x610 > Jan 30 14:09:20 localhost kernel: [] error_code+0x7c/0x84 > Jan 30 14:09:20 localhost kernel: [] sysfs_release+0x3e/0x70 > Jan 30 14:09:20 localhost kernel: [] __fput+0xa1/0x170 > Jan 30 14:09:20 localhost kernel: [] fput+0x19/0x20 > Jan 30 14:09:20 localhost kernel: [] filp_close+0x47/0x70 > Jan 30 14:09:20 localhost kernel: [] sys_close+0x69/0xc0 > Jan 30 14:09:20 localhost kernel: [] sysenter_past_esp+0x5f/0x85 > Jan 30 14:09:20 localhost kernel: === > Jan 30 14:09:20 localhost kernel: Code: 00 8d bf 00 00 00 00 55 85 c0 > 89 e5 89 c2 74 34 89 e0 25 00 e0 ff ff 83 40 14 01 65 a1 04 00 00 00 > c1 e0 07 8d 84 10 80 01 00 00 08 83 3a 02 74 1b 89 e0 25 00 e0 ff > ff 83 68 14 01 8b 40 08 > Jan 30 14:09:20 localhost kernel: EIP: [] > module_put+0x24/0x60 SS:ESP 0068:f4a1bf40 I think I saw similar oopses. Cause was a driver having freed some kmalloced struct _before_ sysfs_release had given its ok. Happened on physical device removal or rmmod here. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc6-mm2
Hi,
with dynticks and highres_timers enabled, cpufreq_ondemand makes mess here on
an AMD64 UP.
cpufreq_ondemand assumes that jiffies advance at exactly the same pace as the
sum of all kstat_cpu(cpu).cpustat.* members.
This isn't the case here as dmesg output from patch below shows.
Is cpufreq_ondemand correct assuming
"jiffies advance at exactly the same pace as the
sum of all kstat_cpu(cpu).cpustat.* members"?
Or is "dynticks and highres_timers"'s behaviour of incrementing the
sum of kstat_cpu(cpu).cpustat.* members faster than jiffies?
Karsten
diff -pur rc6-mm2/drivers/cpufreq/cpufreq_ondemand.c
rc6-mm2-kw/drivers/cpufreq/cpufreq_ondemand.c
--- rc6-mm2/drivers/cpufreq/cpufreq_ondemand.c 2007-01-29 10:40:39.0
+0100
+++ rc6-mm2-kw/drivers/cpufreq/cpufreq_ondemand.c 2007-01-29
11:37:08.0 +0100
@@ -370,7 +370,15 @@ static void dbs_check_cpu(struct cpu_dbs
if (tmp_idle_ticks < idle_ticks)
idle_ticks = tmp_idle_ticks;
}
- load = (100 * (total_ticks - idle_ticks)) / total_ticks;
+ if (total_ticks < idle_ticks) {
+ static bool did;
+ if (!did) {
+ printk(KERN_INFO"%s: t%u < i%u\n", __FUNCTION__,
total_ticks, idle_ticks);
+ did = true;
+ }
+ load = 0;
+ } else
+ load = (100 * (total_ticks - idle_ticks)) / total_ticks;
/* Check for frequency increase */
if (load > dbs_tuners_ins.up_threshold) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt] high_res_timers: precisely update_process_times; Take2
With NO_HZ or HIGH_RES_TIMERS update_process_times() can be called,
when jiffies increments != 1 have to be acounted for.
Cope with these situations by splitting update_process_times() into
__update_process_times() and tick().
New in Take 2 is an attempt to make patch work for SMP also.
This is done by adding
unsigned long update_process_times_jiffies;
to per cpu struct tick_sched.
update_process_times_jiffies is set whenever an unseen yet jiffies value
is seen by a particular cpu after calls to tick_do_update_jiffies64().
Fixes cpufreq_ondemand going nuts here on an AMD64 UP running 2.6.20-rc6-rt2.
Does it work on SMP? (don't have any)
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
diff -pur rc6-rt2/include/linux/sched.h rc6-rt2-kw/include/linux/sched.h
--- rc6-rt2/include/linux/sched.h 2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/include/linux/sched.h2007-01-28 02:02:29.0 +0100
@@ -264,6 +264,13 @@ long io_schedule_timeout(long timeout);
extern void cpu_init (void);
extern void trap_init(void);
extern void update_process_times(int user);
+#ifdef CONFIG_HIGH_RES_TIMERS
+extern void __update_process_times(int user_tick, unsigned long ticks);
+extern void tick(int user_tick);
+#define NO_HIGH_RES_TIMERS_STATIC
+#else
+#define NO_HIGH_RES_TIMERS_STATIC static
+#endif
extern void scheduler_tick(void);
#ifdef CONFIG_GENERIC_HARDIRQS
Nur in rc6-rt2-kw/include/linux: sched.h~.
diff -pur rc6-rt2/include/linux/tick.h rc6-rt2-kw/include/linux/tick.h
--- rc6-rt2/include/linux/tick.h2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/include/linux/tick.h 2007-01-28 16:19:40.0 +0100
@@ -56,6 +56,7 @@ struct tick_sched {
unsigned long last_jiffies;
unsigned long next_jiffies;
ktime_t idle_expires;
+ unsigned long update_process_times_jiffies;
};
extern void __init tick_init(void);
diff -pur rc6-rt2/kernel/time/tick-common.c rc6-rt2-kw/kernel/time/tick-common.c
--- rc6-rt2/kernel/time/tick-common.c 2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/kernel/time/tick-common.c2007-01-28 16:20:00.0
+0100
@@ -57,6 +57,8 @@ int tick_is_oneshot_available(void)
*/
static void tick_periodic(int cpu)
{
+ struct tick_sched *ts = tick_get_tick_sched(smp_processor_id());
+
if (tick_do_timer_cpu == cpu) {
write_seqlock(&xtime_lock);
@@ -67,6 +69,8 @@ static void tick_periodic(int cpu)
write_sequnlock(&xtime_lock);
}
+ ts->update_process_times_jiffies = jiffies;
+
update_process_times(user_mode(get_irq_regs()));
// profile_tick(CPU_PROFILING);
}
Nur in rc6-rt2-kw/kernel/time: tick-common.c~.
diff -pur rc6-rt2/kernel/time/tick-sched.c rc6-rt2-kw/kernel/time/tick-sched.c
--- rc6-rt2/kernel/time/tick-sched.c2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/kernel/time/tick-sched.c 2007-01-28 17:21:34.0 +0100
@@ -148,6 +148,7 @@ void tick_nohz_update_jiffies(void)
local_irq_save(flags);
tick_do_update_jiffies64(now);
+ ts->update_process_times_jiffies = jiffies;
local_irq_restore(flags);
}
@@ -237,6 +238,7 @@ void tick_nohz_stop_sched_tick(void)
* softirq.
*/
tick_do_update_jiffies64(ktime_get());
+ ts->update_process_times_jiffies = jiffies;
}
raise_softirq_irqoff(TIMER_SOFTIRQ);
out:
@@ -265,6 +267,7 @@ void tick_nohz_restart_sched_tick(void)
local_irq_disable();
tick_do_update_jiffies64(now);
+ ts->update_process_times_jiffies = jiffies;
/* Account the idle time */
delta = ktime_sub(now, ts->idle_entrytime);
@@ -310,6 +313,7 @@ void tick_nohz_restart_sched_tick(void)
}
/* Update jiffies and reread time */
tick_do_update_jiffies64(now);
+ ts->update_process_times_jiffies = jiffies;
now = ktime_get();
}
local_irq_enable();
@@ -329,27 +333,36 @@ static void tick_nohz_handler(struct clo
struct tick_sched *ts = &__get_cpu_var(tick_cpu_sched);
struct pt_regs *regs = get_irq_regs();
ktime_t now = ktime_get();
-
+ unsigned long ticks;
+ unsigned long jiffies_now;
dev->next_event.tv64 = KTIME_MAX;
/* Check, if the jiffies need an update */
tick_do_update_jiffies64(now);
- /*
-* When we are idle and the tick is stopped, we have to touch
-* the watchdog as we might not schedule for a really long
-* time. This happens on complete idle SMP systems while
-* waiting on the login prompt. We also increment the "start
-* of idle" jiffy stamp so the idle accounting adjustment we
-* do when we go busy again does not account to
[PATCH] high_res_timers: precisely update_process_times; Re: [patch 36/46] tick-management: dyntick / highres functionality
Am Dienstag, 23. Januar 2007 23:01 schrieb Thomas Gleixner:
>
> Add functions to provide dynamic ticks and high resolution timers.
> The code which keeps track of jiffies and handles the long idle
> periods is shared between tick based and high resolution timer based
> dynticks. The dyntick functionality can be disabled on the kernel
> commandline. Provide also the infrastructure to support high resolution
> timers.
cpufreq_ondemand didn't work here on kernels 2.6.20-rc4-rt1 and above.
Following patch against 20-rc6-rt2 helps.
Karsten
-------
From: Karsten Wiese <[EMAIL PROTECTED]>
high_res_timers: precisely update_process_times
Sometimes tick_sched_timer() calls tick_do_update_jiffies64() and
jiffies is updated by !=1.
Cope with these situations by splitting update_process_times() into
__update_process_times() and tick() and
exchanging call to update_process_times() from tick_sched_timer()
by calls to the splits.
Fixes cpufreq_ondemand going nuts here.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rc6-rt2/include/linux/sched.h 2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/include/linux/sched.h2007-01-28 02:02:29.0 +0100
@@ -264,6 +264,13 @@ long io_schedule_timeout(long timeout);
extern void cpu_init (void);
extern void trap_init(void);
extern void update_process_times(int user);
+#ifdef CONFIG_HIGH_RES_TIMERS
+extern void __update_process_times(int user_tick, unsigned long ticks);
+extern void tick(int user_tick);
+#define NO_HIGH_RES_TIMERS_STATIC
+#else
+#define NO_HIGH_RES_TIMERS_STATIC static
+#endif
extern void scheduler_tick(void);
#ifdef CONFIG_GENERIC_HARDIRQS
diff -pur rc6-rt2/kernel/time/tick-sched.c rc6-rt2-kw/kernel/time/tick-sched.c
--- rc6-rt2/kernel/time/tick-sched.c2007-01-26 14:42:55.0 +0100
+++ rc6-rt2-kw/kernel/time/tick-sched.c 2007-01-28 01:45:14.0 +0100
@@ -41,9 +41,9 @@ struct tick_sched *tick_get_tick_sched(i
/*
* Must be called with interrupts disabled !
*/
-static void tick_do_update_jiffies64(ktime_t now)
+static unsigned long tick_do_update_jiffies64(ktime_t now)
{
- unsigned long ticks = 1;
+ unsigned long ticks = 0;
ktime_t delta;
/* Reevalute with xtime_lock held */
@@ -51,7 +51,7 @@ static void tick_do_update_jiffies64(kti
delta = ktime_sub(now, last_jiffies_update);
if (delta.tv64 >= tick_period.tv64) {
-
+ ticks = 1;
delta = ktime_sub(delta, tick_period);
last_jiffies_update = ktime_add(last_jiffies_update,
tick_period);
@@ -68,6 +68,7 @@ static void tick_do_update_jiffies64(kti
do_timer(ticks);
}
write_sequnlock(&xtime_lock);
+ return ticks;
}
/*
@@ -423,32 +424,36 @@ static enum hrtimer_restart tick_sched_t
ktime_t now = ktime_get();
/* Check, if the jiffies need an update */
- tick_do_update_jiffies64(now);
+ unsigned long ticks = tick_do_update_jiffies64(now);
/*
* Do not call, when we are not in irq context and have
* no valid regs pointer
*/
if (regs) {
- /*
-* When we are idle and the tick is stopped, we have to touch
-* the watchdog as we might not schedule for a really long
-* time. This happens on complete idle SMP systems while
-* waiting on the login prompt. We also increment the "start of
-* idle" jiffy stamp so the idle accounting adjustment we do
-* when we go busy again does not account too much ticks.
-*/
- if (ts->tick_stopped) {
- touch_softlockup_watchdog();
- ts->idle_jiffies++;
+ if (ticks) {
+ /*
+* When we are idle and the tick is stopped, we have to
touch
+* the watchdog as we might not schedule for a really
long
+* time. This happens on complete idle SMP systems while
+* waiting on the login prompt. We also increment the
"start of
+* idle" jiffy stamp so the idle accounting adjustment
we do
+* when we go busy again does not account too much
ticks.
+*/
+ if (ts->tick_stopped) {
+ touch_softlockup_watchdog();
+ ts->idle_jiffies++;
+ __update_process_times(user_mode(regs), 1);
+ } else
+ __update_process_times(user_mode(regs), ticks);
}
/*
-* update_process_times() might take t
Re: 2.6.20-rc6-rt2 compile error on x86 -- undefined reference to `send_IPI_mask_bitmask'
Am Samstag, 27. Januar 2007 12:28 schrieb Frieder Bürzele: > Hi, > > I got the follow while trying to compile 2.6.20-rc6-rt2 > .config attached > > Greetz Frieder > > please CC me > > > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > GZIPkernel/config_data.gz > IKCFG kernel/config_data.h > CC kernel/configs.o > LD kernel/built-in.o > GEN .version > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > arch/i386/kernel/built-in.o: In function > `lapic_timer_broadcast':apic.c:(.text+0xccc8): undefined reference to > `send_IPI_mask_bitmask' > make: *** [.tmp_vmlinux1] Error 1 Enabling CONFIG_SMP works around that. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Immediately update integer and string values in xconfig display
In xconfig's display integer and string values are also shown as part of
the config item's descriptive text.
This patch updates the descriptive text, when the corresponding
value has been changed.
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7744
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rc1/scripts/kconfig/qconf.cc2006-12-23 21:35:12.0 +0100
+++ rc1-rt6-kw/scripts/kconfig/qconf.cc 2006-12-26 18:51:51.0 +0100
@@ -89,6 +89,8 @@ void ConfigItem::okRename(int col)
{
Parent::okRename(col);
sym_set_string_value(menu->sym, text(dataColIdx).latin1());
+ sym_calc_value(menu->sym);
+ updateMenu();
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] kconfig: Only activate UI save widgets when .config changed; Take 3
Am Sonntag, 10. Dezember 2006 09:10 schrieb Andrew Morton: > > So I'm pretending to be kbuild maintainer and I now realise I simply don't > know what this patch series does. > > Can you please explain it a lot more? lets "make xconfig" on a freshly untarred kernel-tree. look at the floppy disk icon of the qt application, that has just started: Its in a normal, active state. Mouse click on it: .config is being saved. Now in the current -mm head version, you'll notice something new: after the mouse click on the floppy disk icon, the icon is greyed out. If you mouse click on it now, nothing happens, which is ok IMHO, as nothing has changed. If you change some CONFIG_*, the floppy disk icon returns to "active state", that is, if you mouse click it now, .config is written. The "icon greying out" aka "save widget de/activation" is done by this patch series. Its done for the save-icons and the file-save menu entries of the applications launched after "make xconfig" or "make gconfig" is called. Purpose is: "let the (gtk/qt kernel configuration) application show me if there are unsaved changes to the .config, so there's 1 thing less I might wonder about" more? Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi()
Am Donnerstag, 7. Dezember 2006 03:28 schrieb Sergio Monteiro Basto: > On Wed, 2006-12-06 at 23:30 +0100, Ingo Molnar wrote: > > Subject: [patch] ACPI, i686, x86_64: fix laptop bootup hang in init_acpi() > > From: Ingo Molnar <[EMAIL PROTECTED]> > Hi Ingo, > Just curiosity ,have we this patch on 2.6.19-1.rt6 ? No, its in rt7. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt 3/3] Make trace_freerunning work; Take 2: change reset_trace_idx()
Move atomic_set(&tr->underrun, 0) and atomic_set(&tr->overrun, 0)
occurrences into reset_trace_idx().
Note this leads to under/overrun being reset more often than before:
- in the trace_all_cpus case.
- from under check_critical_timing()
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rt6-kw/kernel/latency_trace-tk2.2.c 2006-12-06 14:58:44.0 +0100
+++ rt6-kw/kernel/latency_trace.c 2006-12-06 15:37:08.0 +0100
@@ -1695,10 +1695,17 @@ __setup("preempt_thresh=", setup_preempt
static inline void notrace reset_trace_idx(int cpu, struct cpu_trace *tr)
{
if (trace_all_cpus)
- for_each_online_cpu(cpu)
- cpu_traces[cpu].trace_idx = 0;
- else
+ for_each_online_cpu(cpu) {
+ tr = cpu_traces + cpu;
+ tr->trace_idx = 0;
+ atomic_set(&tr->underrun, 0);
+ atomic_set(&tr->overrun, 0);
+ }
+ else{
tr->trace_idx = 0;
+ atomic_set(&tr->underrun, 0);
+ atomic_set(&tr->overrun, 0);
+ }
}
#ifdef CONFIG_CRITICAL_TIMING
@@ -1842,8 +1849,6 @@ __start_critical_timing(unsigned long ei
tr->critical_sequence = max_sequence;
tr->preempt_timestamp = get_monotonic_cycles();
tr->critical_start = eip;
- atomic_set(&tr->underrun, 0);
- atomic_set(&tr->overrun, 0);
reset_trace_idx(cpu, tr);
tr->latency_type = latency_type;
_trace_cmdline(cpu, tr);
@@ -2221,8 +2226,6 @@ void __trace_start_sched_wakeup(struct t
tr->preempt_timestamp = get_monotonic_cycles();
tr->latency_type = WAKEUP_LATENCY;
tr->critical_start = CALLER_ADDR0;
- atomic_set(&tr->underrun, 0);
- atomic_set(&tr->overrun, 0);
_trace_cmdline(raw_smp_processor_id(), tr);
atomic_dec(&tr->disabled);
// }
@@ -2332,8 +2335,6 @@ long user_trace_start(void)
tr->critical_sequence = max_sequence;
tr->preempt_timestamp = get_monotonic_cycles();
tr->critical_start = CALLER_ADDR0;
- atomic_set(&tr->underrun, 0);
- atomic_set(&tr->overrun, 0);
_trace_cmdline(cpu, tr);
mcount();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt 2/3] Make trace_freerunning work; Take 2: Add atomic_t underrun
Add atomic_t underrun to struct cpu_trace.
Increment it only when trace_freerunning is set and an older trace
entry is overwritten.
Modify copy_trace() to reorder entries, if underrun != 0.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rt6-kw/kernel/latency_trace-tk2.1.c 2006-12-06 14:43:52.0 +0100
+++ rt6-kw/kernel/latency_trace.c 2006-12-06 14:58:44.0 +0100
@@ -228,6 +228,7 @@ struct cpu_trace {
cycle_t preempt_timestamp;
unsigned long critical_start, critical_end;
unsigned long critical_sequence;
+ atomic_t underrun;
atomic_t overrun;
int early_warning;
int latency_type;
@@ -606,16 +607,21 @@ again:
idx_next = idx + 1;
timestamp = now();
- if (unlikely((trace_freerunning || print_functions) &&
- (idx_next >= MAX_TRACE)))
+ if (unlikely((trace_freerunning || print_functions ||
atomic_read(&tr->underrun)) &&
+(idx_next >= MAX_TRACE) && !atomic_read(&tr->overrun))) {
+ atomic_inc(&tr->underrun);
idx_next = 0;
+ }
if (unlikely(idx >= MAX_TRACE)) {
atomic_inc(&tr->overrun);
goto out;
}
#ifdef __HAVE_ARCH_CMPXCHG
- if (unlikely(cmpxchg(&tr->trace_idx, idx, idx_next) != idx))
+ if (unlikely(cmpxchg(&tr->trace_idx, idx, idx_next) != idx)) {
+ if (idx_next == 0)
+ atomic_dec(&tr->underrun);
goto again;
+ }
#else
# ifdef CONFIG_SMP
# error CMPXCHG missing
@@ -626,6 +632,9 @@ again:
tr->trace_idx = idx_next;
# endif
#endif
+ if (unlikely(idx_next != 0 && atomic_read(&tr->underrun)))
+ atomic_inc(&tr->underrun);
+
pc = preempt_count();
if (unlikely(!tr->trace))
@@ -938,13 +947,12 @@ char *pid_to_cmdline(unsigned long pid)
return cmdline;
}
-static void copy_trace(struct cpu_trace *save, struct cpu_trace *tr)
+static void copy_trace(struct cpu_trace *save, struct cpu_trace *tr, int
reorder)
{
if (!save->trace || !tr->trace)
return;
/* free-running needs reordering */
- /* FIXME: what if we just switched back from freerunning mode? */
- if (trace_freerunning) {
+ if (reorder && atomic_read(&tr->underrun)) {
int i, idx, idx0 = tr->trace_idx;
for (i = 0; i < MAX_TRACE; i++) {
@@ -959,6 +967,7 @@ static void copy_trace(struct cpu_trace
min(save->trace_idx, MAX_TRACE) *
sizeof(struct trace_entry));
}
+ save->underrun = tr->underrun;
save->overrun = tr->overrun;
}
@@ -1010,7 +1019,7 @@ static void update_out_trace(void)
cycle_t stamp, first_stamp, last_stamp;
struct block_idx bidx = { { 0, }, };
struct cpu_trace *tmp_max, *tmp_out;
- int cpu, sum, entries, overrun_sum;
+ int cpu, sum, entries, underrun_sum, overrun_sum;
/*
* For out_tr we only have the first array's trace entries
@@ -1023,7 +1032,7 @@ static void update_out_trace(void)
* Easier to copy this way. Note: the trace buffer is private
* to the output buffer, so preserve it:
*/
- copy_trace(tmp_out, tmp_max);
+ copy_trace(tmp_out, tmp_max, 0);
tmp = tmp_out->trace;
*tmp_out = *tmp_max;
tmp_out->trace = tmp;
@@ -1134,12 +1143,15 @@ static void update_out_trace(void)
}
sum = 0;
+ underrun_sum = 0;
overrun_sum = 0;
for_each_online_cpu(cpu) {
sum += max_tr.traces[cpu].trace_idx;
+ underrun_sum += atomic_read(&max_tr.traces[cpu].underrun);
overrun_sum += atomic_read(&max_tr.traces[cpu].overrun);
}
tmp_out->trace_idx = sum;
+ atomic_set(&tmp_out->underrun, underrun_sum);
atomic_set(&tmp_out->overrun, overrun_sum);
}
@@ -1186,7 +1198,7 @@ static void * notrace l_start(struct seq
seq_puts(m,
"\n");
seq_printf(m, " latency: %lu us, #%lu/%lu, CPU#%d | (M:%s
VP:%d, KP:%d, SP:%d HP:%d",
cycles_to_usecs(tr->saved_latency),
- entries, entries + atomic_read(&tr->overrun),
+ entries, entries + atomic_read(&tr->underrun) +
atomic_read(&tr->overrun),
out_tr.cpu,
#if defined(CONFIG_PREEMPT_NONE)
"server",
@@ -1629,11 +1641,11 @@ static void update_max_tr(struct cpu_tra
if (all_cpus) {
[PATCH -rt 0/3] Make trace_freerunning work; Take 2
Am Dienstag, 5. Dezember 2006 23:10 schrieb Ingo Molnar: > > freerunning should behave the same way with regard to latency > measurement. I.e. report_latency() is still needed, and the kernel will > thus do a maximum search over all traces triggered via start/stop. > > the difference is in the recording of the last-largest-latency: > > - with !freerunning, the tracer stops recording after MAX_TRACE entries, > i.e. the "head" of the trace is preserved in the trace buffer. > > - with freerunning, the tracer never stops, it 'wraps around' after > MAX_TRACE entries and starts overwriting the oldest entries. I.e. the > "tail" of the trace is preserved in the trace buffer. > > depending on the situation, freerunning or !freerunning might be the > more useful mode. > > but there should be no difference in measurement. Following 3 patches try to implement the above. Tested on a UP only after this incantation: echo 0 > /proc/sys/kernel/wakeup_timing echo 1 > /proc/sys/kernel/trace_enabled echo 1 > /proc/sys/kernel/trace_user_triggered and for half of tests: echo 1 > /proc/sys/kernel/trace_freerunning or echo 0 > /proc/sys/kernel/trace_freerunning . Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -rt 1/3] Make trace_freerunning work; Take 2: Off by 1 tweaks
Needed to make last trace entry appear when trace_freerunning is 1.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- rt6/kernel/latency_trace.c 2006-12-06 00:36:49.0 +0100
+++ rt6-kw/kernel/latency_trace.c 2006-12-06 14:43:52.0 +0100
@@ -181,7 +181,7 @@ static int report_latency(cycle_t delta)
/*
* Number of per-CPU trace entries:
*/
-#define MAX_TRACE (131072UL-1)
+#define MAX_TRACE 131072UL
#define CMDLINE_BYTES 16
@@ -609,7 +609,7 @@ again:
if (unlikely((trace_freerunning || print_functions) &&
(idx_next >= MAX_TRACE)))
idx_next = 0;
- if (unlikely(idx_next >= MAX_TRACE)) {
+ if (unlikely(idx >= MAX_TRACE)) {
atomic_inc(&tr->overrun);
goto out;
}
@@ -899,7 +899,7 @@ static void construct_pid_to_cmdline(str
if (!tr->trace)
return;
- entries = min(tr->trace_idx, MAX_TRACE-1);
+ entries = min(tr->trace_idx, MAX_TRACE);
for (i = 0; i < entries; i++) {
struct trace_entry *entry = tr->trace + i;
@@ -951,12 +951,12 @@ static void copy_trace(struct cpu_trace
idx = (idx0 + i) % MAX_TRACE;
save->trace[i] = tr->trace[idx];
}
- save->trace_idx = MAX_TRACE-1;
+ save->trace_idx = MAX_TRACE;
} else {
save->trace_idx = tr->trace_idx;
memcpy(save->trace, tr->trace,
- min(save->trace_idx + 1, MAX_TRACE-1) *
+ min(save->trace_idx, MAX_TRACE) *
sizeof(struct trace_entry));
}
save->overrun = tr->overrun;
@@ -979,7 +979,7 @@ static int min_idx(struct block_idx *bid
for_each_online_cpu(cpu) {
idx = bidx->idx[cpu];
- if (idx >= min(max_tr.traces[cpu].trace_idx, MAX_TRACE-1))
+ if (idx >= min(max_tr.traces[cpu].trace_idx, MAX_TRACE))
continue;
if (idx >= MAX_TRACE*NR_CPUS) {
printk("huh: idx (%d) > %ld*%d!\n", idx, MAX_TRACE,
NR_CPUS);
@@ -1036,7 +1036,7 @@ static void update_out_trace(void)
out_entry = tmp_out->trace + 0;
if (!trace_all_cpus) {
- entries = min(tmp_out->trace_idx, MAX_TRACE-1);
+ entries = min(tmp_out->trace_idx, MAX_TRACE);
if (!entries)
return;
out_tr.first_timestamp = tmp_out->trace[0].timestamp;
@@ -1059,7 +1059,7 @@ static void update_out_trace(void)
* Save the timestamp range:
*/
tmp_max = max_tr.traces + max_tr.cpu;
- entries = min(tmp_max->trace_idx, MAX_TRACE-1);
+ entries = min(tmp_max->trace_idx, MAX_TRACE);
/*
* No saved trace yet?
*/
@@ -1075,7 +1075,7 @@ static void update_out_trace(void)
for_each_online_cpu(cpu) {
tmp_max = max_tr.traces + cpu;
- entries = min(tmp_max->trace_idx, MAX_TRACE-1);
+ entries = min(tmp_max->trace_idx, MAX_TRACE);
printk("CPU%d: %016Lx (%016Lx) ... #%d (%016Lx)
%016Lx\n", cpu,
tmp_max->trace[0].timestamp,
tmp_max->trace[1].timestamp,
@@ -1084,7 +1084,7 @@ static void update_out_trace(void)
tmp_max->trace[entries-1].timestamp);
}
tmp_max = max_tr.traces + max_tr.cpu;
- entries = min(tmp_max->trace_idx, MAX_TRACE-1);
+ entries = min(tmp_max->trace_idx, MAX_TRACE);
printk("CPU%d entries: %d\n", max_tr.cpu, entries);
printk("first stamp: %016Lx\n", first_stamp);
@@ -1179,7 +1179,7 @@ static void * notrace l_start(struct seq
#endif
construct_pid_to_cmdline(tr);
}
- entries = min(tr->trace_idx, MAX_TRACE-1);
+ entries = min(tr->trace_idx, MAX_TRACE);
if (!n) {
seq_printf(m, "preemption latency trace v1.1.5 on %s\n",
UTS_RELEASE);
@@ -1241,7 +1241,7 @@ static void * notrace l_start(struct seq
static void * notrace l_next(struct seq_file *m, void *p, loff_t *pos)
{
struct cpu_trace *tr = out_tr.traces;
- unsigned long entries = min(tr->trace_idx, MAX_TRACE-1);
+ unsigned long entries = min(tr->trace_idx, MAX_TRACE);
WARN_ON(!tr->trace);
@@ -2431,8 +2431,7 @@ void notrace stop_trace(void)
EXPORT_SYMBOL(stop_trace);
-static void print_entry(struct trace_entry *entry, struct trace_entry *entry0,
- struct trace_entry *next_e
Re: v2.6.19-rt1, yum/rpm
Am Dienstag, 5. Dezember 2006 01:19 schrieb Karsten Wiese: > Am Donnerstag, 30. November 2006 09:33 schrieb Ingo Molnar: > > i have released the 2.6.19-rt1 tree, which can be downloaded from the > > Hi Ingo, > > here comes a freerunning trace explaining the weirdness I see here. > I tried max_latency tracing first, didn't see anything usefull, > went on with tracing freerunning with a user_trace_stop() at the spot, > where snd-usb-usx2y diagnoses hickup. Seams to hickup when irq happens while uhci_hcd is busy doing some kind of timer triggered housekeeping. Will look into uhci code deeper ;-) Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v2.6.19-rt1, yum/rpm
Am Donnerstag, 30. November 2006 09:33 schrieb Ingo Molnar:
> i have released the 2.6.19-rt1 tree, which can be downloaded from the
Hi Ingo,
here comes a freerunning trace explaining the weirdness I see here.
I tried max_latency tracing first, didn't see anything usefull,
went on with tracing freerunning with a user_trace_stop() at the spot,
where snd-usb-usx2y diagnoses hickup.
I tweaked latency_trace.c to make freerunning work. Will post later.
To get an overview of whats happening, search in this e-mail for
i_usX2Y_usbpcm_urb_complete
. Its the interrupt callback.
Those were the rt priorities with IRQ 17 driving the usb soundcard:
$ ps -ALc|grep FF
2 2 FF 90 ?00:00:00 posix_cpu_timer
3 3 FF 41 ?00:00:00 softirq-high/0
4 4 FF 41 ?00:00:00 softirq-timer/0
5 5 FF 41 ?00:00:00 softirq-net-tx/
6 6 FF 41 ?00:00:00 softirq-net-rx/
7 7 FF 41 ?00:00:00 softirq-block/0
8 8 FF 41 ?00:00:06 softirq-tasklet
9 9 FF 41 ?00:00:00 softirq-hrtimer
1010 FF 41 ?00:00:00 softirq-rcu/0
1111 FF 139 ?00:00:00 watchdog/0
1313 FF 41 ?00:00:00 events/0
5050 FF 89 ?00:00:00 IRQ 9
242 242 FF 88 ?00:00:00 IRQ 8
273 273 FF 87 ?00:00:00 IRQ 14
275 275 FF 86 ?00:00:00 IRQ 15
295 295 FF 85 ?00:00:00 IRQ 12
296 296 FF 84 ?00:00:00 IRQ 1
308 308 FF 120 ?00:00:30 IRQ 17
735 735 FF 110 ?00:00:00 IRQ 19
1329 1329 FF 81 ?00:00:00 IRQ 6
1338 1338 FF 80 ?00:00:00 IRQ 7
1684 1684 FF 110 ?00:00:06 IRQ 18
2198 2198 FF 78 ?00:00:00 IRQ 4
2667 2672 FF 49 pts/000:00:00 ardour.bin
2700 2700 FF 90 ?00:00:00 artsd
$ cat /proc/interrupts
CPU0
0:1477957 IO-APIC[N/ 0]-edge timer
1: 7560 IO-APIC[...M./ 0]-edge i8042
4: 12 IO-APIC[...M./ 3]-edge serial
7: 0 IO-APIC[..PM./ 0]-edge parport0
8: 1 IO-APIC[./ 0]-edge rtc
9: 0 IO-APIC[./ 0]-fasteoi acpi
12: 62839 IO-APIC[...M./ 0]-edge i8042
14: 22303 IO-APIC[...M./ 0]-edge ide0
15: 10169 IO-APIC[...M./ 0]-edge ide1
17: 967826 IO-APIC[./ 0]-fasteoi uhci_hcd:usb1,
uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, ehci_hcd:usb5
18: 247356 IO-APIC[./ 1]-fasteoi eth0, nvidia
19:979 IO-APIC[./ 0]-fasteoi VIA8237
NMI: 0
LOC:834
ERR: 0
MIS: 0
Edited Trace, first part showing normal operation,
second part showing things getting weired:
preemption latency trace v1.1.5 on 2.6.19-rt1.dbg
latency: 491583660 us, #131071/131071, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1)
-
| task: IRQ 17-308 (uid:0 nice:-5 policy:1 rt_prio:80)
-
=> started at: snd_usX2Y_pcm_trigger+0x30/0xf4
=> ended at: __schedule+0x680/0x70e
_--=> CPU#
/ _-=> irqs-off
| / _=> need-resched
|| / _---=> hardirq/softirq
||| / _--=> preempt-depth
/
| delay
cmd pid | time | caller
\ /| \ | /
qjackctl-2668 0D...0us < (0)
qjackctl-2668 00us > sys_gettimeofday (b7212324 007b)
qjackctl-2668 0D...2us < (0)
qjackctl-2668 02us > sys_write (0010 b721338a 007b)
qjackctl-2668 04us : try_to_wake_up (c011b4ab 0 0)
qjackctl-2668 0D..15us : __activate_task (172 1)
qjackctl-2668 0D...6us < (1)
qjackctl-2668 06us+> sys_read (000f b721338a 007b)
qjackctl-2668 0D...9us < (1)
qjackctl-2668 0 10us+> sys_poll (0823dea8 0002 007b)
qjackctl-2668 0...1 12us : __schedule (c032a995 0 0)
qjackctl-2668 0D..2 13us : deactivate_task (172 2)
ardour.b-2675 0D..2 14us+: __schedule (172 172)
ardour.b-2675 0D... 17us < (1)
ardour.b-2675 0 18us > sys_gettimeofday (b01fe324 007b)
ardour.b-2675 0D... 20us!< (0)
ardour.b-2675 0D.h. 178us+: do_IRQ (b6281a8a 0 0)
ardour.b-2675 0D.h1 185us : hrtimer_interrupt (d2f6b90d72 eccc1f4c)
ardour.b-2675 0D.h1 185us : try_to_wake_up (c011b58b 0 0)
ardour.b-2675 0D.h2 186us : effective_prio (-5 -5)
ardour.b-2675 0D.h2 187us!: __activate_task (-5 1)
ardour.b-2675 0D.h. 576us : do_IRQ (b61ead92 18 0)
ardour.b-2675 0D.h1 576us : try_to_wake_up (c011b58b 0 0)
ardour.b-2675 0D.h2 577us!: __activate_ta
Re: 2.6.19-rc6-rt8
Am Mittwoch, 29. November 2006 08:06 schrieb Ingo Molnar: > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > After estimated 15 minutes more it bugged again. > > Related dmesg translates to linux error > > -EXDEV > > propably caused by the following lines: > > > > > > static int uhci_result_isochronous(struct uhci_hcd *uhci, struct > > urb *urb) > > hm. Below are all the USB changes done by -rt. Maybe one of them has > some side-effect? On rc6-rt5 rt-audio with usb-sound runs just fine so far, and I didn't find any USB changes between rc6-rt5 and rc6-rt8. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt8
Am Dienstag, 28. November 2006 23:40 schrieb Karsten Wiese:
> Am Montag, 27. November 2006 10:49 schrieb Ingo Molnar:
> > i have released the 2.6.19-rc6-rt8 tree, which can be downloaded from
>
> I saw usb transport errors here before rebooting with
> nmi_watchdog=0
> contained in kernel command line.
>
> Testcase stalled within 2 minutes before change,
> ticks happily after change for 15 minutes now.
> .config is a "release" type, no debugging options.
After estimated 15 minutes more it bugged again.
Related dmesg translates to linux error
-EXDEV
propably caused by the following lines:
static int uhci_result_isochronous(struct uhci_hcd *uhci, struct urb *urb)
{
struct uhci_td *td, *tmp;
struct urb_priv *urbp = urb->hcpriv;
struct uhci_qh *qh = urbp->qh;
list_for_each_entry_safe(td, tmp, &urbp->td_list, list) {
unsigned int ctrlstat;
int status;
int actlength;
if (uhci_frame_before_eq(uhci->cur_iso_frame, qh->iso_frame))
return -EINPROGRESS;
uhci_remove_tds_from_frame(uhci, qh->iso_frame);
ctrlstat = td_status(td);
if (ctrlstat & TD_CTRL_ACTIVE) {
status = -EXDEV;/* TD was added too late? */
Karsten
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt8
Am Montag, 27. November 2006 10:49 schrieb Ingo Molnar: > i have released the 2.6.19-rc6-rt8 tree, which can be downloaded from I saw usb transport errors here before rebooting with nmi_watchdog=0 contained in kernel command line. Testcase stalled within 2 minutes before change, ticks happily after change for 15 minutes now. .config is a "release" type, no debugging options. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt5
> i've released the 2.6.19-rc6-rt5 tree, which can be downloaded from the Hi this fixes issues like rmmod hanging and inodes leaking. Karsten --- fs/dcache.c~2006-11-21 11:25:11.0 +0100 +++ fs/dcache.c 2006-11-26 15:20:31.0 +0100 @@ -150,7 +150,7 @@ void dput(struct dentry *dentry) repeat: if (atomic_read(&dentry->d_count) == 1) might_sleep(); - if (atomic_dec_and_test(&dentry->d_count)) + if (!atomic_dec_and_test(&dentry->d_count)) return; spin_lock(&dentry->d_lock); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt4, changed yum repository
Am Sonntag, 19. November 2006 14:43 schrieb Ingo Molnar: > > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > > work_resched: > > DISABLE_INTERRUPTS > > call __schedule > > # make sure we don't miss an interrupt > > # setting need_resched or sigpending > > # between sampling and the iret > > movl TI_flags(%ebp), %ecx > > andl $_TIF_WORK_MASK, %ecx # is there any work to be done other > > # than syscall tracing? > > jz restore_all > > testl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED), %ecx > > jnz work_resched > > > > The hwclock page_fault happens at the > > movl TI_flags(%ebp), %ecx > > line. > > hm, weird - maybe something corrupts %ebp here? Could you try to add > this to before the faulting instruction: > > GET_THREAD_INFO(%ebp) > > this will make sure %ebp has the right contents. Doesn't make a difference: clock is still set an hour early during boot occasionally. An hour offset I also get when I comment out the hwclock call in rc.sysinit. The Sysrq+T output with GET_THREAD_INFO(%ebp) has: === hwclock R [f7f76550] C1B07224 [on rq #0] 0 329304 (NOTLB) f7f6efb4 3086 c1907434 c1b07224 c1907434 c02d320f 0001 f7f7667c f7f76550 ad91991e 0008 001349cd c02ef1fe 0004 d1292e17 000cc113 f7f6e000 c0102f22 000cc113 Call Trace: [] do_page_fault+0x2b9/0x552 [] work_resched+0x6/0x20 === The [] work_resched+0x6/0x20 corresponds to mov$0xf000,%ebp in: (gdb) disassemble work_resched Dump of assembler code for function work_resched: 0x01c0 :cli 0x01c1 :call 0x1c2 0x01c6 :mov$0xf000,%ebp 0x01cb : and%esp,%ebp 0x01cd : mov0x8(%ebp),%ecx 0x01d0 : and$0xfe3e,%ecx 0x01d6 : je 0x16a 0x01d8 : test $0x80008,%ecx 0x01de : jne0x1c0 End of assembler dump. But "mov$0xf000,%ebp" can't cause a pagefault. So either the Sysrq+T output is wrong or the actual page_fault happens inside the "call __schedule" with __schedule missing from the Call Trace. Your yum-repo kernel seams to stay clear of above problem. Obvious differences to my .config are SMP <> UP and M686+X86_GENERIC <> MK8. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19-rc6-rt4, changed yum repository
Hi, Boot bugs happening here on fc6 running locally compiled 2.6.19-rc-rt UP i386 kernels on a K8. They happen on some boots, some are ok. If bug happens, boot seams to stop after the "for interactive setup , press 'I'" sort of message and continues after I enter control+c. Next message after that is about the time having been set. If bug happened, the time is incorrectly set mostly to 3600s in the future. This is the last part of SysRq+T right after such a bug happened: === init S [f7e6d000] F7EB1F60 0 296 1 297 286 (NOTLB) f7eb1f28 0086 c014928e f7eb1f60 f7fb07b8 c191d6c4 f7eeb1a0 c191d600 0007 f7e6d12c f7e6d000 d4b9b4a7 0007 262b c014a6ab f6867568 00018a21 f7fc1000 0001 f7eb1f88 f7eb1f40 c02ca94b f7feee00 Call Trace: [] do_wp_page+0x34a/0x395 [] __handle_mm_fault+0x7b9/0x7db [] schedule+0xcd/0xe9 [] eligible_child+0x9f/0xb0 [] do_wait+0x9f1/0xacd [] default_wake_function+0x0/0x16 [] sys_wait4+0x31/0x34 [] sys_waitpid+0x27/0x2b [] sysenter_past_esp+0x56/0x79 === rc.sysinitS [f7fc1000] FF889000 0 297296 322 (NOTLB) f7e76f28 0086 c01492cf ff889000 08113fcc f6873860 f7fee600 c17f5760 0006 f7fc112c f7fc1000 dd1e3416 0008 df7d c014a642 f687744c 011543fb f7e7baa0 0001 f7e76f88 f7e76f40 c02ca94b f7fee600 Call Trace: [] do_wp_page+0x38b/0x395 [] __handle_mm_fault+0x750/0x7db [] schedule+0xcd/0xe9 [] eligible_child+0x9f/0xb0 [] do_wait+0x9f1/0xacd [] rt_down+0xe/0x25 [] default_wake_function+0x0/0x16 [] sys_wait4+0x31/0x34 [] sys_waitpid+0x27/0x2b [] sysenter_past_esp+0x56/0x79 === hwclock R [f7e7baa0] F6873224 [on rq #0] 0 322297 (NOTLB) c1902fb4 3086 f7fee434 f6873224 f7fee434 c02cd498 0001 f7e7bbcc f7e7baa0 795f1ab5 000d 003cda22 c02e8fc2 0004 4e8951e9 0002 00240384 c1902000 c0102f22 00240384 Call Trace: [] do_page_fault+0x2b9/0x552 [] work_resched+0x6/0x19 === work_resched sits in entry.S: work_resched: DISABLE_INTERRUPTS call __schedule # make sure we don't miss an interrupt # setting need_resched or sigpending # between sampling and the iret movl TI_flags(%ebp), %ecx andl $_TIF_WORK_MASK, %ecx # is there any work to be done other # than syscall tracing? jz restore_all testl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED), %ecx jnz work_resched The hwclock page_fault happens at the movl TI_flags(%ebp), %ecx line. Will try the yum repo kernel next. Karsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleeping functions called in invalid context during resume
Am Samstag, 18. November 2006 12:43 schrieb Paolo Ornati:
> On Fri, 17 Nov 2006 08:30:08 -0800
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> > > > > APIC error on CPU0: 00(00)
> > > > >
> > > > > Is it an ACPI problem?
> > > >
> > > > a 00 error code? Never seen that ... How frequently does it happen?
> > >
> > > On my x86-64 boxes the "APIC error on CPU0" message appears on every
> > > resume,
> > > but it doesn't seem to be related to any visible problems.
> > >
> > > It's been there forever, AFAICT.
> >
> > Yes, it is there on every resume.
>
> Here too... so it's common on x86_64 ;)
>
>
> $ dmesg | grep Suspending | wc -l
> 9
>
> $ dmesg | grep "APIC err" | wc -l
> 9
>
Could you try the following, as of yet untested patch?
It's i386 twin makes an APIC error vanish here on a K8.
Karsten
---
>From 54248a43231de8d6d64354b51646c54121e3f395 Mon Sep 17 00:00:00 2001
From: Karsten Wiese <[EMAIL PROTECTED]>
Date: Sat, 18 Nov 2006 13:44:14 +0100
Subject: [PATCH 1/1] x86_64: Regard MSRs in lapic_suspend()/lapic_resume()
Read/Write APIC_LVTPC and APIC_LVTTHMR only,
if get_maxlvt() returns certain values.
This is a port to x86_64 from an equaly titled patch against i386.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/apic.c | 25 +
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/x86_64/kernel/apic.c b/arch/x86_64/kernel/apic.c
index 4d9d5ed..16d6755 100644
--- a/arch/x86_64/kernel/apic.c
+++ b/arch/x86_64/kernel/apic.c
@@ -452,23 +452,31 @@ static struct {
static int lapic_suspend(struct sys_device *dev, pm_message_t state)
{
unsigned long flags;
+ int maxlvt;
if (!apic_pm_state.active)
return 0;
+ maxlvt = get_maxlvt();
+
apic_pm_state.apic_id = apic_read(APIC_ID);
apic_pm_state.apic_taskpri = apic_read(APIC_TASKPRI);
apic_pm_state.apic_ldr = apic_read(APIC_LDR);
apic_pm_state.apic_dfr = apic_read(APIC_DFR);
apic_pm_state.apic_spiv = apic_read(APIC_SPIV);
apic_pm_state.apic_lvtt = apic_read(APIC_LVTT);
- apic_pm_state.apic_lvtpc = apic_read(APIC_LVTPC);
+ if (maxlvt >= 4)
+ apic_pm_state.apic_lvtpc = apic_read(APIC_LVTPC);
apic_pm_state.apic_lvt0 = apic_read(APIC_LVT0);
apic_pm_state.apic_lvt1 = apic_read(APIC_LVT1);
apic_pm_state.apic_lvterr = apic_read(APIC_LVTERR);
apic_pm_state.apic_tmict = apic_read(APIC_TMICT);
apic_pm_state.apic_tdcr = apic_read(APIC_TDCR);
- apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
+#ifdef CONFIG_X86_MCE_P4THERMAL
+ if (maxlvt >= 5)
+ apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
+#endif
+
local_irq_save(flags);
disable_local_APIC();
local_irq_restore(flags);
@@ -479,15 +487,20 @@ static int lapic_resume(struct sys_devic
{
unsigned int l, h;
unsigned long flags;
+ int maxlvt;
if (!apic_pm_state.active)
return 0;
+ maxlvt = get_maxlvt();
+
local_irq_save(flags);
+
rdmsr(MSR_IA32_APICBASE, l, h);
l &= ~MSR_IA32_APICBASE_BASE;
l |= MSR_IA32_APICBASE_ENABLE | mp_lapic_addr;
wrmsr(MSR_IA32_APICBASE, l, h);
+
apic_write(APIC_LVTERR, ERROR_APIC_VECTOR | APIC_LVT_MASKED);
apic_write(APIC_ID, apic_pm_state.apic_id);
apic_write(APIC_DFR, apic_pm_state.apic_dfr);
@@ -496,8 +509,12 @@ static int lapic_resume(struct sys_devic
apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
- apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
- apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
+#ifdef CONFIG_X86_MCE_P4THERMAL
+ if (maxlvt >= 5)
+ apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
+#endif
+ if (maxlvt >= 4)
+ apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
apic_write(APIC_TMICT, apic_pm_state.apic_tmict);
--
1.4.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Regard MSRs in lapic_suspend()/lapic_resume()
Read/Write APIC_LVTPC and APIC_LVTTHMR only,
if get_maxlvt() returns certain values.
This is done like everywhere else in i386/kernel/apic.c,
so I guess its correct.
Suspends/Resumes to disk fine and eleminates an smp_error_interrupt()
here on a K8.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
arch/i386/kernel/apic.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/i386/kernel/apic.c b/arch/i386/kernel/apic.c
index 2fd4b7d..776d9be 100644
--- a/arch/i386/kernel/apic.c
+++ b/arch/i386/kernel/apic.c
@@ -647,23 +647,30 @@ static struct {
static int lapic_suspend(struct sys_device *dev, pm_message_t state)
{
unsigned long flags;
+ int maxlvt;
if (!apic_pm_state.active)
return 0;
+ maxlvt = get_maxlvt();
+
apic_pm_state.apic_id = apic_read(APIC_ID);
apic_pm_state.apic_taskpri = apic_read(APIC_TASKPRI);
apic_pm_state.apic_ldr = apic_read(APIC_LDR);
apic_pm_state.apic_dfr = apic_read(APIC_DFR);
apic_pm_state.apic_spiv = apic_read(APIC_SPIV);
apic_pm_state.apic_lvtt = apic_read(APIC_LVTT);
- apic_pm_state.apic_lvtpc = apic_read(APIC_LVTPC);
+ if (maxlvt >= 4)
+ apic_pm_state.apic_lvtpc = apic_read(APIC_LVTPC);
apic_pm_state.apic_lvt0 = apic_read(APIC_LVT0);
apic_pm_state.apic_lvt1 = apic_read(APIC_LVT1);
apic_pm_state.apic_lvterr = apic_read(APIC_LVTERR);
apic_pm_state.apic_tmict = apic_read(APIC_TMICT);
apic_pm_state.apic_tdcr = apic_read(APIC_TDCR);
- apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
+#ifdef CONFIG_X86_MCE_P4THERMAL
+ if (maxlvt >= 5)
+ apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
+#endif
local_irq_save(flags);
disable_local_APIC();
@@ -675,10 +682,13 @@ static int lapic_resume(struct sys_devic
{
unsigned int l, h;
unsigned long flags;
+ int maxlvt;
if (!apic_pm_state.active)
return 0;
+ maxlvt = get_maxlvt();
+
local_irq_save(flags);
/*
@@ -700,8 +710,12 @@ static int lapic_resume(struct sys_devic
apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
- apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
- apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
+#ifdef CONFIG_X86_MCE_P4THERMAL
+ if (maxlvt >= 5)
+ apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
+#endif
+ if (maxlvt >= 4)
+ apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
apic_write(APIC_TMICT, apic_pm_state.apic_tmict);
--
1.4.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix misspelled i8259 typo in io_apic.c
The legacy PIC's name is "i8259".
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
diff -upr linux-2.6.13-rc6/arch/i386/kernel/io_apic.c
linux-2.6.13/arch/i386/kernel/io_apic.c
--- linux-2.6.13-rc6/arch/i386/kernel/io_apic.c 2005-08-08 11:46:00.0
+0200
+++ linux-2.6.13/arch/i386/kernel/io_apic.c 2005-08-08 13:24:52.0
+0200
@@ -1641,9 +1641,9 @@ void disable_IO_APIC(void)
clear_IO_APIC();
/*
-* If the i82559 is routed through an IOAPIC
+* If the i8259 is routed through an IOAPIC
* Put that IOAPIC in virtual wire mode
-* so legacy interrups can be delivered.
+* so legacy interrupts can be delivered.
*/
pin = find_isa_irq_pin(0, mp_ExtINT);
if (pin != -1) {
diff -upr linux-2.6.13-rc6/arch/x86_64/kernel/io_apic.c
linux-2.6.13/arch/x86_64/kernel/io_apic.c
--- linux-2.6.13-rc6/arch/x86_64/kernel/io_apic.c 2005-08-08
11:46:01.0 +0200
+++ linux-2.6.13/arch/x86_64/kernel/io_apic.c 2005-08-08 13:25:09.0
+0200
@@ -1138,9 +1138,9 @@ void disable_IO_APIC(void)
clear_IO_APIC();
/*
-* If the i82559 is routed through an IOAPIC
+* If the i8259 is routed through an IOAPIC
* Put that IOAPIC in virtual wire mode
-* so legacy interrups can be delivered.
+* so legacy interrupts can be delivered.
*/
pin = find_isa_irq_pin(0, mp_ExtINT);
if (pin != -1) {
_
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc7-rt4, fails to build
Am Dienstag, 30. August 2005 08:28 schrieb Ingo Molnar: > ok, managed to reproduce it with this .config. It's an effect of the > IOAPIC_CACHE code. I have fixed it with the patch below (which is also > in 2.6.13-rt2), and the resulting kernel builds & boots fine. Karsten, > does it look sane to you? Sure. Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc6-rt9
Chuck wrote: > I'm still getting the same oops when rebooting. the same process (reboot) > similar call trace (some addresses are slightly different but the functions > are the same: > disable_IO_APIC+0x5a/0x90 (8) > machine_restart+0x5/0x9 (28) > sys_reboot+0x147/0x156 (4) > netdev_run_todo+0xa4/0x209 (4) > etc. Does this patch help? -- diff -up arch/i386/kernel/io_apic.c.rt9 arch/i386/kernel/io_apic.c --- arch/i386/kernel/io_apic.c.rt9 2005-08-19 12:28:42.0 +0200 +++ arch/i386/kernel/io_apic.c 2005-08-19 12:29:30.0 +0200 @@ -1758,8 +1758,8 @@ void disable_IO_APIC(void) * Add it to the IO-APIC irq-routing table: */ spin_lock_irqsave(&ioapic_lock, flags); - io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1)); - io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0)); + io_apic_write(ioapic_data[0], 0x11+2*pin, *(((int *)&entry)+1)); + io_apic_write(ioapic_data[0], 0x10+2*pin, *(((int *)&entry)+0)); spin_unlock_irqrestore(&ioapic_lock, flags); } disconnect_bsp_APIC(pin != -1); -- Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] quirks for VIA VT8237 southbridge
Am Dienstag, 16. August 2005 19:20 schrieb Alan Cox:
>
> PCI interrupt line routing is used for all V-Bus devices. Thats all
> devices in any way on an internal bus of the north or south bridge. The
> quirk is harmless when applied to other devices.
>
> Note the description of the quirk is still wrong
>
>
> > > * For these devices, this register is defined to be 4 bits wide.
> > > * Normally this is fine. However for IO-APIC motherboards, or
> > > * non-x86 architectures (yes Via exists on PPC among other places),
> > > * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
> > > * interrupts delivered properly.
>
> The interrupt line field is used to indicate the ISA type IRQ or the
> APIC pin used for the IRQ delivery. See the data sheet.
>
> The & 0x0F is the old hack used to get the ISA type IRQ line in use from
> the IRQ number.
>
Thanks, Bjorn and Alan!
After thinking again here is a 3rd version to change quirk_via_irq().
Motivation is to cleanup the IOAPIC-case:
Currently as of 2.6.13-rc6 new_irq is wrong then,
as dev->irq isn't the PIN number.
Solutions: either calculate correct new_irq (= PIN-Number & 0x0F)
or don't apply likely wrong value.
Following diff takes the 2nd way.
Well, VT8237 ignores the wrong new_irq in IOAPIC-Mode,
but its irritating to see dmesg print out nonsense then.
--
--- linux-2.6.13-rc6/drivers/pci/quirks.c 2005-08-08 11:46:05.0
+0200
+++ linux-2.6.13/drivers/pci/quirks.c 2005-08-18 11:55:50.0 +0200
@@ -497,9 +516,27 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
+#ifdef CONFIG_X86_IO_APIC
+ extern struct hw_interrupt_type ioapic_edge_type;
+ extern struct hw_interrupt_type ioapic_level_type;
+#include
+#endif
static void quirk_via_irq(struct pci_dev *dev)
{
u8 irq, new_irq;
+#ifdef CONFIG_X86_IO_APIC
+ {
+ irq_desc_t *desc = irq_desc + dev->irq;
+ if (desc &&
+ (desc->handler == &ioapic_edge_type ||
+desc->handler == &ioapic_level_type)
+ )
+ return; /* We cannot guess the right
+* new_irq with the simple hack below.
+* lets just leave.
+*/
+ }
+#endif
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
--
What do you think?
Karsten
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] quirk_via_vt8237_bypass_apic_deassert
Hi Andrew,
This helps at least on Ingo's and my [EMAIL PROTECTED]
and shouldn't bite anybody else.
Please add to -mm for later inclusion into mainline.
Thanks,
Karsten
------
From: Karsten Wiese <[EMAIL PROTECTED]>
The VIA VT8237's IOAPIC sends 'APIC De-Assert Messages' by default,
causing another CPU interrupt when the IRQ pin is de-asserted.
This feature is switched off by the patch to get rid of
doubled ioapic level interrupt rates.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
--- linux-2.6.13-rc6/drivers/pci/quirks.c 2005-08-08 11:46:05.0
+0200
+++ linux-2.6.13/drivers/pci/quirks.c 2005-08-18 10:15:06.0 +0200
@@ -403,6 +403,25 @@ static void __devinit quirk_via_ioapic(s
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
quirk_via_ioapic );
/*
+ * VIA 8237: Some BIOSs don't set the 'Bypass APIC De-Assert Message' Bit.
+ * This leads to doubled level interrupt rates.
+ * Set this bit to get rid of cycle wastage.
+ * Otherwise uncritical.
+ */
+static void __devinit quirk_via_vt8237_bypass_apic_deassert(struct pci_dev
*dev)
+{
+ u8 misc_control2;
+#define BYPASS_APIC_DEASSERT 8
+
+ pci_read_config_byte(dev, 0x5B, &misc_control2);
+ if (!(misc_control2 & BYPASS_APIC_DEASSERT)) {
+ printk(KERN_INFO "PCI: Bypassing VIA 8237 APIC De-Assert
Message\n");
+ pci_write_config_byte(dev, 0x5B,
misc_control2|BYPASS_APIC_DEASSERT);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
quirk_via_vt8237_bypass_apic_deassert);
+
+/*
* The AMD io apic can hang the box when an apic irq is masked.
* We check all revs >= B0 (yet not in the pre production!) as the bug
* is currently marked NoFix
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] quirks for VIA VT8237 southbridge
Am Dienstag, 16. August 2005 00:31 schrieb Bjorn Helgaas:
> These patches seem unrelated except that they both contain the
> text "via", so I think you should at least split them.
Will do.
> This quirk_via_irq() change seems like an awful lot of work to
> get rid of a few log messages. In my opinion, it's just not
> worth it, because it's so hard to debug problems in that area
> already.
What about the following version?
quirk_via_686irq() only works on pci_devs that are part of the 686.
Sooner or later there'll be more VIA southbridge types, which will
not need quirk_via_irq() like the 8237.
--
/*
* Via 686A/B: The PCI_INTERRUPT_LINE register for the on-chip
* devices, USB0/1, AC97, MC97, and ACPI, has an unusual feature:
* when written, it makes an internal connection to the PIC.
* For these devices, this register is defined to be 4 bits wide.
* Normally this is fine. However for IO-APIC motherboards, or
* non-x86 architectures (yes Via exists on PPC among other places),
* we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
* interrupts delivered properly.
*/
static void quirk_via_686irq(struct pci_dev *dev)
{
u8 irq, new_irq;
/*
* The ISA bridge is used to identify the 686.
* It shares it's PCI slot and bus with the device under test
* and is assigned to function 0.
*/
unsigned int isa_bridge_devfn = PCI_DEVFN(PCI_SLOT(dev->devfn), 0);
struct pci_dev * isa_bridge = pci_find_slot(dev->bus->number,
isa_bridge_devfn);
if (isa_bridge == NULL || isa_bridge->vendor != PCI_VENDOR_ID_VIA ||
isa_bridge->device != PCI_DEVICE_ID_VIA_82C686)
return; /* We are not on a 686. Lets leave */
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
if (new_irq != irq) {
printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
pci_name(dev), irq, new_irq);
udelay(15); /* unknown if delay really needed */
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
}
}
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1,
quirk_via_686irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
quirk_via_686irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4,
quirk_via_686irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
quirk_via_686irq);
DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
quirk_via_686irq);
--
We could also add a "pci_dev * housed_in;" to "struct pci_dev"
to get rid of search done above under pci_find_slot().
To fill in "pci_dev * housed_in;", we'd need another quirk though.
Side note 1: IIRC via82xxx IDE code could also make use of such a "pci_dev *
housed_in;"
Side note 2: The members
./include/linux/pci.h:542: unsigned short
vendor_compatible[DEVICE_COUNT_COMPATIBLE];
./include/linux/pci.h:543: unsigned short
device_compatible[DEVICE_COUNT_COMPATIBLE];
of "struct pci_dev" are unused in the current kernel and can vanish.
So a new "pci_dev * housed_in;" in "struct pci_dev" wouldn't add code in the
sum.
Karsten
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH,RFC] quirks for VIA VT8237 southbridge
Am Samstag, 13. August 2005 18:04 schrieb Grant Coady: > > I'm tracking a dataloss on box with this chip, finding it difficult > to nail a configuration that reliably produces dataloss, sometimes > only one bit (e.g. 'c' --> 'C') of unpacking kernel source tree gets > changed. > > Relevant? This is on a KM400 with Skt A Sempron + Seagate SATA HDD. > http://bugsplatter.mine.nu/test/linux-2.6/sempro/ Very unlikely. Rare bitwise errors like yours are more likely caused by i.e. broken IDE cable or too fast an IDE-controller setting for the cable / drive. Or memory error. Or an itch on the mainboard. or++ Interrupt errors would cause errors blockwisely. like whole sectors of data missing, device not working Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH,RFC] quirks for VIA VT8237 southbridge
Hi,
this fixes the 'doubled ioapic level interrupt rate' issue I've been
seeing on a K8T800/AMD64 mainboard.
It also switches off quirk_via_irq() for the VT8237 southbridge.
As both changes are uncritical fixes, I'll post a real patch to -mm
in a week or so.
Karsten
--- ../linux-2.6.13-rc6/drivers/pci/quirks.c2005-08-08 11:46:05.0
+0200
+++ drivers/pci/quirks.c2005-08-13 16:52:19.0 +0200
@@ -403,6 +403,25 @@ static void __devinit quirk_via_ioapic(s
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
quirk_via_ioapic );
/*
+ * VIA 8237: Some BIOSs don't set the 'Bypass APIC De-Assert Message' Bit.
+ * This leads to doubled level interrupt rates.
+ * Set this bit to get rid of cycle wastage.
+ * Otherwise uncritical.
+ */
+static void __devinit quirk_via_vt8237_bypass_apic_deassert(struct pci_dev
*dev)
+{
+ u8 misc_control2;
+#define BYPASS_APIC_DEASSERT 8
+
+ pci_read_config_byte(dev, 0x5B, &misc_control2);
+ if (!(misc_control2 & BYPASS_APIC_DEASSERT)) {
+ printk(KERN_INFO "PCI: Bypassing VIA 8237 APIC De-Assert
Message\n");
+ pci_write_config_byte(dev, 0x5B,
misc_control2|BYPASS_APIC_DEASSERT);
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
quirk_via_vt8237_bypass_apic_deassert);
+
+/*
* The AMD io apic can hang the box when an apic irq is masked.
* We check all revs >= B0 (yet not in the pre production!) as the bug
* is currently marked NoFix
@@ -488,6 +507,47 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_82C686_4,
quirk_via_acpi );
/*
+ * Devices part of the VIA VT8237 don't need quirk_via_irq().
+ * They also don't get confused by it, but dmesg gets quiter
+ * with this 'anti'-quirk.
+ * Here we are overly paranoic:
+ * we assume there might also exist via devices not part of the VT8237
+ * needing quirk_via_irq().
+ * This might never be the case in reality, when there is a VT8237.
+ */
+static unsigned int vt8237_devfn[] = {
+ PCI_DEVFN(15, 0),
+ PCI_DEVFN(15, 1),
+ PCI_DEVFN(16, 0),
+ PCI_DEVFN(16, 1),
+ PCI_DEVFN(16, 2),
+ PCI_DEVFN(16, 3),
+ PCI_DEVFN(16, 4),
+ PCI_DEVFN(16, 5),
+ PCI_DEVFN(17, 5),
+ PCI_DEVFN(17, 6),
+ PCI_DEVFN(18, 0)
+};
+static struct pci_dev *quirk_via_irq_not[ARRAY_SIZE(vt8237_devfn)];
+static void quirk_via_irq_not_for_8237(struct pci_dev *dev)
+{
+ // Make sure we do this only once
+ if (quirk_via_irq_not[0] != NULL)
+ return;
+
+ if (dev->devfn == PCI_DEVFN(0x11, 0)) {
+ int i, j;
+ for (i = 0, j = 0; i < ARRAY_SIZE(vt8237_devfn); i++) {
+ struct pci_dev * d;
+ d = pci_find_slot(dev->bus->number, vt8237_devfn[i]);
+ if (d != NULL)
+ quirk_via_irq_not[j++] = d;
+ }
+ }
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
quirk_via_irq_not_for_8237);
+
+/*
* Via 686A/B: The PCI_INTERRUPT_LINE register for the on-chip
* devices, USB0/1, AC97, MC97, and ACPI, has an unusual feature:
* when written, it makes an internal connection to the PIC.
@@ -499,8 +559,14 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
*/
static void quirk_via_irq(struct pci_dev *dev)
{
+ int i;
u8 irq, new_irq;
+ for (i = 0; i < ARRAY_SIZE(vt8237_devfn); i++)
+ if (quirk_via_irq_not[i] == dev)
+ return;
+
+
new_irq = dev->irq & 0xf;
pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &irq);
if (new_irq != irq) {
_
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] CHECK_IRQ_PER_CPU() to avoid dead code in __do_IRQ()
Am Montag, 8. August 2005 13:19 schrieb Alexander Nyberg: > > There are many places where one could replace run-time tests with > #ifdef's but it makes reading more difficult (and in longer terms > maintainence). Have you benchmarked any workload that benefits > from this? Performance gain is small, but measurable: 0,02% Tested on an Atlon64 running at 1000MHz. I took this value from 9 runs (each with/without the patch) of $ time lame x.wav where each took about 1 minute. 3000 Interrupts/s were generated at the time by running $ jackd -R -dalsa -p64 -n2 0,02% really isn't that muchbut Athlon64 is better than P4 with branch predictions, I think. Erm... ok, I won't insist on having this patch applied ;-) Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Typofix_i82559_to_i8259
The legacy PIC's name is "i8259".
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
diff -upr linux-2.6.13-rc6/arch/i386/kernel/io_apic.c
linux-2.6.13/arch/i386/kernel/io_apic.c
--- linux-2.6.13-rc6/arch/i386/kernel/io_apic.c 2005-08-08 11:46:00.0
+0200
+++ linux-2.6.13/arch/i386/kernel/io_apic.c 2005-08-08 13:24:52.0
+0200
@@ -1641,9 +1641,9 @@ void disable_IO_APIC(void)
clear_IO_APIC();
/*
-* If the i82559 is routed through an IOAPIC
+* If the i8259 is routed through an IOAPIC
* Put that IOAPIC in virtual wire mode
-* so legacy interrups can be delivered.
+* so legacy interrupts can be delivered.
*/
pin = find_isa_irq_pin(0, mp_ExtINT);
if (pin != -1) {
diff -upr linux-2.6.13-rc6/arch/x86_64/kernel/io_apic.c
linux-2.6.13/arch/x86_64/kernel/io_apic.c
--- linux-2.6.13-rc6/arch/x86_64/kernel/io_apic.c 2005-08-08
11:46:01.0 +0200
+++ linux-2.6.13/arch/x86_64/kernel/io_apic.c 2005-08-08 13:25:09.0
+0200
@@ -1138,9 +1138,9 @@ void disable_IO_APIC(void)
clear_IO_APIC();
/*
-* If the i82559 is routed through an IOAPIC
+* If the i8259 is routed through an IOAPIC
* Put that IOAPIC in virtual wire mode
-* so legacy interrups can be delivered.
+* so legacy interrupts can be delivered.
*/
pin = find_isa_irq_pin(0, mp_ExtINT);
if (pin != -1) {
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CHECK_IRQ_PER_CPU() to avoid dead code in __do_IRQ()
Hi Ingo,
This version of the patch has better coding style
thanks to comments from Ingo Oeser.
Please comment or pass it on as appropriate.
Patch is for mainline 2.6.13-rc6.
Thanks,
Karsten
--
From: Karsten Wiese <[EMAIL PROTECTED]>
IRQ_PER_CPU is not used by all architectures.
This patch introduces the macros
ARCH_HAS_IRQ_PER_CPU and CHECK_IRQ_PER_CPU() to avoid the generation of
dead code in __do_IRQ().
ARCH_HAS_IRQ_PER_CPU is defined by architectures using
IRQ_PER_CPU in their
include/asm_ARCH/irq.h
file.
Through grepping the tree I found the following
architectures currently use IRQ_PER_CPU:
cris, ia64, ppc, ppc64 and parisc.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
diff -upr linux-2.6.13-rc6/include/asm-cris/irq.h
linux-2.6.13/include/asm-cris/irq.h
--- linux-2.6.13-rc6/include/asm-cris/irq.h 2005-08-08 11:46:10.0
+0200
+++ linux-2.6.13/include/asm-cris/irq.h 2005-08-08 11:41:12.0 +0200
@@ -1,6 +1,11 @@
#ifndef _ASM_IRQ_H
#define _ASM_IRQ_H
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
#include
extern __inline__ int irq_canonicalize(int irq)
diff -upr linux-2.6.13-rc6/include/asm-ia64/irq.h
linux-2.6.13/include/asm-ia64/irq.h
--- linux-2.6.13-rc6/include/asm-ia64/irq.h 2005-03-02 08:38:33.0
+0100
+++ linux-2.6.13/include/asm-ia64/irq.h 2005-08-06 18:06:53.0 +0200
@@ -14,6 +14,11 @@
#define NR_IRQS256
#define NR_IRQ_VECTORS NR_IRQS
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
static __inline__ int
irq_canonicalize (int irq)
{
diff -upr linux-2.6.13-rc6/include/asm-parisc/irq.h
linux-2.6.13/include/asm-parisc/irq.h
--- linux-2.6.13-rc6/include/asm-parisc/irq.h 2005-08-08 11:45:26.0
+0200
+++ linux-2.6.13/include/asm-parisc/irq.h 2005-08-06 18:05:22.0
+0200
@@ -26,6 +26,11 @@
#define NR_IRQS(CPU_IRQ_MAX + 1)
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
static __inline__ int irq_canonicalize(int irq)
{
return (irq == 2) ? 9 : irq;
diff -upr linux-2.6.13-rc6/include/asm-ppc/irq.h
linux-2.6.13/include/asm-ppc/irq.h
--- linux-2.6.13-rc6/include/asm-ppc/irq.h 2005-08-08 11:46:10.0
+0200
+++ linux-2.6.13/include/asm-ppc/irq.h 2005-08-08 11:41:14.0 +0200
@@ -19,6 +19,11 @@
#define IRQ_POLARITY_POSITIVE 0x2 /* high level or low->high edge */
#define IRQ_POLARITY_NEGATIVE 0x0 /* low level or high->low edge */
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
#if defined(CONFIG_40x)
#include
diff -upr linux-2.6.13-rc6/include/asm-ppc64/irq.h
linux-2.6.13/include/asm-ppc64/irq.h
--- linux-2.6.13-rc6/include/asm-ppc64/irq.h2005-03-02 08:38:33.0
+0100
+++ linux-2.6.13/include/asm-ppc64/irq.h2005-08-06 18:06:58.0
+0200
@@ -33,6 +33,11 @@
#define IRQ_POLARITY_POSITIVE 0x2 /* high level or low->high edge */
#define IRQ_POLARITY_NEGATIVE 0x0 /* low level or high->low edge */
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
#define get_irq_desc(irq) (&irq_desc[(irq)])
/* Define a way to iterate across irqs. */
diff -upr linux-2.6.13-rc6/include/linux/irq.h linux-2.6.13/include/linux/irq.h
--- linux-2.6.13-rc6/include/linux/irq.h2005-08-08 11:46:10.0
+0200
+++ linux-2.6.13/include/linux/irq.h2005-08-08 11:55:11.0 +0200
@@ -32,7 +32,12 @@
#define IRQ_WAITING32 /* IRQ not yet seen - for autodetection */
#define IRQ_LEVEL 64 /* IRQ level triggered */
#define IRQ_MASKED 128 /* IRQ masked - shouldn't be seen again */
-#define IRQ_PER_CPU256 /* IRQ is per CPU */
+#if defined(ARCH_HAS_IRQ_PER_CPU)
+# define IRQ_PER_CPU 256 /* IRQ is per CPU */
+# define CHECK_IRQ_PER_CPU(var) ((var) & IRQ_PER_CPU)
+#else
+# define CHECK_IRQ_PER_CPU(var) 0
+#endif
/*
* Interrupt controller descriptor. This is all we need
diff -upr linux-2.6.13-rc6/kernel/irq/handle.c linux-2.6.13/kernel/irq/handle.c
--- linux-2.6.13-rc6/kernel/irq/handle.c2005-08-08 11:46:11.0
+0200
+++ linux-2.6.13/kernel/irq/handle.c2005-08-08 11:53:00.0 +0200
@@ -111,7 +111,7 @@ fastcall unsigned int __do_IRQ(unsigned
unsigned int status;
kstat_this_cpu.irqs[irq]++;
- if (desc->status & IRQ_PER_CPU) {
+ if (CHECK_IRQ_PER_CPU(desc->status)) {
irqreturn_t action_ret;
/*
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Re: [PATCH] ARCH_HAS_IRQ_PER_CPU avoids dead code in __do_IRQ()
Am Sonntag, 7. August 2005 13:07 schrieb Ingo Oeser:
> Last argument: Many kernel developers -- including Linus --
> don't like "#if" in C files and prefer them in headers.
> Their reasons might be similiar to my own.
What about writing
if(CHECK_IRQ_PER_CPU(desc->status)) {
...
}
in __do_IRQ(),
and
#if defined(ARCH_HAS_IRQ_PER_CPU)
#define IRQ_PER_CPU 256 /* IRQ is per CPU */
#define CHECK_IRQ_PER_CPU(var) ((var) & IRQ_PER_CPU)
#else
#define CHECK_IRQ_PER_CPU(var) 0
#endif
in "include/linux/irq.h" then?
Gruesse,
Karsten
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARCH_HAS_IRQ_PER_CPU avoids dead code in __do_IRQ()
Am Samstag, 6. August 2005 23:28 schrieb Ingo Oeser: > Hi Karsten, > > On Saturday 06 August 2005 18:14, Karsten Wiese wrote: > > From: Karsten Wiese <[EMAIL PROTECTED]> > > > > IRQ_PER_CPU is not used by all architectures. > > To avoid dead code generation in __do_IRQ() > > this patch introduces the macro ARCH_HAS_IRQ_PER_CPU. > > > > ARCH_HAS_IRQ_PER_CPU is defined by architectures using > > IRQ_PER_CPU in their > > include/asm_ARCH/irq.h > > file. > > Why not the other way around? > > Just define IRQ_PER_CPU to 0 on architectures not needing it and > add a FAT comment there, that this disables it. Or make it a config option. > > Then just leave the code as is and let GCC optimize the dead code > away without any changes in the C file. It works, I just checked it ;-) > With my proposal the #if defined(ARCH_HAS_IRQ_PER_CPU) #endif lets readers of __do_IRQ() immediately grasp: "this block might not be compiled / depends an ARCH" And you'll get compile error's using IRQ_PER_CPU on ie i386, letting you immediately know, that you've got to change something to be able to use IRQ_PER_CPU. That are advantages I think. Otherwise your proposal is ok for me too. Regards, Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARCH_HAS_IRQ_PER_CPU avoids dead code in __do_IRQ()
Hi Ingo,
from the bitkeeper logs I found you made the last
global-arch-relevant changes in this area.
Please comment or pass it on as appropriate.
Patch is for mainline 2.6.13-rc5.
Thanks,
Karsten
From: Karsten Wiese <[EMAIL PROTECTED]>
IRQ_PER_CPU is not used by all architectures.
To avoid dead code generation in __do_IRQ()
this patch introduces the macro ARCH_HAS_IRQ_PER_CPU.
ARCH_HAS_IRQ_PER_CPU is defined by architectures using
IRQ_PER_CPU in their
include/asm_ARCH/irq.h
file.
Through grepping the tree I found the following
architectures currently use IRQ_PER_CPU:
cris, ia64, ppc, ppc64 and parisc.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
diff -upr linux-2.6.13_orig/include/asm-cris/irq.h
linux-2.6.13/include/asm-cris/irq.h
--- linux-2.6.13_orig/include/asm-cris/irq.h2005-08-06 16:44:41.0
+0200
+++ linux-2.6.13/include/asm-cris/irq.h 2005-08-06 18:06:48.0 +0200
@@ -1,6 +1,11 @@
#ifndef _ASM_IRQ_H
#define _ASM_IRQ_H
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
#include
extern __inline__ int irq_canonicalize(int irq)
diff -upr linux-2.6.13_orig/include/asm-ia64/irq.h
linux-2.6.13/include/asm-ia64/irq.h
--- linux-2.6.13_orig/include/asm-ia64/irq.h2005-08-06 16:47:24.0
+0200
+++ linux-2.6.13/include/asm-ia64/irq.h 2005-08-06 18:06:53.0 +0200
@@ -14,6 +14,11 @@
#define NR_IRQS256
#define NR_IRQ_VECTORS NR_IRQS
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
static __inline__ int
irq_canonicalize (int irq)
{
diff -upr linux-2.6.13_orig/include/asm-parisc/irq.h
linux-2.6.13/include/asm-parisc/irq.h
--- linux-2.6.13_orig/include/asm-parisc/irq.h 2005-08-06 16:50:29.0
+0200
+++ linux-2.6.13/include/asm-parisc/irq.h 2005-08-06 18:05:22.0
+0200
@@ -26,6 +26,11 @@
#define NR_IRQS(CPU_IRQ_MAX + 1)
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
static __inline__ int irq_canonicalize(int irq)
{
return (irq == 2) ? 9 : irq;
diff -upr linux-2.6.13_orig/include/asm-ppc/irq.h
linux-2.6.13/include/asm-ppc/irq.h
--- linux-2.6.13_orig/include/asm-ppc/irq.h 2005-08-02 13:55:51.0
+0200
+++ linux-2.6.13/include/asm-ppc/irq.h 2005-08-06 18:10:19.0 +0200
@@ -19,6 +19,11 @@
#define IRQ_POLARITY_POSITIVE 0x2 /* high level or low->high edge */
#define IRQ_POLARITY_NEGATIVE 0x0 /* low level or high->low edge */
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
#if defined(CONFIG_40x)
#include
diff -upr linux-2.6.13_orig/include/asm-ppc64/irq.h
linux-2.6.13/include/asm-ppc64/irq.h
--- linux-2.6.13_orig/include/asm-ppc64/irq.h 2005-08-06 16:41:14.0
+0200
+++ linux-2.6.13/include/asm-ppc64/irq.h2005-08-06 18:06:58.0
+0200
@@ -33,6 +33,11 @@
#define IRQ_POLARITY_POSITIVE 0x2 /* high level or low->high edge */
#define IRQ_POLARITY_NEGATIVE 0x0 /* low level or high->low edge */
+/*
+ * IRQ line status macro IRQ_PER_CPU is used
+ */
+#define ARCH_HAS_IRQ_PER_CPU
+
#define get_irq_desc(irq) (&irq_desc[(irq)])
/* Define a way to iterate across irqs. */
diff -upr linux-2.6.13_orig/include/linux/irq.h linux-2.6.13/include/linux/irq.h
--- linux-2.6.13_orig/include/linux/irq.h 2005-08-06 16:36:14.0
+0200
+++ linux-2.6.13/include/linux/irq.h2005-08-06 16:36:30.0 +0200
@@ -32,7 +32,9 @@
#define IRQ_WAITING32 /* IRQ not yet seen - for autodetection */
#define IRQ_LEVEL 64 /* IRQ level triggered */
#define IRQ_MASKED 128 /* IRQ masked - shouldn't be seen again */
+#if defined(ARCH_HAS_IRQ_PER_CPU)
#define IRQ_PER_CPU256 /* IRQ is per CPU */
+#endif
/*
* Interrupt controller descriptor. This is all we need
diff -upr linux-2.6.13_orig/kernel/irq/handle.c linux-2.6.13/kernel/irq/handle.c
--- linux-2.6.13_orig/kernel/irq/handle.c 2005-08-06 15:53:37.0
+0200
+++ linux-2.6.13/kernel/irq/handle.c2005-08-06 15:19:57.0 +0200
@@ -112,6 +112,7 @@ fastcall unsigned int __do_IRQ(unsigned
kstat_this_cpu.irqs[irq]++;
+#if defined(ARCH_HAS_IRQ_PER_CPU)
if (desc->status & IRQ_PER_CPU) {
irqreturn_t action_ret;
@@ -123,6 +124,7 @@ fastcall unsigned int __do_IRQ(unsigned
desc->handler->end(irq);
return 1;
}
+#endif
spin_lock(&desc->lock);
desc->handler->ack(irq);
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
Re: [PATCH] Speedup FAT filesystem directory reads
Am Donnerstag, 4. August 2005 16:21 schrieb OGAWA Hirofumi:
> Karsten Wiese <[EMAIL PROTECTED]> writes:
>
> > Please give this a try and commit to -mm or mainline, if approved.
>
> Looks good. Thanks. However, I tweaked the patch.
>
> - replace __getblk() to sb_getblk()
> - exclude root-dir of FAT12/FAT16 from readahead
> - exclude (sec_per_clus == 1) from readahead
> - move the all readahead stuff to one inline function
>
> What do you think of the following patch?
Looks better, is smaller and works equally well here, thanks.
I had to hand apply it though as it was slightly scrambled
(by my mail client?) so patch couldn't handle it.
Please send patches as attachment.
Andrew,
please replace the initial version in -mm with this one.
Thanks,
Karsten
From: Karsten Wiese <[EMAIL PROTECTED]>
From: OGAWA Hirofumi <[EMAIL PROTECTED]>
This speeds up directory reads for large FAT partitions, if the buffercache
has to be filled from the drive. Following values were taken from:
$ time find path_to_freshly_mounted_fat > /dev/null
on an otherwise idle system.
FAT with 16KB Clusters on IDE attached drive: Factor 2
FAT with 32KB Clusters on USB2 attached drive: Factor 10 (!)
Its less than 1/10 slower, if the buffercache is uptodate.
The patch introduces the new function fat_dir_readahead().
fat_dir_readahead() calls sb_breadahead() to readahead a whole cluster,
if the requested sector is the first one in a cluster.
It is usefull to do this, because on FAT directories occupy whole
clusters, with the exception of FAT12/FAT16 root dirs.
Readahead is only done, if the cluster's first sector is not uptodate
to avoid overhead, when the buffer cache is already uptodate.
Note that under memory pressure, the maximal byte count wasted
(read: has to be red from disk twice) is 1 cluster's size. Thats 64KB.
fat_dir_readahead() is called from fat__get_entry().
There is also an unrelated cleanup at one spot:
if (bh)
brelse(bh);
is replaced with:
brelse(bh);
brelse() can handle NULL pointer arguments by itself.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
diff -ur linux-2.6.13_orig/fs/fat/dir.c linux-2.6.13/fs/fat/dir.c
--- linux-2.6.13_orig/fs/fat/dir.c 2005-07-31 21:14:20.0 +0200
+++ linux-2.6.13/fs/fat/dir.c 2005-08-04 19:11:21.0 +0200
@@ -30,6 +30,29 @@
| (de - (struct msdos_dir_entry *)bh->b_data);
}
+static inline void fat_dir_readahead(struct inode *dir, sector_t iblock,
+ sector_t phys)
+{
+ struct super_block *sb = dir->i_sb;
+ struct msdos_sb_info *sbi = MSDOS_SB(sb);
+ struct buffer_head *bh;
+ int sec;
+
+ /* This is not a first sector of cluster, or sec_per_clus == 1 */
+ if ((iblock & (sbi->sec_per_clus - 1)) || sbi->sec_per_clus == 1)
+ return;
+ /* root dir of FAT12/FAT16 */
+ if ((sbi->fat_bits != 32) && (dir->i_ino == MSDOS_ROOT_INO))
+ return;
+
+ bh = sb_getblk(sb, phys);
+ if (bh && !buffer_uptodate(bh)) {
+ for (sec = 0; sec < sbi->sec_per_clus; sec++)
+ sb_breadahead(sb, phys + sec);
+ }
+ brelse(bh);
+}
+
/* Returns the inode number of the directory entry at offset pos. If bh is
non-NULL, it is brelse'd before. Pos is incremented. The buffer header is
returned in bh.
@@ -58,6 +81,8 @@
if (err || !phys)
return -1; /* beyond EOF or error */
+ fat_dir_readahead(dir, iblock, phys);
+
*bh = sb_bread(sb, phys);
if (*bh == NULL) {
printk(KERN_ERR "FAT: Directory bread(block %llu) failed\n",
@@ -635,8 +660,7 @@
EODir:
filp->f_pos = cpos;
FillFailed:
- if (bh)
- brelse(bh);
+ brelse(bh);
if (unicode)
free_page((unsigned long)unicode);
out:
Re: [RFC] AMD64 @ K8T800/VT8237: Doubled IOAPIC-level-interrupt rate
Am Donnerstag, 4. August 2005 17:19 schrieb Ingo Molnar: > > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > this should likely be addressed to VIA Taiwan, > > but I don't know their engineer's e-mail address and their forum > > doesn't work for me. > > Maybe somebody here has a clue? > > Or maybe this is even motherboard specific? > > > > To reproduce: > > $ aplay -Dhw:0 -fdat /dev/zero > > > > On a sane system (or here in PIC Mode) you'll see > > around 12 Interrupts/s. > > Here I see 24. > > i think this is an effect of the 'POST-flush' symptom: the IO-APIC write > of unmasking the IRQ does not reach the chipset before the ACK via the > local-APIC does. Does it work fine if you artificially read after the > IO-APIC write? > Sorry, I missed to say this happens on mainline .12 and .13-rcx. In i386 and x86_64 mode. So there is no IO-APIC (un)masking during the interrupt Routine. I printk()ed the CPU-APIC's IRR immediately before the soundcard's interrupt pin is deasserted and immediately after that: The relevant IRR-bit is set again just then! Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] AMD64 @ K8T800/VT8237: Doubled IOAPIC-level-interrupt rate
Hi, this should likely be addressed to VIA Taiwan, but I don't know their engineer's e-mail address and their forum doesn't work for me. Maybe somebody here has a clue? Or maybe this is even motherboard specific? To reproduce: $ aplay -Dhw:0 -fdat /dev/zero On a sane system (or here in PIC Mode) you'll see around 12 Interrupts/s. Here I see 24. 12 per s more is no big deal, but if you run low-latency audio, the overhead becomes significant. What exactly happens when i.e. the sounddevice (part of the VT8237) triggers an interrupt (low level on interrupt pin) is this: 1. IOAPIC accepts interrupt, sends it to CPU's APIC. 2. Interrupt Routine runs, tells the sounddevice to deassert the interrupt pin. 3. When sounddevice deasserts pin (low to high transition), IOAPIC accepts an interrupt _again_ , tells APIC, which also accepts interrupt again (IRR-Bit set). _This should not happen_. Looks like the IOAPIC (Part of the VT8237) behaves like Level Triggered _AND_ Edge Triggered at once!?! 3. Interrupt Routine finishes with sending EOI to the CPU's APIC, which tells IOAPIC to accept Interrupts on the soundcards interrupt pin _now_. But the IOAPIC has already wrongly accepted the next interupt in step 2. 4. Processor accepts interrupts again and runs the soundcards interruptroutine again. Now the interrupt Routine sees a soundcard that doesn't need servicing and finishes, having done nothing, but clearing up the APIC/IOAPIC. This bad behavior can be eliminated by masking the IOAPIC's interrupt pin during the phase where the sounddevice's interrupt pin is deasserted. But (Un)masking is also a cycle-costly operation, which shouldn't be necessary on a sane system. So my question here is: Can the VT8237's IOAPIC (or other device) be programmed in a way to behave sanely? Or is this a known bug that can only be circumvented? If it was an Intel/AMD chipsets I'd likely find those info's in publicly available docs, but here the problem for me is to get the docs... (Or WTF do I buy stuff, which comes without public docs $%§!!grmbl!) Thanks, Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Speedup FAT filesystem directory reads
Hi,
Please give this a try and commit to -mm or mainline, if approved.
Thanks,
Karsten
Summary:
This speeds up directory reads for large FAT partitions,
if the buffercache has to be filled from the drive.
Following values were taken from:
$ time find path_to_freshly_mounted_fat > /dev/null
on an otherwise idle system.
FAT with 16KB Clusters on IDE attached drive: Factor 2
FAT with 32KB Clusters on USB2 attached drive: Factor 10 (!)
Its less than 1/10 slower, if the buffercache is uptodate.
The patch touches 3 areas:
- fat_bmap() returns the sector's offset in the cluster or a
negativ error code instead of 0 or the negativ error code.
It's callers are changed accordingly.
- fat__get_entry() calls sb_breadahead() to readahead a whole cluster,
if the requested sector is the first one in a cluster.
It is usefull to do this, because on FAT directories occupy whole
clusters.
Readahead is only done, if the cluster's first sector is not uptodate
to avoid overhead, when the buffer cache is already uptodate.
Note that on memory pressure, the maximal byte count wasted
(read: has to be red from disk twice) is 1 cluster's size. Thats 64KB.
- Unrelated cleanup at one spot:
if (bh)
brelse(bh);
is replaced with:
brelse(bh);
brelse() can handle NULL pointer arguments by itself.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
diff -ur linux-2.6.13_orig/fs/fat/cache.c linux-2.6.13/fs/fat/cache.c
--- linux-2.6.13_orig/fs/fat/cache.c 2005-07-31 21:15:16.0 +0200
+++ linux-2.6.13/fs/fat/cache.c 2005-08-02 13:55:50.0 +0200
@@ -320,5 +320,5 @@
return cluster;
else if (cluster)
*phys = fat_clus_to_blknr(sbi, cluster) + offset;
- return 0;
+ return offset;
}
diff -ur linux-2.6.13_orig/fs/fat/dir.c linux-2.6.13/fs/fat/dir.c
--- linux-2.6.13_orig/fs/fat/dir.c 2005-07-31 21:14:20.0 +0200
+++ linux-2.6.13/fs/fat/dir.c 2005-07-31 21:53:28.0 +0200
@@ -46,7 +46,7 @@
struct super_block *sb = dir->i_sb;
sector_t phys, iblock;
int offset;
- int err;
+ int clu_sector;
next:
if (*bh)
@@ -54,10 +54,21 @@
*bh = NULL;
iblock = *pos >> sb->s_blocksize_bits;
- err = fat_bmap(dir, iblock, &phys);
- if (err || !phys)
+ clu_sector = fat_bmap(dir, iblock, &phys);
+ if (clu_sector < 0 || !phys)
return -1; /* beyond EOF or error */
+ if (0 == clu_sector) {
+ struct buffer_head *bh = __getblk(sb->s_bdev, phys, sb->s_blocksize);
+ if (!buffer_uptodate(bh)) {
+ int sec;
+ int sec_per_clus = MSDOS_SB(sb)->sec_per_clus;
+ for (sec = 0; sec < sec_per_clus; sec++)
+sb_breadahead(sb, phys + sec);
+ }
+ brelse(bh);
+ }
+
*bh = sb_bread(sb, phys);
if (*bh == NULL) {
printk(KERN_ERR "FAT: Directory bread(block %llu) failed\n",
@@ -635,8 +646,7 @@
EODir:
filp->f_pos = cpos;
FillFailed:
- if (bh)
- brelse(bh);
+ brelse(bh);
if (unicode)
free_page((unsigned long)unicode);
out:
diff -ur linux-2.6.13_orig/fs/fat/inode.c linux-2.6.13/fs/fat/inode.c
--- linux-2.6.13_orig/fs/fat/inode.c 2005-07-31 21:15:16.0 +0200
+++ linux-2.6.13/fs/fat/inode.c 2005-08-02 13:55:50.0 +0200
@@ -56,7 +56,7 @@
int err;
err = fat_bmap(inode, iblock, &phys);
- if (err)
+ if (err < 0)
return err;
if (phys) {
map_bh(bh_result, sb, phys);
@@ -76,7 +76,7 @@
}
MSDOS_I(inode)->mmu_private += sb->s_blocksize;
err = fat_bmap(inode, iblock, &phys);
- if (err)
+ if (err < 0)
return err;
if (!phys)
BUG();
Re:=?iso-8859-1?Q?[COMPILE_ERROR]_realtime-preempt-2=2E6=2E12-final-V0=2E7=2E51-33_on_x86_64_SMP_system
Steve, to make it compile and build replace arch/x86_64/kernel/smpboot.c: line 191 with this: static __cpuinitdata raw_spinlock_t tsc_sync_lock = RAW_SPIN_LOCK_UNLOCKED; or alternativly: static DEFINE_RAW_SPINLOCK(tsc_sync_lock); Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]IOAPIC_CACHE for PREEMPT_RT @ x86_64
Hi,
attached patch implements IOAPIC_CACHE on x86_64,
if I haven't forgotten something
Note that in the patch, IOAPIC_POSTFLUSH is initially not set.
Thats different to plain -51-32.
Works fine here on a K8T800 Mobo.
Would be fine, if some guys could give this a try ontop of -51-32.
Thanks,
Karsten
--- linux-2.6.12-RT-51-32/arch/x86_64/kernel/io_apic.c 2005-07-19 11:00:17.0 +0200
+++ linux-2.6.12-RT/arch/x86_64/kernel/io_apic.c 2005-07-20 18:15:10.0 +0200
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -41,16 +42,11 @@
#define __apicdebuginit __init
-int sis_apic_bug; /* not actually supported, dummy for compile */
static int no_timer_check;
static DEFINE_RAW_SPINLOCK(ioapic_lock);
-/*
- * # of IRQ routing registers
- */
-int nr_ioapic_registers[MAX_IO_APICS];
/*
* Rough estimation of how many shared IRQs there are, can
@@ -101,22 +97,123 @@
entry->pin = pin;
}
+#ifdef CONFIG_X86_IOAPIC_FAST
+# define IOAPIC_CACHE
+#endif
+
+/*
+ * some chips need this commented out:
+ */
+// #define IOAPIC_POSTFLUSH
+/*
+ * K8T800 seams not to need it.
+ */
+
+struct ioapic_data_struct {
+ volatile unsigned int *base;
+#ifdef IOAPIC_CACHE
+ unsigned int reg_set;
+#endif
+ int nr_registers; // # of IRQ routing registers
+ struct sys_device dev;
+ struct IO_APIC_route_entry *entry;
+#ifdef IOAPIC_CACHE
+ u32 cached_val[0];
+#endif
+};
+
+static struct ioapic_data_struct *ioapic_data[MAX_IO_APICS];
+
+
+static inline unsigned int __raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+#ifdef IOAPIC_CACHE
+ ioapic->reg_set = reg;
+#endif
+ ioapic->base[0] = reg;
+ return ioapic->base[4];
+}
+
+
+#ifdef IOAPIC_CACHE
+static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
+{
+ int reg;
+ for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
+ ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
+}
+#endif
+
+#if !defined(IOAPIC_CACHE) || defined(IOAPIC_POSTFLUSH)
+static unsigned int raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+ unsigned int val = __raw_io_apic_read(ioapic, reg);
+
+#ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+#endif
+ return val;
+}
+#endif
+
+static inline unsigned int io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+#ifdef IOAPIC_CACHE
+ ioapic->reg_set = -1;
+ return ioapic->cached_val[reg];
+#else
+ return raw_io_apic_read(ioapic, reg);
+#endif
+}
+
+static void io_apic_write(struct ioapic_data_struct *ioapic, unsigned int reg, unsigned int val)
+{
+#ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+ ioapic->reg_set = reg;
+#endif
+ ioapic->base[0] = reg;
+ ioapic->base[4] = val;
+}
+
+/*
+ * Re-write a value: to be used for read-modify-write
+ * cycles where the read already set up the index register.
+ */
+static inline void io_apic_modify(struct ioapic_data_struct *ioapic, unsigned int reg, unsigned int val)
+{
+#ifdef IOAPIC_CACHE
+ if (ioapic->reg_set != reg) {
+ ioapic->base[0] = reg;
+ ioapic->reg_set = reg;
+ }
+ ioapic->cached_val[reg] = val;
+#endif
+ ioapic->base[4] = val;
+
+#ifdef IOAPIC_POSTFLUSH
+ /* Force POST flush by reading: */
+ val = raw_io_apic_read(ioapic, reg);
+#endif
+}
+
#define __DO_ACTION(R, ACTION, FINAL) \
\
{ \
int pin; \
struct irq_pin_list *entry = irq_2_pin + irq; \
+ struct ioapic_data_struct *ioapic;\
\
for (;;) { \
- unsigned int reg; \
+ unsigned int reg, val; \
pin = entry->pin; \
if (pin == -1) \
break; \
- reg = io_apic_read(entry->apic, 0x10 + R + pin*2); \
- reg ACTION; \
- io_apic_modify(entry->apic, reg); \
- /* Force POST flush by reading: */ \
- reg = io_apic_read(entry->apic, 0x10 + R + pin*2); \
+ ioapic = ioapic_data[entry->apic]; \
+ reg = 0x10 + R + pin*2; \
+ val = io_apic_read(ioapic, reg); \
+ val ACTION; \
+ io_apic_modify(ioapic, reg, val); \
\
if (!entry->next) \
break; \
@@ -151,15 +248,15 @@
spin_unlock_irqrestore(&ioapic_lock, flags);
}
-static void clear_IO_APIC_pin(unsigned int apic, unsigned int pin)
+static void clear_IO_APIC_pin(struct ioapic_data_struct *ioapic, unsigned int pin)
{
struct IO_APIC_route_entry entry;
unsigned long flags;
/* Check delivery_mode to be sure we're not clearing an SMI pin */
spin_lock_irqsave(&ioapic_lock, flags);
- *(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
- *(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+ *(((int*)&entry) + 0) = io_apic_read(ioapic, 0x10 + 2 * pin);
+ *(((int*)&entry) + 1) = io_apic_read(ioapic, 0x11 + 2 * pin);
spin_unlock_irqrestore(&ioapic_lock, flags);
if (entry.delivery_mode == dest_SMI)
return;
@@ -169,8 +266,8 @@
memset(&entry, 0, sizeof(entry));
entry.mask = 1;
spin_lock_irqsave(&ioapic_lock, flags);
- io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry) + 0));
- io_apic
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Dienstag, 19. Juli 2005 17:19 schrieb Gene Heskett: > On Tuesday 19 July 2005 09:57, Ingo Molnar wrote: > >* Karsten Wiese <[EMAIL PROTECTED]> wrote: > >> > Found another error: > >> > the ioapic cache isn't fully initialized in -51-31's > >> > ioapic_cache_init(). > >> > >> and another: some NULL-pointers are used in -51-31 instead of > >> ioapic_data[0]. Please apply attached patch on top of -51-31. It > >> includes yesterday's fix. > > > >thanks, i've applied it and released -32. > > And this fixed ntpd (in mode 4) right up. But now Im seeing some > fussing from Xprint when its started, from my logs: > > Jul 19 10:59:58 coyote rc: Starting xprint: succeeded > Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > Jul 19 10:59:58 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > Jul 19 10:59:59 coyote Xprt_33: lpstat: Unable to connect to server: > Connection refused > Jul 19 10:59:59 coyote Xprt_33: No matching visual for __GLcontextMode with > visual class = 0 (32775), nplanes = > 8 > Jul 19 11:00:00 coyote kernel: set_rtc_mmss: can't update from 7 to 59 > > The font path stuff I snipped has been there since forever. > And, I didn't get the set_rtc_mmss messages when I did a service xprint > restart. > And then it "xprinted" right away just fine? > Is this even connected to Xprint, that looks like something from maybe ntp? > "set_rtc_mmss: can't update from 7 to 59" is printk()ed from here: linux-2.6.12-RT/include/asm-i386/mach-default/mach_time.h /* * In order to set the CMOS clock precisely, set_rtc_mmss has to be * called 500 ms after the second nowtime has started, because when * nowtime is written into the registers of the CMOS clock, it will * jump to the next second precisely 500 ms later. Check the Motorola * MC146818A or Dallas DS12887 data sheet for details. * * BUG: This routine does not handle hour overflow properly; it just * sets the minutes. Usually you'll only notice that after reboot! */ static inline int mach_set_rtc_mmss(unsigned long nowtime) so its a rtc timingrelated. which PREEMPT_RT / mode 4 was the last one to do it on the fly ? > And of course in mode 4, tvtime has a blue screen. But you knew that. :) > what is tvtime supposed to do, is it a wine thing as in "bleu screen"? Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Sonntag, 17. Juli 2005 14:07 schrieb Karsten Wiese:
> Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
> >
> > * Karsten Wiese <[EMAIL PROTECTED]> wrote:
> >
> > > Have I corrected the other path of ioapic early initialization, which
> > > had lacked virtual-address setup before ioapic_data[ioapic] was to be
> > > filled in -51-28? Please test attached patch on top of -51-29 or
> > > later. Also on Systems that liked -51-28.
> >
> > thanks - i've applied it to my tree and have released the -51-31 patch.
> > It looks good on my testboxes.
> >
> Found another error:
> the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
>
>
and another: some NULL-pointers are used in -51-31 instead of ioapic_data[0].
Please apply attached patch on top of -51-31. It includes yesterday's fix.
Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c 2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-19 12:53:00.0 +0200
@@ -158,7 +158,7 @@
static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
int reg;
- for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
}
# endif
@@ -1396,8 +1396,8 @@
* Add it to the IO-APIC irq-routing table:
*/
spin_lock_irqsave(&ioapic_lock, flags);
- io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
- io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
+ io_apic_write(ioapic_data[0], 0x11+2*pin, *(((int *)&entry)+1));
+ io_apic_write(ioapic_data[0], 0x10+2*pin, *(((int *)&entry)+0));
spin_unlock_irqrestore(&ioapic_lock, flags);
enable_8259A_irq(0);
@@ -2087,25 +2087,25 @@
* races.
*/
static struct hw_interrupt_type ioapic_edge_type = {
- .typename = "IO-APIC-edge",
+ .typename = "IO-APIC-edge",
.startup = startup_edge_ioapic,
.shutdown = shutdown_edge_ioapic,
.enable = enable_edge_ioapic,
.disable = disable_edge_ioapic,
.ack = ack_edge_ioapic,
.end = end_edge_ioapic,
- .set_affinity = set_ioapic_affinity,
+ .set_affinity = set_ioapic_affinity,
};
static struct hw_interrupt_type ioapic_level_type = {
- .typename = "IO-APIC-level",
+ .typename = "IO-APIC-level",
.startup = startup_level_ioapic,
.shutdown = shutdown_level_ioapic,
.enable = enable_level_ioapic,
.disable = disable_level_ioapic,
.ack = mask_and_ack_level_ioapic,
.end = end_level_ioapic,
- .set_affinity = set_ioapic_affinity,
+ .set_affinity = set_ioapic_affinity,
};
static inline void init_IO_APIC_traps(void)
@@ -2169,13 +2169,13 @@
static void end_lapic_irq (unsigned int i) { /* nothing */ }
static struct hw_interrupt_type lapic_irq_type = {
- .typename = "local-APIC-edge",
- .startup = NULL, /* startup_irq() not used for IRQ0 */
- .shutdown = NULL, /* shutdown_irq() not used for IRQ0 */
- .enable = enable_lapic_irq,
- .disable = disable_lapic_irq,
- .ack = ack_lapic_irq,
- .end = end_lapic_irq
+ .typename = "local-APIC-edge",
+ .startup = NULL, /* startup_irq() not used for IRQ0 */
+ .shutdown = NULL, /* shutdown_irq() not used for IRQ0 */
+ .enable = enable_lapic_irq,
+ .disable = disable_lapic_irq,
+ .ack = ack_lapic_irq,
+ .end = end_lapic_irq
};
static void setup_nmi (void)
@@ -2209,16 +2209,17 @@
struct IO_APIC_route_entry entry0, entry1;
unsigned char save_control, save_freq_select;
unsigned long flags;
+ struct ioapic_data_struct *ioapic0 = ioapic_data[0];
pin = find_isa_irq_pin(8, mp_INT);
if (pin == -1)
return;
spin_lock_irqsave(&ioapic_lock, flags);
- *(((int *)&entry0) + 1) = io_apic_read(0, 0x11 + 2 * pin);
- *(((int *)&entry0) + 0) = io_apic_read(0, 0x10 + 2 * pin);
+ *(((int *)&entry0) + 1) = io_apic_read(ioapic0, 0x11 + 2 * pin);
+ *(((int *)&entry0) + 0) = io_apic_read(ioapic0, 0x10 + 2 * pin);
spin_unlock_irqrestore(&ioapic_lock, flags);
- clear_IO_APIC_pin(0, pin);
+ clear_IO_APIC_pin(ioapic0, pin);
memset(&entry1, 0, sizeof(entry1));
@@ -2231,8 +2232,8 @@
entry1.vector = 0;
spin_lock_irqsave(&ioapic_lock, flags);
- io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry1) + 1));
- io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry1) + 0));
+ io_apic_write(ioapic0, 0x11 + 2 * pin, *(((int *)&entry1) + 1));
+ io_apic_write(ioapic0, 0x10 + 2 * pin, *(((int *)&entry1) + 0));
spin_unlock_irqrestore(&ioapic_lock, flags);
save_control = CMOS_READ(RTC_CONTROL);
@@ -2250,11 +2251,11 @@
CMOS_WRITE(save_control, RTC_CONTROL);
CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
- clear_IO_APIC_pin(0, pin);
+ clear_IO_APIC_pin(ioapic0, pin);
spin_lock_irqsave(&ioapic_lock, flags);
- io_a
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Samstag, 16. Juli 2005 19:15 schrieb Ingo Molnar:
>
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > Have I corrected the other path of ioapic early initialization, which
> > had lacked virtual-address setup before ioapic_data[ioapic] was to be
> > filled in -51-28? Please test attached patch on top of -51-29 or
> > later. Also on Systems that liked -51-28.
>
> thanks - i've applied it to my tree and have released the -51-31 patch.
> It looks good on my testboxes.
>
Found another error:
the ioapic cache isn't fully initialized in -51-31's ioapic_cache_init().
Please apply attached patch on top of -51-31.
Karsten
--- linux-2.6.12-RT-51-31/arch/i386/kernel/io_apic.c 2005-07-17 12:40:35.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-17 13:33:06.0 +0200
@@ -158,7 +158,7 @@
static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
int reg;
- for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ for (reg = 0; reg < (0x10 + 2 * ioapic->nr_registers); reg++)
ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
}
# endif
Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Am Mittwoch, 13. Juli 2005 02:08 schrieb William Weston: > On Wed, 13 Jul 2005, Karsten Wiese wrote: > > > i've only tested on 2005ish [EMAIL PROTECTED]: it doesn't need any of the > > quirks > > IOAPIC_POSTFLUSH, sis_bug, level-edge cleanup. > > IOAPIC_POSTFLUSH caused no negative influence neither. > > i've an io_apic_one.c here, that doesn't have any of the quirks and is > > stripped down > > to handle just one ioapic. It runs just fine on PREEMPT_RT. > > Could be used as a "Do i crash/suffer without the quirks?" test for 1 > > ioapic equipped machines. > > Should i post it? > > Please do. I'll give it a spin on several machines and let you know how > it goes ;-} > This is it. Apply it on top of -51-30 and 'make oldconfig'. You'll be asked about the new CONFIG_ONE_IOAPIC. Answering yes, io_apic_one.c will be used, which is ((io_apic.c minus quirks) minus multi_io_apic_capability) . It'll propably crash some machines, as the quirks are there for some reason... With CONFIG_ONE_IOAPIC unset, you'll get the same kernel as with my previously sent patch. have fun :-) Karsten io_apic-RT-51-30+io_apic_one.bz2 Description: BZip2 compressed data
Re: Realtime Preemption, 2.6.12, Beginners Guide?
Am Mittwoch, 13. Juli 2005 16:01 schrieb K.R. Foley:
> Ingo Molnar wrote:
> > * Chuck Harding <[EMAIL PROTECTED]> wrote:
> >
> >
> >>>CC [M] sound/oss/emu10k1/midi.o
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error before '__attribute__'
> >>>sound/oss/emu10k1/midi.c:48: error: syntax error before ')' token
> >>>
> >>>Here's the offending line:
> >>>
> >>> 48 static DEFINE_SPINLOCK(midi_spinlock __attribute((unused)));
> >>>
> >>>Lee
> >>>
> >>
> >>I got it to compile but it won't boot - it hangs right after the
> >>'Uncompressing Linux... OK, booting the kernel' - I'm using .config
> >>from 51-27 (attached)
> >
> >
> > and -51-27 worked just fine? I've uploaded -29 with the -28 io-apic
> > changes undone (will re-apply them once Karsten has figured out what's
> > wrong).
> >
> > Ingo
>
> I too had the same problem booting -51-28 on my older SMP system at
> home. -51-29 just booted fine.
>
Have I corrected the other path of ioapic early initialization, which had lacked
virtual-address setup before ioapic_data[ioapic] was to be filled in -51-28?
Please test attached patch on top of -51-29 or later.
Also on Systems that liked -51-28.
thanks, Karsten
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/apic.c ./arch/i386/kernel/apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/apic.c 2005-07-14 12:31:33.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/apic.c 2005-07-14 12:34:53.0 +0200
@@ -832,10 +832,10 @@
ioapic_phys = (unsigned long)
alloc_bootmem_pages(PAGE_SIZE);
ioapic_phys = __pa(ioapic_phys);
+set_fixmap_nocache(idx, ioapic_phys);
+printk(KERN_DEBUG "faked IOAPIC to %08lx (%08lx)\n",
+ __fix_to_virt(idx), ioapic_phys);
}
- set_fixmap_nocache(idx, ioapic_phys);
- printk(KERN_DEBUG "mapped IOAPIC to %08lx (%08lx)\n",
- __fix_to_virt(idx), ioapic_phys);
idx++;
}
}
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c ./arch/i386/kernel/io_apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c 2005-07-09 23:49:21.0 +0200
+++ linux-2.6.12-RT/arch/i386/kernel/io_apic.c 2005-07-14 12:34:54.0 +0200
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,11 +56,6 @@
int sis_apic_bug = -1;
/*
- * # of IRQ routing registers
- */
-int nr_ioapic_registers[MAX_IO_APICS];
-
-/*
* Rough estimation of how many shared IRQs there are, can
* be changed anytime.
*/
@@ -132,88 +128,74 @@
# define IOAPIC_CACHE
#endif
-#ifdef IOAPIC_CACHE
-# define MAX_IOAPIC_CACHE 512
-/*
- * Cache register values:
- */
-static struct {
- unsigned int reg;
- unsigned int val[MAX_IOAPIC_CACHE];
-} io_apic_cache[MAX_IO_APICS]
- cacheline_aligned_in_smp;
+
+struct ioapic_data_struct {
+ struct sys_device dev;
+ int nr_registers; // # of IRQ routing registers
+ volatile unsigned int *base;
+ struct IO_APIC_route_entry *entry;
+#ifdef IOAPIC_CACHE
+ unsigned int reg_set;
+ u32 cached_val[0];
#endif
+};
-volatile unsigned int *io_apic_base[MAX_IO_APICS];
+static struct ioapic_data_struct *ioapic_data[MAX_IO_APICS];
-static inline unsigned int __raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+static inline unsigned int __raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
- volatile unsigned int *io_apic;
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].reg = reg;
-#endif
- io_apic = io_apic_base[apic];
- io_apic[0] = reg;
- return io_apic[4];
+# ifdef IOAPIC_CACHE
+ ioapic->reg_set = reg;
+# endif
+ ioapic->base[0] = reg;
+ return ioapic->base[4];
}
-unsigned int raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+# ifdef IOAPIC_CACHE
+static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
- unsigned int val = __raw_io_apic_read(apic, reg);
+ int reg;
+ for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
+}
+# endif
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].val[reg] = val;
-#endif
+
+static unsigned int raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+ unsigned int val = __raw_io_apic_read(ioapic, reg);
+
+# ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+# endif
return val;
}
-unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+static unsigned int io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
-#ifdef IOAPIC_CACHE
- if (unlikely(reg >= MAX_IOAPIC_CACHE)) {
- static int once = 1;
-
- if (once) {
- once = 0;
- printk("WARNING: ioapic register cache overflow: %d.\n",
-reg);
- dump_stack();
- }
- return __raw_io_apic_read(apic, reg);
- }
- if (io_apic_cache[apic].val[reg] && !sis_apic_bug) {
- io_apic_cache[apic].reg = -1;
- return io_apic_cache[apic].val[reg];
+# ifdef IOAPIC_CACHE
+ if (likely(!sis_apic_bug)) {
+ ioapic->reg_set = -1;
+ return ioapic->cached_val[reg];
}
-#endif
- return raw_io_apic_read(apic, reg);
+# endif
+ return raw_io_apic_
Re: Realtime Preemption, 2.6.12, Beginners Guide?
--- Ingo Molnar <[EMAIL PROTECTED]> schrieb: > > hm, -28 is broken, and your patch is the only significant > change: > > - Forwarded message from Chuck Harding > <[EMAIL PROTECTED]> - > > Date: Tue, 12 Jul 2005 14:01:04 -0700 (PDT) > From: Chuck Harding <[EMAIL PROTECTED]> > To: Linux Kernel Discussion List > > Subject: Re: Realtime Preemption, 2.6.12, Beginners > Guide? > Cc: Ingo Molnar <[EMAIL PROTECTED]> > > On Tue, 12 Jul 2005, Lee Revell wrote: > > >On Mon, 2005-07-11 at 17:07 +0200, Ingo Molnar wrote: > >>I've uploaded -27 with the fix - but it should > >>only confirm that it's not a stack overflow. > > > >V0.7.51-28 does not compile: > > > > CC [M] sound/oss/emu10k1/midi.o > >sound/oss/emu10k1/midi.c:48: error: syntax error before > '__attribute__' > >sound/oss/emu10k1/midi.c:48: error: syntax error before > ')' token > > > >Here's the offending line: > > > > 48 static DEFINE_SPINLOCK(midi_spinlock > __attribute((unused))); > > > >Lee > > > > I got it to compile but it won't boot - it hangs right > after the > 'Uncompressing Linux... OK, booting the kernel' - I'm > using .config > from 51-27 (attached) > Please unselect CONFIG_X86_IOAPIC_FAST and try 51-28 again. Also please boot the newest "working for you" RT kernel with the kernel parameter 'apic=debug' added. Post the dmesg that you get right after boot. Karsten ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Am Dienstag, 12. Juli 2005 16:25 schrieb Daniel Walker: > On Tue, 2005-07-12 at 16:02 +0200, Ingo Molnar wrote: > > * Karsten Wiese <[EMAIL PROTECTED]> wrote: > > > > > Hi Ingo > > > > > > I've refined io_apic.c a little more: > > > > great. I've applied these changes and have released the -28 patch. (note > > that the last chunk of your patch was malformed, have applied it by > > hand.) > > > > i'm wondering what your thoughts are about IOAPIC_POSTFLUSH - i had to > > turn it on unconditionally again, to get rid of spurious interrupts and > > outright interrupt storms (and resulting lockups) on some systems. > > IOAPIC_POSTFLUSH is now causing much of the IO-APIC related IRQ handling > > overhead. > > I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on, > would actually cause spurious interrupts. It was odd cause it's suppose > to stop them .. If there was a lot of interrupt traffic on one IRQ , it > would cause interrupt traffic on another IRQ. This would result in > "nobody cared" messages , and the storming IRQ line would get shutdown. > > This would only happen in PREEMPT_RT . > i've only tested on 2005ish [EMAIL PROTECTED]: it doesn't need any of the quirks IOAPIC_POSTFLUSH, sis_bug, level-edge cleanup. IOAPIC_POSTFLUSH caused no negative influence neither. i've an io_apic_one.c here, that doesn't have any of the quirks and is stripped down to handle just one ioapic. It runs just fine on PREEMPT_RT. Could be used as a "Do i crash/suffer without the quirks?" test for 1 ioapic equipped machines. Should i post it? On vanilla level-interrupts behave "nervously" showing the "doubled rate" effect: For level interrupts vanilla just sends an EOI to the apic. Nothing else should be necessary (io)apic wise. Only here, when the edge-level triggered hardware-handler acknowledges its client (== resets the interrupt line) the doubled level interrupt is triggered on the same pin. Thus the same interrupt routine runs again as soon as EOI has been sent and IFlag is open again. hardware-handler receives it, does nothing and returns with "uninterested" <http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24
Hi Ingo
I've refined io_apic.c a little more:
- merged all ioapic data into a struct ioapic_data_struct
- Allocate the ioapic cache memory from bootmem. Allocate only,
what is needed ((nr of registers + 5)*sizeod(u64)).
- Removed "cache overrun by reg out of bounds" check.
this should never happen, as reg is calculated out of irq_2_pin[irq].pin.
- Do the index lookup
struct ioapic_data_struct *ioapic = ioapic_data[apic];
as early and as rarely as possible.
In the consequence many functions parameter changed from
io_apic_*(unsigned int apic,
to
io_apic_*(struct ioapic_data_struct *ioapic,
- New function setup_IO_APIC_early(int _ioapic).
It does the setup of the ioapic's struct ioapic_data_struct.
if IOAPIC_CACHE is defined, it calls the also new function
ioapic_cache_init().
ioapic_cache_init() initializes the cache completely.
Thereby we may safely omit to query a caches elements validity before
reading it.
Works fine here applied against -51-27
Karsten
diff -ur ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c ./arch/i386/kernel/io_apic.c
--- ../linux-2.6.12-RT-51-23/arch/i386/kernel/io_apic.c 2005-07-09 23:49:21.0 +0200
+++ ./arch/i386/kernel/io_apic.c 2005-07-12 01:08:34.0 +0200
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,11 +56,6 @@
int sis_apic_bug = -1;
/*
- * # of IRQ routing registers
- */
-int nr_ioapic_registers[MAX_IO_APICS];
-
-/*
* Rough estimation of how many shared IRQs there are, can
* be changed anytime.
*/
@@ -132,88 +128,74 @@
# define IOAPIC_CACHE
#endif
-#ifdef IOAPIC_CACHE
-# define MAX_IOAPIC_CACHE 512
-/*
- * Cache register values:
- */
-static struct {
- unsigned int reg;
- unsigned int val[MAX_IOAPIC_CACHE];
-} io_apic_cache[MAX_IO_APICS]
- cacheline_aligned_in_smp;
+
+struct ioapic_data_struct {
+ struct sys_device dev;
+ int nr_registers; // # of IRQ routing registers
+ volatile unsigned int *base;
+ struct IO_APIC_route_entry *entry;
+#ifdef IOAPIC_CACHE
+ unsigned int reg_set;
+ u32 cached_val[0];
#endif
+};
-volatile unsigned int *io_apic_base[MAX_IO_APICS];
+static struct ioapic_data_struct *ioapic_data[MAX_IO_APICS];
-static inline unsigned int __raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+static inline unsigned int __raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
- volatile unsigned int *io_apic;
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].reg = reg;
-#endif
- io_apic = io_apic_base[apic];
- io_apic[0] = reg;
- return io_apic[4];
+# ifdef IOAPIC_CACHE
+ ioapic->reg_set = reg;
+# endif
+ ioapic->base[0] = reg;
+ return ioapic->base[4];
}
-unsigned int raw_io_apic_read(unsigned int apic, unsigned int reg)
+
+# ifdef IOAPIC_CACHE
+static void __init ioapic_cache_init(struct ioapic_data_struct *ioapic)
{
- unsigned int val = __raw_io_apic_read(apic, reg);
+ int reg;
+ for (reg = 0; reg < (ioapic->nr_registers + 10); reg++)
+ ioapic->cached_val[reg] = __raw_io_apic_read(ioapic, reg);
+}
+# endif
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].val[reg] = val;
-#endif
+
+static unsigned int raw_io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
+{
+ unsigned int val = __raw_io_apic_read(ioapic, reg);
+
+# ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+# endif
return val;
}
-unsigned int io_apic_read(unsigned int apic, unsigned int reg)
+static unsigned int io_apic_read(struct ioapic_data_struct *ioapic, unsigned int reg)
{
-#ifdef IOAPIC_CACHE
- if (unlikely(reg >= MAX_IOAPIC_CACHE)) {
- static int once = 1;
-
- if (once) {
- once = 0;
- printk("WARNING: ioapic register cache overflow: %d.\n",
-reg);
- dump_stack();
- }
- return __raw_io_apic_read(apic, reg);
- }
- if (io_apic_cache[apic].val[reg] && !sis_apic_bug) {
- io_apic_cache[apic].reg = -1;
- return io_apic_cache[apic].val[reg];
+# ifdef IOAPIC_CACHE
+ if (likely(!sis_apic_bug)) {
+ ioapic->reg_set = -1;
+ return ioapic->cached_val[reg];
}
-#endif
- return raw_io_apic_read(apic, reg);
+# endif
+ return raw_io_apic_read(ioapic, reg);
}
-void io_apic_write(unsigned int apic, unsigned int reg, unsigned int val)
+static void io_apic_write(struct ioapic_data_struct *ioapic, unsigned int reg, unsigned int val)
{
- volatile unsigned int *io_apic;
-#ifdef IOAPIC_CACHE
- if (unlikely(reg >= MAX_IOAPIC_CACHE)) {
- static int once = 1;
-
- if (once) {
- once = 0;
- printk("WARNING: ioapic register cache overflow: %d.\n",
-reg);
- dump_stack();
- }
- } else
- io_apic_cache[apic].val[reg] = val;
-#endif
- io_apic = io_apic_base[apic];
-#ifdef IOAPIC_CACHE
- io_apic_cache[apic].reg = reg;
-#endif
- io_apic[0] = reg;
- io_apic[4] = val;
+# ifdef IOAPIC_CACHE
+ ioapic->cached_val[reg] = val;
+ ioapic->reg_set = reg;
+# endif
+ ioapic->base[0] = reg;
+ ioapic->base[4] = val;
}
+
/*
* Some systems need a POST flush or else level-triggered interrupts
* generate lots of spurious i
