Re: kexec/kdump kernel fails to start

2012-10-18 Thread Flavio Leitner 
On Thu, 18 Oct 2012 14:33:23 +0800
Dave Young dyo...@redhat.com wrote:
[...]
 Just see Yinghai's coments, later init_memory_mapping cleanup
 will also address the 4k pages in first 2/4M, so revert them should be better.
 https://lkml.org/lkml/2012/9/4/533
 
 Here is a patch for the reverting:
 ---
 x86 mm: Revert find_early_table_space fix
 
 722bc6b16771ed80871e1fd81c86d3627dda2ac8 Try to address the issue that the
 first 2/4M should use 4k pages if PSE enabled. but extra counts should only
 valid for x86_32. This commit cause kdump regression, kdump kernel hangs 
 happens
 with it. 
 
 As Yinghai Lu said they should be reverted. see below post:
 https://lkml.org/lkml/2012/9/4/533 
 
 As there's a later fix to above fix which is 
 bd2753b2dda7bb43c7468826de75f49c6a7e8965
 So we need revert both of these two commits.
 
 Tested kdump on physical and virutual machines. 
 
 Reverted commits:
 commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
 Author: WANG Cong xiyou.wangc...@gmail.com
 Date:   Mon Mar 5 15:05:13 2012 -0800
 
 x86/mm: Fix the size calculation of mapping tables
 
 For machines that enable PSE, the first 2/4M memory region still uses
 4K pages, so needs more PTEs in this case, but
 find_early_table_space() doesn't count this.
 
 This patch fixes it.
 
 The bug was found via code review, no misbehavior of the kernel
 was observed.
 
 Signed-off-by: WANG Cong xiyou.wangc...@gmail.com
 Cc: Yinghai Lu ying...@kernel.org
 Cc: Tejun Heo t...@kernel.org
 Cc: ianfang...@gmail.com
 Signed-off-by: Andrew Morton a...@linux-foundation.org
 Link: http://lkml.kernel.org/n/tip-kq6a00qe33h7c7ais2xsy...@git.kernel.org
 Signed-off-by: Ingo Molnar mi...@elte.hu
 
 commit bd2753b2dda7bb43c7468826de75f49c6a7e8965
 Author: Yinghai Lu ying...@kernel.org
 Date:   Wed Jun 6 10:55:40 2012 -0700
 
 x86/mm: Only add extra pages count for the first memory range during 
 pre-allocatio
 
 Robin found this regression:
 
 | I just tried to boot an 8TB system.  It fails very early in boot with:
 | Kernel panic - not syncing: Cannot find space for the kernel page tables
 
 git bisect commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8.
 
 A git revert of that commit does boot past that point on the 8TB
 configuration.
 
 That commit will add up extra pages for all memory range even
 above 4g.
 
 Try to limit that extra page count adding to first entry only.
 
 Bisected-by: Robin Holt h...@sgi.com
 Tested-by: Robin Holt h...@sgi.com
 Signed-off-by: Yinghai Lu ying...@kernel.org
 Cc: WANG Cong xiyou.wangc...@gmail.com
 Cc: Linus Torvalds torva...@linux-foundation.org
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: Peter Zijlstra a.p.zijls...@chello.nl
 Link: 
 http://lkml.kernel.org/r/CAE9FiQUj3wyzQxtq9yzBNc9u220p8JZ1FYHG7t%3DMOzJ%3D9B
 Signed-off-by: Ingo Molnar mi...@kernel.org
 
 
 Signed-off-by: Dave Young dyo...@redhat.com
 ---
  arch/x86/mm/init.c |   22 +-
  1 file changed, 9 insertions(+), 13 deletions(-)

The patch looks good.

I reproduced the issue with last upstream
commit 43c422eda99b894f18d1cca17bcd2401efaf7bd0
and confirmed that it does work with the patch applied.

thanks a lot!

Acked-by: Flavio Leitner f...@redhat.com
Tested-by: Flavio Leitner f...@redhat.com

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] serial: set correct baud_base for EXSYS EX-41092 Dual 16950

2012-09-17 Thread Flavio Leitner 
Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner f...@redhat.com
---
 drivers/tty/serial/8250/8250_pci.c | 7 +--
 include/linux/pci_ids.h| 3 ++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6fe88e6 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3232,8 +3232,11 @@ static struct pci_device_id serial_pci_tbl[] = {
 * For now just used the hex ID 0x950a.
 */
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
-   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
-   pbn_b0_2_115200 },
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_00,
+   0, 0, pbn_b0_2_115200 },
+   {   PCI_VENDOR_ID_OXSEMI, 0x950a,
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_30,
+   0, 0, pbn_b0_2_115200 },
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_113 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..4242013 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,8 @@
 #define PCI_DEVICE_ID_SIIG_8S_20x_650  0x2081
 #define PCI_DEVICE_ID_SIIG_8S_20x_850  0x2082
 #define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL   0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL  0x2530
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_00   0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_30   0x2530
 
 #define PCI_VENDOR_ID_RADISYS  0x1331
 
-- 
1.7.11.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 8250: fix autoconfig to work with serial console

2012-09-18 Thread Flavio Leitner 
The autoconfig prints messages while holding the
port's spinlock and that causes a deadlock when
using serial console.

Signed-off-by: Flavio Leitner f...@redhat.com
---
 drivers/tty/serial/8250/8250.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 8123f78..17e0c3f 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1037,6 +1037,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
unsigned char save_lcr, save_mcr;
struct uart_port *port = up-port;
unsigned long flags;
+   unsigned int old_capabilities;
 
if (!port-iobase  !port-mapbase  !port-membase)
return;
@@ -1087,6 +1088,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
/*
 * We failed; there's nothing here
 */
+   spin_unlock_irqrestore(port-lock, flags);
DEBUG_AUTOCONF(IER test failed (%02x, %02x) ,
   scratch2, scratch3);
goto out;
@@ -1110,6 +1112,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
status1 = serial_in(up, UART_MSR)  0xF0;
serial_out(up, UART_MCR, save_mcr);
if (status1 != 0x90) {
+   spin_unlock_irqrestore(port-lock, flags);
DEBUG_AUTOCONF(LOOP test failed (%02x) ,
   status1);
goto out;
@@ -1132,8 +1135,6 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO);
scratch = serial_in(up, UART_IIR)  6;
 
-   DEBUG_AUTOCONF(iir=%d , scratch);
-
switch (scratch) {
case 0:
autoconfig_8250(up);
@@ -1167,19 +1168,13 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
 
serial_out(up, UART_LCR, save_lcr);
 
-   if (up-capabilities != uart_config[port-type].flags) {
-   printk(KERN_WARNING
-  ttyS%d: detected caps %08x should be %08x\n,
-  serial_index(port), up-capabilities,
-  uart_config[port-type].flags);
-   }
-
port-fifosize = uart_config[up-port.type].fifo_size;
+   old_capabilities = up-capabilities; 
up-capabilities = uart_config[port-type].flags;
up-tx_loadsz = uart_config[port-type].tx_loadsz;
 
if (port-type == PORT_UNKNOWN)
-   goto out;
+   goto out_lock;
 
/*
 * Reset the UART.
@@ -1196,8 +1191,16 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
else
serial_out(up, UART_IER, 0);
 
- out:
+out_lock:
spin_unlock_irqrestore(port-lock, flags);
+   if (up-capabilities != old_capabilities) {
+   printk(KERN_WARNING
+  ttyS%d: detected caps %08x should be %08x\n,
+  serial_index(port), old_capabilities,
+  up-capabilities);
+   }
+out:
+   DEBUG_AUTOCONF(iir=%d , scratch);
DEBUG_AUTOCONF(type=%s\n, uart_config[port-type].name);
 }
 
-- 
1.7.11.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] serial: set correct baud_base for EXSYS EX-41092 Dual 16950

2012-09-21 Thread Flavio Leitner 
Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner f...@redhat.com
---
 drivers/tty/serial/8250/8250_pci.c | 9 +++--
 include/linux/pci_ids.h| 1 -
 2 files changed, 7 insertions(+), 3 deletions(-)

Changelog:
V2
moved IDs from pci_ids.h to 8250_pci.c
requested by greg k-h

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6b8fcb4 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1164,6 +1164,8 @@ pci_xr17c154_setup(struct serial_private *priv,
 #define PCI_SUBDEVICE_ID_OCTPRO422 0x0208
 #define PCI_SUBDEVICE_ID_POCTAL232 0x0308
 #define PCI_SUBDEVICE_ID_POCTAL422 0x0408
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_00  0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_30  0x2530
 #define PCI_VENDOR_ID_ADVANTECH0x13fe
 #define PCI_DEVICE_ID_INTEL_CE4100_UART 0x2e66
 #define PCI_DEVICE_ID_ADVANTECH_PCI36200x3620
@@ -3232,8 +3234,11 @@ static struct pci_device_id serial_pci_tbl[] = {
 * For now just used the hex ID 0x950a.
 */
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
-   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
-   pbn_b0_2_115200 },
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_00,
+   0, 0, pbn_b0_2_115200 },
+   {   PCI_VENDOR_ID_OXSEMI, 0x950a,
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_30,
+   0, 0, pbn_b0_2_115200 },
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_113 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..8d3c427 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,6 @@
 #define PCI_DEVICE_ID_SIIG_8S_20x_650  0x2081
 #define PCI_DEVICE_ID_SIIG_8S_20x_850  0x2082
 #define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL   0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL  0x2530
 
 #define PCI_VENDOR_ID_RADISYS  0x1331
 
-- 
1.7.11.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
Hi folks,

I have system that no longer boots kdump kernel. Basically,

# echo c  /proc/sysrq-trigger

to dump a vmcore doesn't work. It just hangs after showing the usual
panic messages. I've bisected the problem and the commit introducing
the issue is the one below.

Any idea?

commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
Author: WANG Cong xiyou.wangc...@gmail.com  2012-03-05 20:05:13
Committer: Ingo Molnar mi...@elte.hu  2012-03-06 05:38:26
Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 'mmc-fixes-for-3.3' 
of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
Child:  a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in 
leave_mm() only when needed)
Branches: master, remotes/origin/master
Follows: v3.3-rc6
Precedes: v3.5-rc1

x86/mm: Fix the size calculation of mapping tables

For machines that enable PSE, the first 2/4M memory region still uses
4K pages, so needs more PTEs in this case, but
find_early_table_space() doesn't count this.

This patch fixes it.

The bug was found via code review, no misbehavior of the kernel
was observed.


Machine details:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 26
model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
stepping: 5
microcode   : 0x11
cpu MHz : 1596.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 
sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips: 5333.87
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

# free
 total   used   free sharedbuffers cached
Mem:  16161684   117491004412584  0  10212   11421096
-/+ buffers/cache: 317792   15843892
Swap: 17406420  0   17406420


dmesg is attached.

thanks,
fbl




dmesg.log.gz
Description: GNU Zip compressed data

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 12:02:00 -0700
Yinghai Lu ying...@kernel.org wrote:

 On Tue, Sep 4, 2012 at 10:32 AM, Flavio Leitner f...@redhat.com wrote:
  Hi folks,
 
  I have system that no longer boots kdump kernel. Basically,
 
  # echo c  /proc/sysrq-trigger
 
  to dump a vmcore doesn't work. It just hangs after showing the usual
  panic messages. I've bisected the problem and the commit introducing
  the issue is the one below.
 
  Any idea?
 
  commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
  Author: WANG Cong xiyou.wangc...@gmail.com  2012-03-05 20:05:13
  Committer: Ingo Molnar mi...@elte.hu  2012-03-06 05:38:26
  Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 
  'mmc-fixes-for-3.3' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
  Child:  a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in 
  leave_mm() only when needed)
  Branches: master, remotes/origin/master
  Follows: v3.3-rc6
  Precedes: v3.5-rc1
 
  x86/mm: Fix the size calculation of mapping tables
 
  For machines that enable PSE, the first 2/4M memory region still uses
  4K pages, so needs more PTEs in this case, but
  find_early_table_space() doesn't count this.
 
  This patch fixes it.
 
  The bug was found via code review, no misbehavior of the kernel
  was observed.
 
 maybe just revert the offending commit?

I don't know where the 4K pages were noticed. Here is the
dmesg output passing 'debug':

[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] last_pfn = 0xbf800 max_arch_pfn = 0x4
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [88098000] 98000 size 20480
[0.00] init_memory_mapping: -bf80
[0.00]  00 - 00bf80 page 2M
[0.00] kernel direct mapping tables up to bf80 @ 1fa0-2000
[0.00] init_memory_mapping: 0001-00044000
[0.00]  01 - 044000 page 2M
[0.00] kernel direct mapping tables up to 44000 @ bdaab000-bf4bd000
[0.00] RAMDISK: 352c8000 - 3695c000

