3.10.10: WARNING: at kernel/smp.c:181 generic_smp_call_function_single_interrupt+0x11c/0x130()

Hi, I got this stacktrace shortly after bootup. I am disabling the two hyper-threaded cores in my startup scripts so possibly that was the trigger, at least per earlier report from Fernando Soto on Jul 08 2013: https://lkml.org/lkml/2013/7/8/301 I don't see his name in this patch series

3.10.10: WARNING: at kernel/smp.c:181 generic_smp_call_function_single_interrupt+0x11c/0x130()

Hi, I got this stacktrace shortly after bootup. I am disabling the two hyper-threaded cores in my startup scripts so possibly that was the trigger, at least per earlier report from Fernando Soto on Jul 08 2013: https://lkml.org/lkml/2013/7/8/301 I don't see his name in this patch series

Re: 3.10.9: kmemleak disables all CPUs except CPU0

Catalin Marinas wrote: > On Mon, Sep 02, 2013 at 04:51:17PM +0100, Martin MOKREJŠ wrote: >> Catalin Marinas wrote: >>> On Mon, Sep 02, 2013 at 04:44:52PM +0100, Max Filippov wrote: >>>> On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas >>>> wrote: >

Re: 3.10.9: kmemleak disables all CPUs except CPU0

Catalin Marinas wrote: On Mon, Sep 02, 2013 at 04:51:17PM +0100, Martin MOKREJŠ wrote: Catalin Marinas wrote: On Mon, Sep 02, 2013 at 04:44:52PM +0100, Max Filippov wrote: On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas catalin.mari...@arm.com wrote: On 31 August 2013 14:35, Martin

Re: 3.10.9: kmemleak disables all CPUs except CPU0

Catalin Marinas wrote: > On Mon, Sep 02, 2013 at 04:44:52PM +0100, Max Filippov wrote: >> On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas >> wrote: >>> On 31 August 2013 14:35, Martin MOKREJŠ wrote: >>>> never realized that my CPUs are go

Re: 3.10.9: kmemleak disables all CPUs except CPU0

Catalin Marinas wrote: > On 31 August 2013 14:35, Martin MOKREJŠ wrote: >> never realized that my CPUs are gone if I compile into kernel kmemleak. >> Is that really the aim? >> >> CONFIG_HAVE_DEBUG_KMEMLEAK=y >> CONFIG_DEBUG_KMEMLEAK=y >> C

Re: 3.10.9: kmemleak disables all CPUs except CPU0

Catalin Marinas wrote: On 31 August 2013 14:35, Martin MOKREJŠ mmokr...@gmail.com wrote: never realized that my CPUs are gone if I compile into kernel kmemleak. Is that really the aim? CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK=y CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=400

Re: 3.10.9: kmemleak disables all CPUs except CPU0

Catalin Marinas wrote: On Mon, Sep 02, 2013 at 04:44:52PM +0100, Max Filippov wrote: On Mon, Sep 2, 2013 at 7:31 PM, Catalin Marinas catalin.mari...@arm.com wrote: On 31 August 2013 14:35, Martin MOKREJŠ mmokr...@gmail.com wrote: never realized that my CPUs are gone if I compile

Emulating ECC RAM in kernel or mirroring RAM to exclude HW issues

Hi, I am trying to find out why some applications crash on my laptop. I mostly use python and have configured it via configure --with-pydebug so that is wraps memory allocated regions with 0xfb. That helps to realize something overwrote that memory region. So far, it twice reported 0xfb to 0xfa

Emulating ECC RAM in kernel or mirroring RAM to exclude HW issues

Hi, I am trying to find out why some applications crash on my laptop. I mostly use python and have configured it via configure --with-pydebug so that is wraps memory allocated regions with 0xfb. That helps to realize something overwrote that memory region. So far, it twice reported 0xfb to 0xfa

Re: [PATCH linux-next] Prevent a coredump with a large vm_map_count from Oopsing

