On Mon, 8 Aug 2005, Richard Purdie wrote:
> The following patch (against -mm) cleared the problem up but I'm not
> sure how correct it is:
Almost. The new entry needs to be made dirty. new_entry is already made
young. entry is not.
---
Set dirty bit correctly in handle_pte_fault
new_entry is
I've done a bit of analysis:
cmpxchg fail fault mm=c3945b20 vma=c304ad84 addr=402cb000 write=2048
ptep=c2af5b2c pmd=c2bc5008 entry=886c0f7 new=886c077 current=886c077
Note the Dirty bit is set on entry and not new where it probably should
be...
ptep_cmpxchg(mm, address, pte, entry, new_entry)
On Mon, 2005-08-08 at 09:48 -0700, Christoph Lameter wrote:
> Ok. So we cannot set the dirty bit.
>
> Here is a patch that also prints the pte status immediately before
> ptep_cmpxchg. I guess this will show that dirty bit is already set.
>
> Does the ARM have some hardware capability to set dir
On Mon, 8 Aug 2005, Russell King wrote:
> ARM doesn't have cmpxchg nor does it have hardware access nor dirty
> bits. They're simulated in software.
Even the cmpxchg is simulated.
> What's the problem you're trying to solve?
A hang when starting X on ARM with rc4-mm1 which contains the page fa
On Mon, Aug 08, 2005 at 09:48:22AM -0700, Christoph Lameter wrote:
> On Sun, 7 Aug 2005, Richard Purdie wrote:
>
> > > > We know the the failure case can be identified by the
> > > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > > patch to dump useful debugging info
On Sun, 7 Aug 2005, Richard Purdie wrote:
> > > We know the the failure case can be identified by the
> > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > patch to dump useful debugging information when that occurs?
>
> Ok, this results in an infinite loop of one me
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
21:21:30 -0700):
> --"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
> 18:17:33 -0700):
>> --Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005
>> 23:10:29 -0700):
>>
>>> "Mar
On Fri, 2005-08-05 at 08:17 -0700, Christoph Lameter wrote:
> On Thu, 4 Aug 2005, Richard Purdie wrote:
> >
> > We know the the failure case can be identified by the
> > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > patch to dump useful debugging information when that
On Thu, 4 Aug 2005, Richard Purdie wrote:
> I'm at a disadvantage here as the linux mm system is one area I've
> avoided getting too deeply involved with so far. My knowledge is
> therefore limited and I won't know what correct or incorrect behaviour
> would look like.
>
> We know the the failure
Hello Andrew,
Andrew Morton wrote:
Michael, I'm assuming that a) this problem remains in those -mm kernels
which include git-acpi.patch and that b) the problems are not present in
2.6.13-rc5 or 2.6.13-rc6, yes?
a.) I don't have any problems in 2.6.13-rc5-git[1-3] and 2.6.13-rc4-mm1
they are
Michael Thonke <[EMAIL PROTECTED]> wrote:
>
> Moore, Robert schrieb:
>
> >+ACPI-0287: *** Error: Region SystemMemory(0) has no handler
> >+ACPI-0127: *** Error: acpi_load_tables: Could not load namespace:
> >AE_NOT_EXIST
> >+ACPI-0136: *** Error: acpi_load_tables: Could not load tables
On Thu, 2005-08-04 at 07:04 -0700, Christoph Lameter wrote:
> On Thu, 4 Aug 2005, Richard Purdie wrote:
>
> > On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > > Could you try the following patch? I think the problem was that higher
> > > addressses were not mappable via the page fa
On Thu, 4 Aug 2005, Richard Purdie wrote:
> On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > Could you try the following patch? I think the problem was that higher
> > addressses were not mappable via the page fault handler. This patch
> > inserts the pmd entry into the pgd as nec
On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> Could you try the following patch? I think the problem was that higher
> addressses were not mappable via the page fault handler. This patch
> inserts the pmd entry into the pgd as necessary if the pud level is
> folded.
I tried this
Could you try the following patch? I think the problem was that higher
addressses were not mappable via the page fault handler. This patch
inserts the pmd entry into the pgd as necessary if the pud level is
folded.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc4/mm
--"Martin J. Bligh" <[EMAIL PROTECTED]> wrote (on Tuesday, August 02, 2005
18:17:33 -0700):
> --Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005
> 23:10:29 -0700):
>
>> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>>>
>>> NUMA-Q boxes are still crashing on boot with -mm BTW.
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, July 28, 2005 23:10:29
-0700):
> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>>
>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>> identified earlier with the sched patches ...
>>
>> http://test.kernel.org/9398
On Wed, 3 Aug 2005, Ivan Kokshaysky wrote:
>
> On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote:
> > Nice, care to make up a single patch with these two changes in it?
>
> Yep, I'll do it shortly, plus some minor additions as separate
> patches.
Actually, since everybody seems to like th
On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote:
> Nice, care to make up a single patch with these two changes in it?
Yep, I'll do it shortly, plus some minor additions as separate
patches.
Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote:
> So I think it would be much easier to just make the change in
> "pci_bus_alloc_resource()", and say that if the parent resource that we're
> testing starts at some non-zero value, we just use that instead of "min"
> when we call do
On Wed, Aug 03, 2005 at 01:13:37AM +0400, Ivan Kokshaysky wrote:
> On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote:
> > So I think it would be much easier to just make the change in
> > "pci_bus_alloc_resource()", and say that if the parent resource that we're
> > testing starts at s
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote:
>
> Right, and this hurts the cardbus as well...
> But it should be pretty easy to learn the PCI layer to allocate above
> PCIBIOS_MIN_IO _only_ when we allocate on the root bus.
> Something like this (completely untested)?
I think you'd have to follow
On Tue, Aug 02, 2005 at 08:48:21AM -0700, Linus Torvalds wrote:
> The problem with this is that it only papers over the bug.
>
> I don't mind trying to allocate at higher addresses per se: we used to
> have the starting point be 0x4000 at some point, and that part is fine.
> The problem is that
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote:
>
> Does the patch in appended message fix that?
The problem with this is that it only papers over the bug.
I don't mind trying to allocate at higher addresses per se: we used to
have the starting point be 0x4000 at some point, and that part is fine.
On Tue, Aug 02, 2005 at 03:40:22PM +0400, Ivan Kokshaysky wrote:
> On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote:
> > Does not work on -rc4-mm1. The IO-ports pre-reserved message appears,
> > though. The 2 io-regions are still located under the "CardBus #03"
> > device. Re-Applying
>
On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote:
> Does not work on -rc4-mm1. The IO-ports pre-reserved message appears,
> though. The 2 io-regions are still located under the "CardBus #03"
> device. Re-Applying
> "revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it
> wor
On Tue, Aug 02, 2005 at 11:49:28AM +0200, Stelian Pop wrote:
> Le lundi 01 ao??t 2005 ?? 16:37 +0200, Stelian Pop a ??crit :
>
> > > Also, it looks like sonypi really is pretty nasty to probe for, so it's
> > > not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> > > Other
Le lundi 01 août 2005 à 16:37 +0200, Stelian Pop a écrit :
> > Also, it looks like sonypi really is pretty nasty to probe for, so it's
> > not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> > Otherwise I'd just suggest adding a "dmi_check_system()" table to
> > arch/i38
On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
> Hmmm. this should have returned the behavior to normal. Ah. Need to use
> new_entry instead of entry. Try this (is there any way that I could get
> access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
>
> +#ifdef CO
On Tue, 2 Aug 2005, Richard Purdie wrote:
> > + update_mmu_cache(vma, address, entry);
> > + lazy_mmu_prot_update(entry);
> > +#endif
>
> This locks the system up after the "INIT: version 2.86 booting" message.
> SysRq still responds but that's about it.
Hmmm. this should have returned the b
On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > That number rapidly increases and so it looks like something is failing
> > and looping...
>
> Maybe we better restore the pte flags changes the way they were if
> CONFIG_ATOMIC_TABLE_OPS i
On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> Could you get me some more information about the hang? A stacktrace would
> be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed
On Mon, 1 Aug 2005, Richard Purdie wrote:
> That number rapidly increases and so it looks like something is failing
> and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two differe
On Mon, 1 Aug 2005, Richard Purdie wrote:
> cmpxchg_fail_flag_update 1359210189
>
> That number rapidly increases and so it looks like something is failing
> and looping...
That looks like some trouble with the MMU. The time between pte read and
write has been shortened through the page fault s
On Mon, 2005-08-01 at 14:40 -0700, Christoph Lameter wrote:
> Can you run kgdb on it to figure out what is going on?
Maybe, depending on how easily kgdb cross compiles and how quickly I can
learn to use it...
> There are some variables in /proc/vmstat that may help:
>
> spurious_page_faults 0
>
On Mon, 1 Aug 2005, Richard Purdie wrote:
> > IP Not changing? Could it be in a loop doing faults for the same memory
> > location that you cannot observe with gdb? Or is there some hardware fault
> > that has stopped the processor?
>
> I'm not the worlds most experienced user of gdb but I can'
On Mon, 2005-08-01 at 14:16 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> > of the trace is junk as glibc's arm memcpy implementation will have
> > destroyed the frame pointer. The current ins
On Mon, 1 Aug 2005, Richard Purdie wrote:
> On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> > Could you get me some more information about the hang? A stacktrace would
> > be useful.
>
> I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> of the trace is junk a
On Mon, 1 Aug 2005, Richard Purdie wrote:
> > Is this related to the size of the process? Can you do a successful kernel
> > compile w/o X?
>
> Its an embedded device and lacks development tools to test that. I ran
> some programs which abuse malloc and the process would quite happily hit
> oom
On Mon, 2005-08-01 at 09:10 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
>
> > The system appears to be ok and boots happily to a console but if you
> > load any graphical UI, the screen will blank and the process stops
> > working (tested with opie and and xserver+G
On Mon, 1 Aug 2005, Richard Purdie wrote:
> The system appears to be ok and boots happily to a console but if you
> load any graphical UI, the screen will blank and the process stops
> working (tested with opie and and xserver+GPE). You can kill -9 the
> process but you can't regain the console wi
On Friday 29 July 2005 5:17 pm, Andrew Morton wrote:
> Khalid Aziz <[EMAIL PROTECTED]> wrote:
> >
> > Serial console is broken on ia64 on an HP rx2600 machine on
> > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > output ever appears on the console and system is hung. So I
[Sorry all for the duplicate, LKML slipped somehow from the CC: line so I'm
sending this again]
Le dimanche 31 juillet 2005 à 16:22 -0700, Linus Torvalds a écrit :
> Also, it looks like sonypi really is pretty nasty to probe for, so it's
> not enough to just say "oh, it's a sony VAIO, let's res
On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
I'm seeing a problem on ARM with -rc3-mm3 and -rc4-mm1. -rc3-mm2 and
-rc4 are fine and looking for the problem reveals the problems start
after these p
Le dimanche 31 juillet 2005 à 11:25 -0700, Linus Torvalds a écrit :
> - The SonyPI driver just allocates IO regions in random areas.
Those are not really random, the list of IO regions available is given
in the ACPI SPIC device specification. The list is hardcoded here
because the driver does no
On Sun, 31 Jul 2005, Manuel Lauss wrote:
>
> Linus Torvalds wrote:
>
> >
> > - The SonyPI driver just allocates IO regions in random areas. It's got a
> >list of places to try allocating in, and the 1080 area just happens to
> >be the first on the list, and since it's not used by an
Linus Torvalds wrote:
>
> - The SonyPI driver just allocates IO regions in random areas. It's got a
>list of places to try allocating in, and the 1080 area just happens to
>be the first on the list, and since it's not used by anything else, it
>succeeds (never mind that it's on total
On Sun, 31 Jul 2005, Manuel Lauss wrote:
>
> something broke the sonypi driver a bit after -mm2:
> I can no longer set bluetooth-power for instance, and it logs these
> messages:
>
> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
> sonypi command failed at drivers/char
On Sun, Jul 31, 2005 at 10:35:28AM -0700, Andrew Morton wrote:
> Manuel Lauss <[EMAIL PROTECTED]> wrote:
> >
> > Andrew Morton wrote:
> > > Manuel Lauss <[EMAIL PROTECTED]> wrote:
> > >
> > >>something broke the sonypi driver a bit after -mm2:
> > >> I can no longer set bluetooth-power for instanc
Manuel Lauss <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Manuel Lauss <[EMAIL PROTECTED]> wrote:
> >
> >>something broke the sonypi driver a bit after -mm2:
> >> I can no longer set bluetooth-power for instance, and it logs these
> >> messages:
> >>
> >> sonypi command failed at driver
Andrew Morton wrote:
Manuel Lauss <[EMAIL PROTECTED]> wrote:
something broke the sonypi driver a bit after -mm2:
I can no longer set bluetooth-power for instance, and it logs these
messages:
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
sonypi command failed at drive
Andrew Morton wrote:
Manuel Lauss <[EMAIL PROTECTED]> wrote:
something broke the sonypi driver a bit after -mm2:
I can no longer set bluetooth-power for instance, and it logs these
messages:
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
sonypi command failed at drive
Manuel Lauss <[EMAIL PROTECTED]> wrote:
>
> something broke the sonypi driver a bit after -mm2:
> I can no longer set bluetooth-power for instance, and it logs these
> messages:
>
> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
> sonypi command failed at drivers/char
Hello,
something broke the sonypi driver a bit after -mm2:
I can no longer set bluetooth-power for instance, and it logs these
messages:
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
sonypi comman
Khalid Aziz <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2005-07-29 at 16:17 -0700, Andrew Morton wrote:
> > Khalid Aziz <[EMAIL PROTECTED]> wrote:
> > >
> > > Serial console is broken on ia64 on an HP rx2600 machine on
> > > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > >
Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote:
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
> >
> > - There's a pretty large x86_64 update here which naughty maintainer wants
> > in 2.6.
On Fri, 2005-07-29 at 16:17 -0700, Andrew Morton wrote:
> Khalid Aziz <[EMAIL PROTECTED]> wrote:
> >
> > Serial console is broken on ia64 on an HP rx2600 machine on
> > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > output ever appears on the console and system is hung. So
On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
>
> - There's a pretty large x86_64 update here which naughty maintainer wants
> in 2.6.13. Extra testing, please.
>
> +x86_64-switch-to-the-interru
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> If a -mm kernel doesn't compile for you, you can:
> - apply a patch if it is already available
But the only place I see to get patches is from the mailing list.
A 'hotfixes' directory for the -mm patches on kernel.org would be nice.
__
Chuck
-
To unsu
Khalid Aziz <[EMAIL PROTECTED]> wrote:
>
> Serial console is broken on ia64 on an HP rx2600 machine on
> 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> output ever appears on the console and system is hung. So I booted the
> kernel with "console=uart,mmio,0xff5e" to enab
Serial console is broken on ia64 on an HP rx2600 machine on
2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
output ever appears on the console and system is hung. So I booted the
kernel with "console=uart,mmio,0xff5e" to enable early console and
here is how far the kernel g
Moore, Robert schrieb:
+ACPI-0287: *** Error: Region SystemMemory(0) has no handler
+ACPI-0127: *** Error: acpi_load_tables: Could not load namespace:
AE_NOT_EXIST
+ACPI-0136: *** Error: acpi_load_tables: Could not load tables:
This looks like a nasty case where some executable code
Andrew Morton schrieb:
Michael Thonke <[EMAIL PROTECTED]> wrote:
Andrew Morton schrieb:
Michael Thonke <[EMAIL PROTECTED]> wrote:
here again I have two problems. With 2.6.13-rc3-mm3 I have problems
using my SATA drives on Intel ICH6.
The kernel can't route there IRQs or can't d
+ACPI-0287: *** Error: Region SystemMemory(0) has no handler
+ACPI-0127: *** Error: acpi_load_tables: Could not load namespace:
AE_NOT_EXIST
+ACPI-0136: *** Error: acpi_load_tables: Could not load tables:
This looks like a nasty case where some executable code in the table is
attemptin
Michael Thonke <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton schrieb:
> > Michael Thonke <[EMAIL PROTECTED]> wrote:
> >> here again I have two problems. With 2.6.13-rc3-mm3 I have problems
> >> using my SATA drives on Intel ICH6.
> >> The kernel can't route there IRQs or can't discover them. the
"Martin J. Bligh" <[EMAIL PROTECTED]> writes:
>> From: Eric W. Biederman <[EMAIL PROTECTED]>
>>
>> sync_tsc was using smp_call_function to ask the boot processor to report
>> it's tsc value. smp_call_function performs an IPI_send_allbutself which is
>> a broadcast ipi. There is a window during
>> > - There's a pretty large x86_64 update here which naughty maintainer wants
>> > in 2.6.13. Extra testing, please.
>>
>> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
>> Talked to Andi about it at OLS, but then drank too much to remember the
>> conclusion ... howeve
Hi,
Andrew Morton:
> > Note that if you work from my git import, git has a nice tree bisection
> > option.
>
> Is that documented anywhere?
http://lkml.org/lkml/2005/6/24/234
Basically, you do this:
$ set -o noclobber
$ git-rev-tree --bisect ^good1 ^good2 bad > .git/refs/heads/tryN
$ git ch
Hi,
Andrew Morton:
> Matthias Urlichs <[EMAIL PROTECTED]> wrote:
> > Note that if you work from my git import, git has a nice tree bisection
> > option.
>
> Is that documented anywhere?
*checking* Apparently not, not unless you count the git list's archive.
(It's git-rev-list.)
I'll fix that.
On Fri, Jul 29, 2005 at 02:50:34AM +0200, Radoslaw AstralStorm Szkodzinski
wrote:
> On Thu, 28 Jul 2005 22:42:38 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
>
> > I'm surprised that you are that much concerned about compile errors when
> > using a kernel that might regularly exchange the c
Matthias Urlichs <[EMAIL PROTECTED]> wrote:
>
> Hi, Rafael J. Wysocki wrote:
>
> > start a binary search
>
> Note that if you work from my git import, git has a nice tree bisection
> option.
Is that documented anywhere?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
Hi, Rafael J. Wysocki wrote:
> start a binary search
Note that if you work from my git import, git has a nice tree bisection
option.
That tree may be very helpful if the regression is hidden in one of the
git trees imported into -mm, as it allows you to pinpoint the exact change
-- as opposed t
Hi, Radoslaw "AstralStorm" Szkodzinski wrote:
> I wonder which git version is linus.patch updating to
Note, if you want -mm as a nice shiny parent-linked git tree, just pull
from http://www.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
(the whichever-mm-release-you-want branch).
I ca
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
> identified earlier with the sched patches ...
>
> http://test.kernel.org/9398/debug/console.log
Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
> Works with mainl
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
>
> > - There's a pretty large x86_64 update here which naughty maintainer wants
> > in 2.6.13. Extra testing, please.
>
> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
> Talked to Andi about it at OLS, but then drank too
OK, and one last one ... on a more postitive note. rc3-mm3 does indeed fix
the problems crashing on boot I was having on PPC64 with -rc3-mm2. I'll
close the bugzilla bug.
Thanks!
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
identified earlier with the sched patches ...
http://test.kernel.org/9398/debug/console.log
Works with mainline still (including -rc4) ... hopefully those patches
aren't on their way upstream anytime soon ;-)
M.
-
To unsubs
> - There's a pretty large x86_64 update here which naughty maintainer wants
> in 2.6.13. Extra testing, please.
Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
Talked to Andi about it at OLS, but then drank too much to remember the
conclusion ... however, it's still bro
Florian Engelhardt <[EMAIL PROTECTED]> wrote:
>
> i get this warnings when compiling:
>
>CC drivers/acpi/utilities/utalloc.o
> drivers/acpi/utilities/utalloc.c: In function `acpi_ut_create_caches':
> drivers/acpi/utilities/utalloc.c:107: warning: passing arg 3 of
> `acpi_ut_create_list
On Thu, 28 Jul 2005 22:42:38 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> I'm surprised that you are that much concerned about compile errors when
> using a kernel that might regularly exchange the contents of /dev/hda
> and /dev/null .
>
These bugs don't happen too often in reality.
Just pl
Michael Thonke <[EMAIL PROTECTED]> wrote:
>
> here again I have two problems. With 2.6.13-rc3-mm3 I have problems
> using my SATA drives on Intel ICH6.
> The kernel can't route there IRQs or can't discover them. the option
> irqpoll got them to work now.
> The problem is new because 2.6.13-rc
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> Could you please tell me how I can figure out the order in which the
> individual
> patches in -mm have been applied?
It's all in the series file:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/patch-se
Michael Thonke wrote:
> Hello Andrew,
>
> here again I have two problems. With 2.6.13-rc3-mm3 I have problems
> using my SATA drives on Intel ICH6.
> The kernel can't route there IRQs or can't discover them. the option
> irqpoll got them to work now.
> The problem is new because 2.6.13-rc3[-mm1,mm
On Thursday, 28 of July 2005 21:16, Andrew Morton wrote:
>
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > There are two problems with the compilation of arch/x86_64/kernel/nmi.c.
>
> Thanks.
>
> > --- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/nmi.c 2005-07-28
> > 21:05:53.0 +0
Hello Andrew,
here again I have two problems. With 2.6.13-rc3-mm3 I have problems
using my SATA drives on Intel ICH6.
The kernel can't route there IRQs or can't discover them. the option
irqpoll got them to work now.
The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems.
T
Nick Sillik schrieb:
Andrew Morton wrote:
Michael Thonke <[EMAIL PROTECTED]> wrote:
Hello Andrew,
I have some questions :-)
Reiser4:
why there are undefined functions implemented that currently not in
use?
This messages appeared first time in 2.6.13-rc3-mm2.
Any why it complains even CO
On Thu, 28 Jul 2005, Russell King wrote:
> ARM can't support atomic page table operations as such - the Linux view
> of the page table is separate from the hardware view, and there's some
> CPU specific code which translates from the Linux view to the hardware
> view.
Yes. The patches fall back t
Andrew Morton wrote:
Michael Thonke <[EMAIL PROTECTED]> wrote:
Hello Andrew,
I have some questions :-)
Reiser4:
why there are undefined functions implemented that currently not in use?
This messages appeared first time in 2.6.13-rc3-mm2.
Any why it complains even CONFIG_REISER4_DEBUG is not
On Thu, Jul 28, 2005 at 08:31:33PM +0200, Radoslaw AstralStorm Szkodzinski
wrote:
> On Thu, 28 Jul 2005 10:55:51 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>...
> > There are always glitches, I'm afraid.
>
> But there could be less build breakers at least.
The -mm kernels are the result of
On Thu, Jul 28, 2005 at 02:58:40AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc3-mm2:
>...
> +qla2xxx-mark-dependency-on-fw_loader.patch
>
> qlogic Kconfig fix
>...
This patch is wrong since it adds a select to SCSI_QLA2XXX.
Please drop it.
Andrew Vasquez had a better fix and is d
On Thu, Jul 28, 2005 at 10:09:57PM +, Michael Thonke wrote:
> Hello Andrew,
>
> I have some questions :-)
> Reiser4:
>
> why there are undefined functions implemented that currently not in use?
> This messages appeared first time in 2.6.13-rc3-mm2.
>
> Any why it complains even CONFIG_REISE
Michael Thonke <[EMAIL PROTECTED]> wrote:
>
> Hello Andrew,
>
> I have some questions :-)
> Reiser4:
>
> why there are undefined functions implemented that currently not in use?
> This messages appeared first time in 2.6.13-rc3-mm2.
>
> Any why it complains even CONFIG_REISER4_DEBUG is not set?
Hello Andrew,
I have some questions :-)
Reiser4:
why there are undefined functions implemented that currently not in use?
This messages appeared first time in 2.6.13-rc3-mm2.
Any why it complains even CONFIG_REISER4_DEBUG is not set?
Please have a look at the -->snip
SCSI:
CONFIG_SCSI_QLA2XX
On Thu, Jul 28, 2005 at 10:11:18AM -0700, Christoph Lameter wrote:
> On Thu, 28 Jul 2005, Andrew Morton wrote:
> > The patches at present spit warnings or don't compile on lots of
> > architectures. x86, x86_64, ppc64 and ia64 are OK.
>
> I have just sent a fix to you this morning when I got
On Thu, 28 Jul 2005, Andrew Morton wrote:
> I remain fairly dubious about this - it seems a fairly specific and
> complex piece of work to speed up one extremely specific part of one type of
> computer's one type of workload. Surely there's a better way :(
The patches provide the basis fo
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> There are two problems with the compilation of arch/x86_64/kernel/nmi.c.
Thanks.
> --- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/nmi.c 2005-07-28
> 21:05:53.0 +0200
> +++ patched/arch/x86_64/kernel/nmi.c 2005-07-28 18:58:02.0
On Thursday, 28 of July 2005 11:58, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
>
> - Added the anonymous pagefault scalability enhancement patches.
>
> I remain fairly dubious about this - it seems a fairly specific and
>
On Thu, 28 Jul 2005 10:55:51 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> It's there in the patch?
Well, I didn't check there. Poor stupid me.
> There are always glitches, I'm afraid.
But there could be less build breakers at least.
--
AstralStorm
GPG Key ID = 0xD1F10BA2
GPG Key fingerpr
Radoslaw "AstralStorm" Szkodzinski <[EMAIL PROTECTED]> wrote:
>
> I wonder which git version is linus.patch updating to, as it certainly isn't
> the mostly new git/hg tree (sans ALSA tree merge), as one patch didn't apply
> cleanly.
It's there in the patch?
bix:/usr/src/25> head patches/linus.pa
Sebastian Kaergel wrote:
> CC arch/i386/kernel/cpu/mtrr/main.o
>arch/i386/kernel/cpu/mtrr/main.c: In Funktion »set_mtrr«:
>arch/i386/kernel/cpu/mtrr/main.c:225: error: `ipi_handler' undeclared (first
>use in this function)
>arch/i386/kernel/cpu/mtrr/main.c:225: error: (Each undeclared ident
1 - 100 of 101 matches
Mail list logo