so, it appears that on my system, the pages are 2M.
I will try moving the extra accounting to be inside of CONFIG_X86_32.

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 12:20:14 -0700
Yinghai Lu ying...@kernel.org wrote:

 On Tue, Sep 4, 2012 at 12:17 PM, Flavio Leitner f...@redhat.com wrote:
  On Tue, 4 Sep 2012 12:02:00 -0700
  [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
  0x7010600070106
  [0.00] last_pfn = 0xbf800 max_arch_pfn = 0x4
  [0.00] initial memory mapped : 0 - 2000
  [0.00] Base memory trampoline at [88098000] 98000 size 20480
  [0.00] init_memory_mapping: -bf80
  [0.00]  00 - 00bf80 page 2M
  [0.00] kernel direct mapping tables up to bf80 @ 
  1fa0-2000
  [0.00] init_memory_mapping: 0001-00044000
  [0.00]  01 - 044000 page 2M
  [0.00] kernel direct mapping tables up to 44000 @ 
  bdaab000-bf4bd000
  [0.00] RAMDISK: 352c8000 - 3695c000
 

Alright, moving the extra accounting to be inside of CONFIG_X86_32 works out.

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index e0e6990..63e6a5c 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -60,10 +60,10 @@ static void __init find_early_table_space(struct map_range 
*mr, unsigned long en
extra = end - ((endPMD_SHIFT)  PMD_SHIFT);
 #ifdef CONFIG_X86_32
extra += PMD_SIZE;
-#endif
/* The first 2/4M doesn't use large pages. */
if (mr-start  PMD_SIZE)
extra += mr-end - mr-start;
+#endif
 
ptes = (extra + PAGE_SIZE - 1)  PAGE_SHIFT;
} else

 BTW, can you please try our new init_memory_mapping clean up at
 
   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
 for-x86-mm
 
 hope it could make your kdump working.

I will give a try.
fbl

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 12:20:14 -0700
Yinghai Lu ying...@kernel.org wrote:

 On Tue, Sep 4, 2012 at 12:17 PM, Flavio Leitner f...@redhat.com wrote:
  On Tue, 4 Sep 2012 12:02:00 -0700
  [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
  0x7010600070106
  [0.00] last_pfn = 0xbf800 max_arch_pfn = 0x4
  [0.00] initial memory mapped : 0 - 2000
  [0.00] Base memory trampoline at [88098000] 98000 size 20480
  [0.00] init_memory_mapping: -bf80
  [0.00]  00 - 00bf80 page 2M
  [0.00] kernel direct mapping tables up to bf80 @ 
  1fa0-2000
  [0.00] init_memory_mapping: 0001-00044000
  [0.00]  01 - 044000 page 2M
  [0.00] kernel direct mapping tables up to 44000 @ 
  bdaab000-bf4bd000
  [0.00] RAMDISK: 352c8000 - 3695c000
 
 BTW, can you please try our new init_memory_mapping clean up at
 
   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
 for-x86-mm
 
 hope it could make your kdump working.

Sorry, but it didn't work.
The same problem happened. 
fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 13:45:23 -0700
Yinghai Lu ying...@kernel.org wrote:

 On Tue, Sep 4, 2012 at 1:26 PM, Flavio Leitner f...@redhat.com wrote:
 
  Sorry, but it didn't work.
  The same problem happened.
 
 can you send out boot log ?

sure, there you go:
http://sysclose.org/kdump/dmesg-debug.log
http://sysclose.org/kdump/config.log

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 15:25:45 -0700
Yinghai Lu ying...@kernel.org wrote:

 On Tue, Sep 4, 2012 at 2:37 PM, Flavio Leitner f...@redhat.com wrote:
  On Tue, 4 Sep 2012 13:45:23 -0700
  Yinghai Lu ying...@kernel.org wrote:
 
  On Tue, Sep 4, 2012 at 1:26 PM, Flavio Leitner f...@redhat.com wrote:
  
   Sorry, but it didn't work.
   The same problem happened.
 
  can you send out boot log ?
 
  sure, there you go:
  http://sysclose.org/kdump/dmesg-debug.log
  http://sysclose.org/kdump/config.log
 
 looks like you did not use for-x86-mm branch.

No, I didn't. Sorry about that.
I will test and report back.
fbl

 
 [0.00] initial memory mapped: [mem 0x-0x1fff]
 [0.00] Base memory trampoline at [88097000] 97000 size 24576
 [0.00] init_memory_mapping: [mem 0x-0xbf7f]
 [0.00]  [mem 0x-0xbf7f] page 2M
 [0.00] kernel direct mapping tables up to 0xbf7f @ [mem
 0x1fa0-0x1fff]
 [0.00] init_memory_mapping: [mem 0x1-0x43fff]
 [0.00]  [mem 0x1-0x43fff] page 2M
 [0.00] kernel direct mapping tables up to 0x43fff @ [mem
 0xbf7ce000-0xbf7d]
 [0.00] RAMDISK: [mem 0x351d2000-0x368e0fff]
 [0.00] Reserving 256MB of memory at 592MB for crashkernel
 (System RAM: 16372MB)
 
 please try:
 
 mkdir linux || exit -1
 cd linux
 
 git init-db
 
 # Add Linus's tree as a remote
 git remote add linus
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 
 # Add the -tip tree as a remote
 git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
 
 # Add yinghai's tree
 
 git remote add yinghai
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
 
 git remote update
 
 git checkout -b yinghai-for-x86-mm yinghai/for-x86-mm

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 15:25:45 -0700
Yinghai Lu ying...@kernel.org wrote:

 On Tue, Sep 4, 2012 at 2:37 PM, Flavio Leitner f...@redhat.com wrote:
  On Tue, 4 Sep 2012 13:45:23 -0700
  Yinghai Lu ying...@kernel.org wrote:
 
  On Tue, Sep 4, 2012 at 1:26 PM, Flavio Leitner f...@redhat.com wrote:
  
   Sorry, but it didn't work.
   The same problem happened.
 
  can you send out boot log ?
 
  sure, there you go:
  http://sysclose.org/kdump/dmesg-debug.log
  http://sysclose.org/kdump/config.log
 
 looks like you did not use for-x86-mm branch.
 
 [0.00] initial memory mapped: [mem 0x-0x1fff]
 [0.00] Base memory trampoline at [88097000] 97000 size 24576
 [0.00] init_memory_mapping: [mem 0x-0xbf7f]
 [0.00]  [mem 0x-0xbf7f] page 2M
 [0.00] kernel direct mapping tables up to 0xbf7f @ [mem
 0x1fa0-0x1fff]
 [0.00] init_memory_mapping: [mem 0x1-0x43fff]
 [0.00]  [mem 0x1-0x43fff] page 2M
 [0.00] kernel direct mapping tables up to 0x43fff @ [mem
 0xbf7ce000-0xbf7d]
 [0.00] RAMDISK: [mem 0x351d2000-0x368e0fff]
 [0.00] Reserving 256MB of memory at 592MB for crashkernel
 (System RAM: 16372MB)
 
 please try:
 
 mkdir linux || exit -1
 cd linux
 
 git init-db
 
 # Add Linus's tree as a remote
 git remote add linus
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
 
 # Add the -tip tree as a remote
 git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
 
 # Add yinghai's tree
 
 git remote add yinghai
 git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
 
 git remote update
 
 git checkout -b yinghai-for-x86-mm yinghai/for-x86-mm

kdump works when using your branch:

[0.00] Linux version 3.6.0-rc4-00012-g9389673 (r...@f17i7.rh) (gcc 
version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Tue Sep 4 20:36:43 BRT 
2012
...
[0.00] initial memory mapped: [mem 0x-0x1fff]
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] calculate_table_space_size: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] calculate_table_space_size: [mem 0x0010-0xbf4bcfff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0xbf3f] page 2M
[0.00]  [mem 0xbf40-0xbf4bcfff] page 4k
[0.00] calculate_table_space_size: [mem 0xbf4bf000-0xbf4c5fff]
[0.00]  [mem 0xbf4bf000-0xbf4c5fff] page 4k
[0.00] calculate_table_space_size: [mem 0xbf7bf000-0xbf7d]
[0.00]  [mem 0xbf7bf000-0xbf7d] page 4k
[0.00] calculate_table_space_size: [mem 0xbf7ff000-0xbf7f]
[0.00]  [mem 0xbf7ff000-0xbf7f] page 4k
[0.00] calculate_table_space_size: [mem 0x1-0x43fff]
[0.00]  [mem 0x1-0x43fff] page 2M
[0.00] kernel direct mapping tables up to 0x43fff @ [mem 
0x43ffe1000-0x43fff] prealloc
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x0010-0xbf4bcfff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0xbf3f] page 2M
[0.00]  [mem 0xbf40-0xbf4bcfff] page 4k
[0.00] init_memory_mapping: [mem 0xbf4bf000-0xbf4c5fff]
[0.00]  [mem 0xbf4bf000-0xbf4c5fff] page 4k
[0.00] init_memory_mapping: [mem 0xbf7bf000-0xbf7d]
[0.00]  [mem 0xbf7bf000-0xbf7d] page 4k
[0.00] init_memory_mapping: [mem 0xbf7ff000-0xbf7f]
[0.00]  [mem 0xbf7ff000-0xbf7f] page 4k
[0.00] init_memory_mapping: [mem 0x1-0x43fff]
[0.00]  [mem 0x1-0x43fff] page 2M
[0.00] kernel direct mapping tables up to 0x43fff @ [mem 
0x43ffe1000-0x43fff2fff] final
[0.00] RAMDISK: [mem 0x34ffa000-0x367f4fff]
...
http://sysclose.org/kdump/dmesg.log
http://sysclose.org/kdump/config.log

thanks,
fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-05 Thread Flavio Leitner 
On Tue, 4 Sep 2012 18:15:25 -0700
Yinghai Lu ying...@kernel.org wrote:
 assume when we have good_end setting for 64 bit, page table for [4g,
 TOMH) will be just under 512M, and later when first
 first 2M lines changes, will push that page table range a little low,
 and will make kdump not happy.
 
 BTW the first 2M change commit is useless should be reverted. because
 even it is in 2M page mapping at first, later
 kernel will change to 4k page.
 
 and with other change in this patchset, init_memory_mapping(0,
 ISA_END_ADDR) will always make sure first 2M use 4K page.

Hm, it's not clear to me. Are you going to push the patch reverting
that commit and then your patchset?

thank you!
fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch net-next 01/16] net: introduce upper device lists

2012-08-13 Thread Flavio Leitner 
On Mon, 13 Aug 2012 17:27:00 +0200
Jiri Pirko j...@resnulli.us wrote:

 This lists are supposed to serve for storing pointers to all upper devices.
 Eventually it will replace dev-master pointer which is used for
 bonding, bridge, team but it cannot be used for vlan, macvlan where
 there might be multiple masters present.
 
 New upper device list resolves this limitation. Also, the information
 stored in lists is used for preventing looping setups like
 bond-somethingelse-samebond
 
 Signed-off-by: Jiri Pirko j...@resnulli.us
 ---
  include/linux/netdevice.h |   14 +++
  net/core/dev.c|  232 
 -
  2 files changed, 244 insertions(+), 2 deletions(-)
 
 diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
 index a9db4f3..e7a07f8 100644
 --- a/include/linux/netdevice.h
 +++ b/include/linux/netdevice.h
 @@ -1173,6 +1173,8 @@ struct net_device {
 * which this device is member of.
 */
  
 + struct list_headupper_dev_list; /* List of upper devices */
 +
   /* Interface address info used in eth_type_trans() */
   unsigned char   *dev_addr;  /* hw address, (before bcast
  because most packets are
 @@ -2611,6 +2613,18 @@ extern int netdev_max_backlog;
  extern int   netdev_tstamp_prequeue;
  extern int   weight_p;
  extern int   bpf_jit_enable;
 +
 +extern bool netdev_has_upper_dev(struct net_device *dev,
 +  struct net_device *upper_dev);
 +extern bool netdev_has_any_upper_dev(struct net_device *dev);
 +extern struct net_device *netdev_unique_upper_dev_get(struct net_device 
 *dev);
 +extern struct net_device *netdev_unique_upper_dev_get_rcu(struct net_device 
 *dev);
 +extern int netdev_upper_dev_link(struct net_device *dev,
 +  struct net_device *upper_dev);
 +extern int netdev_unique_upper_dev_link(struct net_device *dev,
 + struct net_device *upper_dev);
 +extern void netdev_upper_dev_unlink(struct net_device *dev,
 + struct net_device *upper_dev);
  extern int   netdev_set_master(struct net_device *dev, struct 
 net_device *master);
  extern int netdev_set_bond_master(struct net_device *dev,
 struct net_device *master);
 diff --git a/net/core/dev.c b/net/core/dev.c
 index 1f06df8..68db1ac 100644
 --- a/net/core/dev.c
 +++ b/net/core/dev.c
 @@ -4425,6 +4425,229 @@ static int __init dev_proc_init(void)
  #endif   /* CONFIG_PROC_FS */
  
  
 +struct netdev_upper {
 + struct net_device *dev;
 + bool unique;

unique is quite confusing here. I see that it is possible to have 
one unique and many non-unique linked in the list, so maybe rename
to 'main_dev', 'master' or 'principal'...


 + struct list_head list;
 + struct rcu_head rcu;
 +};
 +
 +static bool __netdev_has_upper_dev(struct net_device *dev,
 +struct net_device *upper_dev,
 +bool deep)
 +{
 + struct netdev_upper *upper;
 +
 + list_for_each_entry(upper, dev-upper_dev_list, list) {
 + if (upper-dev == upper_dev)
 + return true;
 + if (deep  __netdev_has_upper_dev(upper-dev, upper_dev, deep))
 + return true;
 + }
 + return false;
 +}
 +
 +static struct netdev_upper *__netdev_find_upper(struct net_device *dev,
 + struct net_device *upper_dev)
 +{
 + struct netdev_upper *upper;
 +
 + list_for_each_entry(upper, dev-upper_dev_list, list) {
 + if (upper-dev == upper_dev)
 + return upper;
 + }
 + return NULL;
 +}
 +
 +/**
 + * netdev_has_upper_dev - Check if device is linked to an upper device
 + * @dev: device
 + * @upper_dev: upper device to check
 + *
 + * Find out if a device is linked to specified upper device and return true
 + * in case it is. The caller must hold the RTNL semaphore.
 + */
 +bool netdev_has_upper_dev(struct net_device *dev,
 +   struct net_device *upper_dev)
 +{
 + ASSERT_RTNL();
 +
 + return __netdev_has_upper_dev(dev, upper_dev, false);
 +}
 +EXPORT_SYMBOL(netdev_has_upper_dev);
 +
 +/**
 + * netdev_has_any_upper_dev - Check if device is linked to some device
 + * @dev: device
 + *
 + * Find out if a device is linked to an upper device and return true in case
 + * it is. The caller must hold the RTNL semaphore.
 + */
 +bool netdev_has_any_upper_dev(struct net_device *dev)
 +{
 + ASSERT_RTNL();
 +
 + return !list_empty(dev-upper_dev_list);
 +}
 +EXPORT_SYMBOL(netdev_has_any_upper_dev);
 +
 +/**
 + * netdev_unique_upper_dev_get - Get unique upper device
 + * @dev: device
 + *
 + * Find a unique upper device and return pointer to it

Re: [patch net-next 03/16] vlan: add link to upper device

2012-08-13 Thread Flavio Leitner 
On Mon, 13 Aug 2012 17:27:02 +0200
Jiri Pirko j...@resnulli.us wrote:

 Signed-off-by: Jiri Pirko j...@resnulli.us
 ---
  net/8021q/vlan.c |   10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)
 
 diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
 index 9096bcb..739665e 100644
 --- a/net/8021q/vlan.c
 +++ b/net/8021q/vlan.c
 @@ -105,6 +105,8 @@ void unregister_vlan_dev(struct net_device *dev, struct 
 list_head *head)
*/
   unregister_netdevice_queue(dev, head);
  
 + netdev_upper_dev_unlink(real_dev, dev);
 +
   if (grp-nr_vlan_devs == 0)
   vlan_gvrp_uninit_applicant(real_dev);
  
 @@ -162,9 +164,13 @@ int register_vlan_dev(struct net_device *dev)
   if (err  0)
   goto out_uninit_applicant;
  
 + err = netdev_upper_dev_link(real_dev, dev);
 + if (err)
 + goto out_uninit_applicant;
 +
   err = register_netdevice(dev);
   if (err  0)
 - goto out_uninit_applicant;
 + goto out_upper_dev_unlink;
^^^
see below:

  
   /* Account for reference in struct vlan_dev_priv */
   dev_hold(real_dev);
 @@ -180,6 +186,8 @@ int register_vlan_dev(struct net_device *dev)
  
   return 0;
  
 +upper_dev_unlink:
^^^
should be out_upper_dev_unlink:

fbl

 + netdev_upper_dev_unlink(real_dev, dev);
  out_uninit_applicant:
   if (grp-nr_vlan_devs == 0)
   vlan_gvrp_uninit_applicant(real_dev);

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch net-next 01/16] net: introduce upper device lists