Dan Aloni wrote: > On Sat, Aug 31, 2013 at 03:38:33PM +0200, Martin MOKREJŠ wrote: >> Hi Dan, >> thank you for your work on my issue. I would like to test it on 3.10.9 >> where >> I faced the problem initially. > > Sure, see the attached patch for 3.10.9. Than

Re: [PATCH linux-next] Prevent a coredump with a large vm_map_count from Oopsing

Hi Dan, thank you for your work on my issue. I would like to test it on 3.10.9 where I faced the problem initially. linux-3.10.9 # patch -p1 < ../patches/vm_map_count.patch patching file fs/binfmt_elf.c Hunk #1 succeeded at 1415 (offset -14 lines). Hunk #2 succeeded at 1430 (offset -14 lines).

Re: [PATCH linux-next] Prevent a coredump with a large vm_map_count from Oopsing

Hi Dan, thank you for your work on my issue. I would like to test it on 3.10.9 where I faced the problem initially. linux-3.10.9 # patch -p1 ../patches/vm_map_count.patch patching file fs/binfmt_elf.c Hunk #1 succeeded at 1415 (offset -14 lines). Hunk #2 succeeded at 1430 (offset -14 lines).

Re: [PATCH linux-next] Prevent a coredump with a large vm_map_count from Oopsing

Dan Aloni wrote: On Sat, Aug 31, 2013 at 03:38:33PM +0200, Martin MOKREJŠ wrote: Hi Dan, thank you for your work on my issue. I would like to test it on 3.10.9 where I faced the problem initially. Sure, see the attached patch for 3.10.9. Thanks, it works for my case. You can add my

Re: 3.10.9: EXT4-fs (sdb1): delayed block allocation failed for inode 163315715 at logical offset 1 with max blocks 2 with error -5

Theodore Ts'o wrote: > Your SATA disk had enough errors that the ATA link was completely > reset, and the device was detached and then reattached. As far as > kernel is concerned, it's a new device. Later on I rebooted and ran smarctl: # smartctl --test=long /dev/sdb As of now after two days

Re: 3.10.9: EXT4-fs (sdb1): delayed block allocation failed for inode 163315715 at logical offset 1 with max blocks 2 with error -5

Theodore Ts'o wrote: Your SATA disk had enough errors that the ATA link was completely reset, and the device was detached and then reattached. As far as kernel is concerned, it's a new device. Later on I rebooted and ran smarctl: # smartctl --test=long /dev/sdb As of now after two days I

Re: 3.10.9: Oops at elf_core_dump()

15 0f 1f 44 00 00 48 83 c0 01 0f b6 10 f6 82 40 c6 84 81 20 75 f0 5d c3 66 0f 1f 44 00 00 31 c0 <80> 3f 00 55 48 89 e5 74 11 48 89 f8 66 90 48 83 c0 01 80 38 00 [112568.011042] RIP [] strlen+0x2/0x20 [112568.011748] RSP [112568.012445] CR2: 00000000 [112568.013155]

Re: 3.10.9: Oops at elf_core_dump()

. Martin Greg KH wrote: > On Thu, Aug 29, 2013 at 11:46:18PM +0200, Martin MOKREJŠ wrote: >> Hi, >> I just got this stacktrace. Not sure whom to send it, poking throu >> MAINTAINERS >> file and looking for ELF gave me nothing. ;-) >> >> [105670.434336] BU

3.10.9: Oops at elf_core_dump()

Hi, I just got this stacktrace. Not sure whom to send it, poking throu MAINTAINERS file and looking for ELF gave me nothing. ;-) [105670.434336] BUG: unable to handle kernel NULL pointer dereference at (null) [105670.434366] IP: [] strlen+0x2/0x20 [105670.434385] PGD 18c8e5067 PUD

3.10.9: Oops at elf_core_dump()

Hi, I just got this stacktrace. Not sure whom to send it, poking throu MAINTAINERS file and looking for ELF gave me nothing. ;-) [105670.434336] BUG: unable to handle kernel NULL pointer dereference at (null) [105670.434366] IP: [812f7b42] strlen+0x2/0x20 [105670.434385] PGD

Re: 3.10.9: Oops at elf_core_dump()

