On Fri, 22 April 2005 11:22:51 +0300, Denis Vlasenko wrote:
>
> I do it this way:
>
> int f()
> {
> - tuple_t tuple;
> - cisparse_t parse;
> - u_char buf[255];
> + struct {
> + tuple_t tuple;
> + cisparse_t parse;
> + u_char buf[255];
> + }
On Fri, 22 April 2005 11:22:51 +0300, Denis Vlasenko wrote:
I do it this way:
int f()
{
- tuple_t tuple;
- cisparse_t parse;
- u_char buf[255];
+ struct {
+ tuple_t tuple;
+ cisparse_t parse;
+ u_char buf[255];
+ } local;
+
:0
EIP:0060:[<>]Not tainted VLI
EFLAGS: 00010286 (2.6.12-rc2-mm3)
EIP is at 0x0
eax: c1617ec0 ebx: c1617ec0 ecx: edx: c1771a50
esi: edi: c1617f34 ebp: df0fee40 esp: dec6ff2c
ds: 007b es: 007b ss: 0068
Process rpciod/0 (pid: 8166, thre
port patch and the generic
allocator patch (genalloc).
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
diff -urN -X /usr/people/jes/exclude-linux
linux-2.6.12-rc2-mm3-vanilla/arch/ia64/Kconfig
linux-2.6.12-rc2-mm3/arch/ia64/Kconfig
--- linux-2.6.12-rc2-mm3-vanilla/arch/ia64/Kconf
On Friday 22 April 2005 01:02, Yum Rayan wrote:
> This patch reduces the stack usage of the function smc91c92_event() in
> smc91c92_cs driver from 3540 to 132. Currently this is the highest
> stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
> 3.4.3 on i386 wi
On Friday 22 April 2005 01:02, Yum Rayan wrote:
This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time
, formerly known as fetchop. Mostly Used by parallel
appplictions.
This patch relies on the PG_uncached support patch and the generic
allocator patch (genalloc).
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -urN -X /usr/people/jes/exclude-linux
linux-2.6.12-rc2-mm3-vanilla/arch/ia64
:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.12-rc2-mm3)
EIP is at 0x0
eax: c1617ec0 ebx: c1617ec0 ecx: edx: c1771a50
esi: edi: c1617f34 ebp: df0fee40 esp: dec6ff2c
ds: 007b es: 007b ss: 0068
Process rpciod/0 (pid: 8166, threadinfo=dec6f000
to test it.
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>
serial_cs.c | 170 ++--
1 files changed, 110 insertions(+), 60 deletions(-)
diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/dr
This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.
The patch has only been compile tested
This patch reduces the stack usage of the function smc91c92_event() in
smc91c92_cs driver from 3540 to 132. Currently this is the highest
stack user in linux-2.6.12-rc2-mm3. I used a patched version of gcc
3.4.3 on i386 with -fno-unit-at-a-time disabled.
The patch has only been compile tested
to test it.
Acked-by: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: Yum Rayan [EMAIL PROTECTED]
serial_cs.c | 170 ++--
1 files changed, 110 insertions(+), 60 deletions(-)
diff -Nupr -X dontdiff
linux-2.6.12-rc2-mm3.a/drivers/serial
On Wednesday, April 20, 2005 12:50 PM, Tom Duffy wrote:
> > The errors I encountered were:
> > Reading all physical volumes. This may take a while...
> > Umount /sys failed: 16
> > mount: error 6 mounting ext3
> > mount: error 2 mounting none
> > Switching to new root
> > Switchroot: mount failed
el you tested on your hw and worked for you?
>
> > That is a good question. I think it was a 2.6.11 kernel. It was
> > definately before express was moved to a different directory,
> > whenever that occured.
>
> Tom,
>
> I was not able to duplicate this problem on my system yet f
n. I think it was a 2.6.11 kernel. It was
> definately before express was moved to a different directory,
> whenever that occured.
Tom,
I was not able to duplicate this problem on my system yet for I have
trouble in getting my system booted up on 2.6.12-rc2-mm3. I did some
back-tracking and found that the
express was moved to a different directory,
whenever that occured.
Tom,
I was not able to duplicate this problem on my system yet for I have
trouble in getting my system booted up on 2.6.12-rc2-mm3. I did some
back-tracking and found that the boot problem occurred also with
2.6.12-rc2-mm2
think it was a 2.6.11 kernel. It was
definately before express was moved to a different directory,
whenever that occured.
Tom,
I was not able to duplicate this problem on my system yet for I have
trouble in getting my system booted up on 2.6.12-rc2-mm3. I did some
back-tracking
On Wednesday, April 20, 2005 12:50 PM, Tom Duffy wrote:
The errors I encountered were:
Reading all physical volumes. This may take a while...
Umount /sys failed: 16
mount: error 6 mounting ext3
mount: error 2 mounting none
Switching to new root
Switchroot: mount failed 22
umount
> This is wrong because in general the number of actual CPUs is _less_
> than the number of configured CPUs (== NR_CPUS). Hence the code will
> now check the NMI counts of non-existent CPUs, complain that they are
> stuck, and disable the NMI watchdog. Actually the disablement is broken
> in this
On Tue, 19 Apr 2005, Alexander Nyberg wrote:
> tis 2005-04-19 klockan 11:33 +0200 skrev Jesper Juhl:
> > Everything is fine with 2.6.12-rc2, 2.6.12-rc2-mm1, 2.6.12-rc2-mm2 &
> > earlier kernels as well, but 2.6.12-rc2-mm3 seems to have a problem.
> > I don't know what'
tis 2005-04-19 klockan 11:33 +0200 skrev Jesper Juhl:
> Everything is fine with 2.6.12-rc2, 2.6.12-rc2-mm1, 2.6.12-rc2-mm2 &
> earlier kernels as well, but 2.6.12-rc2-mm3 seems to have a problem.
> I don't know what's causing this, all I can do at the moment is describe
&
Andi & Andrew,
The "x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state.patch" in
2.6.12-rc2-mm3 appears to have broken the NMI watchdog. Specifically:
diff -puN
arch/x86_64/kernel/nmi.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
arch/x86_64/kernel/nmi.c
---
Andi Andrew,
The x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state.patch in
2.6.12-rc2-mm3 appears to have broken the NMI watchdog. Specifically:
diff -puN
arch/x86_64/kernel/nmi.c~x86_64-switch-smp-bootup-over-to-new-cpu-hotplug-state
arch/x86_64/kernel/nmi.c
---
25/arch/x86_64/kernel
tis 2005-04-19 klockan 11:33 +0200 skrev Jesper Juhl:
Everything is fine with 2.6.12-rc2, 2.6.12-rc2-mm1, 2.6.12-rc2-mm2
earlier kernels as well, but 2.6.12-rc2-mm3 seems to have a problem.
I don't know what's causing this, all I can do at the moment is describe
the symptoms.
Certain
On Tue, 19 Apr 2005, Alexander Nyberg wrote:
tis 2005-04-19 klockan 11:33 +0200 skrev Jesper Juhl:
Everything is fine with 2.6.12-rc2, 2.6.12-rc2-mm1, 2.6.12-rc2-mm2
earlier kernels as well, but 2.6.12-rc2-mm3 seems to have a problem.
I don't know what's causing this, all I can do
This is wrong because in general the number of actual CPUs is _less_
than the number of configured CPUs (== NR_CPUS). Hence the code will
now check the NMI counts of non-existent CPUs, complain that they are
stuck, and disable the NMI watchdog. Actually the disablement is broken
in this case,
On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:
> drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"
> Please do not #include .c files.
A tested patch would be appreciated.. ;-)
> A proper separation in a .c file and a header file is the better
> solution.
Agreed and
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> All 819 patches:
>...
> bk-netdev.patch
>...
drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"
drivers/net/wireless/hostap/hostap.c:#include "hostap_ap.c"
drivers/net/wireless/hostap/hostap.c:#include
ailure
point where the kernel complains about stuck NMIs.
I tried 2.6.12-rc2-mm3 SMP on UP amd64 and I immediately found a
bug triggering bogus stuck NMI failures, and I want to check if
what you're seeing is caused by the same bug.
> Also in -mm because nmi_hz is
>set to 1 in setup_k7_wat
mån 2005-04-18 klockan 13:14 +0200 skrev Arjan van de Ven:
> On Mon, 2005-04-18 at 13:05 +0200, Alexander Nyberg wrote:
> > [Proper patch now that goes all the way, sorry for spamming]
> >
> > Patch below uses RETIRED_UOPS for a more constant rate of NMI sending.
> > This makes x64 deliver NMI
On Mon, 2005-04-18 at 13:05 +0200, Alexander Nyberg wrote:
> [Proper patch now that goes all the way, sorry for spamming]
>
> Patch below uses RETIRED_UOPS for a more constant rate of NMI sending.
> This makes x64 deliver NMI interrupts every fourth second at a constant
> rate when going through
[Proper patch now that goes all the way, sorry for spamming]
Patch below uses RETIRED_UOPS for a more constant rate of NMI sending.
This makes x64 deliver NMI interrupts every fourth second at a constant
rate when going through the local apic. Makes both cpus on my box to get
NMIs at constant
> >This patch fixes the NMI checking problems in -mm x64 for me. It
>
> What problems?
>
Sorry, in -mm on x64 check_nmi_watchdog() has started to be run as a
late_initcall(). Currently it reports the NMIs as stuck on a few systems
although they are not, both of mine are reported as stuck. This
This patch fixes the NMI checking problems in -mm x64 for me. It
What problems?
Sorry, in -mm on x64 check_nmi_watchdog() has started to be run as a
late_initcall(). Currently it reports the NMIs as stuck on a few systems
although they are not, both of mine are reported as stuck. This
[Proper patch now that goes all the way, sorry for spamming]
Patch below uses RETIRED_UOPS for a more constant rate of NMI sending.
This makes x64 deliver NMI interrupts every fourth second at a constant
rate when going through the local apic. Makes both cpus on my box to get
NMIs at constant
On Mon, 2005-04-18 at 13:05 +0200, Alexander Nyberg wrote:
[Proper patch now that goes all the way, sorry for spamming]
Patch below uses RETIRED_UOPS for a more constant rate of NMI sending.
This makes x64 deliver NMI interrupts every fourth second at a constant
rate when going through the
mån 2005-04-18 klockan 13:14 +0200 skrev Arjan van de Ven:
On Mon, 2005-04-18 at 13:05 +0200, Alexander Nyberg wrote:
[Proper patch now that goes all the way, sorry for spamming]
Patch below uses RETIRED_UOPS for a more constant rate of NMI sending.
This makes x64 deliver NMI interrupts
tried 2.6.12-rc2-mm3 SMP on UP amd64 and I immediately found a
bug triggering bogus stuck NMI failures, and I want to check if
what you're seeing is caused by the same bug.
Also in -mm because nmi_hz is
set to 1 in setup_k7_watchdog() the NMI watchdog checking takes 10
seconds, a bit much
On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
...
All 819 patches:
...
bk-netdev.patch
...
drivers/net/wireless/hostap/hostap.c:#include hostap_crypt.c
drivers/net/wireless/hostap/hostap.c:#include hostap_ap.c
drivers/net/wireless/hostap/hostap.c:#include hostap_info.c
On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:
drivers/net/wireless/hostap/hostap.c:#include hostap_crypt.c
Please do not #include .c files.
A tested patch would be appreciated.. ;-)
A proper separation in a .c file and a header file is the better
solution.
Agreed and this
On Mon, 18 Apr 2005 00:27:02 +0200, Alexander Nyberg wrote:
>This patch fixes the NMI checking problems in -mm x64 for me. It
What problems?
>changes the perfctr selection to use RETIRED_UOPS instead
>(makes both processors tick even on my box).
This patch mixes what appears to be cleanups
mån 2005-04-11 klockan 01:25 -0700 skrev Andrew Morton:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
I tried to kexec on my x64 and it hangs up in calibrate_delay() because
the PIT never fires any interrupts so jiffies is never updated. Has
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
[Mikael Pettersson on CC, would like your advice]
This patch fixes the NMI checking problems in -mm x64 for me. It
changes the perfctr selection to use RETIRED_UOPS instead
(makes both p
.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>>
>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>
>> I think I finally found the culprit. Both rc2-mm3 and rc1-mm1 work
>> fine when I reverse the timer-* p
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
Juergen Kreileder [EMAIL PROTECTED] writes:
Andrew Morton [EMAIL PROTECTED] writes:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
I'm
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
[Mikael Pettersson on CC, would like your advice]
This patch fixes the NMI checking problems in -mm x64 for me. It
changes the perfctr selection to use RETIRED_UOPS instead
(makes both processors tick
mån 2005-04-11 klockan 01:25 -0700 skrev Andrew Morton:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
I tried to kexec on my x64 and it hangs up in calibrate_delay() because
the PIT never fires any interrupts so jiffies is never updated. Has
kexec
On Mon, 18 Apr 2005 00:27:02 +0200, Alexander Nyberg wrote:
This patch fixes the NMI checking problems in -mm x64 for me. It
What problems?
changes the perfctr selection to use RETIRED_UOPS instead
(makes both processors tick even on my box).
This patch mixes what appears to be cleanups with
On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
> Juergen Kreileder <[EMAIL PROTECTED]> writes:
>
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
I think I finall
Juergen Kreileder [EMAIL PROTECTED] writes:
Andrew Morton [EMAIL PROTECTED] writes:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
I think I finally found the culprit. Both rc2-mm3
On Fri, 2005-04-15 at 20:23 +0200, Juergen Kreileder wrote:
Juergen Kreileder [EMAIL PROTECTED] writes:
Andrew Morton [EMAIL PROTECTED] writes:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
I'm getting frequent lockups on my PowerMac G5
Hello.
Ingo Molnar wrote:
does the patch below fix the problem for you?
Works perfectly, thankyou!
-
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
Hello.
Ingo Molnar wrote:
does the patch below fix the problem for you?
Works perfectly, thankyou!
-
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
Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
> > Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> > >
> > > > Don't think so - it works OK here. Checked the .config? Does the
> serial
> > > > port work if you do `echo foo > /dev/ttyS0'? ACPI?
On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >
> > > Don't think so - it works OK here. Checked the .config? Does the serial
> > > port work if you do `echo foo > /dev/ttyS0'? ACPI?
> >
> > Turned out it was some old ups software that got
Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> > Don't think so - it works OK here. Checked the .config? Does the serial
> > port work if you do `echo foo > /dev/ttyS0'? ACPI?
>
> Turned out it was some old ups software that got reactivated on the box
> displaying the
> console - was a pain
On Tuesday 12 April 2005 07:39, Andrew Morton wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >
> > On Monday 11 April 2005 04:25, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> > &g
On Wed, 13 Apr 2005 16:02:48 +0100
Russell King <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 13, 2005 at 11:18:27PM +0900, Yoichi Yuasa wrote:
> > static struct uart_ops early_uart_ops = {
> > - .set_termios= early_set_termios,
> > + .set_termios= siu_set_termios,
> > };
>
> In this
On Tue, Apr 12, 2005 at 10:50:08AM -0400, Jes Sorensen wrote:
> +config MSPEC
> + tristate "Special Memory support"
> + select GENERIC_ALLOCATOR
should depend on IA64_GENERIC || IA64_SGI_SN2 because it's using sn2
functions like bte_copy
> +#define BTE_ZERO_BLOCK(_maddr, _len) \
> +
* Stas Sergeev <[EMAIL PROTECTED]> wrote:
> Hi Ingo.
>
> I have some programs that crash
> in 2.6.12-rc2-mm3. After seeing this:
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.1/1091.html
does the patch below fix the problem for you? (already in Andrew's tree,
shou
Hi Ingo.
I have some programs that crash
in 2.6.12-rc2-mm3. After seeing this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.1/1091.html
I tried to revert the
sched-unlocked-context-switches.patch
and indeed the problem goes away.
Attached is the (crappy) test-case.
If you can make it to say
On Wed, Apr 13, 2005 at 11:18:27PM +0900, Yoichi Yuasa wrote:
> static struct uart_ops early_uart_ops = {
> - .set_termios= early_set_termios,
> + .set_termios= siu_set_termios,
> };
In this case, you don't need the early_uart_ops here - the standard
ones will do just as well.
I had fixed Russell's comment.
On Wed, 30 Mar 2005 10:23:08 +0100
Russell King <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 07, 2005 at 09:20:22PM -0800, [EMAIL PROTECTED] wrote:
> > +static inline const char *siu_type_name(struct uart_port *port)
> > +{
> > + switch (port->type) {
> > + case
I had fixed Russell's comment.
On Wed, 30 Mar 2005 10:23:08 +0100
Russell King [EMAIL PROTECTED] wrote:
On Mon, Mar 07, 2005 at 09:20:22PM -0800, [EMAIL PROTECTED] wrote:
+static inline const char *siu_type_name(struct uart_port *port)
+{
+ switch (port-type) {
+ case
On Wed, Apr 13, 2005 at 11:18:27PM +0900, Yoichi Yuasa wrote:
static struct uart_ops early_uart_ops = {
- .set_termios= early_set_termios,
+ .set_termios= siu_set_termios,
};
In this case, you don't need the early_uart_ops here - the standard
ones will do just as well.
Hi Ingo.
I have some programs that crash
in 2.6.12-rc2-mm3. After seeing this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.1/1091.html
I tried to revert the
sched-unlocked-context-switches.patch
and indeed the problem goes away.
Attached is the (crappy) test-case.
If you can make it to say
* Stas Sergeev [EMAIL PROTECTED] wrote:
Hi Ingo.
I have some programs that crash
in 2.6.12-rc2-mm3. After seeing this:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.1/1091.html
does the patch below fix the problem for you? (already in Andrew's tree,
should be in the next -mm patch
On Tue, Apr 12, 2005 at 10:50:08AM -0400, Jes Sorensen wrote:
+config MSPEC
+ tristate Special Memory support
+ select GENERIC_ALLOCATOR
should depend on IA64_GENERIC || IA64_SGI_SN2 because it's using sn2
functions like bte_copy
+#define BTE_ZERO_BLOCK(_maddr, _len) \
+
On Wed, 13 Apr 2005 16:02:48 +0100
Russell King [EMAIL PROTECTED] wrote:
On Wed, Apr 13, 2005 at 11:18:27PM +0900, Yoichi Yuasa wrote:
static struct uart_ops early_uart_ops = {
- .set_termios= early_set_termios,
+ .set_termios= siu_set_termios,
};
In this case, you don't
On Tuesday 12 April 2005 07:39, Andrew Morton wrote:
Ed Tomlinson [EMAIL PROTECTED] wrote:
On Monday 11 April 2005 04:25, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
- The anticipatory I/O scheduler has always
Ed Tomlinson [EMAIL PROTECTED] wrote:
Don't think so - it works OK here. Checked the .config? Does the serial
port work if you do `echo foo /dev/ttyS0'? ACPI?
Turned out it was some old ups software that got reactivated on the box
displaying the
console - was a pain to disable
On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
Ed Tomlinson [EMAIL PROTECTED] wrote:
Don't think so - it works OK here. Checked the .config? Does the serial
port work if you do `echo foo /dev/ttyS0'? ACPI?
Turned out it was some old ups software that got reactivated on
Ed Tomlinson [EMAIL PROTECTED] wrote:
On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
Ed Tomlinson [EMAIL PROTECTED] wrote:
Don't think so - it works OK here. Checked the .config? Does the
serial
port work if you do `echo foo /dev/ttyS0'? ACPI?
Turned out
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
AS basically does its own TCQ strangulation, which IIRC involves things
> > like completing all reads before issuing new writes, and completing all
> > reads from one process before reads from another. As well as the
> >
orton <[EMAIL PROTECTED]> writes:
>>>>
>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>>>
>>>> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
>>>>
>>>> 2
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> test without it and let me know if it makes a difference ?
IIRC I had disabled that for rc2-mm2 and it didn't make a
difference. I'll disable it again
On Tue, Apr 12, 2005 at 09:53:02PM +0400, Stas Sergeev wrote:
> Hello.
>
> Andrew Morton wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> Fails to compile with
> !CONFIG_ACPI && CONFIG_SMP.
> CONFIG_SMP
>>
> See this patch from Steve French:
> http://cifs.bkbits.net:8080/linux-2.5cifs/[EMAIL PROTECTED]
Thanks, that fixed it.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> >>> Hrm... I just noticed you have CONFIG_PREEMPT enabled... Can you
> >>> test without it and let me know if it makes a difference ?
> >>
> >> IIRC I had disabled that for rc2-mm2 and it didn't make a
> >> difference. I'll disable it again when I try older versions.
> >>
> >> I just got
Hello.
Andrew Morton wrote:
OK, the `int $3' is part of the CONFIG_TRAP_BAD_SYSCALL_EXITS thing which I
never use.
I'm not sure what problem is actually being reported here, now you mention it.
The problem being reported here is that
CONFIG_TRAP_BAD_SYSCALL_EXITS does nothing
but locking up your
Hello.
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
Fails to compile with
!CONFIG_ACPI && CONFIG_SMP.
CONFIG_SMP sets CONFIG_X86_HT,
which sets CONFIG_ACPI_BOOT,
but that fails without CONFIG_ACPI:
CC arch/i386/kernel
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
- The effects of tcq on AS are much less disastrous than I thought they
> were. Do I have the wrong workload? Memory fails me. Or did we fix the
> anticipatory scheduler?
>
>
Yes, we did fix it ;)
Quite a long time ago, so
nk the ia64 port can operate without EFI
at all.
>> --- linux-2.6.12-rc2-mm3-vanilla/include/asm-ia64/sn/fetchop.h
>> 2005-03-01 23:38:12 -08:00 +++
>> linux-2.6.12-rc2-mm3/include/asm-ia64/sn/fetchop.h 1969-12-31
>> 16:00:00 -08:00
Andrew> Did you mean to remove fetch
on. If it disturbs you
too much back out
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/broken-out/rfc-check-nmi-watchdog-is-broken.patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
(-.)
oo| cc )
/`'\(+45) 2553 1337 3-n-(
(\_;/) [EMAIL PROTECTED]_(|/`->
dmesg-2.6.12-rc2-mm3
Description: Binary data
On Tuesday 12 April 2005 06:20, Stas Sergeev wrote:
Here we go again:
You might be right about the int3 instruction:
(gdb) disas 0xc0102ee0
Dump of assembler code for function restore_all:
0xc0102ed1 : mov0x30(%esp),%eax
0xc0102ed5 : mov0x2c(%esp),%al
0xc0102ed9 : test
Ed Tomlinson <[EMAIL PROTECTED]> wrote:
>
> On Monday 11 April 2005 04:25, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
> > - The anticipatory I/O scheduler has always been fairly
On Monday 11 April 2005 04:25, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
> - The anticipatory I/O scheduler has always been fairly useless with SCSI
> disks which perform tagged command queueing. There
It seems that ia64 Kconfig tries to turn on EFI always, but I thing
allnoconfig will turn it off)
> --- linux-2.6.12-rc2-mm3-vanilla/include/asm-ia64/sn/fetchop.h
> 2005-03-01 23:38:12 -08:00
> +++ linux-2.6.12-rc2-mm3/include/asm-ia64/sn/fetchop.h1969-12-31
> 16:00:00 -08
[EMAIL PROTECTED] (Jes Sorensen) wrote:
>
> + getpage:
> +/*
> + * Is this really correct?
> + */
> +page = alloc_pages(GFP_USER, 0);
> +spin_unlock(>lock);
> +return page;
> +
sleeping allocation inside a spinlock.
-
To unsubscribe from this list: send the line
[EMAIL PROTECTED] (Jes Sorensen) wrote:
>
> + if (atomic_dec(>refcnt) == 0) {
atomic_dec() normally returns void. ia64's returns int, which is a bit
risky for cross-arch developemnt.
atomic_dec_and_test() would be more conventional.
-
To unsubscribe from this list: send the line
mappings, formerly known as fetchop. Mostly Used by parallel
appplictions.
This patch relies on the PG_uncached support patch and the generic
allocator patch (genalloc).
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
diff -urN -X /usr/people/jes/exclude-linux
linux-2.6.12-rc2-mm3-vanill
Andrew Morton wrote:
> Jindrich Makovicka <[EMAIL PROTECTED]> wrote:
>
>>Andrew Morton wrote:
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>>
>>MPlayer randomly crashes in various pthread_* calls when
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > AS basically does its own TCQ strangulation, which IIRC involves things
> > > like completing all reads before issuing new writes, and completing all
> > > reads from one process before reads from another. As well as the
> > > fundamental way
On Mon, Apr 11 2005, Andrew Morton wrote:
> - CFQ is seriously, seriously read-starved on this workload.
>
> CFQ3:
>
> procs ---memory-- ---swap-- -io --system-- cpu
> r b swpd free buff cache si sobibo incs us sy id wa
> 1 5 1008
On Mon, 2005-04-11 at 23:19 -0700, Andrew Morton wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > >- The effects of tcq on AS are much less disastrous than I thought they
> > > were. Do I have the wrong workload? Memory fails me. Or did we fix
> > the
> > > anticipatory scheduler?
>
://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >>
> >> I'm getting frequent lockups on my PowerMac G5 with rc2-mm3.
> >>
> >> 2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
> >> -rc1-mm3) lock up
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> >- The effects of tcq on AS are much less disastrous than I thought they
> > were. Do I have the wrong workload? Memory fails me. Or did we fix the
> > anticipatory scheduler?
> >
> >
>
> Yes, we did fix it ;)
> Quite a long time ago, so maybe
Stas Sergeev <[EMAIL PROTECTED]> wrote:
>
> Hello.
>
> Andrew Morton wrote:
> >> Program received signal SIGTRAP, Trace/breakpoint trap.
> SIGTRAP - it looks like the "int $3"
> triggered, not "mov0x30(%esp),%eax",
> which is just the next insn and so the
> %eip points to it, but it might be
1 - 100 of 161 matches
Mail list logo