2012-08-14 Thread Flavio Leitner 
On Tue, 14 Aug 2012 14:24:33 +0200
Jiri Pirko j...@resnulli.us wrote:

 Mon, Aug 13, 2012 at 07:52:17PM CEST, f...@redhat.com wrote:
 On Mon, 13 Aug 2012 17:27:00 +0200
 Jiri Pirko j...@resnulli.us wrote:
  +  /*
  +   * To prevent loops, check if dev is not upper device to upper_dev.
  +   */
  +  if (__netdev_has_upper_dev(upper_dev, dev, true))
  +  return -EBUSY;
  +
  +  if (__netdev_find_upper(dev, upper_dev))
  +  return -EEXIST;
 
 __netdev_has_upper_dev() can go all the way up finding the device and
 the __netdev_find_upper() just check the first level.
 
 
 I do not think this ordering is somewhat inportant.

it's not the order, see below:

 I think it would be better to use:
 __netdev_find_upper_dev(,,deep=true/false)
 __netdev_has_upper(,)

It's their names.  Currently, the function ..._find_... look at
one level only, while the function ..._has_... does one or more
levels.  I think it's better to swap 'has' and 'find' in their names:

__netdev_find_upper_dev(,,deep=true/false) -- find in all levels
__netdev_has_upper(,)  -- check only the one level.

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RIP: mem_cgroup_move_account+0xf4/0x290