what to say more. I just crashed teh kernel but except the Ooops it works so far. The core filesize is zero. Martin Greg KH wrote: On Thu, Aug 29, 2013 at 11:46:18PM +0200, Martin MOKREJŠ wrote: Hi, I just got this stacktrace. Not sure whom to send it, poking throu MAINTAINERS file

Re: 3.10.9: Oops at elf_core_dump()

9d67aee555e92d76 ]--- Martin MOKREJŠ wrote: Got it for the first time. Actually, am doing something really unusual (http://bugs.python.org/issue18843). Am looking for an answer why I suffer memory corruption in python applicatuons. So I installed DUMA from http://duma.sourceforge.net

Re: 3.10.9: EXT4-fs (sdb1): delayed block allocation failed for inode 163315715 at logical offset 1 with max blocks 2 with error -5

to a file filled up some kernel buffers (because could not write to /mnt/external) the ext4 driver choked? # cat /proc/sys/vm/laptop_mode 0 # Have app-laptop/laptop-mode-tools-1.63-r2 on Gentoo Linux. Thank you, Martin Martin MOKREJŠ wrote: > Hi, > I have been running two instances of va

Re: 3.10.9: EXT4-fs (sdb1): delayed block allocation failed for inode 163315715 at logical offset 1 with max blocks 2 with error -5

to a file filled up some kernel buffers (because could not write to /mnt/external) the ext4 driver choked? # cat /proc/sys/vm/laptop_mode 0 # Have app-laptop/laptop-mode-tools-1.63-r2 on Gentoo Linux. Thank you, Martin Martin MOKREJŠ wrote: Hi, I have been running two instances of valgrind on some

e1000 in 2.6.21.2 and even older, like 2.6.13: eth0 does not exist but eth1 does

Hi, today I had to reinstall some machine because the xfs filesystem was broken, because under heavy load I got kernel panic complaining that some internal kernel structure are broken so the filesystem was unmounted. Sorry, I had no time to take a snapshot. So I recreated the filesystem and

e1000 in 2.6.21.2 and even older, like 2.6.13: eth0 does not exist but eth1 does

Hi, today I had to reinstall some machine because the xfs filesystem was broken, because under heavy load I got kernel panic complaining that some internal kernel structure are broken so the filesystem was unmounted. Sorry, I had no time to take a snapshot. So I recreated the filesystem and

2.6.19.1: kernel BUG at mm/slab.c:2911!

Hi, is this a known issue? Should I bother to upgrade to 2.6.19.2 if it contains the fix? Thank you any help. It might be related to NFS. The machine in question is NFSv3 client, udp. And used for computations. The process which died is from torque cluster management package. Please Cc: me

2.6.19.1: kernel BUG at mm/slab.c:2911!

Hi, is this a known issue? Should I bother to upgrade to 2.6.19.2 if it contains the fix? Thank you any help. It might be related to NFS. The machine in question is NFSv3 client, udp. And used for computations. The process which died is from torque cluster management package. Please Cc: me

Regression: spurious 8259A interrupt: IRQ7 appears in 2.6.19-rc6-git10

Hi, I have just tested for fun the upcoming release candidate and have found the following difference with a 'spurious 8259A interrupt: IRQ7' message, possibly triggered by the --- linux-2.6.19-rc5.txt2006-11-28 19:23:54.145722821 +0100 +++ linux-2.6.19-rc6-git10.txt 2006-11-28

XFS: possible recursive locking detected in 2.6.18 to 2.6.19-rc6-git10 but not 2.6.17.11

Hi, I have a looong time opened a bugreport on XFS at http://bugzilla.kernel.org/show_bug.cgi?id=7287 and I see it still appear in my kernel output during bootup. I guess this is one of the relatively new kernel self-testing features introduced recently. I just wanted to let you know about that.

XFS: possible recursive locking detected in 2.6.18 to 2.6.19-rc6-git10 but not 2.6.17.11

Hi, I have a looong time opened a bugreport on XFS at http://bugzilla.kernel.org/show_bug.cgi?id=7287 and I see it still appear in my kernel output during bootup. I guess this is one of the relatively new kernel self-testing features introduced recently. I just wanted to let you know about that.

Regression: spurious 8259A interrupt: IRQ7 appears in 2.6.19-rc6-git10

Hi, I have just tested for fun the upcoming release candidate and have found the following difference with a 'spurious 8259A interrupt: IRQ7' message, possibly triggered by the --- linux-2.6.19-rc5.txt2006-11-28 19:23:54.145722821 +0100 +++ linux-2.6.19-rc6-git10.txt 2006-11-28

PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try pci=usepirqmask

Hi, what does this message really mean? I did what it suggests and the "IRQ 0" is gone then. Is that a problem in kernel or should I just use for my hardware pci=usepirqmask when acpi=off? Should I report somewhere else? Should I care at all? I use 2.6.13 kernel with the patch for pcmcia from

PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try pci=usepirqmask

Hi, what does this message really mean? I did what it suggests and the IRQ 0 is gone then. Is that a problem in kernel or should I just use for my hardware pci=usepirqmask when acpi=off? Should I report somewhere else? Should I care at all? I use 2.6.13 kernel with the patch for pcmcia from

overlapping MTRR regions

Hi, I tested 2.6.13-rc7 on nice server motherboard with 16GB of RAM ;) http://www.msicomputer.com/product/p_spec.asp?model=E7520_Master-S2M=spd and I see the following when acpi is enabled (haven't even tried without): # cat /proc/mtrr reg00: base=0xd000 (3328MB), size= 256MB: uncachable,

