* BUG: using smp_processor_id() in preemptible
@ 2009-06-24 14:15 Johannes Berg
2009-06-28 14:11 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-24 14:15 UTC (permalink / raw)
To: kvm
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
Hi,
I'm trying to run a test environment in kvm (because uml doesn't have
lockdep), and am running into the following problems:
1) I get the $subject warning a lot, when starting kvm:
[85763.262707] BUG: using smp_processor_id() in preemptible [00000000] code: kvm/13877
[85763.262719] caller is kvm_write_guest_time+0x40/0x220 [kvm]
[85763.262722] Pid: 13877, comm: kvm Not tainted 2.6.30-wl-26837-g0ee651a-dirty #54
[85763.262725] Call Trace:
[85763.262729] [<ffffffff8041d482>] debug_smp_processor_id+0xf2/0x100
[85763.262741] [<ffffffffa0331390>] kvm_write_guest_time+0x40/0x220 [kvm]
[85763.262753] [<ffffffffa0331890>] vcpu_enter_guest+0x320/0x580 [kvm]
[85763.262780] [<ffffffffa03347f4>] __vcpu_run+0x74/0x2f0 [kvm]
[85763.262792] [<ffffffffa033571f>] kvm_arch_vcpu_ioctl_run+0x8f/0x200 [kvm]
[85763.262804] [<ffffffffa0329b48>] kvm_vcpu_ioctl+0x4b8/0x900 [kvm]
[85763.262816] [<ffffffff802f5216>] vfs_ioctl+0x36/0xb0
[85763.262819] [<ffffffff802f55f9>] do_vfs_ioctl+0x89/0x320
[85763.262826] [<ffffffff802f58df>] sys_ioctl+0x4f/0x80
[85763.262830] [<ffffffff8020b6fb>] system_call_fastpath+0x16/0x1b
That kernel version is wireless-testing, which is currently based on
v2.6.30, and the -dirty is for some wireless patches I did.
2) The second problem is that it doesn't actually work. I use this
command line:
kvm -kernel arch/x86_64/boot/bzImage \
-hda ../uml/Ubuntu-IntrepidIbex-amd64-root_fs \
-append "root=/dev/hda console=ttyS0" -curses
and the system hangs after
Plex86/Bochs VGABios (PCI) current-cvs 12 Jun 2009
This VGA/VBE Bios is released under the GNU LGPL
Please visit :
. http://bochs.sourceforge.net
. http://www.nongnu.org/vgabios
cirrus-compatible VGA is detected
QEMU BIOS - build: 06/12/09
$Revision: 1.182 $ $Date: 2007/08/01 17:09:51 $
Options: apmbios pcibios eltorito rombios32
ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (1024 MBytes)
ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
Press F12 for boot menu.
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
The guest kernel is the same as the host, but with somewhat different
config options.
The strange thing here is that the exact same command line, with
qemu-system-x86_64 instead of kvm works perfectly.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-24 14:15 BUG: using smp_processor_id() in preemptible Johannes Berg
@ 2009-06-28 14:11 ` Avi Kivity
2009-06-29 8:32 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-28 14:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/24/2009 05:15 PM, Johannes Berg wrote:
> Hi,
>
> I'm trying to run a test environment in kvm (because uml doesn't have
> lockdep), and am running into the following problems:
>
> 1) I get the $subject warning a lot, when starting kvm:
> [85763.262707] BUG: using smp_processor_id() in preemptible [00000000] code: kvm/13877
> [85763.262719] caller is kvm_write_guest_time+0x40/0x220 [kvm]
> [85763.262722] Pid: 13877, comm: kvm Not tainted 2.6.30-wl-26837-g0ee651a-dirty #54
> [85763.262725] Call Trace:
> [85763.262729] [<ffffffff8041d482>] debug_smp_processor_id+0xf2/0x100
> [85763.262741] [<ffffffffa0331390>] kvm_write_guest_time+0x40/0x220 [kvm]
> [85763.262753] [<ffffffffa0331890>] vcpu_enter_guest+0x320/0x580 [kvm]
> [85763.262780] [<ffffffffa03347f4>] __vcpu_run+0x74/0x2f0 [kvm]
> [85763.262792] [<ffffffffa033571f>] kvm_arch_vcpu_ioctl_run+0x8f/0x200 [kvm]
> [85763.262804] [<ffffffffa0329b48>] kvm_vcpu_ioctl+0x4b8/0x900 [kvm]
> [85763.262816] [<ffffffff802f5216>] vfs_ioctl+0x36/0xb0
> [85763.262819] [<ffffffff802f55f9>] do_vfs_ioctl+0x89/0x320
> [85763.262826] [<ffffffff802f58df>] sys_ioctl+0x4f/0x80
> [85763.262830] [<ffffffff8020b6fb>] system_call_fastpath+0x16/0x1b
>
>
ISTR this was fixed...
> That kernel version is wireless-testing, which is currently based on
> v2.6.30, and the -dirty is for some wireless patches I did.
>
Please post the output of 'git merge-base wireless-testing
origin/master' so I can know what tree to look at.
> 2) The second problem is that it doesn't actually work. I use this
> command line:
> kvm -kernel arch/x86_64/boot/bzImage \
> -hda ../uml/Ubuntu-IntrepidIbex-amd64-root_fs \
> -append "root=/dev/hda console=ttyS0" -curses
>
> and the system hangs after
> Plex86/Bochs VGABios (PCI) current-cvs 12 Jun 2009
> This VGA/VBE Bios is released under the GNU LGPL
>
> Please visit :
> . http://bochs.sourceforge.net
> . http://www.nongnu.org/vgabios
>
> cirrus-compatible VGA is detected
>
> QEMU BIOS - build: 06/12/09
> $Revision: 1.182 $ $Date: 2007/08/01 17:09:51 $
> Options: apmbios pcibios eltorito rombios32
>
> ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (1024 MBytes)
> ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
>
> Press F12 for boot menu.
>
>
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel.
>
Does it hang or switch to some graphics mode? What happens if you drop
curses?
You can see where it hangs using the monitor 'info registers' and 'x/30i
$eip' commands.
> The guest kernel is the same as the host, but with somewhat different
> config options.
>
> The strange thing here is that the exact same command line, with
> qemu-system-x86_64 instead of kvm works perfectly.
>
That's probably a qemu without kvm support.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-28 14:11 ` Avi Kivity
@ 2009-06-29 8:32 ` Johannes Berg
2009-06-29 9:08 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 8:32 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 13458 bytes --]
On Sun, 2009-06-28 at 17:11 +0300, Avi Kivity wrote:
> > 1) I get the $subject warning a lot, when starting kvm:
> > [85763.262707] BUG: using smp_processor_id() in preemptible [00000000] code: kvm/13877
> > [85763.262719] caller is kvm_write_guest_time+0x40/0x220 [kvm]
> > [85763.262722] Pid: 13877, comm: kvm Not tainted 2.6.30-wl-26837-g0ee651a-dirty #54
> > [85763.262725] Call Trace:
> > [85763.262729] [<ffffffff8041d482>] debug_smp_processor_id+0xf2/0x100
> > [85763.262741] [<ffffffffa0331390>] kvm_write_guest_time+0x40/0x220 [kvm]
> > [85763.262753] [<ffffffffa0331890>] vcpu_enter_guest+0x320/0x580 [kvm]
> > [85763.262780] [<ffffffffa03347f4>] __vcpu_run+0x74/0x2f0 [kvm]
> > [85763.262792] [<ffffffffa033571f>] kvm_arch_vcpu_ioctl_run+0x8f/0x200 [kvm]
> > [85763.262804] [<ffffffffa0329b48>] kvm_vcpu_ioctl+0x4b8/0x900 [kvm]
> > [85763.262816] [<ffffffff802f5216>] vfs_ioctl+0x36/0xb0
> > [85763.262819] [<ffffffff802f55f9>] do_vfs_ioctl+0x89/0x320
> > [85763.262826] [<ffffffff802f58df>] sys_ioctl+0x4f/0x80
> > [85763.262830] [<ffffffff8020b6fb>] system_call_fastpath+0x16/0x1b
> >
> >
>
> ISTR this was fixed...
>
> > That kernel version is wireless-testing, which is currently based on
> > v2.6.30, and the -dirty is for some wireless patches I did.
> >
>
> Please post the output of 'git merge-base wireless-testing
> origin/master' so I can know what tree to look at.
ITYM
$ git merge-base wireless-testing/master linux-2.6/master
07a2039b8eb0af4ff464efd3dfd95de5c02648c6
$ git describe 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
v2.6.30
since my personal 'origin' branch is something completely different.
> > 2) The second problem is that it doesn't actually work. I use this
> > command line:
> > kvm -kernel arch/x86_64/boot/bzImage \
> > -hda ../uml/Ubuntu-IntrepidIbex-amd64-root_fs \
> > -append "root=/dev/hda console=ttyS0" -curses
> >
> > and the system hangs after
> > Plex86/Bochs VGABios (PCI) current-cvs 12 Jun 2009
> > This VGA/VBE Bios is released under the GNU LGPL
> >
> > Please visit :
> > . http://bochs.sourceforge.net
> > . http://www.nongnu.org/vgabios
> >
> > cirrus-compatible VGA is detected
> >
> > QEMU BIOS - build: 06/12/09
> > $Revision: 1.182 $ $Date: 2007/08/01 17:09:51 $
> > Options: apmbios pcibios eltorito rombios32
> >
> > ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (1024 MBytes)
> > ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
> >
> > Press F12 for boot menu.
> >
> >
> > Decompressing Linux... Parsing ELF... done.
> > Booting the kernel.
> >
>
> Does it hang or switch to some graphics mode? What happens if you drop
> curses?
Same, I just used curses to copy/paste the messages I get.
> You can see where it hangs using the monitor 'info registers' and 'x/30i
> $eip' commands.
not much luck since it doesn't hang at a specific instruction:
(qemu) info registers
RAX=0000000000000001 RBX=0000000000000000 RCX=0000000001062560 RDX=0000000000000000
RSI=0000000000000001 RDI=0000000000000001 RBP=ffffffff80a6dd98 RSP=ffffffff80a6dd98
R8 =0000000000000001 R9 =0000000000000000 R10=0000000000000001 R11=0000000000000001
R12=000000011544e510 R13=0000000000000010 R14=0000000000000b8e R15=ffff8800001fee00
RIP=ffffffff803d5360 RFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00c09300
CS =0010 0000000000000000 ffffffff 00a09b00
SS =0018 0000000000000000 ffffffff 00c09300
DS =0018 0000000000000000 ffffffff 00c09300
FS =0000 0000000000000000 ffffffff 00000000
GS =0000 ffff880006200000 ffffffff 00000000
LDT=0000 0000000000000000 ffffffff 00000000
TR =0040 ffff8800063d0a40 00002087 00008b00
GDT= ffff880006204000 0000007f
IDT= ffffffff80ca5000 00000fff
CR0=8005003b CR2=0000000000000000 CR3=0000000000201000 CR4=000006a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000
(qemu) x/30i $eip
0xffffffff8028fc60: push %rbp
0xffffffff8028fc61: mov $0x1cebe8,%rax
0xffffffff8028fc68: mov %rsp,%rbp
0xffffffff8028fc6b: mov %gs:0xc8a0,%rdx
0xffffffff8028fc74: movq $0x0,(%rax,%rdx,1)
0xffffffff8028fc7c: leaveq
0xffffffff8028fc7d: retq
0xffffffff8028fc7e: xchg %ax,%ax
0xffffffff8028fc80: push %rbp
0xffffffff8028fc81: mov %rsp,%rbp
0xffffffff8028fc84: sub $0x10,%rsp
0xffffffff8028fc88: mov %rbx,(%rsp)
0xffffffff8028fc8c: mov %r12,0x8(%rsp)
0xffffffff8028fc91: mov $0x1cebe8,%rbx
0xffffffff8028fc98: mov %gs:0xc8a0,%r12
0xffffffff8028fca1: mov %gs:0xc8a8,%edi
0xffffffff8028fca9: callq 0xffffffff80268ef0
0xffffffff8028fcae: shr $0x1e,%rax
0xffffffff8028fcb2: mov %rax,(%r12,%rbx,1)
0xffffffff8028fcb6: mov (%rsp),%rbx
0xffffffff8028fcba: mov 0x8(%rsp),%r12
0xffffffff8028fcbf: leaveq
0xffffffff8028fcc0: retq
0xffffffff8028fcc1: nopw %cs:0x0(%rax,%rax,1)
0xffffffff8028fcd0: push %rbp
0xffffffff8028fcd1: mov $0x1,%esi
0xffffffff8028fcd6: mov %rsp,%rbp
0xffffffff8028fcd9: push %rbx
0xffffffff8028fcda: lea -0x20(%rbp),%rdx
0xffffffff8028fcde: sub $0x18,%rsp
(qemu) info registers
RAX=ffffffffffffffff RBX=0000000000000000 RCX=0000000001062560 RDX=0000000000000000
RSI=0000000000000001 RDI=0000000000000001 RBP=ffffffff80a6de98 RSP=ffffffff80a6ddb8
R8 =0000000000000001 R9 =0000000000000000 R10=0000000000000001 R11=0000000000000001
R12=0000000125ac5486 R13=0000000000000010 R14=0000000000000b8e R15=ffff8800001fee00
RIP=ffffffff805da6be RFL=00000296 [--S-AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00c09300
CS =0010 0000000000000000 ffffffff 00a09b00
SS =0018 0000000000000000 ffffffff 00c09300
DS =0018 0000000000000000 ffffffff 00c09300
FS =0000 0000000000000000 ffffffff 00000000
GS =0000 ffff880006200000 ffffffff 00000000
LDT=0000 0000000000000000 ffffffff 00000000
TR =0040 ffff8800063d0a40 00002087 00008b00
GDT= ffff880006204000 0000007f
IDT= ffffffff80ca5000 00000fff
CR0=8005003b CR2=0000000000000000 CR3=0000000000201000 CR4=000006a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000
(qemu) x/30i $eip
0xffffffff80249ce6: leaveq
0xffffffff80249ce7: retq
0xffffffff80249ce8: nopl 0x0(%rax,%rax,1)
0xffffffff80249cf0: push %rbp
0xffffffff80249cf1: mov 0xa93668(%rip),%rax # 0xffffffff80cdd360
0xffffffff80249cf8: mov %rsp,%rbp
0xffffffff80249cfb: leaveq
0xffffffff80249cfc: retq
0xffffffff80249cfd: nopl (%rax)
0xffffffff80249d00: push %rbp
0xffffffff80249d01: xor %eax,%eax
0xffffffff80249d03: mov %rsp,%rbp
0xffffffff80249d06: cmpl $0x0,0xa9365f(%rip) # 0xffffffff80cdd36c
0xffffffff80249d0d: leaveq
0xffffffff80249d0e: sete %al
0xffffffff80249d11: retq
0xffffffff80249d12: nopw %cs:0x0(%rax,%rax,1)
0xffffffff80249d20: push %rbp
0xffffffff80249d21: mov 0xa93648(%rip),%rax # 0xffffffff80cdd370
0xffffffff80249d28: mov %rsp,%rbp
0xffffffff80249d2b: test %rax,%rax
0xffffffff80249d2e: je 0xffffffff80249d40
0xffffffff80249d30: inc %rax
0xffffffff80249d33: mov %rax,0xa93636(%rip) # 0xffffffff80cdd370
0xffffffff80249d3a: xor %eax,%eax
0xffffffff80249d3c: leaveq
0xffffffff80249d3d: retq
0xffffffff80249d3e: xchg %ax,%ax
0xffffffff80249d40: mov $0x8,%esi
0xffffffff80249d45: mov $0xffffffff80cdd370,%rdi
(qemu) info registers
RAX=0000000000000000 RBX=0000000000000000 RCX=0000000001062560 RDX=0000000000000000
RSI=0000000000000001 RDI=0000000000418958 RBP=ffffffff80a6dda8 RSP=ffffffff80a6dda8
R8 =0000000000000001 R9 =0000000000000000 R10=0000000000000001 R11=0000000000000001
R12=000000013473bc5c R13=0000000000000010 R14=0000000000000b8e R15=ffff8800001fee00
RIP=ffffffff803d53da RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00c09300
CS =0010 0000000000000000 ffffffff 00a09b00
SS =0018 0000000000000000 ffffffff 00c09300
DS =0018 0000000000000000 ffffffff 00c09300
FS =0000 0000000000000000 ffffffff 00000000
GS =0000 ffff880006200000 ffffffff 00000000
LDT=0000 0000000000000000 ffffffff 00000000
TR =0040 ffff8800063d0a40 00002087 00008b00
GDT= ffff880006204000 0000007f
IDT= ffffffff80ca5000 00000fff
CR0=8005003b CR2=0000000000000000 CR3=0000000000201000 CR4=000006a0
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00000000
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000
(qemu) x/30i $eip
0xffffffff805da6be: callq 0xffffffff8028fc60
0xffffffff805da6c3: mov %r12,%rdi
0xffffffff805da6c6: callq *0x702854(%rip) # 0xffffffff80cdcf20
0xffffffff805da6cc: mov $0x418958,%edi
0xffffffff805da6d1: mov %rax,%rbx
0xffffffff805da6d4: callq 0xffffffff803d53a0
0xffffffff805da6d9: lea 0x1(%r12,%rbx,1),%r12
0xffffffff805da6de: jmp 0xffffffff805da6be
0xffffffff805da6e0: movq $0xffffffff80249ce0,0x702835(%rip) # 0xffffffff80cdcf20
0xffffffff805da6eb: jmp 0xffffffff805da6a5
0xffffffff805da6ed: xor %eax,%eax
0xffffffff805da6ef: mov $0xffffffff806d0063,%rdi
0xffffffff805da6f6: callq 0xffffffff805da747
0xffffffff805da6fb: imul $0x3e8,0x702823(%rip),%eax # 0xffffffff80cdcf28
0xffffffff805da705: test %eax,%eax
0xffffffff805da707: jle 0xffffffff805da73d
0xffffffff805da709: xor %r12d,%r12d
0xffffffff805da70c: callq 0xffffffff80227860
0xffffffff805da711: mov %r12,%rdi
0xffffffff805da714: callq *0x702806(%rip) # 0xffffffff80cdcf20
0xffffffff805da71a: mov $0x418958,%edi
0xffffffff805da71f: mov %rax,%rbx
0xffffffff805da722: callq 0xffffffff803d53a0
0xffffffff805da727: lea 0x1(%r12,%rbx,1),%r12
0xffffffff805da72c: imul $0x3e8,0x7027f2(%rip),%eax # 0xffffffff80cdcf28
0xffffffff805da736: cltq
0xffffffff805da738: cmp %r12,%rax
0xffffffff805da73b: jg 0xffffffff805da70c
0xffffffff805da73d: callq 0xffffffff8025cd30
0xffffffff805da742: jmpq 0xffffffff805da6af
> > The guest kernel is the same as the host, but with somewhat different
> > config options.
> >
> > The strange thing here is that the exact same command line, with
> > qemu-system-x86_64 instead of kvm works perfectly.
> >
>
> That's probably a qemu without kvm support.
Yes, I know that, I just used that to verify the guest kernel is ok.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 8:32 ` Johannes Berg
@ 2009-06-29 9:08 ` Avi Kivity
2009-06-29 9:54 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 9:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 11:32 AM, Johannes Berg wrote:
> On Sun, 2009-06-28 at 17:11 +0300, Avi Kivity wrote:
>
>
>>> 1) I get the $subject warning a lot, when starting kvm:
>>> [85763.262707] BUG: using smp_processor_id() in preemptible [00000000] code: kvm/13877
>>> [85763.262719] caller is kvm_write_guest_time+0x40/0x220 [kvm]
>>> [85763.262722] Pid: 13877, comm: kvm Not tainted 2.6.30-wl-26837-g0ee651a-dirty #54
>>> [85763.262725] Call Trace:
>>> [85763.262729] [<ffffffff8041d482>] debug_smp_processor_id+0xf2/0x100
>>> [85763.262741] [<ffffffffa0331390>] kvm_write_guest_time+0x40/0x220 [kvm]
>>> [85763.262753] [<ffffffffa0331890>] vcpu_enter_guest+0x320/0x580 [kvm]
>>> [85763.262780] [<ffffffffa03347f4>] __vcpu_run+0x74/0x2f0 [kvm]
>>> [85763.262792] [<ffffffffa033571f>] kvm_arch_vcpu_ioctl_run+0x8f/0x200 [kvm]
>>> [85763.262804] [<ffffffffa0329b48>] kvm_vcpu_ioctl+0x4b8/0x900 [kvm]
>>> [85763.262816] [<ffffffff802f5216>] vfs_ioctl+0x36/0xb0
>>> [85763.262819] [<ffffffff802f55f9>] do_vfs_ioctl+0x89/0x320
>>> [85763.262826] [<ffffffff802f58df>] sys_ioctl+0x4f/0x80
>>> [85763.262830] [<ffffffff8020b6fb>] system_call_fastpath+0x16/0x1b
>>>
>>>
>>>
>> ISTR this was fixed...
>>
>>
>>> That kernel version is wireless-testing, which is currently based on
>>> v2.6.30, and the -dirty is for some wireless patches I did.
>>>
>>>
>> Please post the output of 'git merge-base wireless-testing
>> origin/master' so I can know what tree to look at.
>>
>
> ITYM
>
> $ git merge-base wireless-testing/master linux-2.6/master
> 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
> $ git describe 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
> v2.6.30
>
> since my personal 'origin' branch is something completely different.
>
>
Yes. It was fixed in mainline by 2dea4c84bc. I'll prepare something
for -stable.
>> You can see where it hangs using the monitor 'info registers' and 'x/30i
>> $eip' commands.
>>
>
> not much luck since it doesn't hang at a specific instruction:
>
You can try mapping these with gdb (in fact, you can have gdb connect to
qemu and do source level debugging).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 9:08 ` Avi Kivity
@ 2009-06-29 9:54 ` Johannes Berg
2009-06-29 9:57 ` Johannes Berg
2009-06-29 9:59 ` Avi Kivity
0 siblings, 2 replies; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 9:54 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
On Mon, 2009-06-29 at 12:08 +0300, Avi Kivity wrote:
> >> You can see where it hangs using the monitor 'info registers' and 'x/30i
> >> $eip' commands.
> >>
> >
> > not much luck since it doesn't hang at a specific instruction:
> >
>
> You can try mapping these with gdb (in fact, you can have gdb connect to
> qemu and do source level debugging).
It's actually panic'ed because it ran out of memory, but didn't print
that to my vga/console/curses/...
(gdb) bt full
#0 touch_softlockup_watchdog ()
at /home/johannes/sys/wireless-testing/kernel/softlockup.c:77
No locals.
#1 0xffffffff805d6373 in panic (fmt=0x0)
at /home/johannes/sys/wireless-testing/kernel/panic.c:134
args = {{gp_offset = 8, fp_offset = 48, overflow_arg_area =
0xffffffff80a69ea8, reg_save_area = 0xffffffff80a69dd8}}
i = 1810713685
buf = "Out of memory", '\0' <repeats 1010 times>
#2 0xffffffff80a889c4 in ___alloc_bootmem (size=512,
align=<value optimized out>, goal=<value optimized out>,
limit=<value optimized out>)
at /home/johannes/sys/wireless-testing/mm/bootmem.c:607
mem = <value optimized out>
#3 0xffffffff80a88a49 in __alloc_bootmem (size=1, align=1, goal=0)
at /home/johannes/sys/wireless-testing/mm/bootmem.c:627
No locals.
#4 0xffffffff80a8daa3 in alloc_bootmem_cpumask_var (mask=0xffffffff8097dda8)
at /home/johannes/sys/wireless-testing/lib/cpumask.c:161
No locals.
#5 0xffffffff80a87804 in early_irq_init ()
at /home/johannes/sys/wireless-testing/include/linux/irq.h:442
i = 2978
#6 0xffffffff80a71bda in start_kernel ()
at /home/johannes/sys/wireless-testing/init/main.c:604
command_line = 0xffffffff80a9ed00 "root=/dev/hda"
#7 0xffffffff80a71299 in x86_64_start_reservations (
real_mode_data=<value optimized out>)
at /home/johannes/sys/wireless-testing/arch/x86/kernel/head64.c:123
No locals.
#8 0xffffffff80a713be in x86_64_start_kernel (real_mode_data=
0x13050 <Address 0x13050 out of bounds>)
at /home/johannes/sys/wireless-testing/arch/x86/kernel/head64.c:94
No locals.
#9 0x0000000000000000 in ?? ()
No symbol table info available.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 9:54 ` Johannes Berg
@ 2009-06-29 9:57 ` Johannes Berg
2009-06-29 10:00 ` Avi Kivity
2009-06-29 9:59 ` Avi Kivity
1 sibling, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 9:57 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Mon, 2009-06-29 at 11:54 +0200, Johannes Berg wrote:
> On Mon, 2009-06-29 at 12:08 +0300, Avi Kivity wrote:
>
> > >> You can see where it hangs using the monitor 'info registers' and 'x/30i
> > >> $eip' commands.
> > >>
> > >
> > > not much luck since it doesn't hang at a specific instruction:
> > >
> >
> > You can try mapping these with gdb (in fact, you can have gdb connect to
> > qemu and do source level debugging).
>
> It's actually panic'ed because it ran out of memory, but didn't print
> that to my vga/console/curses/...
And if I add -m 512 it works just fine. Seems the default is too small
for me... But why would qemu/kvm have different defaults?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 9:54 ` Johannes Berg
2009-06-29 9:57 ` Johannes Berg
@ 2009-06-29 9:59 ` Avi Kivity
2009-06-29 10:00 ` Johannes Berg
1 sibling, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 9:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 12:54 PM, Johannes Berg wrote:
> On Mon, 2009-06-29 at 12:08 +0300, Avi Kivity wrote:
>
>
>>>> You can see where it hangs using the monitor 'info registers' and 'x/30i
>>>> $eip' commands.
>>>>
>>>>
>>> not much luck since it doesn't hang at a specific instruction:
>>>
>>>
>> You can try mapping these with gdb (in fact, you can have gdb connect to
>> qemu and do source level debugging).
>>
>
> It's actually panic'ed because it ran out of memory, but didn't print
> that to my vga/console/curses/...
>
Maybe we give it crappy numa table, try booting with numa disabled.
Also make sure you boot with the bios provided by qemu-kvm, not some
random qemu.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 9:59 ` Avi Kivity
@ 2009-06-29 10:00 ` Johannes Berg
2009-06-29 10:04 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 10:00 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Mon, 2009-06-29 at 12:59 +0300, Avi Kivity wrote:
> > It's actually panic'ed because it ran out of memory, but didn't print
> > that to my vga/console/curses/...
> >
>
> Maybe we give it crappy numa table, try booting with numa disabled.
# CONFIG_NUMA is not set
> Also make sure you boot with the bios provided by qemu-kvm, not some
> random qemu.
I, uh, have no idea how to ensure that -- I'm simply using the debian
kvm package.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 9:57 ` Johannes Berg
@ 2009-06-29 10:00 ` Avi Kivity
2009-06-29 10:06 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 10:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 12:57 PM, Johannes Berg wrote:
>> It's actually panic'ed because it ran out of memory, but didn't print
>> that to my vga/console/curses/...
>>
>
> And if I add -m 512 it works just fine. Seems the default is too small
> for me... But why would qemu/kvm have different defaults?
>
Both are 128 MB. Strange. And certainly Linux should boot in 128 MB.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:04 ` Avi Kivity
@ 2009-06-29 10:04 ` Johannes Berg
0 siblings, 0 replies; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 10:04 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 421 bytes --]
On Mon, 2009-06-29 at 13:04 +0300, Avi Kivity wrote:
> On 06/29/2009 01:00 PM, Johannes Berg wrote:
>
> >> Also make sure you boot with the bios provided by qemu-kvm, not some
> >> random qemu.
> >>
> >
> > I, uh, have no idea how to ensure that -- I'm simply using the debian
> > kvm package.
> >
>
> That should be a good way to ensure it. What version is it?
Version: 85+dfsg-4
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:00 ` Johannes Berg
@ 2009-06-29 10:04 ` Avi Kivity
2009-06-29 10:04 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 10:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 01:00 PM, Johannes Berg wrote:
>> Also make sure you boot with the bios provided by qemu-kvm, not some
>> random qemu.
>>
>
> I, uh, have no idea how to ensure that -- I'm simply using the debian
> kvm package.
>
That should be a good way to ensure it. What version is it?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:00 ` Avi Kivity
@ 2009-06-29 10:06 ` Johannes Berg
2009-06-29 10:16 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 10:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
On Mon, 2009-06-29 at 13:00 +0300, Avi Kivity wrote:
> On 06/29/2009 12:57 PM, Johannes Berg wrote:
> >> It's actually panic'ed because it ran out of memory, but didn't print
> >> that to my vga/console/curses/...
> >>
> >
> > And if I add -m 512 it works just fine. Seems the default is too small
> > for me... But why would qemu/kvm have different defaults?
> >
>
> Both are 128 MB. Strange. And certainly Linux should boot in 128 MB.
If I boot with -m 512 I get this:
root@(none):~# free
total used free shared buffers cached
Mem: 378608 25196 353412 0 1012 8692
-/+ buffers/cache: 15492 363116
Swap: 0 0 0
so something is definitely eating a lot of memory (missing about 142M).
Same guest kernel/fs in qemu gets:
freeroot@(none):~# free
total used free shared buffers cached
Mem: 407080 23236 383844 0 1056 8692
-/+ buffers/cache: 13488 393592
Swap: 0 0 0
so it's missing about 114M.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:06 ` Johannes Berg
@ 2009-06-29 10:16 ` Avi Kivity
2009-06-29 10:18 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 10:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 01:06 PM, Johannes Berg wrote:
>>> And if I add -m 512 it works just fine. Seems the default is too small
>>> for me... But why would qemu/kvm have different defaults?
>>>
>>>
>> Both are 128 MB. Strange. And certainly Linux should boot in 128 MB.
>>
>
> If I boot with -m 512 I get this:
> root@(none):~# free
> total used free shared buffers cached
> Mem: 378608 25196 353412 0 1012 8692
> -/+ buffers/cache: 15492 363116
> Swap: 0 0 0
>
>
> so something is definitely eating a lot of memory (missing about 142M).
> Same guest kernel/fs in qemu gets:
> freeroot@(none):~# free
> total used free shared buffers cached
> Mem: 407080 23236 383844 0 1056 8692
> -/+ buffers/cache: 13488 393592
> Swap: 0 0 0
>
> so it's missing about 114M.
>
I get 500MB with 2.6.31-rc1+. What does dmesg say about the e820 map?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:16 ` Avi Kivity
@ 2009-06-29 10:18 ` Johannes Berg
2009-06-29 10:25 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 10:18 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]
On Mon, 2009-06-29 at 13:16 +0300, Avi Kivity wrote:
> > If I boot with -m 512 I get this:
> > root@(none):~# free
> > total used free shared buffers cached
> > Mem: 378608 25196 353412 0 1012 8692
> > -/+ buffers/cache: 15492 363116
> > Swap: 0 0 0
> >
> >
> > so something is definitely eating a lot of memory (missing about 142M).
> > Same guest kernel/fs in qemu gets:
> > freeroot@(none):~# free
> > total used free shared buffers cached
> > Mem: 407080 23236 383844 0 1056 8692
> > -/+ buffers/cache: 13488 393592
> > Swap: 0 0 0
> >
> > so it's missing about 114M.
> >
>
> I get 500MB with 2.6.31-rc1+.
So even my qemu is missing a lot more than you are. But I guess my
kernel might also be a lot larger.
> What does dmesg say about the e820 map?
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
[ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
[ 0.000000] BIOS-e820: 000000000fff0000 - 0000000010000000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:18 ` Johannes Berg
@ 2009-06-29 10:25 ` Avi Kivity
2009-06-29 10:32 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 10:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 01:18 PM, Johannes Berg wrote:
>>> If I boot with -m 512 I get this:
>>> root@(none):~# free
>>> total used free shared buffers cached
>>> Mem: 378608 25196 353412 0 1012 8692
>>> -/+ buffers/cache: 15492 363116
>>> Swap: 0 0 0
>>>
>>>
>>> so something is definitely eating a lot of memory (missing about 142M).
>>> Same guest kernel/fs in qemu gets:
>>> freeroot@(none):~# free
>>> total used free shared buffers cached
>>> Mem: 407080 23236 383844 0 1056 8692
>>> -/+ buffers/cache: 13488 393592
>>> Swap: 0 0 0
>>>
>>> so it's missing about 114M.
>>>
>>>
>> I get 500MB with 2.6.31-rc1+.
>>
>
> So even my qemu is missing a lot more than you are. But I guess my
> kernel might also be a lot larger.
>
Aha. Maybe paravirt patching allocates a lot of memory? Otherwise
there should be no difference between qemu-kvm and qemu.
Do you really have a 100MB kernel?
>> What does dmesg say about the e820 map?
>>
>
> [ 0.000000] BIOS-provided physical RAM map:
> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> [ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
> [ 0.000000] BIOS-e820: 000000000fff0000 - 0000000010000000 (ACPI data)
> [ 0.000000] BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved)
>
That's only 256MB (0xfff0000).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:25 ` Avi Kivity
@ 2009-06-29 10:32 ` Johannes Berg
2009-06-29 10:39 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 10:32 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
On Mon, 2009-06-29 at 13:25 +0300, Avi Kivity wrote:
> > So even my qemu is missing a lot more than you are. But I guess my
> > kernel might also be a lot larger.
> >
>
> Aha. Maybe paravirt patching allocates a lot of memory? Otherwise
> there should be no difference between qemu-kvm and qemu.
No idea.
> Do you really have a 100MB kernel?
Hmm. Maybe?
text data bss dec hex filename
5635486 5482828 84287488 95405802 5afc6ea vmlinux
-rwxr-xr-x 1 johannes johannes 86242879 2009-06-29 11:31 vmlinux
-rwxr-xr-x 1 johannes johannes 83M 2009-06-29 11:31 vmlinux
But that's with complete debug info.
> >> What does dmesg say about the e820 map?
> >>
> >
> > [ 0.000000] BIOS-provided physical RAM map:
> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
> > [ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
> > [ 0.000000] BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
> > [ 0.000000] BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
> > [ 0.000000] BIOS-e820: 000000000fff0000 - 0000000010000000 (ACPI data)
> > [ 0.000000] BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved)
> >
>
> That's only 256MB (0xfff0000).
Oh, yes, sorry, I booted with 256 now since that worked too. 512 yields
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
[ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
[ 0.000000] BIOS-e820: 000000001fff0000 - 0000000020000000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:32 ` Johannes Berg
@ 2009-06-29 10:39 ` Avi Kivity
2009-06-29 10:55 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 10:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 01:32 PM, Johannes Berg wrote:
>
>> Do you really have a 100MB kernel?
>>
>
> Hmm. Maybe?
>
> text data bss dec hex filename
> 5635486 5482828 84287488 95405802 5afc6ea vmlinux
> -rwxr-xr-x 1 johannes johannes 86242879 2009-06-29 11:31 vmlinux
> -rwxr-xr-x 1 johannes johannes 83M 2009-06-29 11:31 vmlinux
>
> But that's with complete debug info.
>
debug info is not loaded IIUC. But you have 84MB of BSS, that looks
very broken. Maybe you have a zillion cpus configured, though that
should be dynamic now.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:39 ` Avi Kivity
@ 2009-06-29 10:55 ` Johannes Berg
2009-06-29 11:38 ` Avi Kivity
0 siblings, 1 reply; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 10:55 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 886 bytes --]
On Mon, 2009-06-29 at 13:39 +0300, Avi Kivity wrote:
> On 06/29/2009 01:32 PM, Johannes Berg wrote:
> >
> >> Do you really have a 100MB kernel?
> >>
> >
> > Hmm. Maybe?
> >
> > text data bss dec hex filename
> > 5635486 5482828 84287488 95405802 5afc6ea vmlinux
> > -rwxr-xr-x 1 johannes johannes 86242879 2009-06-29 11:31 vmlinux
> > -rwxr-xr-x 1 johannes johannes 83M 2009-06-29 11:31 vmlinux
> >
> > But that's with complete debug info.
> >
>
> debug info is not loaded IIUC. But you have 84MB of BSS, that looks
> very broken. Maybe you have a zillion cpus configured, though that
> should be dynamic now.
I had MAXSMP configured, which makes it 4096, but if I turn off MAXSMP
and make NR_CPUS 8, then I get
text data bss dec hex filename
5594521 2562924 12726272 20883717 13ea905 vmlinux
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 10:55 ` Johannes Berg
@ 2009-06-29 11:38 ` Avi Kivity
2009-06-29 12:03 ` Johannes Berg
0 siblings, 1 reply; 31+ messages in thread
From: Avi Kivity @ 2009-06-29 11:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: kvm
On 06/29/2009 01:55 PM, Johannes Berg wrote:
> I had MAXSMP configured, which makes it 4096, but if I turn off MAXSMP
> and make NR_CPUS 8, then I get
> text data bss dec hex filename
> 5594521 2562924 12726272 20883717 13ea905 vmlinux
>
12MB bss is still pretty bloated, but I guess that's beyond the scope of
this thread.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-06-29 11:38 ` Avi Kivity
@ 2009-06-29 12:03 ` Johannes Berg
0 siblings, 0 replies; 31+ messages in thread
From: Johannes Berg @ 2009-06-29 12:03 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
On Mon, 2009-06-29 at 14:38 +0300, Avi Kivity wrote:
> On 06/29/2009 01:55 PM, Johannes Berg wrote:
> > I had MAXSMP configured, which makes it 4096, but if I turn off MAXSMP
> > and make NR_CPUS 8, then I get
> > text data bss dec hex filename
> > 5594521 2562924 12726272 20883717 13ea905 vmlinux
> >
>
> 12MB bss is still pretty bloated,
Yeah, should probably check where that's coming from.
> but I guess that's beyond the scope of
> this thread.
Indeed. In any case, thanks for your help.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2018-01-11 12:31 Ricardo Nabinger Sanchez
@ 2018-01-11 17:14 ` Eric Dumazet
0 siblings, 0 replies; 31+ messages in thread
From: Eric Dumazet @ 2018-01-11 17:14 UTC (permalink / raw)
To: Ricardo Nabinger Sanchez, netdev
On Thu, 2018-01-11 at 10:31 -0200, Ricardo Nabinger Sanchez wrote:
> Greetings,
>
> I'm getting occasional video lock-ups, and while checking logs I found
> these:
>
> ===
> [ 297.445296] BUG: using smp_processor_id() in preemptible [00000000] code: claws-mail/1635
> [ 297.445319] caller is jprobe_return+0x12/0x25
> [ 297.445332] CPU: 1 PID: 1635 Comm: claws-mail Not tainted 4.14.0 #1
> [ 297.445341] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
> [ 297.445349] Call Trace:
> [ 297.445372] dump_stack+0x9f/0xe1
> [ 297.445392] check_preemption_disabled+0xec/0xf0
> [ 297.445409] jprobe_return+0x12/0x25
> [ 297.445425] tcp_v4_do_rcv+0x7f/0x1a0
> [ 297.445443] __release_sock+0x6d/0x100
> [ 297.445462] release_sock+0x2b/0xb0
> [ 297.445475] tcp_recvmsg+0x300/0x8f0
> [ 297.445504] ? __lock_acquire+0x3ee/0x1610
> [ 297.445517] ? core_sys_select+0x240/0x3e0
> [ 297.445541] inet_recvmsg+0x51/0x1b0
> [ 297.445566] sock_read_iter+0x8c/0xd0
> [ 297.445598] __vfs_read+0xd5/0x140
> [ 297.445632] vfs_read+0x9e/0x150
> [ 297.445652] SyS_read+0x45/0xa0
> [ 297.445675] entry_SYSCALL_64_fastpath+0x23/0xc2
> [ 297.445687] RIP: 0033:0x7ff2536001b8
> [ 297.445696] RSP: 002b:00007ff247152890 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
> [ 297.445713] RAX: ffffffffffffffda RBX: ffff9cd088ccbff0 RCX: 00007ff2536001b8
> [ 297.445721] RDX: 0000000000000005 RSI: 00007ff23c02bb43 RDI: 0000000000000013
> [ 297.445730] RBP: 00007ff23c02bb43 R08: 0000000000000000 R09: 00007ff23c00e520
> [ 297.445738] R10: 0000000000100000 R11: 0000000000000246 R12: 0000000000000086
> [ 297.445746] R13: 000000000000002f R14: 00007ff254d3c998 R15: 0000000000000001
> ...
> [ 366.965766] BUG: using smp_processor_id() in preemptible [00000000] code: Socket Thread/1435
> [ 366.965769] caller is jprobe_return+0x12/0x25
> [ 366.965773] CPU: 0 PID: 1435 Comm: Socket Thread Not tainted 4.14.0 #1
> [ 366.965775] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
> [ 366.965777] Call Trace:
> [ 366.965780] dump_stack+0x9f/0xe1
> [ 366.965786] check_preemption_disabled+0xec/0xf0
> [ 366.965790] jprobe_return+0x12/0x25
> [ 366.965793] tcp_v4_do_rcv+0x7f/0x1a0
> [ 366.965797] __release_sock+0x6d/0x100
> [ 366.965811] release_sock+0x2b/0xb0
> [ 366.965813] tcp_recvmsg+0x300/0x8f0
> [ 366.965826] inet_recvmsg+0x51/0x1b0
> [ 366.965834] SYSC_recvfrom+0xc6/0x130
> [ 366.965845] ? entry_SYSCALL_64_fastpath+0x5/0xc2
> [ 366.965848] ? trace_hardirqs_on_caller+0xcb/0x200
> [ 366.965851] ? trace_hardirqs_on_thunk+0x1a/0x1c
> [ 366.965858] entry_SYSCALL_64_fastpath+0x23/0xc2
> [ 366.965860] RIP: 0033:0x7f475ab7e5da
> [ 366.965862] RSP: 002b:00007f47438fc8b0 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
> [ 366.965864] RAX: ffffffffffffffda RBX: ffff9cd088ae7ff0 RCX: 00007f475ab7e5da
> [ 366.965865] RDX: 0000000000008000 RSI: 00007f4721202000 RDI: 000000000000007c
> [ 366.965867] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> [ 366.965868] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000086
> [ 366.965869] R13: 00007f47212025a8 R14: 0000000000007a58 R15: 00007f474ba1e5f2
> [ 366.966571] BUG: using smp_processor_id() in preemptible [00000000] code: Socket Thread/1435
> [ 366.966574] caller is jprobe_return+0x12/0x25
> [ 366.966576] CPU: 0 PID: 1435 Comm: Socket Thread Not tainted 4.14.0 #1
> [ 366.966577] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
> [ 366.966578] Call Trace:
> [ 366.966582] dump_stack+0x9f/0xe1
> [ 366.966586] check_preemption_disabled+0xec/0xf0
> [ 366.966592] jprobe_return+0x12/0x25
> [ 366.966596] tcp_v4_do_rcv+0x7f/0x1a0
> [ 366.966601] __release_sock+0x6d/0x100
> [ 366.966606] release_sock+0x2b/0xb0
> [ 366.966610] tcp_recvmsg+0x300/0x8f0
> [ 366.966622] inet_recvmsg+0x51/0x1b0
> [ 366.966630] SYSC_recvfrom+0xc6/0x130
> [ 366.966643] ? entry_SYSCALL_64_fastpath+0x5/0xc2
> [ 366.966647] ? trace_hardirqs_on_caller+0xcb/0x200
> [ 366.966651] ? trace_hardirqs_on_thunk+0x1a/0x1c
> [ 366.966667] entry_SYSCALL_64_fastpath+0x23/0xc2
> [ 366.966669] RIP: 0033:0x7f475ab7e5da
> [ 366.966670] RSP: 002b:00007f47438fc8b0 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
> [ 366.966673] RAX: ffffffffffffffda RBX: ffff9cd088ae7ff0 RCX: 00007f475ab7e5da
> [ 366.966674] RDX: 0000000000008000 RSI: 00007f4721202000 RDI: 000000000000007c
> [ 366.966676] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> [ 366.966677] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000086
> [ 366.966679] R13: 00007f47438fca70 R14: 00000000000005a8 R15: 00007f4721202000
> [ 366.979991] BUG: using smp_processor_id() in preemptible [00000000] code: Socket Thread/1435
> [ 366.979999] caller is jprobe_return+0x12/0x25
> [ 366.980004] CPU: 0 PID: 1435 Comm: Socket Thread Not tainted 4.14.0 #1
> [ 366.980007] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
> [ 366.980012] Call Trace:
> [ 366.980023] dump_stack+0x9f/0xe1
> [ 366.980033] check_preemption_disabled+0xec/0xf0
> [ 366.980040] jprobe_return+0x12/0x25
> [ 366.980046] tcp_v4_do_rcv+0x7f/0x1a0
> [ 366.980054] __release_sock+0x6d/0x100
> [ 366.980062] release_sock+0x2b/0xb0
> [ 366.980068] tcp_recvmsg+0x300/0x8f0
> [ 366.980105] inet_recvmsg+0x51/0x1b0
> [ 366.980117] SYSC_recvfrom+0xc6/0x130
> [ 366.980130] ? entry_SYSCALL_64_fastpath+0x5/0xc2
> [ 366.980134] ? trace_hardirqs_on_caller+0xcb/0x200
> [ 366.980137] ? trace_hardirqs_on_thunk+0x1a/0x1c
> [ 366.980145] entry_SYSCALL_64_fastpath+0x23/0xc2
> [ 366.980147] RIP: 0033:0x7f475ab7e5da
> [ 366.980149] RSP: 002b:00007f47438fc8b0 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
> [ 366.980152] RAX: ffffffffffffffda RBX: ffff9cd088ae7ff0 RCX: 00007f475ab7e5da
> [ 366.980154] RDX: 0000000000008000 RSI: 00007f4721202000 RDI: 000000000000007c
> [ 366.980157] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> [ 366.980158] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000086
> [ 366.980161] R13: 0000000000008000 R14: 00007f47438fca70 R15: 00007f474ba1e5f2
> ===
>
> There are many of those, and they keep popping up throughout normal
> usage. Sometimes, though, things go awry but without much information:
>
> ===
> Jan 10 17:54:39 kernel: [ 2717.421681] note: Socket Thread[1812] exited with preempt_count 1
> ===
>
> It seems that when the event above happens (preempt_count 1), a chain of
> events unfolds and my video locks up. Sometimes the mouse pointer will
> continue to work; others it is a full lockup.
>
> I understand this is not necessarily linked to the network stack, but as it
> happens, the traces always have the network stack in common and the application
> that exits has always been one that deals with network (Firefox and Claws
> Mail so far).
>
> This has been happening for quite a while now, at least since 4.9 (probably
> before that). I don't know how to trigger this: it could take as much as
> 45 days to "lock up" or as little as a few minutes in sequence. Yesterday,
> the first time it locked up took around 20 days, and then less than 10 minutes.
>
>
> The best information I have are dumps from SysRq:
> ===
> Jan 10 17:54:39 darkbook kernel: [ 2717.421681] note: Socket Thread[1812] exited with preempt_count 1
> Jan 10 17:55:45 darkbook acpid: client 1084[0:100] has disconnected
> Jan 10 17:55:46 darkbook /usr/sbin/gpm[970]: *** info [mice.c(1990)]:
> Jan 10 17:55:46 darkbook /usr/sbin/gpm[970]: imps2: Auto-detected intellimouse PS/2
> Jan 10 17:56:12 darkbook kernel: [ 2811.376514] sysrq: SysRq : Show Locks Held
> Jan 10 17:56:14 darkbook kernel: [ 2813.214132] sysrq: SysRq : Show backtrace of all active CPUs
> Jan 10 17:56:14 darkbook kernel: [ 2813.215131] Sending NMI from CPU 0 to CPUs 1-7:
> Jan 10 17:56:16 darkbook kernel: [ 2814.975638] sysrq: SysRq : Show Blocked State
> Jan 10 17:56:16 darkbook kernel: [ 2814.975679] task PC stack pid father
> Jan 10 17:56:20 darkbook kernel: [ 2819.060962] localStorage DB S 0 1884 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.061483] LoadRoots S 0 1900 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.061970] SysProxySetting S 0 1901 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.062477] dconf worker S 0 1902 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.063222] ProxyResolution S 0 1903 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.063727] DataStorage S 0 1904 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.064175] URL Classifier S 0 1905 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.064680] Classif~ Update S 0 1906 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.065182] DataStorage S 0 1908 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.065718] DataStorage S 0 1909 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.066151] SaveScripts S 0 1910 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.066684] Cache I/O S 0 1911 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.067149] mozStorage #1 S 0 1913 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.067693] mozStorage #2 S 0 1916 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.068222] QuotaManager IO S 0 1917 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.068721] mozStorage #3 S 0 1918 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.069210] mozStorage #4 S 0 1919 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.069714] mozStorage #5 S 0 1922 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.070242] DOM Worker S 0 1923 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.070743] DOM Worker S 0 1947 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.071272] IdentityCrypto S 0 1967 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.071799] mozStorage #7 S 0 1976 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.072267] mozStorage #8 S 0 1978 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.072775] DNS Resolver #7 S 0 2265 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.073256] DNS Resolver #9 S 0 2860 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.073763] DNS Res~ver #10 S 0 2861 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.074266] DNS Res~ver #11 S 0 2862 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.074765] speechd init S 0 2894 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.075268] BgFileSaver S 0 2916 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.075779] mozStorage #9 S 0 2919 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.076270] DOMCacheThread S 0 2939 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.076793] Web Content S 0 1852 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.077632] Chrome_~dThread S 0 1855 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.078069] JS Watchdog S 0 1858 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.078634] JS Helper S 0 1859 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.079164] JS Helper S 0 1860 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.079689] JS Helper S 0 1861 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.080219] JS Helper S 0 1862 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.080785] JS Helper S 0 1863 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.081369] JS Helper S 0 1864 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.081901] JS Helper S 0 1865 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.082450] JS Helper S 0 1866 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.082964] JS Helper S 0 1867 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.083507] JS Helper S 0 1868 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.084043] JS Helper S 0 1869 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.084610] JS Helper S 0 1870 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.085146] Socket Thread S 0 1871 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.085872] Hang Monitor S 0 1872 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.086379] Timer S 0 1873 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.086886] ImgDecoder #1 S 0 1874 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.087411] ImgDecoder #2 S 0 1875 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.087960] ImgDecoder #3 S 0 1876 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.088527] ImgDecoder #4 S 0 1877 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.089036] ImgDecoder #5 S 0 1878 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.089578] ImgDecoder #6 S 0 1879 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.090130] ImgDecoder #7 S 0 1880 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.090673] ImageIO S 0 1881 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.091220] ImageBr~geChild S 0 1882 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.092005] VideoChild S 0 1883 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.092782] threaded-ml S 0 1887 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.093679] ProcessHangMon S 0 1888 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.094371] ProfilerChild S 0 1889 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.094984] gmain S 0 1890 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.095822] gdbus S 0 1891 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.096438] StyleThread#0 S 0 1893 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.096909] StyleThread#1 S 0 1894 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.097453] StyleThread#2 S 0 1895 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.098059] StyleThread#3 S 0 1896 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.098717] StyleThread#4 S 0 1897 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.099407] StyleThread#5 S 0 1898 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.100011] HTML5 Parser S 0 1914 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.100616] dconf worker S 0 1979 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.101536] MediaPl~ack #13 S 0 2853 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.102052] MediaPl~ack #14 S 0 2854 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.102605] DOM Worker S 0 2889 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.103124] DOM Worker S 0 2893 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.103708] MediaTimer #3 S 0 2898 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.104244] MediaPl~ack #17 S 0 2900 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.104802] MediaPl~ack #18 S 0 2901 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.105328] MediaPD~oder #6 S 0 2902 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.105835] MediaPD~oder #7 S 0 2903 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.106378] MediaPD~oder #8 S 0 2904 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.106883] MediaPD~oder #9 S 0 2905 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.107405] DOM Worker S 0 2938 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.107937] SubtleCrypto #1 S 0 2947 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.108457] StreamTrans #16 S 0 2954 1809 0x00000100
> Jan 10 17:56:20 darkbook kernel: [ 2819.109021] fish S 0 2165 1422 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.109522] ssh S 0 2214 2165 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.110386] kworker/0:4 I 0 2327 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.110599] xfrun4 S 0 2329 1127 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.111390] gmain S 0 2330 1127 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.112123] gdbus S 0 2331 1127 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.112797] xmms S 0 2337 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.113584] xmms S 0 2338 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.114426] xmms S 0 2339 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.114842] xmms S 0 2340 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.115265] xmms S 0 2345 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.116489] xmms S 0 2847 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.117433] threaded-ml S 0 2848 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.118185] xmms S 0 2849 2329 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.118992] kworker/0:6 I 0 2346 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.119203] kworker/0:14 I 0 2362 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.119424] fish S 0 2414 1422 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.120179] kworker/u16:1 I 0 2455 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.120408] kworker/0:23 I 0 2520 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.120617] kworker/0:25 I 0 2540 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.120821] kworker/u16:0 I 0 2641 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.121027] kworker/2:1 I 0 2763 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.121231] kworker/0:0 I 0 2782 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.121451] kworker/0:1 I 0 2850 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.121657] kworker/0:2 I 0 2866 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.121861] kworker/0:3 I 0 2867 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.122066] kworker/2:0 I 0 2877 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.122273] kworker/0:5 I 0 2890 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.122495] kworker/0:7 I 0 2908 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.122705] kworker/0:8 I 0 2914 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.122910] kworker/0:9 I 0 2944 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.123115] kworker/0:10 I 0 2945 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.123335] kworker/0:13 I 0 2978 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.123543] kworker/0:15 I 0 2980 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.123749] xterm S 0 2981 1126 0x00000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.124568] kworker/0:16 I 0 2984 2 0x80000000
> Jan 10 17:56:20 darkbook kernel: [ 2819.124775] kworker/0:17 I 0 2987 2 0x80000000
> Jan 10 17:56:21 darkbook kernel: [ 2819.173457] Showing busy workqueues and worker pools:
> Jan 10 17:56:21 darkbook kernel: [ 2819.173480] workqueue events_freezable: flags=0x4
> Jan 10 17:56:21 darkbook kernel: [ 2819.173502] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
> Jan 10 17:56:21 darkbook kernel: [ 2819.173540] in-flight: 1635:mmc_rescan
> Jan 10 17:56:21 darkbook kernel: [ 2819.173599] pool 4: cpus=2 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 2877 2763
> Jan 10 17:56:21 darkbook kernel: [ 2820.056697] sysrq: SysRq : Show clockevent devices & pending hrtimers (no others)
> Jan 10 17:56:23 darkbook kernel: [ 2821.458675] sysrq: SysRq : Show Regs
> Jan 10 17:56:23 darkbook kernel: [ 2821.459453]
> Jan 10 17:56:23 darkbook kernel: [ 2821.459464] CPU#0: ctrl: 000000000000000f
> Jan 10 17:56:23 darkbook kernel: [ 2821.459482] CPU#0: status: 8000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459500] CPU#0: overflow: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459518] CPU#0: fixed: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459537] CPU#0: pebs: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459555] CPU#0: debugctl: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459573] CPU#0: active: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459592] CPU#0: gen-PMC0 ctrl: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459611] CPU#0: gen-PMC0 count: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459630] CPU#0: gen-PMC0 left: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459650] CPU#0: gen-PMC1 ctrl: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459670] CPU#0: gen-PMC1 count: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459689] CPU#0: gen-PMC1 left: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459709] CPU#0: gen-PMC2 ctrl: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459728] CPU#0: gen-PMC2 count: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459748] CPU#0: gen-PMC2 left: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459767] CPU#0: gen-PMC3 ctrl: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459787] CPU#0: gen-PMC3 count: 000000000000ffff
> Jan 10 17:56:23 darkbook kernel: [ 2821.459806] CPU#0: gen-PMC3 left: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459826] CPU#0: fixed-PMC0 count: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459846] CPU#0: fixed-PMC1 count: 0000000000000000
> Jan 10 17:56:23 darkbook kernel: [ 2821.459866] CPU#0: fixed-PMC2 count: 0000000000000000
> Jan 10 17:56:24 darkbook kernel: [ 2822.972704] sysrq: SysRq : Show Memory
> Jan 10 17:56:24 darkbook kernel: [ 2822.973707] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
> Jan 10 17:56:28 darkbook kernel: [ 2827.075135] sysrq: SysRq : Emergency Sync
> Jan 10 17:56:31 darkbook exiting on signal 15
> ===
>
> The last one is me issuing a terminate-all-tasks so I can safely reboot.
>
> This is a regular build with many tracing/tracers options plus some
> debugging info. It is available at <http://rnsanchez.wait4.org/config-4.14>,
> if you need it.
>
> Let me know if you need more info.
>
> Cheers,
>
Some context of this problem :
commit 29869d66870a715177bfb505f66a7e0e8bcc89c3
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Feb 21 06:21:47 2017 -0800
tcp: Revert "tcp: tcp_probe: use spin_lock_bh()"
This reverts commit e70ac171658679ecf6bea4bbd9e9325cd6079d2b.
jtcp_rcv_established() is in fact called with hard irq being disabled.
Initial bug report from Ricardo Nabinger Sanchez [1] still needs
to be investigated, but does not look like a TCP bug.
[1] https://www.spinics.net/lists/netdev/msg420960.html
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: kernel test robot <xiaolong.ye@intel.com>
Cc: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit e70ac171658679ecf6bea4bbd9e9325cd6079d2b
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Feb 14 17:11:14 2017 -0800
tcp: tcp_probe: use spin_lock_bh()
tcp_rcv_established() can now run in process context.
We need to disable BH while acquiring tcp probe spinlock,
or risk a deadlock.
Fixes: 5413d1babe8f ("net: do not block BH while processing socket backlog")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Ricardo Nabinger Sanchez <rnsanchez@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply [flat|nested] 31+ messages in thread
* BUG: using smp_processor_id() in preemptible
@ 2018-01-11 12:31 Ricardo Nabinger Sanchez
2018-01-11 17:14 ` Eric Dumazet
0 siblings, 1 reply; 31+ messages in thread
From: Ricardo Nabinger Sanchez @ 2018-01-11 12:31 UTC (permalink / raw)
To: netdev
Greetings,
I'm getting occasional video lock-ups, and while checking logs I found
these:
===
[ 297.445296] BUG: using smp_processor_id() in preemptible [00000000] code: claws-mail/1635
[ 297.445319] caller is jprobe_return+0x12/0x25
[ 297.445332] CPU: 1 PID: 1635 Comm: claws-mail Not tainted 4.14.0 #1
[ 297.445341] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
[ 297.445349] Call Trace:
[ 297.445372] dump_stack+0x9f/0xe1
[ 297.445392] check_preemption_disabled+0xec/0xf0
[ 297.445409] jprobe_return+0x12/0x25
[ 297.445425] tcp_v4_do_rcv+0x7f/0x1a0
[ 297.445443] __release_sock+0x6d/0x100
[ 297.445462] release_sock+0x2b/0xb0
[ 297.445475] tcp_recvmsg+0x300/0x8f0
[ 297.445504] ? __lock_acquire+0x3ee/0x1610
[ 297.445517] ? core_sys_select+0x240/0x3e0
[ 297.445541] inet_recvmsg+0x51/0x1b0
[ 297.445566] sock_read_iter+0x8c/0xd0
[ 297.445598] __vfs_read+0xd5/0x140
[ 297.445632] vfs_read+0x9e/0x150
[ 297.445652] SyS_read+0x45/0xa0
[ 297.445675] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 297.445687] RIP: 0033:0x7ff2536001b8
[ 297.445696] RSP: 002b:00007ff247152890 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 297.445713] RAX: ffffffffffffffda RBX: ffff9cd088ccbff0 RCX: 00007ff2536001b8
[ 297.445721] RDX: 0000000000000005 RSI: 00007ff23c02bb43 RDI: 0000000000000013
[ 297.445730] RBP: 00007ff23c02bb43 R08: 0000000000000000 R09: 00007ff23c00e520
[ 297.445738] R10: 0000000000100000 R11: 0000000000000246 R12: 0000000000000086
[ 297.445746] R13: 000000000000002f R14: 00007ff254d3c998 R15: 0000000000000001
...
[ 366.965766] BUG: using smp_processor_id() in preemptible [00000000] code: Socket Thread/1435
[ 366.965769] caller is jprobe_return+0x12/0x25
[ 366.965773] CPU: 0 PID: 1435 Comm: Socket Thread Not tainted 4.14.0 #1
[ 366.965775] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
[ 366.965777] Call Trace:
[ 366.965780] dump_stack+0x9f/0xe1
[ 366.965786] check_preemption_disabled+0xec/0xf0
[ 366.965790] jprobe_return+0x12/0x25
[ 366.965793] tcp_v4_do_rcv+0x7f/0x1a0
[ 366.965797] __release_sock+0x6d/0x100
[ 366.965811] release_sock+0x2b/0xb0
[ 366.965813] tcp_recvmsg+0x300/0x8f0
[ 366.965826] inet_recvmsg+0x51/0x1b0
[ 366.965834] SYSC_recvfrom+0xc6/0x130
[ 366.965845] ? entry_SYSCALL_64_fastpath+0x5/0xc2
[ 366.965848] ? trace_hardirqs_on_caller+0xcb/0x200
[ 366.965851] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 366.965858] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 366.965860] RIP: 0033:0x7f475ab7e5da
[ 366.965862] RSP: 002b:00007f47438fc8b0 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
[ 366.965864] RAX: ffffffffffffffda RBX: ffff9cd088ae7ff0 RCX: 00007f475ab7e5da
[ 366.965865] RDX: 0000000000008000 RSI: 00007f4721202000 RDI: 000000000000007c
[ 366.965867] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 366.965868] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000086
[ 366.965869] R13: 00007f47212025a8 R14: 0000000000007a58 R15: 00007f474ba1e5f2
[ 366.966571] BUG: using smp_processor_id() in preemptible [00000000] code: Socket Thread/1435
[ 366.966574] caller is jprobe_return+0x12/0x25
[ 366.966576] CPU: 0 PID: 1435 Comm: Socket Thread Not tainted 4.14.0 #1
[ 366.966577] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
[ 366.966578] Call Trace:
[ 366.966582] dump_stack+0x9f/0xe1
[ 366.966586] check_preemption_disabled+0xec/0xf0
[ 366.966592] jprobe_return+0x12/0x25
[ 366.966596] tcp_v4_do_rcv+0x7f/0x1a0
[ 366.966601] __release_sock+0x6d/0x100
[ 366.966606] release_sock+0x2b/0xb0
[ 366.966610] tcp_recvmsg+0x300/0x8f0
[ 366.966622] inet_recvmsg+0x51/0x1b0
[ 366.966630] SYSC_recvfrom+0xc6/0x130
[ 366.966643] ? entry_SYSCALL_64_fastpath+0x5/0xc2
[ 366.966647] ? trace_hardirqs_on_caller+0xcb/0x200
[ 366.966651] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 366.966667] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 366.966669] RIP: 0033:0x7f475ab7e5da
[ 366.966670] RSP: 002b:00007f47438fc8b0 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
[ 366.966673] RAX: ffffffffffffffda RBX: ffff9cd088ae7ff0 RCX: 00007f475ab7e5da
[ 366.966674] RDX: 0000000000008000 RSI: 00007f4721202000 RDI: 000000000000007c
[ 366.966676] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 366.966677] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000086
[ 366.966679] R13: 00007f47438fca70 R14: 00000000000005a8 R15: 00007f4721202000
[ 366.979991] BUG: using smp_processor_id() in preemptible [00000000] code: Socket Thread/1435
[ 366.979999] caller is jprobe_return+0x12/0x25
[ 366.980004] CPU: 0 PID: 1435 Comm: Socket Thread Not tainted 4.14.0 #1
[ 366.980007] Hardware name: Micro-Star International Co., Ltd. GX780/GT780/MS-1761, BIOS E1761IMS V3.01 05/02/2011
[ 366.980012] Call Trace:
[ 366.980023] dump_stack+0x9f/0xe1
[ 366.980033] check_preemption_disabled+0xec/0xf0
[ 366.980040] jprobe_return+0x12/0x25
[ 366.980046] tcp_v4_do_rcv+0x7f/0x1a0
[ 366.980054] __release_sock+0x6d/0x100
[ 366.980062] release_sock+0x2b/0xb0
[ 366.980068] tcp_recvmsg+0x300/0x8f0
[ 366.980105] inet_recvmsg+0x51/0x1b0
[ 366.980117] SYSC_recvfrom+0xc6/0x130
[ 366.980130] ? entry_SYSCALL_64_fastpath+0x5/0xc2
[ 366.980134] ? trace_hardirqs_on_caller+0xcb/0x200
[ 366.980137] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 366.980145] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 366.980147] RIP: 0033:0x7f475ab7e5da
[ 366.980149] RSP: 002b:00007f47438fc8b0 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
[ 366.980152] RAX: ffffffffffffffda RBX: ffff9cd088ae7ff0 RCX: 00007f475ab7e5da
[ 366.980154] RDX: 0000000000008000 RSI: 00007f4721202000 RDI: 000000000000007c
[ 366.980157] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 366.980158] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000086
[ 366.980161] R13: 0000000000008000 R14: 00007f47438fca70 R15: 00007f474ba1e5f2
===
There are many of those, and they keep popping up throughout normal
usage. Sometimes, though, things go awry but without much information:
===
Jan 10 17:54:39 kernel: [ 2717.421681] note: Socket Thread[1812] exited with preempt_count 1
===
It seems that when the event above happens (preempt_count 1), a chain of
events unfolds and my video locks up. Sometimes the mouse pointer will
continue to work; others it is a full lockup.
I understand this is not necessarily linked to the network stack, but as it
happens, the traces always have the network stack in common and the application
that exits has always been one that deals with network (Firefox and Claws
Mail so far).
This has been happening for quite a while now, at least since 4.9 (probably
before that). I don't know how to trigger this: it could take as much as
45 days to "lock up" or as little as a few minutes in sequence. Yesterday,
the first time it locked up took around 20 days, and then less than 10 minutes.
The best information I have are dumps from SysRq:
===
Jan 10 17:54:39 darkbook kernel: [ 2717.421681] note: Socket Thread[1812] exited with preempt_count 1
Jan 10 17:55:45 darkbook acpid: client 1084[0:100] has disconnected
Jan 10 17:55:46 darkbook /usr/sbin/gpm[970]: *** info [mice.c(1990)]:
Jan 10 17:55:46 darkbook /usr/sbin/gpm[970]: imps2: Auto-detected intellimouse PS/2
Jan 10 17:56:12 darkbook kernel: [ 2811.376514] sysrq: SysRq : Show Locks Held
Jan 10 17:56:14 darkbook kernel: [ 2813.214132] sysrq: SysRq : Show backtrace of all active CPUs
Jan 10 17:56:14 darkbook kernel: [ 2813.215131] Sending NMI from CPU 0 to CPUs 1-7:
Jan 10 17:56:16 darkbook kernel: [ 2814.975638] sysrq: SysRq : Show Blocked State
Jan 10 17:56:16 darkbook kernel: [ 2814.975679] task PC stack pid father
Jan 10 17:56:20 darkbook kernel: [ 2819.060962] localStorage DB S 0 1884 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.061483] LoadRoots S 0 1900 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.061970] SysProxySetting S 0 1901 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.062477] dconf worker S 0 1902 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.063222] ProxyResolution S 0 1903 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.063727] DataStorage S 0 1904 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.064175] URL Classifier S 0 1905 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.064680] Classif~ Update S 0 1906 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.065182] DataStorage S 0 1908 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.065718] DataStorage S 0 1909 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.066151] SaveScripts S 0 1910 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.066684] Cache I/O S 0 1911 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.067149] mozStorage #1 S 0 1913 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.067693] mozStorage #2 S 0 1916 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.068222] QuotaManager IO S 0 1917 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.068721] mozStorage #3 S 0 1918 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.069210] mozStorage #4 S 0 1919 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.069714] mozStorage #5 S 0 1922 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.070242] DOM Worker S 0 1923 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.070743] DOM Worker S 0 1947 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.071272] IdentityCrypto S 0 1967 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.071799] mozStorage #7 S 0 1976 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.072267] mozStorage #8 S 0 1978 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.072775] DNS Resolver #7 S 0 2265 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.073256] DNS Resolver #9 S 0 2860 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.073763] DNS Res~ver #10 S 0 2861 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.074266] DNS Res~ver #11 S 0 2862 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.074765] speechd init S 0 2894 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.075268] BgFileSaver S 0 2916 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.075779] mozStorage #9 S 0 2919 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.076270] DOMCacheThread S 0 2939 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.076793] Web Content S 0 1852 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.077632] Chrome_~dThread S 0 1855 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.078069] JS Watchdog S 0 1858 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.078634] JS Helper S 0 1859 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.079164] JS Helper S 0 1860 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.079689] JS Helper S 0 1861 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.080219] JS Helper S 0 1862 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.080785] JS Helper S 0 1863 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.081369] JS Helper S 0 1864 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.081901] JS Helper S 0 1865 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.082450] JS Helper S 0 1866 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.082964] JS Helper S 0 1867 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.083507] JS Helper S 0 1868 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.084043] JS Helper S 0 1869 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.084610] JS Helper S 0 1870 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.085146] Socket Thread S 0 1871 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.085872] Hang Monitor S 0 1872 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.086379] Timer S 0 1873 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.086886] ImgDecoder #1 S 0 1874 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.087411] ImgDecoder #2 S 0 1875 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.087960] ImgDecoder #3 S 0 1876 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.088527] ImgDecoder #4 S 0 1877 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.089036] ImgDecoder #5 S 0 1878 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.089578] ImgDecoder #6 S 0 1879 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.090130] ImgDecoder #7 S 0 1880 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.090673] ImageIO S 0 1881 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.091220] ImageBr~geChild S 0 1882 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.092005] VideoChild S 0 1883 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.092782] threaded-ml S 0 1887 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.093679] ProcessHangMon S 0 1888 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.094371] ProfilerChild S 0 1889 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.094984] gmain S 0 1890 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.095822] gdbus S 0 1891 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.096438] StyleThread#0 S 0 1893 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.096909] StyleThread#1 S 0 1894 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.097453] StyleThread#2 S 0 1895 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.098059] StyleThread#3 S 0 1896 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.098717] StyleThread#4 S 0 1897 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.099407] StyleThread#5 S 0 1898 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.100011] HTML5 Parser S 0 1914 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.100616] dconf worker S 0 1979 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.101536] MediaPl~ack #13 S 0 2853 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.102052] MediaPl~ack #14 S 0 2854 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.102605] DOM Worker S 0 2889 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.103124] DOM Worker S 0 2893 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.103708] MediaTimer #3 S 0 2898 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.104244] MediaPl~ack #17 S 0 2900 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.104802] MediaPl~ack #18 S 0 2901 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.105328] MediaPD~oder #6 S 0 2902 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.105835] MediaPD~oder #7 S 0 2903 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.106378] MediaPD~oder #8 S 0 2904 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.106883] MediaPD~oder #9 S 0 2905 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.107405] DOM Worker S 0 2938 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.107937] SubtleCrypto #1 S 0 2947 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.108457] StreamTrans #16 S 0 2954 1809 0x00000100
Jan 10 17:56:20 darkbook kernel: [ 2819.109021] fish S 0 2165 1422 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.109522] ssh S 0 2214 2165 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.110386] kworker/0:4 I 0 2327 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.110599] xfrun4 S 0 2329 1127 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.111390] gmain S 0 2330 1127 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.112123] gdbus S 0 2331 1127 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.112797] xmms S 0 2337 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.113584] xmms S 0 2338 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.114426] xmms S 0 2339 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.114842] xmms S 0 2340 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.115265] xmms S 0 2345 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.116489] xmms S 0 2847 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.117433] threaded-ml S 0 2848 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.118185] xmms S 0 2849 2329 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.118992] kworker/0:6 I 0 2346 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.119203] kworker/0:14 I 0 2362 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.119424] fish S 0 2414 1422 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.120179] kworker/u16:1 I 0 2455 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.120408] kworker/0:23 I 0 2520 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.120617] kworker/0:25 I 0 2540 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.120821] kworker/u16:0 I 0 2641 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.121027] kworker/2:1 I 0 2763 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.121231] kworker/0:0 I 0 2782 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.121451] kworker/0:1 I 0 2850 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.121657] kworker/0:2 I 0 2866 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.121861] kworker/0:3 I 0 2867 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.122066] kworker/2:0 I 0 2877 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.122273] kworker/0:5 I 0 2890 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.122495] kworker/0:7 I 0 2908 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.122705] kworker/0:8 I 0 2914 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.122910] kworker/0:9 I 0 2944 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.123115] kworker/0:10 I 0 2945 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.123335] kworker/0:13 I 0 2978 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.123543] kworker/0:15 I 0 2980 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.123749] xterm S 0 2981 1126 0x00000000
Jan 10 17:56:20 darkbook kernel: [ 2819.124568] kworker/0:16 I 0 2984 2 0x80000000
Jan 10 17:56:20 darkbook kernel: [ 2819.124775] kworker/0:17 I 0 2987 2 0x80000000
Jan 10 17:56:21 darkbook kernel: [ 2819.173457] Showing busy workqueues and worker pools:
Jan 10 17:56:21 darkbook kernel: [ 2819.173480] workqueue events_freezable: flags=0x4
Jan 10 17:56:21 darkbook kernel: [ 2819.173502] pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=1/256
Jan 10 17:56:21 darkbook kernel: [ 2819.173540] in-flight: 1635:mmc_rescan
Jan 10 17:56:21 darkbook kernel: [ 2819.173599] pool 4: cpus=2 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 2877 2763
Jan 10 17:56:21 darkbook kernel: [ 2820.056697] sysrq: SysRq : Show clockevent devices & pending hrtimers (no others)
Jan 10 17:56:23 darkbook kernel: [ 2821.458675] sysrq: SysRq : Show Regs
Jan 10 17:56:23 darkbook kernel: [ 2821.459453]
Jan 10 17:56:23 darkbook kernel: [ 2821.459464] CPU#0: ctrl: 000000000000000f
Jan 10 17:56:23 darkbook kernel: [ 2821.459482] CPU#0: status: 8000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459500] CPU#0: overflow: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459518] CPU#0: fixed: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459537] CPU#0: pebs: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459555] CPU#0: debugctl: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459573] CPU#0: active: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459592] CPU#0: gen-PMC0 ctrl: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459611] CPU#0: gen-PMC0 count: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459630] CPU#0: gen-PMC0 left: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459650] CPU#0: gen-PMC1 ctrl: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459670] CPU#0: gen-PMC1 count: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459689] CPU#0: gen-PMC1 left: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459709] CPU#0: gen-PMC2 ctrl: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459728] CPU#0: gen-PMC2 count: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459748] CPU#0: gen-PMC2 left: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459767] CPU#0: gen-PMC3 ctrl: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459787] CPU#0: gen-PMC3 count: 000000000000ffff
Jan 10 17:56:23 darkbook kernel: [ 2821.459806] CPU#0: gen-PMC3 left: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459826] CPU#0: fixed-PMC0 count: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459846] CPU#0: fixed-PMC1 count: 0000000000000000
Jan 10 17:56:23 darkbook kernel: [ 2821.459866] CPU#0: fixed-PMC2 count: 0000000000000000
Jan 10 17:56:24 darkbook kernel: [ 2822.972704] sysrq: SysRq : Show Memory
Jan 10 17:56:24 darkbook kernel: [ 2822.973707] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jan 10 17:56:28 darkbook kernel: [ 2827.075135] sysrq: SysRq : Emergency Sync
Jan 10 17:56:31 darkbook exiting on signal 15
===
The last one is me issuing a terminate-all-tasks so I can safely reboot.
This is a regular build with many tracing/tracers options plus some
debugging info. It is available at <http://rnsanchez.wait4.org/config-4.14>,
if you need it.
Let me know if you need more info.
Cheers,
--
Ricardo Nabinger Sanchez http://rnsanchez.wait4.org/
"You never learned anything by doing it right."
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2012-10-24 8:24 Paul Thompson
@ 2012-10-24 22:39 ` Borislav Petkov
0 siblings, 0 replies; 31+ messages in thread
From: Borislav Petkov @ 2012-10-24 22:39 UTC (permalink / raw)
To: Paul Thompson; +Cc: linux-kernel
On Wed, Oct 24, 2012 at 04:24:23AM -0400, Paul Thompson wrote:
> Hi;
>
> Just saw this after invoking cpufreq-set -g performance in
> an attempt to enhance a stuttering mpeg transcode for ps3mediaserver.
> This repeats in the logs about 10 times. If anyone cares, I
> will be responsive.
>
> Paul
>
> 2012 Oct 24 01:39:14: BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq-set/22941
> 2012 Oct 24 01:39:14: caller is powernowk8_target+0x19/0x50
...
http://marc.info/?l=linux-kernel&m=135111561229153
HTH.
--
Regards/Gruss,
Boris.
^ permalink raw reply [flat|nested] 31+ messages in thread
* BUG: using smp_processor_id() in preemptible
@ 2012-10-24 8:24 Paul Thompson
2012-10-24 22:39 ` Borislav Petkov
0 siblings, 1 reply; 31+ messages in thread
From: Paul Thompson @ 2012-10-24 8:24 UTC (permalink / raw)
To: linux-kernel
Hi;
Just saw this after invoking cpufreq-set -g performance in
an attempt to enhance a stuttering mpeg transcode for ps3mediaserver.
This repeats in the logs about 10 times. If anyone cares, I
will be responsive.
Paul
2012 Oct 24 01:39:14: BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq-set/22941
2012 Oct 24 01:39:14: caller is powernowk8_target+0x19/0x50
2012 Oct 24 01:39:14: Pid: 22941, comm: cpufreq-set Not tainted 3.6.2-low-lat #13
2012 Oct 24 01:39:14: Call Trace:
2012 Oct 24 01:39:14: [<ffffffff811b0476>] ? debug_smp_processor_id+0xd6/0xf0
2012 Oct 24 01:39:14: [<ffffffff812eb6e9>] ? powernowk8_target+0x19/0x50
2012 Oct 24 01:39:14: [<ffffffff812e9a95>] ? cpufreq_governor_performance+0x25/0x30
2012 Oct 24 01:39:14: [<ffffffff812e7f87>] ? __cpufreq_governor+0x47/0xc0
2012 Oct 24 01:39:14: [<ffffffff812e8164>] ? __cpufreq_set_policy+0x164/0x1a0
2012 Oct 24 01:39:14: [<ffffffff812e8849>] ? store_scaling_governor+0xc9/0x1b0
2012 Oct 24 01:39:15: [<ffffffff812e8c40>] ? cpufreq_update_policy+0xf0/0xf0
2012 Oct 24 01:39:15: [<ffffffff812e9005>] ? store+0x65/0xb0
2012 Oct 24 01:39:15: [<ffffffff8112574d>] ? sysfs_write_file+0xcd/0x150
2012 Oct 24 01:39:15: [<ffffffff810ca9a7>] ? vfs_write+0xa7/0x180
2012 Oct 24 01:39:15: [<ffffffff810cacd7>] ? sys_write+0x47/0x90
2012 Oct 24 01:39:15: [<ffffffff813d8526>] ? system_call_fastpath+0x1a/0x1f
^ permalink raw reply [flat|nested] 31+ messages in thread
* BUG: using smp_processor_id() in preemptible
@ 2010-05-25 5:57 ` Artem Bityutskiy
0 siblings, 0 replies; 31+ messages in thread
From: Artem Bityutskiy @ 2010-05-25 5:57 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: linux-fsdevel, LKML
Hi,
I get tons of these debugging complaints with the latest Linus' tree:
BUG: using smp_processor_id() in preemptible [00000000] code: sync/2503
caller is dqstats_inc+0x19/0x2c
Pid: 2503, comm: sync Tainted: G D 2.6.34-misc-2.6 #9
Call Trace:
[<ffffffff811ad1a2>] debug_smp_processor_id+0xc2/0xdc
[<ffffffff81134c7e>] dqstats_inc+0x19/0x2c
[<ffffffff8113786e>] vfs_quota_sync+0x1bd/0x2a5
[<ffffffff8111252b>] ? sync_one_sb+0x0/0x1d
[<ffffffff811124e7>] __sync_filesystem+0x3a/0x7e
[<ffffffff81112546>] sync_one_sb+0x1b/0x1d
[<ffffffff810f4d70>] iterate_supers+0x6d/0xb2
[<ffffffff81112477>] sync_filesystems+0x1b/0x1d
[<ffffffff81112564>] sys_sync+0x1c/0x2e
[<ffffffff81002a6b>] system_call_fastpath+0x16/0x1b
and git blame points to you.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply [flat|nested] 31+ messages in thread
* BUG: using smp_processor_id() in preemptible
@ 2010-05-25 5:57 ` Artem Bityutskiy
0 siblings, 0 replies; 31+ messages in thread
From: Artem Bityutskiy @ 2010-05-25 5:57 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: linux-fsdevel, LKML
Hi,
I get tons of these debugging complaints with the latest Linus' tree:
BUG: using smp_processor_id() in preemptible [00000000] code: sync/2503
caller is dqstats_inc+0x19/0x2c
Pid: 2503, comm: sync Tainted: G D 2.6.34-misc-2.6 #9
Call Trace:
[<ffffffff811ad1a2>] debug_smp_processor_id+0xc2/0xdc
[<ffffffff81134c7e>] dqstats_inc+0x19/0x2c
[<ffffffff8113786e>] vfs_quota_sync+0x1bd/0x2a5
[<ffffffff8111252b>] ? sync_one_sb+0x0/0x1d
[<ffffffff811124e7>] __sync_filesystem+0x3a/0x7e
[<ffffffff81112546>] sync_one_sb+0x1b/0x1d
[<ffffffff810f4d70>] iterate_supers+0x6d/0xb2
[<ffffffff81112477>] sync_filesystems+0x1b/0x1d
[<ffffffff81112564>] sys_sync+0x1c/0x2e
[<ffffffff81002a6b>] system_call_fastpath+0x16/0x1b
and git blame points to you.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2009-01-13 9:44 ` Tim Blechmann
@ 2009-02-20 20:42 ` Paul Gortmaker
0 siblings, 0 replies; 31+ messages in thread
From: Paul Gortmaker @ 2009-02-20 20:42 UTC (permalink / raw)
To: Tim Blechmann; +Cc: linux-rt-users, Steven Rostedt
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
On Tue, Jan 13, 2009 at 4:44 AM, Tim Blechmann <tim@klingt.org> wrote:
> fyi, this is still an issue in 2.6.26.8-rt13.
>
> tim
The attached patch should fix it ; it is based on the discussion
that took place here on rt-users.
Paul.
>
> Tim Blechmann wrote:
>
>> hi all,
>>
>> using the 2.6.26.6-rt11 patchset on a 2.6.26.8 kernel, i get the
>> following stack traces:
>>
>> [ 4262.931832] BUG: using smp_processor_id() in preemptible [00000000]
>> code: bash/361 [ 4262.931846] caller is
>> mem_cgroup_charge_statistics+0x6d/0xa0 [ 4262.931852] Pid: 361, comm:
>> bash Not tainted 2.6.26.8-rt11 #3 [ 4262.931855]
>> [ 4262.931856] Call Trace:
>> [ 4262.931886] [<ffffffff80396e8c>] debug_smp_processor_id+0xcc/0xd0 [
>> 4262.931895] [<ffffffff802daead>]
>> mem_cgroup_charge_statistics+0x6d/0xa0 [ 4262.931905]
[-- Attachment #2: 0001-memcg-fix-BUG-using-smp_processor_id.patch --]
[-- Type: text/x-patch, Size: 2987 bytes --]
From faa0ea31405ec9d44e8242e224f8e607642f3c5e Mon Sep 17 00:00:00 2001
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon, 26 Jan 2009 21:15:22 -0500
Subject: [PATCH] memcg: fix BUG: using smp_processor_id() in preemptible
A combination of upstream (e.g. addb9efe) and as per discussion
on rt list (Dec 2008) between Tim Blechmann and Kamezawa Hiroyuki,
this is needed to fix the following:
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/1
caller is mem_cgroup_charge_statistics+0x85/0xa0
Pid: 1, comm: swapper Not tainted 2.6.26.8-rt12 #1
Call Trace:
[<ffffffff8038eb94>] debug_smp_processor_id+0xc4/0xd0
[<ffffffff8029ffe5>] mem_cgroup_charge_statistics+0x85/0xa0
[<ffffffff802a0039>] __mem_cgroup_add_list+0x39/0x60
[<ffffffff802a0807>] mem_cgroup_charge_common+0x317/0x340
[<ffffffff802a0849>] mem_cgroup_cache_charge+0x19/0x20
[<ffffffff80276918>] add_to_page_cache+0x38/0x250
[<ffffffff8027d43d>] ? __alloc_pages_internal+0xed/0x4f0
[<ffffffff80276b49>] add_to_page_cache_lru+0x19/0x40
[<ffffffff80277603>] find_or_create_page+0x63/0xb0
[<ffffffff802cd401>] __getblk+0x101/0x320
[<ffffffff802fddd6>] __ext3_get_inode_loc+0x106/0x320
[<ffffffff802fe060>] ext3_iget+0x70/0x420
[<ffffffff80305068>] ext3_lookup+0xa8/0x100
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
mm/memcontrol.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ed1cfb1..86e7f14 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -65,11 +65,11 @@ struct mem_cgroup_stat {
/*
* For accounting under irq disable, no need for increment preempt count.
*/
-static void __mem_cgroup_stat_add_safe(struct mem_cgroup_stat *stat,
+static inline void __mem_cgroup_stat_add_safe(struct mem_cgroup_stat_cpu *stat,
enum mem_cgroup_stat_index idx, int val)
{
- int cpu = smp_processor_id();
- stat->cpustat[cpu].count[idx] += val;
+ stat->count[idx] += val;
+
}
static s64 mem_cgroup_read_stat(struct mem_cgroup_stat *stat,
@@ -195,19 +195,24 @@ static void mem_cgroup_charge_statistics(struct mem_cgroup *mem, int flags,
{
int val = (charge)? 1 : -1;
struct mem_cgroup_stat *stat = &mem->stat;
+ struct mem_cgroup_stat_cpu *cpustat;
+ int cpu = get_cpu();
VM_BUG_ON(!irqs_disabled());
+
+ cpustat = &stat->cpustat[cpu];
if (flags & PAGE_CGROUP_FLAG_CACHE)
- __mem_cgroup_stat_add_safe(stat, MEM_CGROUP_STAT_CACHE, val);
+ __mem_cgroup_stat_add_safe(cpustat, MEM_CGROUP_STAT_CACHE, val);
else
- __mem_cgroup_stat_add_safe(stat, MEM_CGROUP_STAT_RSS, val);
+ __mem_cgroup_stat_add_safe(cpustat, MEM_CGROUP_STAT_RSS, val);
if (charge)
- __mem_cgroup_stat_add_safe(stat,
+ __mem_cgroup_stat_add_safe(cpustat,
MEM_CGROUP_STAT_PGPGIN_COUNT, 1);
else
- __mem_cgroup_stat_add_safe(stat,
+ __mem_cgroup_stat_add_safe(cpustat,
MEM_CGROUP_STAT_PGPGOUT_COUNT, 1);
+ put_cpu();
}
static struct mem_cgroup_per_zone *
--
1.6.0.4
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2008-12-08 12:13 Tim Blechmann
@ 2009-01-13 9:44 ` Tim Blechmann
2009-02-20 20:42 ` Paul Gortmaker
0 siblings, 1 reply; 31+ messages in thread
From: Tim Blechmann @ 2009-01-13 9:44 UTC (permalink / raw)
To: linux-rt-users
fyi, this is still an issue in 2.6.26.8-rt13.
tim
On Mon, 08 Dec 2008 12:13:31 +0000, Tim Blechmann wrote:
> hi all,
>
> using the 2.6.26.6-rt11 patchset on a 2.6.26.8 kernel, i get the
> following stack traces:
>
> [ 4262.931832] BUG: using smp_processor_id() in preemptible [00000000]
> code: bash/361 [ 4262.931846] caller is
> mem_cgroup_charge_statistics+0x6d/0xa0 [ 4262.931852] Pid: 361, comm:
> bash Not tainted 2.6.26.8-rt11 #3 [ 4262.931855]
> [ 4262.931856] Call Trace:
> [ 4262.931886] [<ffffffff80396e8c>] debug_smp_processor_id+0xcc/0xd0 [
> 4262.931895] [<ffffffff802daead>]
> mem_cgroup_charge_statistics+0x6d/0xa0 [ 4262.931905]
> [<ffffffff802daf19>] __mem_cgroup_add_list+0x39/0x60 [ 4262.931911]
> [<ffffffff802db744>] mem_cgroup_charge_common+0x314/0x330 [ 4262.931925]
> [<ffffffff802db78e>] mem_cgroup_charge+0xe/0x10 [ 4262.931933]
> [<ffffffff802b8773>] do_wp_page+0x133/0x5a0 [ 4262.931944]
> [<ffffffff804d7461>] ? __rt_spin_lock+0x81/0x90 [ 4262.931956]
> [<ffffffff802ba805>] handle_mm_fault+0x605/0x900 [ 4262.931975]
> [<ffffffff804dacfc>] do_page_fault+0x45c/0xd50 [ 4262.931998]
> [<ffffffff8021d6ee>] ? native_smp_send_reschedule+0x2e/0x50 [
> 4262.932006] [<ffffffff8023a041>] ? __resched_task+0x91/0x120 [
> 4262.932015] [<ffffffff8023b5f4>] ? task_new_fair+0xb4/0x100 [
> 4262.932027] [<ffffffff8023e09b>] ? wake_up_new_task+0xdb/0x190 [
> 4262.932038] [<ffffffff80241190>] ? do_fork+0xf0/0x330 [ 4262.932048]
> [<ffffffff804d748e>] ? rt_spin_lock+0x1e/0x50 [ 4262.932056]
> [<ffffffff802dbad2>] ? fd_install+0x52/0x60 [ 4262.932072]
> [<ffffffff804d81c9>] error_exit+0x0/0x60
--
tim@klingt.org
http://tim.klingt.org
Lesser artists borrow, great artists steal.
Igor Stravinsky
^ permalink raw reply [flat|nested] 31+ messages in thread
* BUG: using smp_processor_id() in preemptible
@ 2008-12-08 12:13 Tim Blechmann
2009-01-13 9:44 ` Tim Blechmann
0 siblings, 1 reply; 31+ messages in thread
From: Tim Blechmann @ 2008-12-08 12:13 UTC (permalink / raw)
To: linux-rt-users
hi all,
using the 2.6.26.6-rt11 patchset on a 2.6.26.8 kernel, i get the
following stack traces:
[ 4262.931832] BUG: using smp_processor_id() in preemptible [00000000] code: bash/361
[ 4262.931846] caller is mem_cgroup_charge_statistics+0x6d/0xa0
[ 4262.931852] Pid: 361, comm: bash Not tainted 2.6.26.8-rt11 #3
[ 4262.931855]
[ 4262.931856] Call Trace:
[ 4262.931886] [<ffffffff80396e8c>] debug_smp_processor_id+0xcc/0xd0
[ 4262.931895] [<ffffffff802daead>] mem_cgroup_charge_statistics+0x6d/0xa0
[ 4262.931905] [<ffffffff802daf19>] __mem_cgroup_add_list+0x39/0x60
[ 4262.931911] [<ffffffff802db744>] mem_cgroup_charge_common+0x314/0x330
[ 4262.931925] [<ffffffff802db78e>] mem_cgroup_charge+0xe/0x10
[ 4262.931933] [<ffffffff802b8773>] do_wp_page+0x133/0x5a0
[ 4262.931944] [<ffffffff804d7461>] ? __rt_spin_lock+0x81/0x90
[ 4262.931956] [<ffffffff802ba805>] handle_mm_fault+0x605/0x900
[ 4262.931975] [<ffffffff804dacfc>] do_page_fault+0x45c/0xd50
[ 4262.931998] [<ffffffff8021d6ee>] ? native_smp_send_reschedule+0x2e/0x50
[ 4262.932006] [<ffffffff8023a041>] ? __resched_task+0x91/0x120
[ 4262.932015] [<ffffffff8023b5f4>] ? task_new_fair+0xb4/0x100
[ 4262.932027] [<ffffffff8023e09b>] ? wake_up_new_task+0xdb/0x190
[ 4262.932038] [<ffffffff80241190>] ? do_fork+0xf0/0x330
[ 4262.932048] [<ffffffff804d748e>] ? rt_spin_lock+0x1e/0x50
[ 4262.932056] [<ffffffff802dbad2>] ? fd_install+0x52/0x60
[ 4262.932072] [<ffffffff804d81c9>] error_exit+0x0/0x60
hth, tim
--
tim@klingt.org
http://tim.klingt.org
There's no such entity as "most people". These are generalities. All
generalities are meaningless. You've got to pin it down to a specific
person doing a specific thing at a specific time and space.
William S. Burroughs
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible
2008-08-20 5:34 Aneesh Kumar K.V
@ 2008-08-21 4:17 ` Eric Sandeen
0 siblings, 0 replies; 31+ messages in thread
From: Eric Sandeen @ 2008-08-21 4:17 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: ext4 development
Aneesh Kumar K.V wrote:
> BUG: using smp_processor_id() in preemptible [00000000] code:
> fsstress/20995
> caller is ext4_mb_initialize_context+0x20c/0x22c
> Pid: 20995, comm: fsstress Not tainted 2.6.27-rc3-autokern1 #1
> [<c0294a2f>] debug_smp_processor_id+0x9f/0xb8
> [<c01e523d>] ext4_mb_initialize_context+0x20c/0x22c
> [<c01ea017>] ext4_mb_new_blocks+0x17c/0x715
> [<c0136b43>] ? trace_hardirqs_on+0xb/0xd
> [<c01e23f2>] ext4_ext_get_blocks+0xbaf/0xde1
> [<c0137d20>] ? __lock_acquire+0x61e/0x674
> [<c0137d20>] ? __lock_acquire+0x61e/0x674
> [<c01d464a>] ext4_get_blocks_wrap+0xce/0x1eb
> [<c01dfaba>] ext4_fallocate+0x135/0x27d
> [<c016472d>] ? fget+0x1d/0xd3
> [<c01647aa>] ? fget+0x9a/0xd3
> [<c01623a4>] sys_fallocate+0xce/0xf3
> [<c0102bb9>] sysenter_do_call+0x12/0x35
> =======================
whoops, ok, I should probably convert it to use raw_smp_processor_id; I
don't think we care if we get pre-empted and the cpu changes; we use the
cpu id exactly once to grab it from the array, I think we don't need any
atomicity. I'll convert to raw_smp_processor_id() to avoid the debug
check, unless anyone sees a problem with that ...
-Eric
^ permalink raw reply [flat|nested] 31+ messages in thread
* BUG: using smp_processor_id() in preemptible
@ 2008-08-20 5:34 Aneesh Kumar K.V
2008-08-21 4:17 ` Eric Sandeen
0 siblings, 1 reply; 31+ messages in thread
From: Aneesh Kumar K.V @ 2008-08-20 5:34 UTC (permalink / raw)
To: Eric Sandeen; +Cc: ext4 development
BUG: using smp_processor_id() in preemptible [00000000] code:
fsstress/20995
caller is ext4_mb_initialize_context+0x20c/0x22c
Pid: 20995, comm: fsstress Not tainted 2.6.27-rc3-autokern1 #1
[<c0294a2f>] debug_smp_processor_id+0x9f/0xb8
[<c01e523d>] ext4_mb_initialize_context+0x20c/0x22c
[<c01ea017>] ext4_mb_new_blocks+0x17c/0x715
[<c0136b43>] ? trace_hardirqs_on+0xb/0xd
[<c01e23f2>] ext4_ext_get_blocks+0xbaf/0xde1
[<c0137d20>] ? __lock_acquire+0x61e/0x674
[<c0137d20>] ? __lock_acquire+0x61e/0x674
[<c01d464a>] ext4_get_blocks_wrap+0xce/0x1eb
[<c01dfaba>] ext4_fallocate+0x135/0x27d
[<c016472d>] ? fget+0x1d/0xd3
[<c01647aa>] ? fget+0x9a/0xd3
[<c01623a4>] sys_fallocate+0xce/0xf3
[<c0102bb9>] sysenter_do_call+0x12/0x35
=======================
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2018-01-11 17:14 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-24 14:15 BUG: using smp_processor_id() in preemptible Johannes Berg
2009-06-28 14:11 ` Avi Kivity
2009-06-29 8:32 ` Johannes Berg
2009-06-29 9:08 ` Avi Kivity
2009-06-29 9:54 ` Johannes Berg
2009-06-29 9:57 ` Johannes Berg
2009-06-29 10:00 ` Avi Kivity
2009-06-29 10:06 ` Johannes Berg
2009-06-29 10:16 ` Avi Kivity
2009-06-29 10:18 ` Johannes Berg
2009-06-29 10:25 ` Avi Kivity
2009-06-29 10:32 ` Johannes Berg
2009-06-29 10:39 ` Avi Kivity
2009-06-29 10:55 ` Johannes Berg
2009-06-29 11:38 ` Avi Kivity
2009-06-29 12:03 ` Johannes Berg
2009-06-29 9:59 ` Avi Kivity
2009-06-29 10:00 ` Johannes Berg
2009-06-29 10:04 ` Avi Kivity
2009-06-29 10:04 ` Johannes Berg
-- strict thread matches above, loose matches on Subject: below --
2018-01-11 12:31 Ricardo Nabinger Sanchez
2018-01-11 17:14 ` Eric Dumazet
2012-10-24 8:24 Paul Thompson
2012-10-24 22:39 ` Borislav Petkov
2010-05-25 5:57 Artem Bityutskiy
2010-05-25 5:57 ` Artem Bityutskiy
2008-12-08 12:13 Tim Blechmann
2009-01-13 9:44 ` Tim Blechmann
2009-02-20 20:42 ` Paul Gortmaker
2008-08-20 5:34 Aneesh Kumar K.V
2008-08-21 4:17 ` Eric Sandeen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.