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, 200
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 >
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
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?
> >
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
therwise 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 s
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?
> >
> &g
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
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 ht
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 u
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/stat
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
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
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'
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 Tho
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 res
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 local
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_ond
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/li
-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 split
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
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 Wie
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 i
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.
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
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
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
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 @@ stat
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
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 fre
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 followi
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
>
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 ha
> 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(stru
Am Sonntag, 19. November 2006 14:43 schrieb Ingo Molnar:
>
> * Karsten Wiese <[EMAIL PROTECTED]> wrote:
>
> > work_resched:
> > DISABLE_INTERRUPTS
> > call __schedule
> >
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
; 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
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 PROTEC
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
+++ l
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
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/0
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
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-A
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 opi
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? T
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/
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 s
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
+++ l
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 archite
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)) {
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
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 architectur
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()
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
>
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 P
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/cac
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
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,
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
> &g
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
> >
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
> > fille
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.
> > IOAPI
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
--- 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
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:
> >
>
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 ha
66 matches
Mail list logo