overlapping MTRR regions

Hi, I tested 2.6.13-rc7 on nice server motherboard with 16GB of RAM ;) http://www.msicomputer.com/product/p_spec.asp?model=E7520_Master-S2Mclass=spd and I see the following when acpi is enabled (haven't even tried without): # cat /proc/mtrr reg00: base=0xd000 (3328MB), size= 256MB:

Re: openafs is really faster on linux-2.4. than 2.6

Hi Con, thank you for anwers. It seems my main confusion was that values in 'id' and 'wa' columns in vmstat(1) output do not reflect the 2.4 kernel stats well. The timing shows that the real time is more or less same and we could only argue if the sys time is significantly higher on 2.6 kernel

Re: openafs is really faster on linux-2.4. than 2.6

the main problem I think at the moment. M. Con Kolivas wrote: > On Thu, 18 Aug 2005 22:48, Martin MOKREJŠ wrote: > >>I think the problem here is outside afs. >>Just doing this dd test but writing data directly to the ext2 >>target gives same behaviour, i.e. on 2.4 kernel

Re: openafs is really faster on linux-2.4. than 2.6

I think the problem here is outside afs. Just doing this dd test but writing data directly to the ext2 target gives same behaviour, i.e. on 2.4 kernel I see most of the CPU idle but on 2.6 kernel all that CPU amount is shown as in wait state. And the numbers from 2.4 kernel show higher throughput

Re: openafs is really faster on linux-2.4. than 2.6

I think the problem here is outside afs. Just doing this dd test but writing data directly to the ext2 target gives same behaviour, i.e. on 2.4 kernel I see most of the CPU idle but on 2.6 kernel all that CPU amount is shown as in wait state. And the numbers from 2.4 kernel show higher throughput

Re: openafs is really faster on linux-2.4. than 2.6

the main problem I think at the moment. M. Con Kolivas wrote: On Thu, 18 Aug 2005 22:48, Martin MOKREJŠ wrote: I think the problem here is outside afs. Just doing this dd test but writing data directly to the ext2 target gives same behaviour, i.e. on 2.4 kernel I see most of the CPU idle

Re: openafs is really faster on linux-2.4. than 2.6

Hi Con, thank you for anwers. It seems my main confusion was that values in 'id' and 'wa' columns in vmstat(1) output do not reflect the 2.4 kernel stats well. The timing shows that the real time is more or less same and we could only argue if the sys time is significantly higher on 2.6 kernel

2.6.13-rc6 ntfs oops