2013-10-29 Thread Flavio Leitner 
On Sat, Oct 26, 2013 at 08:41:11AM -0700, Greg Thelen wrote:
 On Sat, Oct 26 2013, 含黛 wrote:
 
  On 10/26/2013 11:39 AM, Johannes Weiner wrote:
  On Fri, Oct 25, 2013 at 02:15:55PM -0200, Flavio Leitner wrote:
  While playing with guests and net-next kernel, I've triggered
  this with some frequency.  Even Fedora 19 kernel reproduces.
 
  It it a known issue?
 
  Thanks,
  fbl
 
  [ 6790.349763] kvm: zapping shadow pages for mmio generation wraparound
  [ 6792.283879] kvm: zapping shadow pages for mmio generation wraparound
  [ 7535.654438] perf samples too long (2719  2500), lowering 
  kernel.perf_event_max_sample_rate to 5
  [ 7535.665948] INFO: NMI handler (perf_event_nmi_handler) took too long 
  to run: 11.560 msecs
  [ 7691.048392] virbr0: port 1(vnet0) entered disabled state
  [ 7691.056281] device vnet0 left promiscuous mode
  [ 7691.061674] virbr0: port 1(vnet0) entered disabled state
  [ 7691.163363] BUG: unable to handle kernel paging request at 
  60fbc0002a20
  [ 7691.171145] IP: [8119dcb4] mem_cgroup_move_account+0xf4/0x290
  [ 7691.178574] PGD 0
  [ 7691.181042] Oops:  [#1] SMP
  [ 7691.184761] Modules linked in: vhost_net vhost macvtap macvlan tun veth
  openvswitch xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast
  ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge 
  stp
  llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
  nf_nat_ipv6 vxlan ip_tunnel gre libcrc32c ip6table_mangle 
  ip6table_security
  ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4
  nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
  iptable_security iptable_raw coretemp kvm_intel snd_hda_codec_realtek
  snd_hda_intel nfsd snd_hda_codec kvm auth_rpcgss nfs_acl snd_hwdep lockd
  snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc sunrpc snd_timer
  crc32c_intel i7core_edac bnx2 shpchp ptp snd iTCO_wdt joydev pps_core
  iTCO_vendor_support pcspkr soundcore microcode serio_raw lpc_ich edac_core
  mfd_core i2c_i801 acpi_cpufreq hid_logitech_dj nouveau ata_generic 
  pata_acpi
  video i2c_algo_bit drm_kms_helper ttm drm mxm_wmi i2c_core pata_marvell 
  wmi
  [last unloaded: openvswitch]
  [ 7691.285989] CPU: 1 PID: 14 Comm: kworker/1:0 Tainted: G  I  
  3.12.0-rc6-01188-gb45bd46 #1
  [ 7691.295779] Hardware name:  /DX58SO, BIOS 
  SOX5810J.86A.5599.2012.0529.2218 05/29/2012
  [ 7691.306066] Workqueue: events css_killed_work_fn
  [ 7691.311303] task: 880429555dc0 ti: 88042957a000 task.ti: 
  88042957a000
  [ 7691.319673] RIP: 0010:[8119dcb4]  [8119dcb4] 
  mem_cgroup_move_account+0xf4/0x290
  [ 7691.329728] RSP: 0018:88042957bcc8  EFLAGS: 00010002
  [ 7691.335747] RAX: 0246 RBX: 88042b17bc30 RCX: 
  0004
  [ 7691.343720] RDX: 880424cd6000 RSI: 60fbc0002a08 RDI: 
  880424cd622c
  [ 7691.351735] RBP: 88042957bd20 R08: 880424cd4000 R09: 
  0001
  [ 7691.359751] R10: 0001 R11: 0001 R12: 
  ea00103ef0c0
  [ 7691.367745] R13: 880424cd6000 R14:  R15: 
  880424cd622c
  [ 7691.375738] FS:  () GS:88043fc2() 
  knlGS:
  [ 7691.384755] CS:  0010 DS:  ES:  CR0: 8005003b
  [ 7691.391238] CR2: 60fbc0002a20 CR3: 01c0c000 CR4: 
  27e0
  [ 7691.399235] Stack:
  [ 7691.401672]  88042957bce8 88042957bce8 81312b6d 
  880424cd4000
  [ 7691.409968]  88040001 880424cd6000 ea00103ef0c0 
  880424cd0430
  [ 7691.418264]  88042b17bc30 ea00103ef0e0 880424cd6000 
  88042957bda8
  [ 7691.426578] Call Trace:
  [ 7691.429513]  [81312b6d] ? list_del+0xd/0x30
  [ 7691.435250]  [8119f5e7] 
  mem_cgroup_reparent_charges+0x247/0x460
  [ 7691.442874]  [8119f9af] mem_cgroup_css_offline+0xaf/0x1b0
  [ 7691.449942]  [810da877] offline_css+0x27/0x50
  [ 7691.455874]  [810dcf8d] css_killed_work_fn+0x2d/0xa0
  [ 7691.462466]  [810821f5] process_one_work+0x175/0x430
  [ 7691.469041]  [81082e1b] worker_thread+0x11b/0x3a0
  [ 7691.475345]  [81082d00] ? rescuer_thread+0x340/0x340
  [ 7691.481919]  [81089860] kthread+0xc0/0xd0
  [ 7691.487478]  [810897a0] ? insert_kthread_work+0x40/0x40
  [ 7691.494352]  [8166ea3c] ret_from_fork+0x7c/0xb0
  [ 7691.500464]  [810897a0] ? insert_kthread_work+0x40/0x40
  [ 7691.507335] Code: 85 f6 48 8b 55 d0 44 8b 4d c8 4c 8b 45 c0 0f 85 b3 
  00 00
  00 41 8b 4c 24 18 85 c9 0f 88 a6 00 00 00 48 8b b2 30 02 00 00 45 89 ca 
  4c
  39 56 18 0f 8c 36 01 00 00 44 89 c9 f7 d9 89 cf 65 48 01 7e
  This is
 
  All code
  
  0:   85 f6   test   %esi,%esi
  2:   48 8b 55 d0 mov-0x30(%rbp),%rdx
  6:   44 8b 4d c8 mov-0x38(%rbp),%r9d
  a:   4c 8b 45 c0 mov

RIP: mem_cgroup_move_account+0xf4/0x290

2013-10-25 Thread Flavio Leitner 

While playing with guests and net-next kernel, I've triggered
this with some frequency.  Even Fedora 19 kernel reproduces.

It it a known issue?

Thanks,
fbl

[ 6790.349763] kvm: zapping shadow pages for mmio generation wraparound
[ 6792.283879] kvm: zapping shadow pages for mmio generation wraparound
[ 7535.654438] perf samples too long (2719  2500), lowering 
kernel.perf_event_max_sample_rate to 5
[ 7535.665948] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 
11.560 msecs
[ 7691.048392] virbr0: port 1(vnet0) entered disabled state
[ 7691.056281] device vnet0 left promiscuous mode
[ 7691.061674] virbr0: port 1(vnet0) entered disabled state
[ 7691.163363] BUG: unable to handle kernel paging request at 60fbc0002a20
[ 7691.171145] IP: [8119dcb4] mem_cgroup_move_account+0xf4/0x290
[ 7691.178574] PGD 0 
[ 7691.181042] Oops:  [#1] SMP 
[ 7691.184761] Modules linked in: vhost_net vhost macvtap macvlan tun veth 
openvswitch xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast 
ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp 
llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 
nf_nat_ipv6 vxlan ip_tunnel gre libcrc32c ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw coretemp kvm_intel snd_hda_codec_realtek snd_hda_intel nfsd 
snd_hda_codec kvm auth_rpcgss nfs_acl snd_hwdep lockd snd_seq snd_seq_device 
snd_pcm e1000e snd_page_alloc sunrpc snd_timer crc32c_intel i7core_edac bnx2 
shpchp ptp snd iTCO_wdt joydev pps_core iTCO_vendor_support pcspkr soundcore 
microcode serio_raw lpc_ich edac_core mfd_core i2c_i801 acpi_cpufreq 
hid_logitech_dj nouveau ata_generic pata_acpi video i2c_algo_bit drm_kms_helper 
ttm drm mxm_wmi i2c_core pata_marvell wmi [last unloaded: openvswitch]
[ 7691.285989] CPU: 1 PID: 14 Comm: kworker/1:0 Tainted: G  I  
3.12.0-rc6-01188-gb45bd46 #1
[ 7691.295779] Hardware name:  /DX58SO, BIOS 
SOX5810J.86A.5599.2012.0529.2218 05/29/2012
[ 7691.306066] Workqueue: events css_killed_work_fn
[ 7691.311303] task: 880429555dc0 ti: 88042957a000 task.ti: 
88042957a000
[ 7691.319673] RIP: 0010:[8119dcb4]  [8119dcb4] 
mem_cgroup_move_account+0xf4/0x290
[ 7691.329728] RSP: 0018:88042957bcc8  EFLAGS: 00010002
[ 7691.335747] RAX: 0246 RBX: 88042b17bc30 RCX: 0004
[ 7691.343720] RDX: 880424cd6000 RSI: 60fbc0002a08 RDI: 880424cd622c
[ 7691.351735] RBP: 88042957bd20 R08: 880424cd4000 R09: 0001
[ 7691.359751] R10: 0001 R11: 0001 R12: ea00103ef0c0
[ 7691.367745] R13: 880424cd6000 R14:  R15: 880424cd622c
[ 7691.375738] FS:  () GS:88043fc2() 
knlGS:
[ 7691.384755] CS:  0010 DS:  ES:  CR0: 8005003b
[ 7691.391238] CR2: 60fbc0002a20 CR3: 01c0c000 CR4: 27e0
[ 7691.399235] Stack:
[ 7691.401672]  88042957bce8 88042957bce8 81312b6d 
880424cd4000
[ 7691.409968]  88040001 880424cd6000 ea00103ef0c0 
880424cd0430
[ 7691.418264]  88042b17bc30 ea00103ef0e0 880424cd6000 
88042957bda8
[ 7691.426578] Call Trace:
[ 7691.429513]  [81312b6d] ? list_del+0xd/0x30
[ 7691.435250]  [8119f5e7] mem_cgroup_reparent_charges+0x247/0x460
[ 7691.442874]  [8119f9af] mem_cgroup_css_offline+0xaf/0x1b0
[ 7691.449942]  [810da877] offline_css+0x27/0x50
[ 7691.455874]  [810dcf8d] css_killed_work_fn+0x2d/0xa0
[ 7691.462466]  [810821f5] process_one_work+0x175/0x430
[ 7691.469041]  [81082e1b] worker_thread+0x11b/0x3a0
[ 7691.475345]  [81082d00] ? rescuer_thread+0x340/0x340
[ 7691.481919]  [81089860] kthread+0xc0/0xd0
[ 7691.487478]  [810897a0] ? insert_kthread_work+0x40/0x40
[ 7691.494352]  [8166ea3c] ret_from_fork+0x7c/0xb0
[ 7691.500464]  [810897a0] ? insert_kthread_work+0x40/0x40
[ 7691.507335] Code: 85 f6 48 8b 55 d0 44 8b 4d c8 4c 8b 45 c0 0f 85 b3 00 00 
00 41 8b 4c 24 18 85 c9 0f 88 a6 00 00 00 48 8b b2 30 02 00 00 45 89 ca 4c 39 
56 18 0f 8c 36 01 00 00 44 89 c9 f7 d9 89 cf 65 48 01 7e 
[ 7691.528638] RIP  [8119dcb4] mem_cgroup_move_account+0xf4/0x290
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i8k: increase fan limit to 3

2014-05-21 Thread Flavio Leitner 
From: Flavio Leitner f...@sysclose.org

It is possible to increase left fan speed on a
DELL Precision 490n system up to 3.

valuefan rpm
  1  35460
  2  64740
  3  78510

Signed-off-by: Flavio Leitner f...@sysclose.org
---
 drivers/char/i8k.c   | 4 ++--
 include/uapi/linux/i8k.h | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index d915707..99180f0 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -519,7 +519,7 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
status = i8k_get_fan_status(index);
if (status  0)
return -EIO;
-   return sprintf(buf, %d\n, clamp_val(status * 128, 0, 255));
+   return sprintf(buf, %d\n, clamp_val(status * 128, 0, 384));
 }
 
 static ssize_t i8k_hwmon_set_pwm(struct device *dev,
@@ -533,7 +533,7 @@ static ssize_t i8k_hwmon_set_pwm(struct device *dev,
err = kstrtoul(buf, 10, val);
if (err)
return err;
-   val = clamp_val(DIV_ROUND_CLOSEST(val, 128), 0, 2);
+   val = clamp_val(DIV_ROUND_CLOSEST(val, 128), 0, 3);
 
mutex_lock(i8k_mutex);
err = i8k_set_fan(index, val);
diff --git a/include/uapi/linux/i8k.h b/include/uapi/linux/i8k.h
index 1c45ba5..133d02f 100644
--- a/include/uapi/linux/i8k.h
+++ b/include/uapi/linux/i8k.h
@@ -34,7 +34,8 @@
 #define I8K_FAN_OFF0
 #define I8K_FAN_LOW1
 #define I8K_FAN_HIGH   2
-#define I8K_FAN_MAXI8K_FAN_HIGH
+#define I8K_FAN_TURBO  3
+#define I8K_FAN_MAXI8K_FAN_TURBO
 
 #define I8K_VOL_UP 1
 #define I8K_VOL_DOWN   2
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-21 Thread Flavio Leitner 
On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:
 On 05/21/2014 07:19 PM, Flavio Leitner wrote:
 From: Flavio Leitner f...@sysclose.org
 
 It is possible to increase left fan speed on a
 DELL Precision 490n system up to 3.
 
  valuefan rpm
1  35460
2  64740
3  78510
 
 Guess the speed factor 30 doesn't apply here.

Those are actual rpms, not just a multiplied rpm. What I mean
is that you can hear the fan spinning up or down and the
temperature going up or down accordingly.

But even setting it to 3 is not enough to spin at maximum
speed. Anyway, now I can load the system without the FBDIMM
going above 75oC.

[...]
 I'll have to test this on older systems to make sure it doesn't cause 
 problems there.

Sure, let me know your findings. In meanwhile, I am using the patch here.
Thanks,
fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-22 Thread Flavio Leitner 
On Wed, May 21, 2014 at 10:36:45PM -0700, Guenter Roeck wrote:
 On 05/21/2014 08:45 PM, Flavio Leitner wrote:
 On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:
 On 05/21/2014 07:19 PM, Flavio Leitner wrote:
 From: Flavio Leitner f...@sysclose.org
 
 It is possible to increase left fan speed on a
 DELL Precision 490n system up to 3.
 
  valuefan rpm
1  35460
2  64740
3  78510
 
 Guess the speed factor 30 doesn't apply here.
 
 Those are actual rpms, not just a multiplied rpm. What I mean
 is that you can hear the fan spinning up or down and the
 temperature going up or down accordingly.
 
 I don't think there are any fans running at 78k rpm. The real speed
 is 78,510 / 30 or 2,617 rpm. You should set the fan_mult module
 parameter to 1 for your system.

Sure. I will do that. I didn't want to change anything else besides
the speed level and that is what sensors reports by default.

 But even setting it to 3 is not enough to spin at maximum
 speed. Anyway, now I can load the system without the FBDIMM
 going above 75oC.
 
 Did you try to set higher values ?

Up to 4 which did nothing that I could notice.
No difference regarding to noise or temp or rpm.

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-22 Thread Flavio Leitner 
On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
 On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
  From: Flavio Leitner f...@sysclose.org
  
  It is possible to increase left fan speed on a
  DELL Precision 490n system up to 3.
  
  valuefan rpm
1  35460
2  64740
3  78510
  
  Signed-off-by: Flavio Leitner f...@sysclose.org
  ---
   drivers/char/i8k.c   | 4 ++--
   include/uapi/linux/i8k.h | 3 ++-
   2 files changed, 4 insertions(+), 3 deletions(-)
  
  diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
  index d915707..99180f0 100644
  --- a/drivers/char/i8k.c
  +++ b/drivers/char/i8k.c
  @@ -519,7 +519,7 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
  status = i8k_get_fan_status(index);
  if (status  0)
  return -EIO;
  -   return sprintf(buf, %d\n, clamp_val(status * 128, 0, 255));
  +   return sprintf(buf, %d\n, clamp_val(status * 128, 0, 384));
 
 pwm value range is limited to (0, 255), so we'll have to find another
 solution.

You mean in the hw? Because the code today just multiply by 128 so
you have 0, 128 and 256 as possible pwm values. See below.

 I think we'll have to define a per-system data structure
 which holds the fan speed range and the fan multiplier, and attach it
 to the dmi data. Currently, .driver_data is used directly to override
 the fan multiplier; it will have to point to a configuration data
 structure with both fan multiplier and maximum fan speed value.
 Unless someone has a better idea, of course.

Sounds good to me.  It could provide a generic one that works as
today in case there is no specific per-system data structure.

It could also include the status multiplier so that for systems with
levels off, minimum and maximum then use x128 and systems with more
states can use another multiplier.

I volunteer to test on precision 490n and on latitude D520.

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-23 Thread Flavio Leitner 
On Thu, May 22, 2014 at 11:00:23AM -0700, Guenter Roeck wrote:
 On Thu, May 22, 2014 at 12:54:58PM -0300, Flavio Leitner wrote:
  On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
   On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
From: Flavio Leitner f...@sysclose.org
  I volunteer to test on precision 490n and on latitude D520.
  
 Can you send me dmi information for those systems ?
 The output of grep . /sys/class/dmi/id/* should do.

490n:
# grep . /sys/class/dmi/id/*
/sys/class/dmi/id/bios_date:05/24/2007
/sys/class/dmi/id/bios_vendor:Dell Inc.
/sys/class/dmi/id/bios_version:A05
/sys/class/dmi/id/board_name:0GU083
/sys/class/dmi/id/board_serial:..CN1374075H003N.
/sys/class/dmi/id/board_vendor:Dell Inc.  
/sys/class/dmi/id/board_version:A00
/sys/class/dmi/id/chassis_asset_tag:
/sys/class/dmi/id/chassis_serial:69FS6D1
/sys/class/dmi/id/chassis_type:7
/sys/class/dmi/id/chassis_vendor:Dell Inc.
/sys/class/dmi/id/modalias:dmi:bvnDellInc.:bvrA05:bd05/24/2007:svnDellInc.:pnPrecisionWorkStation490:pvr:rvnDellInc.:rn0GU083:rvrA00:cvnDellInc.:ct7:cvr:
grep: /sys/class/dmi/id/power: Is a directory
/sys/class/dmi/id/product_name:Precision WorkStation 490
/sys/class/dmi/id/product_serial:69FS6D1
/sys/class/dmi/id/product_uuid:44454C4C-3900-1046-8053-B6C04F364431
grep: /sys/class/dmi/id/subsystem: Is a directory
/sys/class/dmi/id/sys_vendor:Dell Inc.
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnDellInc.:bvrA05:bd05/24/2007:svnDellInc.:pnPrecisionWorkStation490:pvr:rvnDellInc.:rn0GU083:rvrA00:cvnDellInc.:ct7:cvr:


d520:
#  grep . /sys/class/dmi/id/*
/sys/class/dmi/id/bios_date:10/13/2006
/sys/class/dmi/id/bios_vendor:Dell Inc.
/sys/class/dmi/id/bios_version:A02
/sys/class/dmi/id/board_asset_tag:
/sys/class/dmi/id/board_name:0NF744
/sys/class/dmi/id/board_serial:.JYCM0C1.CN4864368I4174.
/sys/class/dmi/id/board_vendor:Dell Inc.
/sys/class/dmi/id/board_version:   
/sys/class/dmi/id/chassis_serial:JYCM0C1
/sys/class/dmi/id/chassis_type:8
/sys/class/dmi/id/chassis_vendor:Dell Inc.
/sys/class/dmi/id/modalias:dmi:bvnDellInc.:bvrA02:bd10/13/2006:svnDellInc.:pnLatitudeD520:pvr:rvnDellInc.:rn0NF744:rvr:cvnDellInc.:ct8:cvr:
grep: /sys/class/dmi/id/power: Is a directory
/sys/class/dmi/id/product_name:Latitude D520   
/sys/class/dmi/id/product_serial:JYCM0C1
/sys/class/dmi/id/product_uuid:44454C4C-5900-1043-804D-CAC04F304331
grep: /sys/class/dmi/id/subsystem: Is a directory
/sys/class/dmi/id/sys_vendor:Dell Inc.
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnDellInc.:bvrA02:bd10/13/2006:svnDellInc.:pnLatitudeD520:pvr:rvnDellInc.:rn0NF744:rvr:cvnDellInc.:ct8:cvr:

fbl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-25 Thread Flavio Leitner 
On Fri, May 23, 2014 at 11:33:11AM -0700, Guenter Roeck wrote:
 On 05/23/2014 10:09 AM, Flavio Leitner wrote:
 On Thu, May 22, 2014 at 11:00:23AM -0700, Guenter Roeck wrote:
 On Thu, May 22, 2014 at 12:54:58PM -0300, Flavio Leitner wrote:
 On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
 On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
 From: Flavio Leitner f...@sysclose.org
 I volunteer to test on precision 490n and on latitude D520.
 
 Can you send me dmi information for those systems ?
 The output of grep . /sys/class/dmi/id/* should do.
 
 
 /sys/class/dmi/id/chassis_vendor:Dell Inc.
 /sys/class/dmi/id/product_name:Latitude D520
 
 What is the maximum speed value for the D520 ?

D520, with no factor change:

   i8kfan i8kctl
*  -   0  1.0 A02 JYCM0C1 31 -1 0 27660 0 0 -1
   -   0  1.0 A02 JYCM0C1 28 -1 0 27660 0 0 -1
   -   1  1.0 A02 JYCM0C1 29 -1 1 27660 97050 0 -1
   -   2  1.0 A02 JYCM0C1 28 -1 2 27660 153660 0 -1
   -   3  1.0 A02 JYCM0C1 28 -1 2 27660 155280 0 -1
   0   -  1.0 A02 JYCM0C1 28 -1 0 27660 0 0 -1
   1   -  1.0 A02 JYCM0C1 28 -1 0 27660 0 0 -1
   2   -  1.0 A02 JYCM0C1 29 -1 0 27660 0 0 -1
   3   -  1.0 A02 JYCM0C1 29 -1 0 27660 0 0 -1

[*] default after boot.

The level 3 doesn't change anything.  Actually i8kfan
reports -1 then.

fbl

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtnetlink: fix missing size for IFLA_IF_NETNSID

2017-11-15 Thread Flavio Leitner 
On Mon, 6 Nov 2017 16:16:20 +0100
Jiri Benc  wrote:

> On Mon,  6 Nov 2017 15:04:54 +, Colin King wrote:
> > The size for IFLA_IF_NETNSID is missing from the size calculation
> > because the proceeding semicolon was not removed. Fix this by removing
> > the semicolon.  
> 
> Acked-by: Jiri Benc 
> 
> Thanks for spotting this! Looking at my initial code, I had that right,
> this was probably introduced during one of rebases, so I blame
> Flavio :-p (On a serious note, thank you, Flavio, for taking care of
> the rebases.)

That's right, ouch!
Thanks for fixing it.

-- 
Flavio

Re: [PATCH] netfilter: check if the socket netns is correct.

2018-09-27 Thread Flavio Leitner 
On Thu, Sep 27, 2018 at 01:46:29PM -0700, Guenter Roeck wrote:
> Hi Flavio,
> 
> On Wed, Jun 27, 2018 at 10:34:25AM -0300, Flavio Leitner wrote:
> > Netfilter assumes that if the socket is present in the skb, then
> > it can be used because that reference is cleaned up while the skb
> > is crossing netns.
> > 
> > We want to change that to preserve the socket reference in a future
> > patch, so this is a preparation updating netfilter to check if the
> > socket netns matches before use it.
> > 
> > Signed-off-by: Flavio Leitner 
> > Acked-by: Florian Westphal 
> > Signed-off-by: David S. Miller 
> > ---
> ...
> > --- a/net/netfilter/xt_socket.c
> > +++ b/net/netfilter/xt_socket.c
> > @@ -56,8 +56,12 @@ socket_match(const struct sk_buff *skb, struct 
> > xt_action_param *par,
> > struct sk_buff *pskb = (struct sk_buff *)skb;
> > struct sock *sk = skb->sk;
> >  
> > +   if (!net_eq(xt_net(par), sock_net(sk)))
> > +   sk = NULL;
> > +
> 
> I am having trouble with this code. With CONFIG_NET_NS enabled, it crashes
> for me in read_pnet() because sk is NULL.
> 
> > if (!sk)
> > sk = nf_sk_lookup_slow_v4(xt_net(par), skb, xt_in(par));
> 
> The old code seems to suggest that sk == NULL was possible.
> 
> I see the problem with the Chrome OS kernel rebased to v4.19-rc5, so I
> can not guarantee that this really an upstream problem. The change seems
> odd, though. Are you sure that it is not (or, rather, no longer) necessary
> to check if sk == NULL before dereferencing it in sock_net() ?

Oops, it is necessary but if it's not and the netns doesn't match, we need
do the lookup. So, could you check if this fixes the problem for you?

>From a5f927e7f1368d753f87cb978d630d786d5adb62 Mon Sep 17 00:00:00 2001
From: Flavio Leitner 
Date: Thu, 27 Sep 2018 19:36:28 -0300
Subject: [PATCH] xt_socket: check sk before checking for netns.

Only check for the network namespace if the socket is available.

Fixes: f564650106a6 ("netfilter: check if the socket netns is correct.")
Reported-by: Guenter Roeck 
Signed-off-by: Flavio Leitner 
---
 net/netfilter/xt_socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 0472f3472842..ada144e5645b 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -56,7 +56,7 @@ socket_match(const struct sk_buff *skb, struct 
xt_action_param *par,
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
 
-   if (!net_eq(xt_net(par), sock_net(sk)))
+   if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
 
if (!sk)
@@ -117,7 +117,7 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct 
xt_action_param *par)
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
 
-   if (!net_eq(xt_net(par), sock_net(sk)))
+   if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
 
if (!sk)
-- 
2.14.4

Re: RIP: mem_cgroup_move_account+0xf4/0x290

2013-10-29 Thread Flavio Leitner 
On Sat, Oct 26, 2013 at 08:41:11AM -0700, Greg Thelen wrote:
> On Sat, Oct 26 2013, 含黛 wrote:
> 
> > On 10/26/2013 11:39 AM, Johannes Weiner wrote:
> >> On Fri, Oct 25, 2013 at 02:15:55PM -0200, Flavio Leitner wrote:
> >>> While playing with guests and net-next kernel, I've triggered
> >>> this with some frequency.  Even Fedora 19 kernel reproduces.
> >>>
> >>> It it a known issue?
> >>>
> >>> Thanks,
> >>> fbl
> >>>
> >>> [ 6790.349763] kvm: zapping shadow pages for mmio generation wraparound
> >>> [ 6792.283879] kvm: zapping shadow pages for mmio generation wraparound
> >>> [ 7535.654438] perf samples too long (2719 > 2500), lowering 
> >>> kernel.perf_event_max_sample_rate to 5
> >>> [ 7535.665948] INFO: NMI handler (perf_event_nmi_handler) took too long 
> >>> to run: 11.560 msecs
> >>> [ 7691.048392] virbr0: port 1(vnet0) entered disabled state
> >>> [ 7691.056281] device vnet0 left promiscuous mode
> >>> [ 7691.061674] virbr0: port 1(vnet0) entered disabled state
> >>> [ 7691.163363] BUG: unable to handle kernel paging request at 
> >>> 60fbc0002a20
> >>> [ 7691.171145] IP: [] mem_cgroup_move_account+0xf4/0x290
> >>> [ 7691.178574] PGD 0
> >>> [ 7691.181042] Oops:  [#1] SMP
> >>> [ 7691.184761] Modules linked in: vhost_net vhost macvtap macvlan tun veth
> >>> openvswitch xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast
> >>> ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge 
> >>> stp
> >>> llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
> >>> nf_nat_ipv6 vxlan ip_tunnel gre libcrc32c ip6table_mangle 
> >>> ip6table_security
> >>> ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4
> >>> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
> >>> iptable_security iptable_raw coretemp kvm_intel snd_hda_codec_realtek
> >>> snd_hda_intel nfsd snd_hda_codec kvm auth_rpcgss nfs_acl snd_hwdep lockd
> >>> snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc sunrpc snd_timer
> >>> crc32c_intel i7core_edac bnx2 shpchp ptp snd iTCO_wdt joydev pps_core
> >>> iTCO_vendor_support pcspkr soundcore microcode serio_raw lpc_ich edac_core
> >>> mfd_core i2c_i801 acpi_cpufreq hid_logitech_dj nouveau ata_generic 
> >>> pata_acpi
> >>> video i2c_algo_bit drm_kms_helper ttm drm mxm_wmi i2c_core pata_marvell 
> >>> wmi
> >>> [last unloaded: openvswitch]
> >>> [ 7691.285989] CPU: 1 PID: 14 Comm: kworker/1:0 Tainted: G  I  
> >>> 3.12.0-rc6-01188-gb45bd46 #1
> >>> [ 7691.295779] Hardware name:  /DX58SO, BIOS 
> >>> SOX5810J.86A.5599.2012.0529.2218 05/29/2012
> >>> [ 7691.306066] Workqueue: events css_killed_work_fn
> >>> [ 7691.311303] task: 880429555dc0 ti: 88042957a000 task.ti: 
> >>> 88042957a000
> >>> [ 7691.319673] RIP: 0010:[]  [] 
> >>> mem_cgroup_move_account+0xf4/0x290
> >>> [ 7691.329728] RSP: 0018:88042957bcc8  EFLAGS: 00010002
> >>> [ 7691.335747] RAX: 0246 RBX: 88042b17bc30 RCX: 
> >>> 0004
> >>> [ 7691.343720] RDX: 880424cd6000 RSI: 60fbc0002a08 RDI: 
> >>> 880424cd622c
> >>> [ 7691.351735] RBP: 88042957bd20 R08: 880424cd4000 R09: 
> >>> 0001
> >>> [ 7691.359751] R10: 0001 R11: 0001 R12: 
> >>> ea00103ef0c0
> >>> [ 7691.367745] R13: 880424cd6000 R14:  R15: 
> >>> 880424cd622c
> >>> [ 7691.375738] FS:  () GS:88043fc2() 
> >>> knlGS:
> >>> [ 7691.384755] CS:  0010 DS:  ES:  CR0: 8005003b
> >>> [ 7691.391238] CR2: 60fbc0002a20 CR3: 01c0c000 CR4: 
> >>> 27e0
> >>> [ 7691.399235] Stack:
> >>> [ 7691.401672]  88042957bce8 88042957bce8 81312b6d 
> >>> 880424cd4000
> >>> [ 7691.409968]  88040001 880424cd6000 ea00103ef0c0 
> >>> 880424cd0430
> >>> [ 7691.418264]  88042b17bc30 ea00103ef0e0 880424cd6000 
> >>> 88042957bda8
> >>> [ 7691.426578] Call Trace:
> >>> [ 7691.429513]  [] ? list_del+0xd/0x30
> >>> [

RIP: mem_cgroup_move_account+0xf4/0x290

2013-10-25 Thread Flavio Leitner 

While playing with guests and net-next kernel, I've triggered
this with some frequency.  Even Fedora 19 kernel reproduces.

It it a known issue?

Thanks,
fbl

[ 6790.349763] kvm: zapping shadow pages for mmio generation wraparound
[ 6792.283879] kvm: zapping shadow pages for mmio generation wraparound
[ 7535.654438] perf samples too long (2719 > 2500), lowering 
kernel.perf_event_max_sample_rate to 5
[ 7535.665948] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 
11.560 msecs
[ 7691.048392] virbr0: port 1(vnet0) entered disabled state
[ 7691.056281] device vnet0 left promiscuous mode
[ 7691.061674] virbr0: port 1(vnet0) entered disabled state
[ 7691.163363] BUG: unable to handle kernel paging request at 60fbc0002a20
[ 7691.171145] IP: [] mem_cgroup_move_account+0xf4/0x290
[ 7691.178574] PGD 0 
[ 7691.181042] Oops:  [#1] SMP 
[ 7691.184761] Modules linked in: vhost_net vhost macvtap macvlan tun veth 
openvswitch xt_CHECKSUM nf_conntrack_netbios_ns nf_conntrack_broadcast 
ipt_MASQUERADE ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp 
llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 
nf_nat_ipv6 vxlan ip_tunnel gre libcrc32c ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw coretemp kvm_intel snd_hda_codec_realtek snd_hda_intel nfsd 
snd_hda_codec kvm auth_rpcgss nfs_acl snd_hwdep lockd snd_seq snd_seq_device 
snd_pcm e1000e snd_page_alloc sunrpc snd_timer crc32c_intel i7core_edac bnx2 
shpchp ptp snd iTCO_wdt joydev pps_core iTCO_vendor_support pcspkr soundcore 
microcode serio_raw lpc_ich edac_core mfd_core i2c_i801 acpi_cpufreq 
hid_logitech_dj nouveau ata_generic pata_acpi video i2c_algo_bit drm_kms_helper 
ttm drm mxm_wmi i2c_core pata_marvell wmi [last unloaded: openvswitch]
[ 7691.285989] CPU: 1 PID: 14 Comm: kworker/1:0 Tainted: G  I  
3.12.0-rc6-01188-gb45bd46 #1
[ 7691.295779] Hardware name:  /DX58SO, BIOS 
SOX5810J.86A.5599.2012.0529.2218 05/29/2012
[ 7691.306066] Workqueue: events css_killed_work_fn
[ 7691.311303] task: 880429555dc0 ti: 88042957a000 task.ti: 
88042957a000
[ 7691.319673] RIP: 0010:[]  [] 
mem_cgroup_move_account+0xf4/0x290
[ 7691.329728] RSP: 0018:88042957bcc8  EFLAGS: 00010002
[ 7691.335747] RAX: 0246 RBX: 88042b17bc30 RCX: 0004
[ 7691.343720] RDX: 880424cd6000 RSI: 60fbc0002a08 RDI: 880424cd622c
[ 7691.351735] RBP: 88042957bd20 R08: 880424cd4000 R09: 0001
[ 7691.359751] R10: 0001 R11: 0001 R12: ea00103ef0c0
[ 7691.367745] R13: 880424cd6000 R14:  R15: 880424cd622c
[ 7691.375738] FS:  () GS:88043fc2() 
knlGS:
[ 7691.384755] CS:  0010 DS:  ES:  CR0: 8005003b
[ 7691.391238] CR2: 60fbc0002a20 CR3: 01c0c000 CR4: 27e0
[ 7691.399235] Stack:
[ 7691.401672]  88042957bce8 88042957bce8 81312b6d 
880424cd4000
[ 7691.409968]  88040001 880424cd6000 ea00103ef0c0 
880424cd0430
[ 7691.418264]  88042b17bc30 ea00103ef0e0 880424cd6000 
88042957bda8
[ 7691.426578] Call Trace:
[ 7691.429513]  [] ? list_del+0xd/0x30
[ 7691.435250]  [] mem_cgroup_reparent_charges+0x247/0x460
[ 7691.442874]  [] mem_cgroup_css_offline+0xaf/0x1b0
[ 7691.449942]  [] offline_css+0x27/0x50
[ 7691.455874]  [] css_killed_work_fn+0x2d/0xa0
[ 7691.462466]  [] process_one_work+0x175/0x430
[ 7691.469041]  [] worker_thread+0x11b/0x3a0
[ 7691.475345]  [] ? rescuer_thread+0x340/0x340
[ 7691.481919]  [] kthread+0xc0/0xd0
[ 7691.487478]  [] ? insert_kthread_work+0x40/0x40
[ 7691.494352]  [] ret_from_fork+0x7c/0xb0
[ 7691.500464]  [] ? insert_kthread_work+0x40/0x40
[ 7691.507335] Code: 85 f6 48 8b 55 d0 44 8b 4d c8 4c 8b 45 c0 0f 85 b3 00 00 
00 41 8b 4c 24 18 85 c9 0f 88 a6 00 00 00 48 8b b2 30 02 00 00 45 89 ca <4c> 39 
56 18 0f 8c 36 01 00 00 44 89 c9 f7 d9 89 cf 65 48 01 7e 
[ 7691.528638] RIP  [] mem_cgroup_move_account+0xf4/0x290
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-22 Thread Flavio Leitner 
On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
> On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
> > From: Flavio Leitner 
> > 
> > It is possible to increase left fan speed on a
> > DELL Precision 490n system up to 3.
> > 
> > valuefan rpm
> >   1  35460
> >   2  64740
> >   3  78510
> > 
> > Signed-off-by: Flavio Leitner 
> > ---
> >  drivers/char/i8k.c   | 4 ++--
> >  include/uapi/linux/i8k.h | 3 ++-
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
> > index d915707..99180f0 100644
> > --- a/drivers/char/i8k.c
> > +++ b/drivers/char/i8k.c
> > @@ -519,7 +519,7 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
> > status = i8k_get_fan_status(index);
> > if (status < 0)
> > return -EIO;
> > -   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 255));
> > +   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 384));
> 
> pwm value range is limited to (0, 255), so we'll have to find another
> solution.

You mean in the hw? Because the code today just multiply by 128 so
you have 0, 128 and 256 as possible pwm values. See below.

> I think we'll have to define a per-system data structure
> which holds the fan speed range and the fan multiplier, and attach it
> to the dmi data. Currently, .driver_data is used directly to override
> the fan multiplier; it will have to point to a configuration data
> structure with both fan multiplier and maximum fan speed value.
> Unless someone has a better idea, of course.

Sounds good to me.  It could provide a generic one that works as
today in case there is no specific per-system data structure.

It could also include the status multiplier so that for systems with
levels off, minimum and maximum then use x128 and systems with more
states can use another multiplier.

I volunteer to test on precision 490n and on latitude D520.

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-23 Thread Flavio Leitner 
On Thu, May 22, 2014 at 11:00:23AM -0700, Guenter Roeck wrote:
> On Thu, May 22, 2014 at 12:54:58PM -0300, Flavio Leitner wrote:
> > On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
> > > On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
> > > > From: Flavio Leitner 
> > I volunteer to test on precision 490n and on latitude D520.
> > 
> Can you send me dmi information for those systems ?
> The output of "grep . /sys/class/dmi/id/*" should do.

490n:
# grep . /sys/class/dmi/id/*
/sys/class/dmi/id/bios_date:05/24/2007
/sys/class/dmi/id/bios_vendor:Dell Inc.
/sys/class/dmi/id/bios_version:A05
/sys/class/dmi/id/board_name:0GU083
/sys/class/dmi/id/board_serial:..CN1374075H003N.
/sys/class/dmi/id/board_vendor:Dell Inc.  
/sys/class/dmi/id/board_version:A00
/sys/class/dmi/id/chassis_asset_tag:
/sys/class/dmi/id/chassis_serial:69FS6D1
/sys/class/dmi/id/chassis_type:7
/sys/class/dmi/id/chassis_vendor:Dell Inc.
/sys/class/dmi/id/modalias:dmi:bvnDellInc.:bvrA05:bd05/24/2007:svnDellInc.:pnPrecisionWorkStation490:pvr:rvnDellInc.:rn0GU083:rvrA00:cvnDellInc.:ct7:cvr:
grep: /sys/class/dmi/id/power: Is a directory
/sys/class/dmi/id/product_name:Precision WorkStation 490
/sys/class/dmi/id/product_serial:69FS6D1
/sys/class/dmi/id/product_uuid:44454C4C-3900-1046-8053-B6C04F364431
grep: /sys/class/dmi/id/subsystem: Is a directory
/sys/class/dmi/id/sys_vendor:Dell Inc.
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnDellInc.:bvrA05:bd05/24/2007:svnDellInc.:pnPrecisionWorkStation490:pvr:rvnDellInc.:rn0GU083:rvrA00:cvnDellInc.:ct7:cvr:


d520:
#  grep . /sys/class/dmi/id/*
/sys/class/dmi/id/bios_date:10/13/2006
/sys/class/dmi/id/bios_vendor:Dell Inc.
/sys/class/dmi/id/bios_version:A02
/sys/class/dmi/id/board_asset_tag:
/sys/class/dmi/id/board_name:0NF744
/sys/class/dmi/id/board_serial:.JYCM0C1.CN4864368I4174.
/sys/class/dmi/id/board_vendor:Dell Inc.
/sys/class/dmi/id/board_version:   
/sys/class/dmi/id/chassis_serial:JYCM0C1
/sys/class/dmi/id/chassis_type:8
/sys/class/dmi/id/chassis_vendor:Dell Inc.
/sys/class/dmi/id/modalias:dmi:bvnDellInc.:bvrA02:bd10/13/2006:svnDellInc.:pnLatitudeD520:pvr:rvnDellInc.:rn0NF744:rvr:cvnDellInc.:ct8:cvr:
grep: /sys/class/dmi/id/power: Is a directory
/sys/class/dmi/id/product_name:Latitude D520   
/sys/class/dmi/id/product_serial:JYCM0C1
/sys/class/dmi/id/product_uuid:44454C4C-5900-1043-804D-CAC04F304331
grep: /sys/class/dmi/id/subsystem: Is a directory
/sys/class/dmi/id/sys_vendor:Dell Inc.
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnDellInc.:bvrA02:bd10/13/2006:svnDellInc.:pnLatitudeD520:pvr:rvnDellInc.:rn0NF744:rvr:cvnDellInc.:ct8:cvr:

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-25 Thread Flavio Leitner 
On Fri, May 23, 2014 at 11:33:11AM -0700, Guenter Roeck wrote:
> On 05/23/2014 10:09 AM, Flavio Leitner wrote:
> >On Thu, May 22, 2014 at 11:00:23AM -0700, Guenter Roeck wrote:
> >>On Thu, May 22, 2014 at 12:54:58PM -0300, Flavio Leitner wrote:
> >>>On Thu, May 22, 2014 at 08:10:48AM -0700, Guenter Roeck wrote:
> >>>>On Wed, May 21, 2014 at 11:19:28PM -0300, Flavio Leitner wrote:
> >>>>>From: Flavio Leitner 
> >>>I volunteer to test on precision 490n and on latitude D520.
> >>>
> >>Can you send me dmi information for those systems ?
> >>The output of "grep . /sys/class/dmi/id/*" should do.
> >
> 
> >/sys/class/dmi/id/chassis_vendor:Dell Inc.
> >/sys/class/dmi/id/product_name:Latitude D520
> 
> What is the maximum speed value for the D520 ?

D520, with no factor change:

   i8kfan i8kctl
*  -   0  1.0 A02 JYCM0C1 31 -1 0 27660 0 0 -1
   -   0  1.0 A02 JYCM0C1 28 -1 0 27660 0 0 -1
   -   1  1.0 A02 JYCM0C1 29 -1 1 27660 97050 0 -1
   -   2  1.0 A02 JYCM0C1 28 -1 2 27660 153660 0 -1
   -   3  1.0 A02 JYCM0C1 28 -1 2 27660 155280 0 -1
   0   -  1.0 A02 JYCM0C1 28 -1 0 27660 0 0 -1
   1   -  1.0 A02 JYCM0C1 28 -1 0 27660 0 0 -1
   2   -  1.0 A02 JYCM0C1 29 -1 0 27660 0 0 -1
   3   -  1.0 A02 JYCM0C1 29 -1 0 27660 0 0 -1

[*] default after boot.

The level 3 doesn't change anything.  Actually i8kfan
reports -1 then.

fbl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i8k: increase fan limit to 3

2014-05-21 Thread Flavio Leitner 
From: Flavio Leitner 

It is possible to increase left fan speed on a
DELL Precision 490n system up to 3.

valuefan rpm
  1  35460
  2  64740
  3  78510

Signed-off-by: Flavio Leitner 
---
 drivers/char/i8k.c   | 4 ++--
 include/uapi/linux/i8k.h | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/char/i8k.c b/drivers/char/i8k.c
index d915707..99180f0 100644
--- a/drivers/char/i8k.c
+++ b/drivers/char/i8k.c
@@ -519,7 +519,7 @@ static ssize_t i8k_hwmon_show_pwm(struct device *dev,
status = i8k_get_fan_status(index);
if (status < 0)
return -EIO;
-   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 255));
+   return sprintf(buf, "%d\n", clamp_val(status * 128, 0, 384));
 }
 
 static ssize_t i8k_hwmon_set_pwm(struct device *dev,
@@ -533,7 +533,7 @@ static ssize_t i8k_hwmon_set_pwm(struct device *dev,
err = kstrtoul(buf, 10, );
if (err)
return err;
-   val = clamp_val(DIV_ROUND_CLOSEST(val, 128), 0, 2);
+   val = clamp_val(DIV_ROUND_CLOSEST(val, 128), 0, 3);
 
mutex_lock(_mutex);
err = i8k_set_fan(index, val);
diff --git a/include/uapi/linux/i8k.h b/include/uapi/linux/i8k.h
index 1c45ba5..133d02f 100644
--- a/include/uapi/linux/i8k.h
+++ b/include/uapi/linux/i8k.h
@@ -34,7 +34,8 @@
 #define I8K_FAN_OFF0
 #define I8K_FAN_LOW1
 #define I8K_FAN_HIGH   2
-#define I8K_FAN_MAXI8K_FAN_HIGH
+#define I8K_FAN_TURBO  3
+#define I8K_FAN_MAXI8K_FAN_TURBO
 
 #define I8K_VOL_UP 1
 #define I8K_VOL_DOWN   2
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-21 Thread Flavio Leitner 
On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:
> On 05/21/2014 07:19 PM, Flavio Leitner wrote:
> >From: Flavio Leitner 
> >
> >It is possible to increase left fan speed on a
> >DELL Precision 490n system up to 3.
> >
> > valuefan rpm
> >   1  35460
> >   2  64740
> >   3  78510
> >
> Guess the speed factor 30 doesn't apply here.

Those are actual rpms, not just a multiplied rpm. What I mean
is that you can hear the fan spinning up or down and the
temperature going up or down accordingly.

But even setting it to 3 is not enough to spin at maximum
speed. Anyway, now I can load the system without the FBDIMM
going above 75oC.

[...]
> I'll have to test this on older systems to make sure it doesn't cause 
> problems there.

Sure, let me know your findings. In meanwhile, I am using the patch here.
Thanks,
fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i8k: increase fan limit to 3

2014-05-22 Thread Flavio Leitner 
On Wed, May 21, 2014 at 10:36:45PM -0700, Guenter Roeck wrote:
> On 05/21/2014 08:45 PM, Flavio Leitner wrote:
> >On Wed, May 21, 2014 at 08:32:24PM -0700, Guenter Roeck wrote:
> >>On 05/21/2014 07:19 PM, Flavio Leitner wrote:
> >>>From: Flavio Leitner 
> >>>
> >>>It is possible to increase left fan speed on a
> >>>DELL Precision 490n system up to 3.
> >>>
> >>> valuefan rpm
> >>>   1  35460
> >>>   2  64740
> >>>   3  78510
> >>>
> >>Guess the speed factor 30 doesn't apply here.
> >
> >Those are actual rpms, not just a multiplied rpm. What I mean
> >is that you can hear the fan spinning up or down and the
> >temperature going up or down accordingly.
> >
> I don't think there are any fans running at 78k rpm. The real speed
> is 78,510 / 30 or 2,617 rpm. You should set the fan_mult module
> parameter to 1 for your system.

Sure. I will do that. I didn't want to change anything else besides
the speed level and that is what sensors reports by default.

> >But even setting it to 3 is not enough to spin at maximum
> >speed. Anyway, now I can load the system without the FBDIMM
> >going above 75oC.
> >
> Did you try to set higher values ?

Up to 4 which did nothing that I could notice.
No difference regarding to noise or temp or rpm.

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] serial: set correct baud_base for EXSYS EX-41092 Dual 16950

2012-09-21 Thread Flavio Leitner 
Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner 
---
 drivers/tty/serial/8250/8250_pci.c | 9 +++--
 include/linux/pci_ids.h| 1 -
 2 files changed, 7 insertions(+), 3 deletions(-)

Changelog:
V2
moved IDs from pci_ids.h to 8250_pci.c
requested by greg k-h

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6b8fcb4 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1164,6 +1164,8 @@ pci_xr17c154_setup(struct serial_private *priv,
 #define PCI_SUBDEVICE_ID_OCTPRO422 0x0208
 #define PCI_SUBDEVICE_ID_POCTAL232 0x0308
 #define PCI_SUBDEVICE_ID_POCTAL422 0x0408
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_00  0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_30  0x2530
 #define PCI_VENDOR_ID_ADVANTECH0x13fe
 #define PCI_DEVICE_ID_INTEL_CE4100_UART 0x2e66
 #define PCI_DEVICE_ID_ADVANTECH_PCI36200x3620
@@ -3232,8 +3234,11 @@ static struct pci_device_id serial_pci_tbl[] = {
 * For now just used the hex ID 0x950a.
 */
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
-   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
-   pbn_b0_2_115200 },
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_00,
+   0, 0, pbn_b0_2_115200 },
+   {   PCI_VENDOR_ID_OXSEMI, 0x950a,
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_30,
+   0, 0, pbn_b0_2_115200 },
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_113 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..8d3c427 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,6 @@
 #define PCI_DEVICE_ID_SIIG_8S_20x_650  0x2081
 #define PCI_DEVICE_ID_SIIG_8S_20x_850  0x2082
 #define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL   0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL  0x2530
 
 #define PCI_VENDOR_ID_RADISYS  0x1331
 
-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-10-18 Thread Flavio Leitner 
On Thu, 18 Oct 2012 14:33:23 +0800
Dave Young  wrote:
[...]
> Just see Yinghai's coments, later init_memory_mapping cleanup
> will also address the 4k pages in first 2/4M, so revert them should be better.
> https://lkml.org/lkml/2012/9/4/533
> 
> Here is a patch for the reverting:
> ---
> x86 mm: Revert find_early_table_space fix
> 
> 722bc6b16771ed80871e1fd81c86d3627dda2ac8 Try to address the issue that the
> first 2/4M should use 4k pages if PSE enabled. but extra counts should only
> valid for x86_32. This commit cause kdump regression, kdump kernel hangs 
> happens
> with it. 
> 
> As Yinghai Lu said they should be reverted. see below post:
> https://lkml.org/lkml/2012/9/4/533 
> 
> As there's a later fix to above fix which is 
> bd2753b2dda7bb43c7468826de75f49c6a7e8965
> So we need revert both of these two commits.
> 
> Tested kdump on physical and virutual machines. 
> 
> Reverted commits:
> commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
> Author: WANG Cong 
> Date:   Mon Mar 5 15:05:13 2012 -0800
> 
> x86/mm: Fix the size calculation of mapping tables
> 
> For machines that enable PSE, the first 2/4M memory region still uses
> 4K pages, so needs more PTEs in this case, but
> find_early_table_space() doesn't count this.
> 
> This patch fixes it.
> 
> The bug was found via code review, no misbehavior of the kernel
> was observed.
> 
> Signed-off-by: WANG Cong 
> Cc: Yinghai Lu 
> Cc: Tejun Heo 
> Cc: 
> Signed-off-by: Andrew Morton 
> Link: http://lkml.kernel.org/n/tip-kq6a00qe33h7c7ais2xsy...@git.kernel.org
> Signed-off-by: Ingo Molnar 
> 
> commit bd2753b2dda7bb43c7468826de75f49c6a7e8965
> Author: Yinghai Lu 
> Date:   Wed Jun 6 10:55:40 2012 -0700
> 
> x86/mm: Only add extra pages count for the first memory range during 
> pre-allocatio
> 
> Robin found this regression:
> 
> | I just tried to boot an 8TB system.  It fails very early in boot with:
> | Kernel panic - not syncing: Cannot find space for the kernel page tables
> 
> git bisect commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8.
> 
> A git revert of that commit does boot past that point on the 8TB
> configuration.
> 
> That commit will add up extra pages for all memory range even
> above 4g.
> 
> Try to limit that extra page count adding to first entry only.
> 
> Bisected-by: Robin Holt 
> Tested-by: Robin Holt 
> Signed-off-by: Yinghai Lu 
> Cc: WANG Cong 
> Cc: Linus Torvalds 
> Cc: Andrew Morton 
> Cc: Peter Zijlstra 
> Link: 
> http://lkml.kernel.org/r/CAE9FiQUj3wyzQxtq9yzBNc9u220p8JZ1FYHG7t%3DMOzJ%3D9B
> Signed-off-by: Ingo Molnar 
> 
> 
> Signed-off-by: Dave Young 
> ---
>  arch/x86/mm/init.c |   22 +-----
>  1 file changed, 9 insertions(+), 13 deletions(-)

The patch looks good.

I reproduced the issue with last upstream
commit 43c422eda99b894f18d1cca17bcd2401efaf7bd0
and confirmed that it does work with the patch applied.

thanks a lot!

Acked-by: Flavio Leitner 
Tested-by: Flavio Leitner 

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch net-next 01/16] net: introduce upper device lists

