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
On Wed, 2005-04-20 at 11:56 -0700, Sy, Dely L wrote:
> On Friday, April 15, 2005 12:48 PM, Tom Duffy wrote:
> > From: "Sy, Dely L" <[EMAIL PROTECTED]>
> > > Thanks for reporting this. I'll look into it. Which was the last
> > > kernel you tested on your hw and worked for you?
>
> > That is a
On Friday, April 15, 2005 12:48 PM, Tom Duffy wrote:
> From: "Sy, Dely L" <[EMAIL PROTECTED]>
> > Thanks for reporting this. I'll look into it. Which was the last
> > kernel 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
>
On Friday, April 15, 2005 12:48 PM, Tom Duffy wrote:
From: Sy, Dely L [EMAIL PROTECTED]
Thanks for reporting this. I'll look into it. Which was the last
kernel 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
On Wed, 2005-04-20 at 11:56 -0700, Sy, Dely L wrote:
On Friday, April 15, 2005 12:48 PM, Tom Duffy wrote:
From: Sy, Dely L [EMAIL PROTECTED]
Thanks for reporting this. I'll look into it. Which was the last
kernel you tested on your hw and worked for you?
That is a good question. I
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
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
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.
>
>
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 at the
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, 18 Apr 2005 11:56:15 +0200, Alexander Nyberg wrote:
>> >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
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
On Mon, 18 Apr 2005 11:56:15 +0200, Alexander Nyberg wrote:
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
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
kexec
> 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
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:
>>>
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/
> >
> > I'm getting frequent lockups on my
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
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 and
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 with
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/
> > >
> > >
> > > - The anticipatory I/O
* 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
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
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 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
> >
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote:
>> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>>
>>> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
Andrew Morton <[EMAIL PROTECTED]> writes:
>
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 sets CONFIG_X86_HT,
> which sets
>>
> 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/setup.o
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
> [ 19.617890] Testing NMI watchdog ... <6>ACPI: No ACPI bus support
> for 2-2 [ 19.705673] ACPI: No ACPI bus support for 2-2:1.0
> [ 20.002417] usb 3-2: new full speed USB device using uhci_hcd and
> address 2 [ 20.121763] ACPI: No ACPI bus support for 3-2
> [ 20.156293] ACPI: No ACPI
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 useless with SCSI
> > disks which
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's a patch here
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 using binary
>>codecs. 2.6.12-rc2-mm2 was ok.
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?
>
On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> >> Andrew Morton <[EMAIL PROTECTED]> writes:
> >>
> >>>
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
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
innocent. And besides, 0x30(%esp) is
EFLAGS, not OLDSS. So I
Andrew Morton wrote:
So it turns out that patch was broken. I've fixed it locally and the
results are good, but odd.
The machine is a 4GB x86_64 with aic79xx controllers and MAXTOR
ATLAS10K4_73WLS disks. ext2 filesystem.
The workload is continuous pagecache writeback versus
Andrew Morton wrote:
So it turns out that patch was broken. I've fixed it locally and the
results are good, but odd.
The machine is a 4GB x86_64 with aic79xx controllers and MAXTOR
ATLAS10K4_73WLS disks. ext2 filesystem.
The workload is continuous pagecache writeback versus
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
innocent. And besides, 0x30(%esp) is
EFLAGS, not OLDSS. So I think
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
innocent. And
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?
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 25888
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 that waiting for
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 using binary
codecs. 2.6.12-rc2-mm2 was ok. I tried to
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's a patch here from
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 useless with SCSI
disks which perform tagged
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 restore_all+0: mov0x30(%esp),%eax
0xc0102ed5 restore_all+4: mov0x2c(%esp),%al
[ 19.617890] Testing NMI watchdog ... 6ACPI: No ACPI bus support
for 2-2 [ 19.705673] ACPI: No ACPI bus support for 2-2:1.0
[ 20.002417] usb 3-2: new full speed USB device using uhci_hcd and
address 2 [ 20.121763] ACPI: No ACPI bus support for 3-2
[ 20.156293] ACPI: No ACPI bus
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 maybe
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/setup.o
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
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 another crash with rc2-mm3.
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
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 sets CONFIG_X86_HT,
which sets CONFIG_ACPI_BOOT,
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 when I try older versions.
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Tue, 2005-04-12 at 06:42 +0200, Juergen Kreileder wrote:
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
Andrew Morton [EMAIL PROTECTED] writes:
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
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
>> 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
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> - The anticipatory I/O scheduler has always been fairly useless with SCSI
>disks which perform tagged command queueing. There's a patch here from
> Jens
>which is designed to fix that up by constraining the number of requests
>which we'll
On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> 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.
>
> 2.6.11-mm4 works fine but
On Tue, 2005-04-12 at 03:18 +0200, Juergen Kreileder wrote:
> 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.
>
> 2.6.11-mm4 works fine but
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.
2.6.11-mm4 works fine but all 2.6.12 versions I've tried (all since
-rc1-mm3) lock up randomly. The
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 using binary
> codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse
>
On Apr 11, 2005 10:46 PM, Martin J. Bligh <[EMAIL PROTECTED]> wrote:
>
>
> --On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton <[EMAIL PROTECTED]>
> 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
Borislav Petkov <[EMAIL PROTECTED]> wrote:
>
> On Monday 11 April 2005 11:43, Andrew Morton wrote:
> > (Please do reply-to-all)
> >
> > "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > > On 04.11, Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
>
On Monday 11 April 2005 11:43, Andrew Morton wrote:
> (Please do reply-to-all)
>
> "J.A. Magallon" <[EMAIL PROTECTED]> wrote:
> > On 04.11, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-r
> > >c2/2.6.12-rc2-mm3/
> >
> > Is this not needed
--On Monday, April 11, 2005 01:25:32 -0700 Andrew Morton <[EMAIL PROTECTED]>
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
1 - 100 of 120 matches
Mail list logo