Hi, I was just copying some data from ntfs partition to xfs and I got the following: Does someone need more info? Briefly, no SMP but HIGHMEm 4GB, i686 P4 machine, 32bit. Martin NTFS driver 2.1.23 [Flags: R/W MODULE]. NTFS volume version 3.1. Unable to handle kernel NULL pointer dereference

2.6.13-rc6 ntfs oops

Hi, I was just copying some data from ntfs partition to xfs and I got the following: Does someone need more info? Briefly, no SMP but HIGHMEm 4GB, i686 P4 machine, 32bit. Martin NTFS driver 2.1.23 [Flags: R/W MODULE]. NTFS volume version 3.1. Unable to handle kernel NULL pointer dereference

Re: Giving developers clue how many testers verified certain kernel version

Hi Adrian, I think you don't understand me. I do report bugs and will always do. The point was that developers could be "assured" there is possibly no problem when people do NOT report bugs in that piece of code because they would know that it _was_ tested by 1000 people on 357 different HW's.

Re: Giving developers clue how many testers verified certain kernel version

Hi Adrian, well, the idea was to give you a clue how many people did NOT complain because it either worked or they did not realize/care. The goal was different. For example, I have 2 computers and both need current acpi patch to work fine. I went to bugzilla and found nobody has filed such bugs

Re: Giving developers clue how many testers verified certain kernel version

Hi Adrian, well, the idea was to give you a clue how many people did NOT complain because it either worked or they did not realize/care. The goal was different. For example, I have 2 computers and both need current acpi patch to work fine. I went to bugzilla and found nobody has filed such bugs

Re: Giving developers clue how many testers verified certain kernel version

Hi Adrian, I think you don't understand me. I do report bugs and will always do. The point was that developers could be assured there is possibly no problem when people do NOT report bugs in that piece of code because they would know that it _was_ tested by 1000 people on 357 different HW's. And

Re: Giving developers clue how many testers verified certain kernel version

Hi, Mark Nipper wrote: I have a different idea along these lines but not using bugzilla. A nice system for tracking usage of certain components might be made by having people register using a certain e-mail address and then submitting their .config as they try out new versions of

Giving developers clue how many testers verified certain kernel version

Hi, I think the discussion going on here in another thread about lack of positive information on how many testers successfully tested certain kernel version can be easily solved with real solution. How about opening separate "project" in bugzilla.kernel.org named kernel-testers or whatever,

Giving developers clue how many testers verified certain kernel version

Hi, I think the discussion going on here in another thread about lack of positive information on how many testers successfully tested certain kernel version can be easily solved with real solution. How about opening separate project in bugzilla.kernel.org named kernel-testers or whatever,

Re: Giving developers clue how many testers verified certain kernel version

Hi, Mark Nipper wrote: I have a different idea along these lines but not using bugzilla. A nice system for tracking usage of certain components might be made by having people register using a certain e-mail address and then submitting their .config as they try out new versions of

Oops: 2.6.13-rc2 at vma_prio_tree_remove

Hi, has anybody seen this? I have 2.6.13-rc2 kernel on intel P4 box. Unable to handle kernel paging request at virtual address 00040034 printing eip: c014937e *pde = Oops: [#1] PREEMPT DEBUG_PAGEALLOC Modules linked in: radeon drm parport_pc lp parport snd_rtctimer

Oops: 2.6.13-rc2 at vma_prio_tree_remove

Hi, has anybody seen this? I have 2.6.13-rc2 kernel on intel P4 box. Unable to handle kernel paging request at virtual address 00040034 printing eip: c014937e *pde = Oops: [#1] PREEMPT DEBUG_PAGEALLOC Modules linked in: radeon drm parport_pc lp parport snd_rtctimer

Re: Two 2.6.13-rc1 kernel crashes

Hi, it seems it has helped. ;) Thanks! Jens Axboe wrote: On Mon, Jul 04 2005, Martin Mokrejs wrote: Hi, I use on i686 architecture Gentoo linux with XFS filesystem. Recently it happened to me 3 time that the machine locked, although at least once sys-rq+b worked. Here is the log from remote

Re: Two 2.6.13-rc1 kernel crashes

Hi, it seems it has helped. ;) Thanks! Jens Axboe wrote: On Mon, Jul 04 2005, Martin Mokrejs wrote: Hi, I use on i686 architecture Gentoo linux with XFS filesystem. Recently it happened to me 3 time that the machine locked, although at least once sys-rq+b worked. Here is the log from remote