2012-08-13 Thread Flavio Leitner 
On Mon, 13 Aug 2012 17:27:00 +0200
Jiri Pirko  wrote:

> This lists are supposed to serve for storing pointers to all upper devices.
> Eventually it will replace dev->master pointer which is used for
> bonding, bridge, team but it cannot be used for vlan, macvlan where
> there might be multiple "masters" present.
> 
> New upper device list resolves this limitation. Also, the information
> stored in lists is used for preventing looping setups like
> "bond->somethingelse->samebond"
> 
> Signed-off-by: Jiri Pirko 
> ---
>  include/linux/netdevice.h |   14 +++
>  net/core/dev.c|  232 
> -
>  2 files changed, 244 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index a9db4f3..e7a07f8 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1173,6 +1173,8 @@ struct net_device {
> * which this device is member of.
> */
>  
> + struct list_headupper_dev_list; /* List of upper devices */
> +
>   /* Interface address info used in eth_type_trans() */
>   unsigned char   *dev_addr;  /* hw address, (before bcast
>  because most packets are
> @@ -2611,6 +2613,18 @@ extern int netdev_max_backlog;
>  extern int   netdev_tstamp_prequeue;
>  extern int   weight_p;
>  extern int   bpf_jit_enable;
> +
> +extern bool netdev_has_upper_dev(struct net_device *dev,
> +  struct net_device *upper_dev);
> +extern bool netdev_has_any_upper_dev(struct net_device *dev);
> +extern struct net_device *netdev_unique_upper_dev_get(struct net_device 
> *dev);
> +extern struct net_device *netdev_unique_upper_dev_get_rcu(struct net_device 
> *dev);
> +extern int netdev_upper_dev_link(struct net_device *dev,
> +  struct net_device *upper_dev);
> +extern int netdev_unique_upper_dev_link(struct net_device *dev,
> + struct net_device *upper_dev);
> +extern void netdev_upper_dev_unlink(struct net_device *dev,
> + struct net_device *upper_dev);
>  extern int   netdev_set_master(struct net_device *dev, struct 
> net_device *master);
>  extern int netdev_set_bond_master(struct net_device *dev,
> struct net_device *master);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 1f06df8..68db1ac 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4425,6 +4425,229 @@ static int __init dev_proc_init(void)
>  #endif   /* CONFIG_PROC_FS */
>  
>  
> +struct netdev_upper {
> + struct net_device *dev;
> + bool unique;

unique is quite confusing here. I see that it is possible to have 
one unique and many non-unique linked in the list, so maybe rename
to 'main_dev', 'master' or 'principal'...


> + struct list_head list;
> + struct rcu_head rcu;
> +};
> +
> +static bool __netdev_has_upper_dev(struct net_device *dev,
> +struct net_device *upper_dev,
> +bool deep)
> +{
> + struct netdev_upper *upper;
> +
> + list_for_each_entry(upper, >upper_dev_list, list) {
> + if (upper->dev == upper_dev)
> + return true;
> + if (deep && __netdev_has_upper_dev(upper->dev, upper_dev, deep))
> + return true;
> + }
> + return false;
> +}
> +
> +static struct netdev_upper *__netdev_find_upper(struct net_device *dev,
> + struct net_device *upper_dev)
> +{
> + struct netdev_upper *upper;
> +
> + list_for_each_entry(upper, >upper_dev_list, list) {
> + if (upper->dev == upper_dev)
> + return upper;
> + }
> + return NULL;
> +}
> +
> +/**
> + * netdev_has_upper_dev - Check if device is linked to an upper device
> + * @dev: device
> + * @upper_dev: upper device to check
> + *
> + * Find out if a device is linked to specified upper device and return true
> + * in case it is. The caller must hold the RTNL semaphore.
> + */
> +bool netdev_has_upper_dev(struct net_device *dev,
> +   struct net_device *upper_dev)
> +{
> + ASSERT_RTNL();
> +
> + return __netdev_has_upper_dev(dev, upper_dev, false);
> +}
> +EXPORT_SYMBOL(netdev_has_upper_dev);
> +
> +/**
> + * netdev_has_any_upper_dev - Check if device is linked to some device
> + * @dev: device
> + *
> + * Find out if a device is linked to an upper device and return true in case
> + * it is. The caller must hold the RTNL semaphore.
> + */
> +bool netdev_has_any_upper_dev(struct net_device *dev)
> +{
> + ASSERT_RTNL();
> +
> + return !list_empty(>upper_dev_list);
> +}
> +EXPORT_SYMBOL(netdev_has_any_upper_dev);
> +
> +/**
> + * netdev_unique_upper_dev_get - Get

Re: [patch net-next 03/16] vlan: add link to upper device

2012-08-13 Thread Flavio Leitner 
On Mon, 13 Aug 2012 17:27:02 +0200
Jiri Pirko  wrote:

> Signed-off-by: Jiri Pirko 
> ---
>  net/8021q/vlan.c |   10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index 9096bcb..739665e 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -105,6 +105,8 @@ void unregister_vlan_dev(struct net_device *dev, struct 
> list_head *head)
>*/
>   unregister_netdevice_queue(dev, head);
>  
> + netdev_upper_dev_unlink(real_dev, dev);
> +
>   if (grp->nr_vlan_devs == 0)
>   vlan_gvrp_uninit_applicant(real_dev);
>  
> @@ -162,9 +164,13 @@ int register_vlan_dev(struct net_device *dev)
>   if (err < 0)
>   goto out_uninit_applicant;
>  
> + err = netdev_upper_dev_link(real_dev, dev);
> + if (err)
> + goto out_uninit_applicant;
> +
>   err = register_netdevice(dev);
>   if (err < 0)
> - goto out_uninit_applicant;
> + goto out_upper_dev_unlink;
^^^
see below:

>  
>   /* Account for reference in struct vlan_dev_priv */
>   dev_hold(real_dev);
> @@ -180,6 +186,8 @@ int register_vlan_dev(struct net_device *dev)
>  
>   return 0;
>  
> +upper_dev_unlink:
^^^
should be out_upper_dev_unlink:

fbl

> + netdev_upper_dev_unlink(real_dev, dev);
>  out_uninit_applicant:
>   if (grp->nr_vlan_devs == 0)
>   vlan_gvrp_uninit_applicant(real_dev);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch net-next 01/16] net: introduce upper device lists

