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 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
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 &g
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
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 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
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:
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
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, )
before and after poll()call: i.e
ise 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.
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
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
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?
> >
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 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 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
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
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
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
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
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 >
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
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?
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
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
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
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
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
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
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
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
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
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
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
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/s
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.h
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 spl
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
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
---
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
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 <[EM
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
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
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
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
Move atomic_set(>underrun, 0) and atomic_set(>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
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
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
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
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
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
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
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
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
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
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 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:
snip
static int uhci_result_isochronous
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
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
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
> 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
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
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
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
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
> $ 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
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
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
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
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-
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
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
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?
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)
>
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
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-Assert Messages' by d
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
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
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
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,
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?
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
---
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
---
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
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
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-
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
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
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
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
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
1 - 100 of 132 matches
Mail list logo