Re: Two 2.6.13-rc1 kernel crashes

# grep CONFIG_4KSTACKS .config # CONFIG_4KSTACKS is not set # .config is attached. Thanks. BTW: The .config should be almost same as for the previous kernel. I usually copy the old-one into new source tree and do "make oldconfig". Zwane Mwaikambo wrote: On Mon, 4 Jul 2005, Martin Mokrejs

Re: Two 2.6.13-rc1 kernel crashes

# grep CONFIG_4KSTACKS .config # CONFIG_4KSTACKS is not set # .config is attached. Thanks. BTW: The .config should be almost same as for the previous kernel. I usually copy the old-one into new source tree and do make oldconfig. Zwane Mwaikambo wrote: On Mon, 4 Jul 2005, Martin Mokrejs wrote:

find: /usr/src/linux-2.4.30/include/asm: Too many levels of symbolic links

Hi, again I've hit some wird problem doing "make dep" for 2.4 kernel: I've extracted the linxu-2.4.30.tar.gz file, copied .config from previous src-tree, ran `make oldconfig', did `make menuconfig', and finally `make dep': [cut] make[2]: Leaving directory `/usr/src/linux-2.4.30/arch/i386/lib'

linux-2.4.30-rc1/include/asm: Too many levels of symbolic links

Hi, I recompiled current kernel to test something, and have realized everything went well including "make modules_install", but no System.map was generated. So I dug around and the "make dep" did not work well: make[2]: Leaving directory `/usr/src/linux-2.4.30-rc1/arch/i386/lib' make[1]: Leaving

Re: Unresolved symbols in /lib/modules/2.4.28-pre2/xfree-drm/via_drv.o

Marcelo Tosatti wrote: On Wed, Mar 16, 2005 at 04:21:12PM +0100, Martin MOKREJ? wrote: Arjan van de Ven wrote: On Wed, 2005-03-16 at 16:03 +0100, Martin MOKREJ?? wrote: Hi, does anyone still use 2.4 series kernel? ;) # make dep; make bzImage; make modules [cut] # make modules_install [cut] cd

Unresolved symbols in /lib/modules/2.4.28-pre2/xfree-drm/via_drv.o

Hi, does anyone still use 2.4 series kernel? ;) # make dep; make bzImage; make modules [cut] # make modules_install [cut] cd /lib/modules/2.4.30-pre3-bk2; \ mkdir -p pcmcia; \ find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia if [ -r System.map ]; then /sbin/depmod -ae

Re: memory management weirdness

Ingo Molnar wrote: * Andi Kleen <[EMAIL PROTECTED]> wrote: Although I've not re-tested this today again, it used to help a bit to specify mem=3548M to decrease memory used by linux (tested with AGP card plugged in, when bios reported 3556MB RAM only). I found that removing the AGP based videoc

Re: memory management weirdness

Parag Warudkar wrote: Hi, I have received no answer to my former question (see http://marc.theaimsgroup.com/?l=linux-kernel=110827143716215=2). I've spent some more time on that problem and have more or less confirmed it's because of buggy bios. However, the linux kernel doesn't handle properly

memory management weirdness

Hi, I have received no answer to my former question (see http://marc.theaimsgroup.com/?l=linux-kernel=110827143716215=2). I've spent some more time on that problem and have more or less confirmed it's because of buggy bios. However, the linux kernel doesn't handle properly such case. I've tested

HIGHMEM slows down 2.6.11-rc3-bk7 machine

Hi Marcello and other gurus! I have just bough 4GB of RAM into my machine. Immediately, I have noticed the machine is terribly slow on bootup. After inspecting all BIOS related possibilities I found that the problem goes off with highmem=off. I should note I don't see this slowdown when I have