2012-08-14 Thread Flavio Leitner 
On Tue, 14 Aug 2012 14:24:33 +0200
Jiri Pirko  wrote:

> Mon, Aug 13, 2012 at 07:52:17PM CEST, f...@redhat.com wrote:
> >On Mon, 13 Aug 2012 17:27:00 +0200
> >Jiri Pirko  wrote:
> >> +  /*
> >> +   * To prevent loops, check if dev is not upper device to upper_dev.
> >> +   */
> >> +  if (__netdev_has_upper_dev(upper_dev, dev, true))
> >> +  return -EBUSY;
> >> +
> >> +  if (__netdev_find_upper(dev, upper_dev))
> >> +  return -EEXIST;
> >
> >__netdev_has_upper_dev() can go all the way up finding the device and
> >the __netdev_find_upper() just check the first level.
> 
> 
> I do not think this ordering is somewhat inportant.

it's not the order, see below:

> >I think it would be better to use:
> >__netdev_find_upper_dev(,,deep=true/false)
> >__netdev_has_upper(,)

It's their names.  Currently, the function ..._find_... look at
one level only, while the function ..._has_... does one or more
levels.  I think it's better to swap 'has' and 'find' in their names:

__netdev_find_upper_dev(,,deep=true/false) <-- find in all levels
__netdev_has_upper(,)  <-- check only the one level.

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 13:45:23 -0700
Yinghai Lu  wrote:

> On Tue, Sep 4, 2012 at 1:26 PM, Flavio Leitner  wrote:
> >
> > Sorry, but it didn't work.
> > The same problem happened.
> 
> can you send out boot log ?

sure, there you go:
http://sysclose.org/kdump/dmesg-debug.log
http://sysclose.org/kdump/config.log

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 15:25:45 -0700
Yinghai Lu  wrote:

> On Tue, Sep 4, 2012 at 2:37 PM, Flavio Leitner  wrote:
> > On Tue, 4 Sep 2012 13:45:23 -0700
> > Yinghai Lu  wrote:
> >
> >> On Tue, Sep 4, 2012 at 1:26 PM, Flavio Leitner  wrote:
> >> >
> >> > Sorry, but it didn't work.
> >> > The same problem happened.
> >>
> >> can you send out boot log ?
> >
> > sure, there you go:
> > http://sysclose.org/kdump/dmesg-debug.log
> > http://sysclose.org/kdump/config.log
> 
> looks like you did not use for-x86-mm branch.

No, I didn't. Sorry about that.
I will test and report back.
fbl

> 
> [0.00] initial memory mapped: [mem 0x-0x1fff]
> [0.00] Base memory trampoline at [88097000] 97000 size 24576
> [0.00] init_memory_mapping: [mem 0x-0xbf7f]
> [0.00]  [mem 0x-0xbf7f] page 2M
> [0.00] kernel direct mapping tables up to 0xbf7f @ [mem
> 0x1fa0-0x1fff]
> [0.00] init_memory_mapping: [mem 0x1-0x43fff]
> [0.00]  [mem 0x1-0x43fff] page 2M
> [0.00] kernel direct mapping tables up to 0x43fff @ [mem
> 0xbf7ce000-0xbf7d]
> [0.00] RAMDISK: [mem 0x351d2000-0x368e0fff]
> [0.00] Reserving 256MB of memory at 592MB for crashkernel
> (System RAM: 16372MB)
> 
> please try:
> 
> mkdir linux || exit -1
> cd linux
> 
> git init-db
> 
> # Add Linus's tree as a remote
> git remote add linus
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> # Add the -tip tree as a remote
> git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> 
> # Add yinghai's tree
> 
> git remote add yinghai
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> 
> git remote update
> 
> git checkout -b yinghai-for-x86-mm yinghai/for-x86-mm

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 15:25:45 -0700
Yinghai Lu  wrote:

> On Tue, Sep 4, 2012 at 2:37 PM, Flavio Leitner  wrote:
> > On Tue, 4 Sep 2012 13:45:23 -0700
> > Yinghai Lu  wrote:
> >
> >> On Tue, Sep 4, 2012 at 1:26 PM, Flavio Leitner  wrote:
> >> >
> >> > Sorry, but it didn't work.
> >> > The same problem happened.
> >>
> >> can you send out boot log ?
> >
> > sure, there you go:
> > http://sysclose.org/kdump/dmesg-debug.log
> > http://sysclose.org/kdump/config.log
> 
> looks like you did not use for-x86-mm branch.
> 
> [0.00] initial memory mapped: [mem 0x-0x1fff]
> [0.00] Base memory trampoline at [88097000] 97000 size 24576
> [0.00] init_memory_mapping: [mem 0x-0xbf7f]
> [0.00]  [mem 0x-0xbf7f] page 2M
> [0.00] kernel direct mapping tables up to 0xbf7f @ [mem
> 0x1fa0-0x1fff]
> [0.00] init_memory_mapping: [mem 0x1-0x43fff]
> [0.00]  [mem 0x1-0x43fff] page 2M
> [0.00] kernel direct mapping tables up to 0x43fff @ [mem
> 0xbf7ce000-0xbf7d]
> [0.00] RAMDISK: [mem 0x351d2000-0x368e0fff]
> [0.00] Reserving 256MB of memory at 592MB for crashkernel
> (System RAM: 16372MB)
> 
> please try:
> 
> mkdir linux || exit -1
> cd linux
> 
> git init-db
> 
> # Add Linus's tree as a remote
> git remote add linus
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> # Add the -tip tree as a remote
> git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> 
> # Add yinghai's tree
> 
> git remote add yinghai
> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> 
> git remote update
> 
> git checkout -b yinghai-for-x86-mm yinghai/for-x86-mm

kdump works when using your branch:

[0.00] Linux version 3.6.0-rc4-00012-g9389673 (r...@f17i7.rh) (gcc 
version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC) ) #1 SMP Tue Sep 4 20:36:43 BRT 
2012
...
[0.00] initial memory mapped: [mem 0x-0x1fff]
[0.00] Base memory trampoline at [88097000] 97000 size 24576
[0.00] calculate_table_space_size: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] calculate_table_space_size: [mem 0x0010-0xbf4bcfff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0xbf3f] page 2M
[0.00]  [mem 0xbf40-0xbf4bcfff] page 4k
[0.00] calculate_table_space_size: [mem 0xbf4bf000-0xbf4c5fff]
[0.00]  [mem 0xbf4bf000-0xbf4c5fff] page 4k
[0.00] calculate_table_space_size: [mem 0xbf7bf000-0xbf7d]
[0.00]  [mem 0xbf7bf000-0xbf7d] page 4k
[0.00] calculate_table_space_size: [mem 0xbf7ff000-0xbf7f]
[0.00]  [mem 0xbf7ff000-0xbf7f] page 4k
[0.00] calculate_table_space_size: [mem 0x1-0x43fff]
[0.00]  [mem 0x1-0x43fff] page 2M
[0.00] kernel direct mapping tables up to 0x43fff @ [mem 
0x43ffe1000-0x43fff] prealloc
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x0010-0xbf4bcfff]
[0.00]  [mem 0x0010-0x001f] page 4k
[0.00]  [mem 0x0020-0xbf3f] page 2M
[0.00]  [mem 0xbf40-0xbf4bcfff] page 4k
[0.00] init_memory_mapping: [mem 0xbf4bf000-0xbf4c5fff]
[0.00]  [mem 0xbf4bf000-0xbf4c5fff] page 4k
[0.00] init_memory_mapping: [mem 0xbf7bf000-0xbf7d]
[0.00]  [mem 0xbf7bf000-0xbf7d] page 4k
[0.00] init_memory_mapping: [mem 0xbf7ff000-0xbf7f]
[0.00]  [mem 0xbf7ff000-0xbf7f] page 4k
[0.00] init_memory_mapping: [mem 0x1-0x43fff]
[0.00]  [mem 0x1-0x43fff] page 2M
[0.00] kernel direct mapping tables up to 0x43fff @ [mem 
0x43ffe1000-0x43fff2fff] final
[0.00] RAMDISK: [mem 0x34ffa000-0x367f4fff]
...
http://sysclose.org/kdump/dmesg.log
http://sysclose.org/kdump/config.log

thanks,
fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-05 Thread Flavio Leitner 
On Tue, 4 Sep 2012 18:15:25 -0700
Yinghai Lu  wrote:
> assume when we have good_end setting for 64 bit, page table for [4g,
> TOMH) will be just under 512M, and later when first
> first 2M lines changes, will push that page table range a little low,
> and will make kdump not happy.
> 
> BTW the first 2M change commit is useless should be reverted. because
> even it is in 2M page mapping at first, later
> kernel will change to 4k page.
> 
> and with other change in this patchset, init_memory_mapping(0,
> ISA_END_ADDR) will always make sure first 2M use 4K page.

Hm, it's not clear to me. Are you going to push the patch reverting
that commit and then your patchset?

thank you!
fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
Hi folks,

I have system that no longer boots kdump kernel. Basically,

# echo c > /proc/sysrq-trigger

to dump a vmcore doesn't work. It just hangs after showing the usual
panic messages. I've bisected the problem and the commit introducing
the issue is the one below.

Any idea?

commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
Author: WANG Cong   2012-03-05 20:05:13
Committer: Ingo Molnar   2012-03-06 05:38:26
Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 'mmc-fixes-for-3.3' 
of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
Child:  a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in 
leave_mm() only when needed)
Branches: master, remotes/origin/master
Follows: v3.3-rc6
Precedes: v3.5-rc1

x86/mm: Fix the size calculation of mapping tables

For machines that enable PSE, the first 2/4M memory region still uses
4K pages, so needs more PTEs in this case, but
find_early_table_space() doesn't count this.

This patch fixes it.

The bug was found via code review, no misbehavior of the kernel
was observed.


Machine details:
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 26
model name  : Intel(R) Core(TM) i7 CPU 920  @ 2.67GHz
stepping: 5
microcode   : 0x11
cpu MHz : 1596.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 
sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips: 5333.87
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

# free
 total   used   free sharedbuffers cached
Mem:  16161684   117491004412584  0  10212   11421096
-/+ buffers/cache: 317792   15843892
Swap: 17406420  0   17406420


dmesg is attached.

thanks,
fbl




dmesg.log.gz
Description: GNU Zip compressed data

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 12:02:00 -0700
Yinghai Lu  wrote:

> On Tue, Sep 4, 2012 at 10:32 AM, Flavio Leitner  wrote:
> > Hi folks,
> >
> > I have system that no longer boots kdump kernel. Basically,
> >
> > # echo c > /proc/sysrq-trigger
> >
> > to dump a vmcore doesn't work. It just hangs after showing the usual
> > panic messages. I've bisected the problem and the commit introducing
> > the issue is the one below.
> >
> > Any idea?
> >
> > commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8
> > Author: WANG Cong   2012-03-05 20:05:13
> > Committer: Ingo Molnar   2012-03-06 05:38:26
> > Parent: 550cf00dbc8ee402bef71628cb71246493dd4500 (Merge tag 
> > 'mmc-fixes-for-3.3' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc)
> > Child:  a6fca40f1d7f3e232c9de27c1cebbb9f787fbc4f (x86, tlb: Switch cr3 in 
> > leave_mm() only when needed)
> > Branches: master, remotes/origin/master
> > Follows: v3.3-rc6
> > Precedes: v3.5-rc1
> >
> > x86/mm: Fix the size calculation of mapping tables
> >
> > For machines that enable PSE, the first 2/4M memory region still uses
> > 4K pages, so needs more PTEs in this case, but
> > find_early_table_space() doesn't count this.
> >
> > This patch fixes it.
> >
> > The bug was found via code review, no misbehavior of the kernel
> > was observed.
> 
> maybe just revert the offending commit?

I don't know where the 4K pages were noticed. Here is the
dmesg output passing 'debug':

[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] last_pfn = 0xbf800 max_arch_pfn = 0x4
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [88098000] 98000 size 20480
[0.00] init_memory_mapping: -bf80
[0.00]  00 - 00bf80 page 2M
[0.00] kernel direct mapping tables up to bf80 @ 1fa0-2000
[0.00] init_memory_mapping: 0001-00044000
[0.00]  01 - 044000 page 2M
[0.00] kernel direct mapping tables up to 44000 @ bdaab000-bf4bd000
[0.00] RAMDISK: 352c8000 - 3695c000

so, it appears that on my system, the pages are 2M.
I will try moving the extra accounting to be inside of CONFIG_X86_32.

fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 12:20:14 -0700
Yinghai Lu  wrote:

> On Tue, Sep 4, 2012 at 12:17 PM, Flavio Leitner  wrote:
> > On Tue, 4 Sep 2012 12:02:00 -0700
> > [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
> > 0x7010600070106
> > [0.00] last_pfn = 0xbf800 max_arch_pfn = 0x4
> > [0.00] initial memory mapped : 0 - 2000
> > [0.00] Base memory trampoline at [88098000] 98000 size 20480
> > [0.00] init_memory_mapping: -bf80
> > [0.00]  00 - 00bf80 page 2M
> > [0.00] kernel direct mapping tables up to bf80 @ 
> > 1fa0-2000
> > [0.00] init_memory_mapping: 0001-00044000
> > [0.00]  01 - 044000 page 2M
> > [0.00] kernel direct mapping tables up to 44000 @ 
> > bdaab000-bf4bd000
> > [0.00] RAMDISK: 352c8000 - 3695c000
> >

Alright, moving the extra accounting to be inside of CONFIG_X86_32 works out.

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index e0e6990..63e6a5c 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -60,10 +60,10 @@ static void __init find_early_table_space(struct map_range 
*mr, unsigned long en
extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
 #ifdef CONFIG_X86_32
extra += PMD_SIZE;
-#endif
/* The first 2/4M doesn't use large pages. */
if (mr->start < PMD_SIZE)
extra += mr->end - mr->start;
+#endif
 
ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
} else

> BTW, can you please try our new init_memory_mapping clean up at
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-x86-mm
> 
> hope it could make your kdump working.

I will give a try.
fbl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kexec/kdump kernel fails to start

2012-09-04 Thread Flavio Leitner 
On Tue, 4 Sep 2012 12:20:14 -0700
Yinghai Lu  wrote:

> On Tue, Sep 4, 2012 at 12:17 PM, Flavio Leitner  wrote:
> > On Tue, 4 Sep 2012 12:02:00 -0700
> > [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
> > 0x7010600070106
> > [0.00] last_pfn = 0xbf800 max_arch_pfn = 0x4
> > [0.00] initial memory mapped : 0 - 2000
> > [0.00] Base memory trampoline at [88098000] 98000 size 20480
> > [0.00] init_memory_mapping: -bf80
> > [0.00]  00 - 00bf80 page 2M
> > [0.00] kernel direct mapping tables up to bf80 @ 
> > 1fa0-2000
> > [0.00] init_memory_mapping: 0001-00044000
> > [0.00]  01 - 044000 page 2M
> > [0.00] kernel direct mapping tables up to 44000 @ 
> > bdaab000-bf4bd000
> > [0.00] RAMDISK: 352c8000 - 3695c000
> >
> BTW, can you please try our new init_memory_mapping clean up at
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> for-x86-mm
> 
> hope it could make your kdump working.

Sorry, but it didn't work.
The same problem happened. 
fbl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] serial: set correct baud_base for EXSYS EX-41092 Dual 16950

2012-09-17 Thread Flavio Leitner 
Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner 
---
 drivers/tty/serial/8250/8250_pci.c | 7 +--
 include/linux/pci_ids.h| 3 ++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_pci.c 
b/drivers/tty/serial/8250/8250_pci.c
index 28e7c7c..6fe88e6 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -3232,8 +3232,11 @@ static struct pci_device_id serial_pci_tbl[] = {
 * For now just used the hex ID 0x950a.
 */
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
-   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL, 0, 0,
-   pbn_b0_2_115200 },
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_00,
+   0, 0, pbn_b0_2_115200 },
+   {   PCI_VENDOR_ID_OXSEMI, 0x950a,
+   PCI_SUBVENDOR_ID_SIIG, PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_30,
+   0, 0, pbn_b0_2_115200 },
{   PCI_VENDOR_ID_OXSEMI, 0x950a,
PCI_ANY_ID, PCI_ANY_ID, 0, 0,
pbn_b0_2_113 },
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..4242013 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1847,7 +1847,8 @@
 #define PCI_DEVICE_ID_SIIG_8S_20x_650  0x2081
 #define PCI_DEVICE_ID_SIIG_8S_20x_850  0x2082
 #define PCI_SUBDEVICE_ID_SIIG_QUARTET_SERIAL   0x2050
-#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL  0x2530
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_00   0x2500
+#define PCI_SUBDEVICE_ID_SIIG_DUAL_SERIAL_30   0x2530
 
 #define PCI_VENDOR_ID_RADISYS  0x1331
 
-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] 8250: fix autoconfig to work with serial console

2012-09-18 Thread Flavio Leitner 
The autoconfig prints messages while holding the
port's spinlock and that causes a deadlock when
using serial console.

Signed-off-by: Flavio Leitner 
---
 drivers/tty/serial/8250/8250.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 8123f78..17e0c3f 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1037,6 +1037,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
unsigned char save_lcr, save_mcr;
struct uart_port *port = >port;
unsigned long flags;
+   unsigned int old_capabilities;
 
if (!port->iobase && !port->mapbase && !port->membase)
return;
@@ -1087,6 +1088,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
/*
 * We failed; there's nothing here
 */
+   spin_unlock_irqrestore(>lock, flags);
DEBUG_AUTOCONF("IER test failed (%02x, %02x) ",
   scratch2, scratch3);
goto out;
@@ -1110,6 +1112,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
status1 = serial_in(up, UART_MSR) & 0xF0;
serial_out(up, UART_MCR, save_mcr);
if (status1 != 0x90) {
+   spin_unlock_irqrestore(>lock, flags);
DEBUG_AUTOCONF("LOOP test failed (%02x) ",
   status1);
goto out;
@@ -1132,8 +1135,6 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO);
scratch = serial_in(up, UART_IIR) >> 6;
 
-   DEBUG_AUTOCONF("iir=%d ", scratch);
-
switch (scratch) {
case 0:
autoconfig_8250(up);
@@ -1167,19 +1168,13 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
 
serial_out(up, UART_LCR, save_lcr);
 
-   if (up->capabilities != uart_config[port->type].flags) {
-   printk(KERN_WARNING
-  "ttyS%d: detected caps %08x should be %08x\n",
-  serial_index(port), up->capabilities,
-  uart_config[port->type].flags);
-   }
-
port->fifosize = uart_config[up->port.type].fifo_size;
+   old_capabilities = up->capabilities; 
up->capabilities = uart_config[port->type].flags;
up->tx_loadsz = uart_config[port->type].tx_loadsz;
 
if (port->type == PORT_UNKNOWN)
-   goto out;
+   goto out_lock;
 
/*
 * Reset the UART.
@@ -1196,8 +1191,16 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
else
serial_out(up, UART_IER, 0);
 
- out:
+out_lock:
spin_unlock_irqrestore(>lock, flags);
+   if (up->capabilities != old_capabilities) {
+   printk(KERN_WARNING
+  "ttyS%d: detected caps %08x should be %08x\n",
+  serial_index(port), old_capabilities,
+  up->capabilities);
+   }
+out:
+   DEBUG_AUTOCONF("iir=%d ", scratch);
DEBUG_AUTOCONF("type=%s\n", uart_config[port->type].name);
 }
 
-- 
1.7.11.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtnetlink: fix missing size for IFLA_IF_NETNSID

2017-11-15 Thread Flavio Leitner 
On Mon, 6 Nov 2017 16:16:20 +0100
Jiri Benc  wrote:

> On Mon,  6 Nov 2017 15:04:54 +, Colin King wrote:
> > The size for IFLA_IF_NETNSID is missing from the size calculation
> > because the proceeding semicolon was not removed. Fix this by removing
> > the semicolon.  
> 
> Acked-by: Jiri Benc 
> 
> Thanks for spotting this! Looking at my initial code, I had that right,
> this was probably introduced during one of rebases, so I blame
> Flavio :-p (On a serious note, thank you, Flavio, for taking care of
> the rebases.)

That's right, ouch!
Thanks for fixing it.

-- 
Flavio

Re: [PATCH] netfilter: check if the socket netns is correct.

2018-09-27 Thread Flavio Leitner 
On Thu, Sep 27, 2018 at 01:46:29PM -0700, Guenter Roeck wrote:
> Hi Flavio,
> 
> On Wed, Jun 27, 2018 at 10:34:25AM -0300, Flavio Leitner wrote:
> > Netfilter assumes that if the socket is present in the skb, then
> > it can be used because that reference is cleaned up while the skb
> > is crossing netns.
> > 
> > We want to change that to preserve the socket reference in a future
> > patch, so this is a preparation updating netfilter to check if the
> > socket netns matches before use it.
> > 
> > Signed-off-by: Flavio Leitner 
> > Acked-by: Florian Westphal 
> > Signed-off-by: David S. Miller 
> > ---
> ...
> > --- a/net/netfilter/xt_socket.c
> > +++ b/net/netfilter/xt_socket.c
> > @@ -56,8 +56,12 @@ socket_match(const struct sk_buff *skb, struct 
> > xt_action_param *par,
> > struct sk_buff *pskb = (struct sk_buff *)skb;
> > struct sock *sk = skb->sk;
> >  
> > +   if (!net_eq(xt_net(par), sock_net(sk)))
> > +   sk = NULL;
> > +
> 
> I am having trouble with this code. With CONFIG_NET_NS enabled, it crashes
> for me in read_pnet() because sk is NULL.
> 
> > if (!sk)
> > sk = nf_sk_lookup_slow_v4(xt_net(par), skb, xt_in(par));
> 
> The old code seems to suggest that sk == NULL was possible.
> 
> I see the problem with the Chrome OS kernel rebased to v4.19-rc5, so I
> can not guarantee that this really an upstream problem. The change seems
> odd, though. Are you sure that it is not (or, rather, no longer) necessary
> to check if sk == NULL before dereferencing it in sock_net() ?

Oops, it is necessary but if it's not and the netns doesn't match, we need
do the lookup. So, could you check if this fixes the problem for you?

>From a5f927e7f1368d753f87cb978d630d786d5adb62 Mon Sep 17 00:00:00 2001
From: Flavio Leitner 
Date: Thu, 27 Sep 2018 19:36:28 -0300
Subject: [PATCH] xt_socket: check sk before checking for netns.

Only check for the network namespace if the socket is available.

Fixes: f564650106a6 ("netfilter: check if the socket netns is correct.")
Reported-by: Guenter Roeck 
Signed-off-by: Flavio Leitner 
---
 net/netfilter/xt_socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 0472f3472842..ada144e5645b 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -56,7 +56,7 @@ socket_match(const struct sk_buff *skb, struct 
xt_action_param *par,
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
 
-   if (!net_eq(xt_net(par), sock_net(sk)))
+   if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
 
if (!sk)
@@ -117,7 +117,7 @@ socket_mt6_v1_v2_v3(const struct sk_buff *skb, struct 
xt_action_param *par)
struct sk_buff *pskb = (struct sk_buff *)skb;
struct sock *sk = skb->sk;
 
-   if (!net_eq(xt_net(par), sock_net(sk)))
+   if (sk && !net_eq(xt_net(par), sock_net(sk)))
sk = NULL;
 
if (!sk)
-- 
2.14.4