[PATCH] perf tools: Fix old email address

[Jaswinder Singh Rajput]

jaswin...@kernel.org is old email and not in use.

Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Ingo Molnar <mi...@elte.hu>
Cc: Arnaldo Carvalho de Melo <a...@kernel.org>
Cc: Alexander Shishkin <alexander.shish...@linux.intel.com>
Cc: Jiri Olsa <jo...@redhat.com>
Cc: Namhyung Kim <namhy...@kernel.org>
Signed-off-by: Jaswinder Singh Rajput <jaswin...@perfectintelligent.com>
---
 tools/perf/builtin-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 59af5a8..dfb2159 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -36,7 +36,7 @@
  *   Wu Fengguang <fengguang...@intel.com>
  *   Mike Galbraith <efa...@gmx.de>
  *   Paul Mackerras <pau...@samba.org>
- *   Jaswinder Singh Rajput <jaswin...@kernel.org>
+ *   Jaswinder Singh Rajput <jaswin...@perfectintelligent.com>
  *
  * Released under the GPL v2. (and only v2, not any later version)
  */
-- 
2.7.5

[PATCH] perf tools: Fix old email address

[Jaswinder Singh Rajput]

jaswin...@kernel.org is old email and not in use.

Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Signed-off-by: Jaswinder Singh Rajput 
---
 tools/perf/builtin-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 59af5a8..dfb2159 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -36,7 +36,7 @@
  *   Wu Fengguang 
  *   Mike Galbraith 
  *   Paul Mackerras 
- *   Jaswinder Singh Rajput 
+ *   Jaswinder Singh Rajput 
  *
  * Released under the GPL v2. (and only v2, not any later version)
  */
-- 
2.7.5

[PATCH 3/3] perf tools: Fix old email address

[Jaswinder Singh Rajput]

Cc: Ingo Molnar <mi...@elte.hu>
Signed-off-by: Jaswinder Singh Rajput <jaswin...@perfectintelligent.com
> 
> 
---
 tools/perf/builtin-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 59af5a8..dfb2159 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -36,7 +36,7 @@
  *   Wu Fengguang <fengguang...@intel.com>
  *   Mike Galbraith <efa...@gmx.de>
  *   Paul Mackerras <pau...@samba.org>
- *   Jaswinder Singh Rajput <jaswin...@kernel.org>
+ *   Jaswinder Singh Rajput <jaswin...@perfectintelligent.com>
  *
  * Released under the GPL v2. (and only v2, not any later version)
  */

[PATCH 3/3] perf tools: Fix old email address

[Jaswinder Singh Rajput]

Cc: Ingo Molnar 
Signed-off-by: Jaswinder Singh Rajput  
> 
---
 tools/perf/builtin-stat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 59af5a8..dfb2159 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -36,7 +36,7 @@
  *   Wu Fengguang 
  *   Mike Galbraith 
  *   Paul Mackerras 
- *   Jaswinder Singh Rajput 
+ *   Jaswinder Singh Rajput 
  *
  * Released under the GPL v2. (and only v2, not any later version)
  */

[PATCH 2/3] perf x86: Fix missing email address

[Jaswinder Singh Rajput]

Cc: Ingo Molnar <mi...@elte.hu>
Signed-off-by: Jaswinder Singh Rajput <jaswin...@perfectintelligent.com
> 
> 
---
 arch/x86/events/perf_event.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/perf_event.h
b/arch/x86/events/perf_event.h
index f7aaadf..84643b7 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -3,7 +3,7 @@
  *
  *  Copyright (C) 2008 Thomas Gleixner <t...@linutronix.de>
  *  Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
- *  Copyright (C) 2009 Jaswinder Singh Rajput
+ *  Copyright (C) 2009 Jaswinder Singh Rajput <jaswinder@perfectintell
igent.com>
  *  Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
  *  Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
  *  Copyright (C) 2009 Intel Corporation, <markus.t.metz...@intel.com>

[PATCH 2/3] perf x86: Fix missing email address

[Jaswinder Singh Rajput]

Cc: Ingo Molnar 
Signed-off-by: Jaswinder Singh Rajput  
> 
---
 arch/x86/events/perf_event.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/perf_event.h
b/arch/x86/events/perf_event.h
index f7aaadf..84643b7 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -3,7 +3,7 @@
  *
  *  Copyright (C) 2008 Thomas Gleixner 
  *  Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
- *  Copyright (C) 2009 Jaswinder Singh Rajput
+ *  Copyright (C) 2009 Jaswinder Singh Rajput 
  *  Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
  *  Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
  *  Copyright (C) 2009 Intel Corporation, 

[PATCH 0/3] perf: fix missing and old email address

[Jaswinder Singh Rajput]

This patchset fix my missing and old email address

 0001-perf-x86-Fix-missing-email-address.patch
 0002-perf-x86-Fix-missing-email-address.patch
 0003-perf-tools-Fix-old-email-address.patch

 arch/x86/events/core.c   | 2 +-
 arch/x86/events/perf_event.h | 2 +-
 tools/perf/builtin-stat.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 0/3] perf: fix missing and old email address

[Jaswinder Singh Rajput]

This patchset fix my missing and old email address

 0001-perf-x86-Fix-missing-email-address.patch
 0002-perf-x86-Fix-missing-email-address.patch
 0003-perf-tools-Fix-old-email-address.patch

 arch/x86/events/core.c   | 2 +-
 arch/x86/events/perf_event.h | 2 +-
 tools/perf/builtin-stat.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 1/3] perf x86: Fix missing email address

[Jaswinder Singh Rajput]

Cc: Ingo Molnar <mi...@elte.hu>
Signed-off-by: Jaswinder Singh Rajput <jaswin...@perfectintelligent.com
> 
> 
---
 arch/x86/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 140d332..574d662 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -3,7 +3,7 @@
  *
  *  Copyright (C) 2008 Thomas Gleixner <t...@linutronix.de>
  *  Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
- *  Copyright (C) 2009 Jaswinder Singh Rajput
+ *  Copyright (C) 2009 Jaswinder Singh Rajput <jaswinder@perfectintell
igent.com>
  *  Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
  *  Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
  *  Copyright (C) 2009 Intel Corporation, <markus.t.metz...@intel.com>

[PATCH 1/3] perf x86: Fix missing email address

[Jaswinder Singh Rajput]

Cc: Ingo Molnar 
Signed-off-by: Jaswinder Singh Rajput  
> 
---
 arch/x86/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 140d332..574d662 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -3,7 +3,7 @@
  *
  *  Copyright (C) 2008 Thomas Gleixner 
  *  Copyright (C) 2008-2009 Red Hat, Inc., Ingo Molnar
- *  Copyright (C) 2009 Jaswinder Singh Rajput
+ *  Copyright (C) 2009 Jaswinder Singh Rajput 
  *  Copyright (C) 2009 Advanced Micro Devices, Inc., Robert Richter
  *  Copyright (C) 2008-2009 Red Hat, Inc., Peter Zijlstra
  *  Copyright (C) 2009 Intel Corporation, 

Re: Warning in i915/intel_audio.c

[Jaswinder Singh Rajput]

On Fri, 2017-12-15 at 16:23 +0200, Mika Kahola wrote:
> On Fri, 2017-12-15 at 19:20 +0530, Jaswinder Singh Rajput wrote:
> > 
> > On Fri, 2017-12-15 at 14:44 +0200, Mika Kahola wrote:
> > > 
> > > 
> > > Hi,
> > > 
> > > This is a known issue. Could you try out this patch to see if
> > > that
> > > would fix this issue for you?
> > > 
> > > https://patchwork.freedesktop.org/series/35389/
> > > 
> > Yes, Thanks. It works :-)
> Great that it worked for you!
> 
> > 
> > 
> > When this patch will merge with linus kernel.
> If you can, you may add a Tested-by tag on the patch. It will help
> the
> review process. This patch needs a review before its merged to our
> drm-
> tip tree and eventually further on to Linus tree.
> 


Sure, kindly add me in CC and add my tag to the patch:

Tested-by: Jaswinder Singh Rajput <jaswin...@perfectintelligent.com>



> > 
> > 
> > Thanks,
> > --
> > Jaswinder Singh Rajput
> >  
> > > 
> > > 
> > > On Fri, 2017-12-15 at 17:08 +0530, Jaswinder Singh Rajput wrote:
> > > > 
> > > > 
> > > > 
> > > > Hello friends,
> > > > 
> > > > I am getting multiple warnings in i915/intel_audio.c . I am
> > > > attaching 
> > > > dmesg, config and lsmod for your reference.
> > > > 
> > > > 
> > > > [0.390606] WARN_ON(pipe >= intel_info((dev_priv))-
> > > > >num_pipes)
> > > > [0.390619] WARNING: CPU: 1 PID: 1051 at 
> > > > drivers/gpu/drm/i915/intel_audio.c:757 get_saved_enc+0x74/0x80
> > > > [0.390620] Modules linked in:
> > > > [0.390621] CPU: 1 PID: 1051 Comm: kworker/1:2 Not tainted 
> > > > 4.15.0-rc3+ #13
> > > > [0.390622] Hardware name: Gigabyte Technology Co., Ltd. 
> > > > H81M-S/H81M-S, BIOS F2 08/19/2015
> > > > [0.390624] Workqueue: events azx_probe_work
> > > > [0.390625] RIP: 0010:get_saved_enc+0x74/0x80
> > > > [0.390626] RSP: 0018:9b650061fba8 EFLAGS: 00010292
> > > > [0.390627] RAX: 0032 RBX: 888e17384cb8
> > > > RCX: 
> > > > 
> > > > [0.390627] RDX: 0001 RSI: 0002
> > > > RDI: 
> > > > 97032bb0
> > > > [0.390627] RBP: 888e1738 R08: 0032
> > > > R09: 
> > > > 0032
> > > > [0.390628] R10: 888e19cc3840 R11: 000344e0
> > > > R12: 
> > > > 0100
> > > > [0.390628] R13: 0001 R14: 888e168fba08
> > > > R15: 
> > > > 888e168fba10
> > > > [0.390629] FS:  ()
> > > > GS:888e1f30() 
> > > > knlGS:
> > > > [0.390629] CS:  0010 DS:  ES:  CR0:
> > > > 80050033
> > > > [0.390630] CR2: 7f7dd01c6914 CR3: 3da0a001
> > > > CR4: 
> > > > 000606e0
> > > > [0.390630] Call Trace:
> > > > [0.390633]  i915_audio_component_get_eld+0x43/0xe0
> > > > [0.390635]  hdmi_present_sense+0x95/0x330
> > > > [0.390636]  generic_hdmi_build_controls+0x143/0x1e0
> > > > [0.390638]  snd_hda_codec_build_controls+0x178/0x1c0
> > > > [0.390639]  ? snd_hda_codec_build_pcms+0x14f/0x1a0
> > > > [0.390641]  hda_codec_driver_probe+0x76/0x100
> > > > [0.390644]  driver_probe_device+0x27d/0x310
> > > > [0.390645]  ? __driver_attach+0xa0/0xa0
> > > > [0.390646]  bus_for_each_drv+0x50/0x80
> > > > [0.390647]  __device_attach+0xb0/0x110
> > > > [0.390649]  bus_probe_device+0x82/0x90
> > > > [0.390650]  device_add+0x2dc/0x570
> > > > [0.390652]  snd_hdac_device_register+0xd/0x40
> > > > [0.390654]  snd_hda_codec_configure+0x32/0x120
> > > > [0.390655]  azx_codec_configure+0x2a/0x60
> > > > [0.390656]  azx_probe_work+0x40c/0x860
> > > > [0.390659]  process_one_work+0x1d2/0x3c0
> > > > [0.390660]  worker_thread+0x42/0x3e0
> > > > [0.390661]  kthread+0xf0/0x130
> > > > [0.390663]  ?
> > > > trace_event_raw_event_workqueue_work+0x80/0x80
> > > > [0.390664]  ? kthread_create_worker_on_cpu+0x40/0x40
> > > > [0.390665]  ? call_usermodehelper_exec_async+0x11c/0x120
> > > > [0.390667]  ret_from_fork+0x1f/0x30
> > > > [0.390668] Code: 83 c2 01 39 d1 7f e0 31 c0 c3 83 78 70 0b
> > > > 74
> > > > f9
> > > > 31 
> > > > c0 85 d2 74 cb eb f1 48 c7 c6 d0 c0 df 96 48 c7 c7 57 dd db 96
> > > > e8
> > > > 9c
> > > > 2d 
> > > > bf ff <0f> ff 31 c0 c3 0f 1f 80 00 00 00 00 41 57 4d 89 c7 41
> > > > 56
> > > > 49
> > > > 89
> > > > [0.390679] ---[ end trace 9a14f34c58dc94ff ]---
> > > > 
> > > > 
> > > > Thanks,
> > > > --
> > > > Jaswinder Singh Rajput
> > > > 

Re: Warning in i915/intel_audio.c

[Jaswinder Singh Rajput]

On Fri, 2017-12-15 at 16:23 +0200, Mika Kahola wrote:
> On Fri, 2017-12-15 at 19:20 +0530, Jaswinder Singh Rajput wrote:
> > 
> > On Fri, 2017-12-15 at 14:44 +0200, Mika Kahola wrote:
> > > 
> > > 
> > > Hi,
> > > 
> > > This is a known issue. Could you try out this patch to see if
> > > that
> > > would fix this issue for you?
> > > 
> > > https://patchwork.freedesktop.org/series/35389/
> > > 
> > Yes, Thanks. It works :-)
> Great that it worked for you!
> 
> > 
> > 
> > When this patch will merge with linus kernel.
> If you can, you may add a Tested-by tag on the patch. It will help
> the
> review process. This patch needs a review before its merged to our
> drm-
> tip tree and eventually further on to Linus tree.
> 


Sure, kindly add me in CC and add my tag to the patch:

Tested-by: Jaswinder Singh Rajput 



> > 
> > 
> > Thanks,
> > --
> > Jaswinder Singh Rajput
> >  
> > > 
> > > 
> > > On Fri, 2017-12-15 at 17:08 +0530, Jaswinder Singh Rajput wrote:
> > > > 
> > > > 
> > > > 
> > > > Hello friends,
> > > > 
> > > > I am getting multiple warnings in i915/intel_audio.c . I am
> > > > attaching 
> > > > dmesg, config and lsmod for your reference.
> > > > 
> > > > 
> > > > [0.390606] WARN_ON(pipe >= intel_info((dev_priv))-
> > > > >num_pipes)
> > > > [0.390619] WARNING: CPU: 1 PID: 1051 at 
> > > > drivers/gpu/drm/i915/intel_audio.c:757 get_saved_enc+0x74/0x80
> > > > [0.390620] Modules linked in:
> > > > [0.390621] CPU: 1 PID: 1051 Comm: kworker/1:2 Not tainted 
> > > > 4.15.0-rc3+ #13
> > > > [0.390622] Hardware name: Gigabyte Technology Co., Ltd. 
> > > > H81M-S/H81M-S, BIOS F2 08/19/2015
> > > > [0.390624] Workqueue: events azx_probe_work
> > > > [0.390625] RIP: 0010:get_saved_enc+0x74/0x80
> > > > [0.390626] RSP: 0018:9b650061fba8 EFLAGS: 00010292
> > > > [0.390627] RAX: 0032 RBX: 888e17384cb8
> > > > RCX: 
> > > > 
> > > > [0.390627] RDX: 0001 RSI: 0002
> > > > RDI: 
> > > > 97032bb0
> > > > [0.390627] RBP: 888e1738 R08: 0032
> > > > R09: 
> > > > 0032
> > > > [0.390628] R10: 888e19cc3840 R11: 000344e0
> > > > R12: 
> > > > 0100
> > > > [0.390628] R13: 0001 R14: 888e168fba08
> > > > R15: 
> > > > 888e168fba10
> > > > [0.390629] FS:  ()
> > > > GS:888e1f30() 
> > > > knlGS:
> > > > [0.390629] CS:  0010 DS:  ES:  CR0:
> > > > 80050033
> > > > [0.390630] CR2: 7f7dd01c6914 CR3: 3da0a001
> > > > CR4: 
> > > > 000606e0
> > > > [0.390630] Call Trace:
> > > > [0.390633]  i915_audio_component_get_eld+0x43/0xe0
> > > > [0.390635]  hdmi_present_sense+0x95/0x330
> > > > [0.390636]  generic_hdmi_build_controls+0x143/0x1e0
> > > > [0.390638]  snd_hda_codec_build_controls+0x178/0x1c0
> > > > [0.390639]  ? snd_hda_codec_build_pcms+0x14f/0x1a0
> > > > [0.390641]  hda_codec_driver_probe+0x76/0x100
> > > > [0.390644]  driver_probe_device+0x27d/0x310
> > > > [0.390645]  ? __driver_attach+0xa0/0xa0
> > > > [0.390646]  bus_for_each_drv+0x50/0x80
> > > > [0.390647]  __device_attach+0xb0/0x110
> > > > [0.390649]  bus_probe_device+0x82/0x90
> > > > [0.390650]  device_add+0x2dc/0x570
> > > > [0.390652]  snd_hdac_device_register+0xd/0x40
> > > > [0.390654]  snd_hda_codec_configure+0x32/0x120
> > > > [0.390655]  azx_codec_configure+0x2a/0x60
> > > > [0.390656]  azx_probe_work+0x40c/0x860
> > > > [0.390659]  process_one_work+0x1d2/0x3c0
> > > > [0.390660]  worker_thread+0x42/0x3e0
> > > > [0.390661]  kthread+0xf0/0x130
> > > > [0.390663]  ?
> > > > trace_event_raw_event_workqueue_work+0x80/0x80
> > > > [0.390664]  ? kthread_create_worker_on_cpu+0x40/0x40
> > > > [0.390665]  ? call_usermodehelper_exec_async+0x11c/0x120
> > > > [0.390667]  ret_from_fork+0x1f/0x30
> > > > [0.390668] Code: 83 c2 01 39 d1 7f e0 31 c0 c3 83 78 70 0b
> > > > 74
> > > > f9
> > > > 31 
> > > > c0 85 d2 74 cb eb f1 48 c7 c6 d0 c0 df 96 48 c7 c7 57 dd db 96
> > > > e8
> > > > 9c
> > > > 2d 
> > > > bf ff <0f> ff 31 c0 c3 0f 1f 80 00 00 00 00 41 57 4d 89 c7 41
> > > > 56
> > > > 49
> > > > 89
> > > > [0.390679] ---[ end trace 9a14f34c58dc94ff ]---
> > > > 
> > > > 
> > > > Thanks,
> > > > --
> > > > Jaswinder Singh Rajput
> > > > 

Re: Warning in i915/intel_audio.c

[Jaswinder Singh Rajput]

On Fri, 2017-12-15 at 14:44 +0200, Mika Kahola wrote:
> Hi,
> 
> This is a known issue. Could you try out this patch to see if that
> would fix this issue for you?
> 
> https://patchwork.freedesktop.org/series/35389/
> 

Yes, Thanks. It works :-)

When this patch will merge with linus kernel.

Thanks,
--
Jaswinder Singh Rajput
 
> On Fri, 2017-12-15 at 17:08 +0530, Jaswinder Singh Rajput wrote:
> > 
> > Hello friends,
> > 
> > I am getting multiple warnings in i915/intel_audio.c . I am
> > attaching 
> > dmesg, config and lsmod for your reference.
> > 
> > 
> > [0.390606] WARN_ON(pipe >= intel_info((dev_priv))->num_pipes)
> > [0.390619] WARNING: CPU: 1 PID: 1051 at 
> > drivers/gpu/drm/i915/intel_audio.c:757 get_saved_enc+0x74/0x80
> > [0.390620] Modules linked in:
> > [0.390621] CPU: 1 PID: 1051 Comm: kworker/1:2 Not tainted 
> > 4.15.0-rc3+ #13
> > [0.390622] Hardware name: Gigabyte Technology Co., Ltd. 
> > H81M-S/H81M-S, BIOS F2 08/19/2015
> > [0.390624] Workqueue: events azx_probe_work
> > [0.390625] RIP: 0010:get_saved_enc+0x74/0x80
> > [0.390626] RSP: 0018:9b650061fba8 EFLAGS: 00010292
> > [0.390627] RAX: 0032 RBX: 888e17384cb8 RCX: 
> > 
> > [0.390627] RDX: 0001 RSI: 0002 RDI: 
> > 97032bb0
> > [0.390627] RBP: 888e1738 R08: 0032 R09: 
> > 0032
> > [0.390628] R10: 888e19cc3840 R11: 000344e0 R12: 
> > 0100
> > [0.390628] R13: 0001 R14: 888e168fba08 R15: 
> > 888e168fba10
> > [0.390629] FS:  ()
> > GS:888e1f30() 
> > knlGS:
> > [0.390629] CS:  0010 DS:  ES:  CR0: 80050033
> > [0.390630] CR2: 7f7dd01c6914 CR3: 3da0a001 CR4: 
> > 000606e0
> > [0.390630] Call Trace:
> > [0.390633]  i915_audio_component_get_eld+0x43/0xe0
> > [0.390635]  hdmi_present_sense+0x95/0x330
> > [0.390636]  generic_hdmi_build_controls+0x143/0x1e0
> > [0.390638]  snd_hda_codec_build_controls+0x178/0x1c0
> > [0.390639]  ? snd_hda_codec_build_pcms+0x14f/0x1a0
> > [0.390641]  hda_codec_driver_probe+0x76/0x100
> > [0.390644]  driver_probe_device+0x27d/0x310
> > [0.390645]  ? __driver_attach+0xa0/0xa0
> > [0.390646]  bus_for_each_drv+0x50/0x80
> > [0.390647]  __device_attach+0xb0/0x110
> > [0.390649]  bus_probe_device+0x82/0x90
> > [0.390650]  device_add+0x2dc/0x570
> > [0.390652]  snd_hdac_device_register+0xd/0x40
> > [0.390654]  snd_hda_codec_configure+0x32/0x120
> > [0.390655]  azx_codec_configure+0x2a/0x60
> > [0.390656]  azx_probe_work+0x40c/0x860
> > [0.390659]  process_one_work+0x1d2/0x3c0
> > [0.390660]  worker_thread+0x42/0x3e0
> > [0.390661]  kthread+0xf0/0x130
> > [0.390663]  ? trace_event_raw_event_workqueue_work+0x80/0x80
> > [0.390664]  ? kthread_create_worker_on_cpu+0x40/0x40
> > [0.390665]  ? call_usermodehelper_exec_async+0x11c/0x120
> > [    0.390667]  ret_from_fork+0x1f/0x30
> > [0.390668] Code: 83 c2 01 39 d1 7f e0 31 c0 c3 83 78 70 0b 74
> > f9
> > 31 
> > c0 85 d2 74 cb eb f1 48 c7 c6 d0 c0 df 96 48 c7 c7 57 dd db 96 e8
> > 9c
> > 2d 
> > bf ff <0f> ff 31 c0 c3 0f 1f 80 00 00 00 00 41 57 4d 89 c7 41 56 49
> > 89
> > [0.390679] ---[ end trace 9a14f34c58dc94ff ]---
> > 
> > 
> > Thanks,
> > --
> > Jaswinder Singh Rajput
> > 

Re: Warning in i915/intel_audio.c

[Jaswinder Singh Rajput]

On Fri, 2017-12-15 at 14:44 +0200, Mika Kahola wrote:
> Hi,
> 
> This is a known issue. Could you try out this patch to see if that
> would fix this issue for you?
> 
> https://patchwork.freedesktop.org/series/35389/
> 

Yes, Thanks. It works :-)

When this patch will merge with linus kernel.

Thanks,
--
Jaswinder Singh Rajput
 
> On Fri, 2017-12-15 at 17:08 +0530, Jaswinder Singh Rajput wrote:
> > 
> > Hello friends,
> > 
> > I am getting multiple warnings in i915/intel_audio.c . I am
> > attaching 
> > dmesg, config and lsmod for your reference.
> > 
> > 
> > [0.390606] WARN_ON(pipe >= intel_info((dev_priv))->num_pipes)
> > [0.390619] WARNING: CPU: 1 PID: 1051 at 
> > drivers/gpu/drm/i915/intel_audio.c:757 get_saved_enc+0x74/0x80
> > [0.390620] Modules linked in:
> > [0.390621] CPU: 1 PID: 1051 Comm: kworker/1:2 Not tainted 
> > 4.15.0-rc3+ #13
> > [0.390622] Hardware name: Gigabyte Technology Co., Ltd. 
> > H81M-S/H81M-S, BIOS F2 08/19/2015
> > [0.390624] Workqueue: events azx_probe_work
> > [0.390625] RIP: 0010:get_saved_enc+0x74/0x80
> > [0.390626] RSP: 0018:9b650061fba8 EFLAGS: 00010292
> > [0.390627] RAX: 0032 RBX: 888e17384cb8 RCX: 
> > 
> > [0.390627] RDX: 0001 RSI: 0002 RDI: 
> > 97032bb0
> > [0.390627] RBP: 888e1738 R08: 0032 R09: 
> > 0032
> > [0.390628] R10: 888e19cc3840 R11: 000344e0 R12: 
> > 0100
> > [0.390628] R13: 0001 R14: 888e168fba08 R15: 
> > 888e168fba10
> > [0.390629] FS:  ()
> > GS:888e1f30() 
> > knlGS:
> > [0.390629] CS:  0010 DS:  ES:  CR0: 80050033
> > [0.390630] CR2: 7f7dd01c6914 CR3: 3da0a001 CR4: 
> > 000606e0
> > [0.390630] Call Trace:
> > [0.390633]  i915_audio_component_get_eld+0x43/0xe0
> > [0.390635]  hdmi_present_sense+0x95/0x330
> > [0.390636]  generic_hdmi_build_controls+0x143/0x1e0
> > [0.390638]  snd_hda_codec_build_controls+0x178/0x1c0
> > [0.390639]  ? snd_hda_codec_build_pcms+0x14f/0x1a0
> > [0.390641]  hda_codec_driver_probe+0x76/0x100
> > [0.390644]  driver_probe_device+0x27d/0x310
> > [0.390645]  ? __driver_attach+0xa0/0xa0
> > [0.390646]  bus_for_each_drv+0x50/0x80
> > [0.390647]  __device_attach+0xb0/0x110
> > [0.390649]  bus_probe_device+0x82/0x90
> > [0.390650]  device_add+0x2dc/0x570
> > [0.390652]  snd_hdac_device_register+0xd/0x40
> > [0.390654]  snd_hda_codec_configure+0x32/0x120
> > [0.390655]  azx_codec_configure+0x2a/0x60
> > [0.390656]  azx_probe_work+0x40c/0x860
> > [0.390659]  process_one_work+0x1d2/0x3c0
> > [0.390660]  worker_thread+0x42/0x3e0
> > [0.390661]  kthread+0xf0/0x130
> > [0.390663]  ? trace_event_raw_event_workqueue_work+0x80/0x80
> > [0.390664]  ? kthread_create_worker_on_cpu+0x40/0x40
> > [0.390665]  ? call_usermodehelper_exec_async+0x11c/0x120
> > [    0.390667]  ret_from_fork+0x1f/0x30
> > [0.390668] Code: 83 c2 01 39 d1 7f e0 31 c0 c3 83 78 70 0b 74
> > f9
> > 31 
> > c0 85 d2 74 cb eb f1 48 c7 c6 d0 c0 df 96 48 c7 c7 57 dd db 96 e8
> > 9c
> > 2d 
> > bf ff <0f> ff 31 c0 c3 0f 1f 80 00 00 00 00 41 57 4d 89 c7 41 56 49
> > 89
> > [0.390679] ---[ end trace 9a14f34c58dc94ff ]---
> > 
> > 
> > Thanks,
> > --
> > Jaswinder Singh Rajput
> > 

[PATCH] mailbox: mailbox-test: avoid reading iomem twice

[jaswinder . singh]

From: Jassi Brar 

Don't pass mmio region as source to print_hex_dump() and then
again to memcpy_fromio(). Do it once and give print_hex_dump()
the buffer we just read the data in.

Signed-off-by: Jassi Brar 
---
 drivers/mailbox/mailbox-test.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
index f82dc89..684ae17 100644
--- a/drivers/mailbox/mailbox-test.c
+++ b/drivers/mailbox/mailbox-test.c
@@ -221,11 +221,10 @@ static void mbox_test_receive_message(struct mbox_client 
*client, void *message)
 
spin_lock_irqsave(>lock, flags);
if (tdev->mmio) {
+   memcpy_fromio(tdev->rx_buffer, tdev->mmio, MBOX_MAX_MSG_LEN);
print_hex_dump(KERN_INFO, "Client: Received [MMIO]: ",
   DUMP_PREFIX_ADDRESS, MBOX_BYTES_PER_LINE, 1,
-  __io_virt(tdev->mmio), MBOX_MAX_MSG_LEN, true);
-   memcpy_fromio(tdev->rx_buffer, tdev->mmio, MBOX_MAX_MSG_LEN);
-
+  tdev->rx_buffer, MBOX_MAX_MSG_LEN, true);
} else if (message) {
print_hex_dump(KERN_INFO, "Client: Received [API]: ",
   DUMP_PREFIX_ADDRESS, MBOX_BYTES_PER_LINE, 1,
-- 
1.9.1

--
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] mailbox: mailbox-test: avoid reading iomem twice

[jaswinder . singh]

From: Jassi Brar 

Don't pass mmio region as source to print_hex_dump() and then
again to memcpy_fromio(). Do it once and give print_hex_dump()
the buffer we just read the data in.

Signed-off-by: Jassi Brar 
---
 drivers/mailbox/mailbox-test.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
index f82dc89..684ae17 100644
--- a/drivers/mailbox/mailbox-test.c
+++ b/drivers/mailbox/mailbox-test.c
@@ -221,11 +221,10 @@ static void mbox_test_receive_message(struct mbox_client 
*client, void *message)
 
spin_lock_irqsave(>lock, flags);
if (tdev->mmio) {
+   memcpy_fromio(tdev->rx_buffer, tdev->mmio, MBOX_MAX_MSG_LEN);
print_hex_dump(KERN_INFO, "Client: Received [MMIO]: ",
   DUMP_PREFIX_ADDRESS, MBOX_BYTES_PER_LINE, 1,
-  __io_virt(tdev->mmio), MBOX_MAX_MSG_LEN, true);
-   memcpy_fromio(tdev->rx_buffer, tdev->mmio, MBOX_MAX_MSG_LEN);
-
+  tdev->rx_buffer, MBOX_MAX_MSG_LEN, true);
} else if (message) {
print_hex_dump(KERN_INFO, "Client: Received [API]: ",
   DUMP_PREFIX_ADDRESS, MBOX_BYTES_PER_LINE, 1,
-- 
1.9.1

--
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: OT: Open letter to the Linux World

[Jaswinder Singh]

Hello,

On Wed, Aug 13, 2014 at 1:08 AM, Christopher Barry
 wrote:
>
>
> What is intelligence? Not exactly the spook kind, but rather what is
> the definition of intelligence in humans? This is pretty good:
> http://en.wikipedia.org/wiki/Intelligence#Definitions
>

Do you want to see bigger picture ?

Ideal intelligent application software:
1. Software which can automatically add/modify/delete functions.
2. Software which can automatically fix bugs.

Ideal intelligent operating software:
1. Software which can automatically add/modify/delete hardware.
2. Software which can automatically add/modify/delete drivers.
3. Software which can automatically add/modify/delete service packs.
4. Software which can automatically add/modify/delete functions.
5. Software which can automatically fix bugs.

Thanks,
--
Jaswinder Singh.
--
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: OT: Open letter to the Linux World

[Jaswinder Singh]

Hello,

On Wed, Aug 13, 2014 at 1:08 AM, Christopher Barry
christopher.r.ba...@gmail.com wrote:


 What is intelligence? Not exactly the spook kind, but rather what is
 the definition of intelligence in humans? This is pretty good:
 http://en.wikipedia.org/wiki/Intelligence#Definitions


Do you want to see bigger picture ?

Ideal intelligent application software:
1. Software which can automatically add/modify/delete functions.
2. Software which can automatically fix bugs.

Ideal intelligent operating software:
1. Software which can automatically add/modify/delete hardware.
2. Software which can automatically add/modify/delete drivers.
3. Software which can automatically add/modify/delete service packs.
4. Software which can automatically add/modify/delete functions.
5. Software which can automatically fix bugs.

Thanks,
--
Jaswinder Singh.
--
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 1/3] mailbox: rename pl320-ipc specific mailbox.h

[jaswinder . singh]

From: Suman Anna 

The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.

Signed-off-by: Suman Anna 
Cc: Mark Langsdorf 
Cc: Rafael J. Wysocki 
---
 drivers/cpufreq/highbank-cpufreq.c   |2 +-
 drivers/mailbox/pl320-ipc.c  |2 +-
 include/linux/{mailbox.h => pl320-ipc.h} |0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename include/linux/{mailbox.h => pl320-ipc.h} (100%)

diff --git a/drivers/cpufreq/highbank-cpufreq.c 
b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..3118b87 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #define HB_CPUFREQ_CHANGE_NOTE 0x8001
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cba..f3755e0 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #define IPCMxSOURCE(m) ((m) * 0x40)
 #define IPCMxDSET(m)   (((m) * 0x40) + 0x004)
diff --git a/include/linux/mailbox.h b/include/linux/pl320-ipc.h
similarity index 100%
rename from include/linux/mailbox.h
rename to include/linux/pl320-ipc.h
-- 
1.7.10.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 1/3] mailbox: rename pl320-ipc specific mailbox.h

[jaswinder . singh]

From: Suman Anna s-a...@ti.com

The patch 30058677 ARM / highbank: add support for pl320 IPC
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.

Signed-off-by: Suman Anna s-a...@ti.com
Cc: Mark Langsdorf mark.langsd...@calxeda.com
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
 drivers/cpufreq/highbank-cpufreq.c   |2 +-
 drivers/mailbox/pl320-ipc.c  |2 +-
 include/linux/{mailbox.h = pl320-ipc.h} |0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename include/linux/{mailbox.h = pl320-ipc.h} (100%)

diff --git a/drivers/cpufreq/highbank-cpufreq.c 
b/drivers/cpufreq/highbank-cpufreq.c
index b61b5a3..3118b87 100644
--- a/drivers/cpufreq/highbank-cpufreq.c
+++ b/drivers/cpufreq/highbank-cpufreq.c
@@ -19,7 +19,7 @@
 #include linux/cpu.h
 #include linux/err.h
 #include linux/of.h
-#include linux/mailbox.h
+#include linux/pl320-ipc.h
 #include linux/platform_device.h
 
 #define HB_CPUFREQ_CHANGE_NOTE 0x8001
diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cba..f3755e0 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -26,7 +26,7 @@
 #include linux/device.h
 #include linux/amba/bus.h
 
-#include linux/mailbox.h
+#include linux/pl320-ipc.h
 
 #define IPCMxSOURCE(m) ((m) * 0x40)
 #define IPCMxDSET(m)   (((m) * 0x40) + 0x004)
diff --git a/include/linux/mailbox.h b/include/linux/pl320-ipc.h
similarity index 100%
rename from include/linux/mailbox.h
rename to include/linux/pl320-ipc.h
-- 
1.7.10.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 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

hello Juergen,

On 12/20/07, Juergen Beisert <[EMAIL PROTECTED]> wrote:
> On Thursday 20 December 2007 13:45, Jaswinder Singh wrote:
> > So I am curious, if possible, user can switch softirq-threads or IRQs
> > RT tasks to non-RT tasks for slow hardware or least important hardware
> > for NON-RT tasks. So this will improve RT behaviour.
> ^^
> Why?
>
> IMHO: Simply decrease the RT priority of less important IRQs or increase all
> other more important IRQs. IRQs are always more important than other
> processes in a system, also in non RT systems.
>

In RT Kernel we have :-
RT Tasks and Non-RT tasks.

So we can also support :-
RT softirq-threads/IRQs and non-RT softirq-threads/IRQs

So RT softirq-threads/IRQs for RT Tasks
and non-RT softirq-threads/IRQs for non-RT Tasks.

OR also remove Non-RT tasks from RT Kernel and simply decrease the RT
priority of less important task as per your suggestions.

Thank you,

Jaswinder Singh.

> Juergen
> --
> Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
>  Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
>  Vertretung Sued/Muenchen, Germany
>Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

Hello Remy,

On 12/20/07, Remy Bohmer <[EMAIL PROTECTED]> wrote:
> So, Is this a serious requirement? Should this be possible?

I have noticed this problem:
[EMAIL PROTECTED]:~# cat /proc/loadavgrt
1.00 1.00 1.00 0/52 1158
[EMAIL PROTECTED]:~# cat /proc/loadavg
0.00 0.00 0.02 1/52 1159
[EMAIL PROTECTED]:~#

So I am curious, if possible, user can switch softirq-threads or IRQs
RT tasks to non-RT tasks for slow hardware or least important hardware
for NON-RT tasks. So this will improve RT behaviour.

By default, all softirq-threads or IRQs will be RT task but if there
is some option user can switch it to NON-RT task then it will be good.

Thank you,

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

Re: [patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

[Jaswinder Singh]

On 12/20/07, Remy Bohmer <[EMAIL PROTECTED]> wrote:
>   struct task_struct  *thread;
> + int rt_prio;
>   wait_queue_head_t   wait_for_handler;

int rt_prio or unsigned int rt_prio, which one is better.

Thank you,

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

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

On 12/20/07, Remy Bohmer <[EMAIL PROTECTED]> wrote:
> The RT-patch originally creates all its softirq-threads at
> priority 50.

Is it possible to run softirq-threads or IRQs as a non-realtime tasks
in RT kernel.

If yes, then how.

Thank you,

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

Re: [PATCH 1/3] x86: fix kprobe_handler reenable preemption

[Jaswinder Singh]

v2.6.25 or v2.6.24 ?

On Dec 20, 2007 2:45 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
>
> > Fix a preemption bug in kprobe_handler(). It has to call
> > preempt_enable() before returning.
>
> thanks - i've applied all 3 kprobes patches from you. (for v2.6.25)
>
>Ingo
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] x86: fix kprobe_handler reenable preemption

[Jaswinder Singh]

v2.6.25 or v2.6.24 ?

On Dec 20, 2007 2:45 PM, Ingo Molnar [EMAIL PROTECTED] wrote:

 * Masami Hiramatsu [EMAIL PROTECTED] wrote:

  Fix a preemption bug in kprobe_handler(). It has to call
  preempt_enable() before returning.

 thanks - i've applied all 3 kprobes patches from you. (for v2.6.25)

Ingo

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

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

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

On 12/20/07, Remy Bohmer [EMAIL PROTECTED] wrote:
 The RT-patch originally creates all its softirq-threads at
 priority 50.

Is it possible to run softirq-threads or IRQs as a non-realtime tasks
in RT kernel.

If yes, then how.

Thank you,

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

Re: [patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

[Jaswinder Singh]

On 12/20/07, Remy Bohmer [EMAIL PROTECTED] wrote:
   struct task_struct  *thread;
 + int rt_prio;
   wait_queue_head_t   wait_for_handler;

int rt_prio or unsigned int rt_prio, which one is better.

Thank you,

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

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

Hello Remy,

On 12/20/07, Remy Bohmer [EMAIL PROTECTED] wrote:
 So, Is this a serious requirement? Should this be possible?

I have noticed this problem:
[EMAIL PROTECTED]:~# cat /proc/loadavgrt
1.00 1.00 1.00 0/52 1158
[EMAIL PROTECTED]:~# cat /proc/loadavg
0.00 0.00 0.02 1/52 1159
[EMAIL PROTECTED]:~#

So I am curious, if possible, user can switch softirq-threads or IRQs
RT tasks to non-RT tasks for slow hardware or least important hardware
for NON-RT tasks. So this will improve RT behaviour.

By default, all softirq-threads or IRQs will be RT task but if there
is some option user can switch it to NON-RT task then it will be good.

Thank you,

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

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

[Jaswinder Singh]

hello Juergen,

On 12/20/07, Juergen Beisert [EMAIL PROTECTED] wrote:
 On Thursday 20 December 2007 13:45, Jaswinder Singh wrote:
  So I am curious, if possible, user can switch softirq-threads or IRQs
  RT tasks to non-RT tasks for slow hardware or least important hardware
  for NON-RT tasks. So this will improve RT behaviour.
 ^^
 Why?

 IMHO: Simply decrease the RT priority of less important IRQs or increase all
 other more important IRQs. IRQs are always more important than other
 processes in a system, also in non RT systems.


In RT Kernel we have :-
RT Tasks and Non-RT tasks.

So we can also support :-
RT softirq-threads/IRQs and non-RT softirq-threads/IRQs

So RT softirq-threads/IRQs for RT Tasks
and non-RT softirq-threads/IRQs for non-RT Tasks.

OR also remove Non-RT tasks from RT Kernel and simply decrease the RT
priority of less important task as per your suggestions.

Thank you,

Jaswinder Singh.

 Juergen
 --
 Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
  Pengutronix - Linux Solutions for Science and Industry
 Handelsregister: Amtsgericht Hildesheim, HRA 2686
  Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 |  Fax: +49-5121-206917-9

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

Re: [PATCH] Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

We have two options:

1. Either move arch/s390/crypto/Kconfig to drivers/crypto/Kconfig

OR

2. In arch/s390/crypto/Kconfig , replace "depends on S390" to "depends
on CRYPRO_HW"

I think 2nd option is better for everyone.

Thank you,

Jaswinder Singh.

On 11/30/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
> > > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > > > index 1330061..b699ed5 100644
> > > > --- a/arch/s390/Kconfig
> > > > +++ b/arch/s390/Kconfig
> > > > @@ -537,4 +537,6 @@ source "security/Kconfig"
> > > >
> > > >  source "crypto/Kconfig"
> > > >
> > > > +source "arch/s390/crypto/Kconfig"
> > > > +
> > >
> > > With this there's no dependency on CRYPTO_HW anymore.
> > >
> >
> > Anyhow "if CRYPTO_HW" is not working in drivers/crypto/Kconfig
> >
> > have you tested this patch on S390. Is this giving errors ?
> >
> > And you can also add depends with CRYPTO_HW in arch/s390/crypto/Kconfig
>
> Jan just created a patch which moves everything from
> arch/s390/crypto/Kconfig
> to drivers/crypto/Kconfig. Probably will be merged during the 2.6.25 merge
> window.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

On 11/30/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 30, 2007 at 04:33:19PM +0530, Jaswinder Singh wrote:
> > This patch fixes s390 dependency for x86
> >
> > Signed-off-by: Jaswinder Singh <[EMAIL PROTECTED]>
>
> Deleting random parts of the kernel tree is actually not
> supported.
>

I agree with you. I just did this to same some space because I keep
many kernel trees.

But i am curious if other arch do not depends on x86 then s390 ?

> > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> > index 1330061..b699ed5 100644
> > --- a/arch/s390/Kconfig
> > +++ b/arch/s390/Kconfig
> > @@ -537,4 +537,6 @@ source "security/Kconfig"
> >
> >  source "crypto/Kconfig"
> >
> > +source "arch/s390/crypto/Kconfig"
> > +
>
> With this there's no dependency on CRYPTO_HW anymore.
>

Anyhow "if CRYPTO_HW" is not working in drivers/crypto/Kconfig

have you tested this patch on S390. Is this giving errors ?

And you can also add depends with CRYPTO_HW in arch/s390/crypto/Kconfig

Thank you,

Jaswinder Singh.


> > +#ifdef CONFIG_S390
> >  #include "../arch/s390/appldata/appldata.h"
> > +#endif
>
> This include can go away.
>
> Since this pops up again and again we'll come up with a patch to fix this.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

Yes, what is the use of keeping other arch, if I am not going to build those.

Thank you,

Jaswinder Singh.

On 11/30/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 30, 2007 at 01:44:56PM +0530, Jaswinder Singh wrote:
> > 2.6.24-rc3 git kernel's x86 make depends on s390 arch:
> >
> > 1.   HOSTLD  scripts/kconfig/conf
> > scripts/kconfig/conf -s arch/x86/Kconfig
> > drivers/crypto/Kconfig:51: can't open file "arch/s390/crypto/Kconfig"
> > make[2]: *** [silentoldconfig] Error 1
> > make[1]: *** [silentoldconfig] Error 2
> >
> > 2.  CC  kernel/sysctl_check.o
> > kernel/sysctl_check.c:3:44: error: ../arch/s390/appldata/appldata.h:
> > No such file or directory
> > make[1]: *** [kernel/sysctl_check.o] Error 1
> > make: *** [kernel] Error 2
>
> Could it be that you deleted half of the kernel tree? In specific
> arch/[everything besides x86]*/ ?
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

This patch fixes s390 dependency for x86

Signed-off-by: Jaswinder Singh <[EMAIL PROTECTED]>


diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 1330061..b699ed5 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -537,4 +537,6 @@ source "security/Kconfig"

 source "crypto/Kconfig"

+source "arch/s390/crypto/Kconfig"
+
 source "lib/Kconfig"
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 5fd6688..5c2c7eb 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -48,8 +48,6 @@ config CRYPTO_DEV_PADLOCK_SHA
  If unsure say M. The compiled module will be
  called padlock-sha.ko

-source "arch/s390/crypto/Kconfig"
-
 config CRYPTO_DEV_GEODE
tristate "Support for the Geode LX AES engine"
depends on X86_32 && PCI
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 6972f26..529be08 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -1,6 +1,8 @@
 #include 
 #include 
+#ifdef CONFIG_S390
 #include "../arch/s390/appldata/appldata.h"
+#endif
 #include "../fs/xfs/linux-2.6/xfs_sysctl.h"
 #include 
 #include 


On 11/30/07, Jaswinder Singh <[EMAIL PROTECTED]> wrote:
> 2.6.24-rc3 git kernel's x86 make depends on s390 arch:
>
> 1.   HOSTLD  scripts/kconfig/conf
> scripts/kconfig/conf -s arch/x86/Kconfig
> drivers/crypto/Kconfig:51: can't open file "arch/s390/crypto/Kconfig"
> make[2]: *** [silentoldconfig] Error 1
> make[1]: *** [silentoldconfig] Error 2
>
> 2.  CC  kernel/sysctl_check.o
> kernel/sysctl_check.c:3:44: error: ../arch/s390/appldata/appldata.h:
> No such file or directory
> make[1]: *** [kernel/sysctl_check.o] Error 1
> make: *** [kernel] Error 2
>
> Thank you,
>
> Jaswinder Singh.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[WARNINGS] 2.6.24-rc3 x86 make

[Jaswinder Singh]

2.6.24-rc3 git kernel's x86 make warnings:

1.   CC  fs/partitions/check.o
fs/partitions/check.c: In function 'add_partition':
fs/partitions/check.c:393: warning: ignoring return value of
'kobject_add', declared with attribute warn_unused_result
fs/partitions/check.c:396: warning: ignoring return value of
'sysfs_create_link', declared with attribute warn_unused_result
fs/partitions/check.c:403: warning: ignoring return value of
'sysfs_create_file', declared with attribute warn_unused_result
  CC  fs/partitions/ldm.o

2.  CC  drivers/pci/search.o
drivers/pci/search.c: In function 'pci_find_slot':
drivers/pci/search.c:135: warning: 'pci_find_device' is deprecated
(declared at include/linux/pci.h:492)
drivers/pci/search.c: At top level:
drivers/pci/search.c:478: warning: 'pci_find_device' is deprecated
(declared at drivers/pci/search.c:283)
drivers/pci/search.c:478: warning: 'pci_find_device' is deprecated
(declared at drivers/pci/search.c:283)
drivers/pci/search.c:479: warning: 'pci_find_slot' is deprecated
(declared at drivers/pci/search.c:132)
drivers/pci/search.c:479: warning: 'pci_find_slot' is deprecated
(declared at drivers/pci/search.c:132)
  CC  drivers/pci/pci-sysfs.o

3.  CC  sound/pci/ac97/ac97_codec.o
sound/pci/ac97/ac97_patch.h:86: warning: 'snd_ac97_restore_status'
declared 'static' but never defined
sound/pci/ac97/ac97_patch.h:87: warning: 'snd_ac97_restore_iec958'
declared 'static' but never defined
  CC  sound/pci/ac97/ac97_pcm.o

Thank you,

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

[BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

2.6.24-rc3 git kernel's x86 make depends on s390 arch:

1.   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -s arch/x86/Kconfig
drivers/crypto/Kconfig:51: can't open file "arch/s390/crypto/Kconfig"
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2

2.  CC  kernel/sysctl_check.o
kernel/sysctl_check.c:3:44: error: ../arch/s390/appldata/appldata.h:
No such file or directory
make[1]: *** [kernel/sysctl_check.o] Error 1
make: *** [kernel] Error 2

Thank you,

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

[WARNINGS] 2.6.24-rc3 x86 make

[Jaswinder Singh]

2.6.24-rc3 git kernel's x86 make warnings:

1.   CC  fs/partitions/check.o
fs/partitions/check.c: In function 'add_partition':
fs/partitions/check.c:393: warning: ignoring return value of
'kobject_add', declared with attribute warn_unused_result
fs/partitions/check.c:396: warning: ignoring return value of
'sysfs_create_link', declared with attribute warn_unused_result
fs/partitions/check.c:403: warning: ignoring return value of
'sysfs_create_file', declared with attribute warn_unused_result
  CC  fs/partitions/ldm.o

2.  CC  drivers/pci/search.o
drivers/pci/search.c: In function 'pci_find_slot':
drivers/pci/search.c:135: warning: 'pci_find_device' is deprecated
(declared at include/linux/pci.h:492)
drivers/pci/search.c: At top level:
drivers/pci/search.c:478: warning: 'pci_find_device' is deprecated
(declared at drivers/pci/search.c:283)
drivers/pci/search.c:478: warning: 'pci_find_device' is deprecated
(declared at drivers/pci/search.c:283)
drivers/pci/search.c:479: warning: 'pci_find_slot' is deprecated
(declared at drivers/pci/search.c:132)
drivers/pci/search.c:479: warning: 'pci_find_slot' is deprecated
(declared at drivers/pci/search.c:132)
  CC  drivers/pci/pci-sysfs.o

3.  CC  sound/pci/ac97/ac97_codec.o
sound/pci/ac97/ac97_patch.h:86: warning: 'snd_ac97_restore_status'
declared 'static' but never defined
sound/pci/ac97/ac97_patch.h:87: warning: 'snd_ac97_restore_iec958'
declared 'static' but never defined
  CC  sound/pci/ac97/ac97_pcm.o

Thank you,

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

Re: [PATCH] Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

We have two options:

1. Either move arch/s390/crypto/Kconfig to drivers/crypto/Kconfig

OR

2. In arch/s390/crypto/Kconfig , replace depends on S390 to depends
on CRYPRO_HW

I think 2nd option is better for everyone.

Thank you,

Jaswinder Singh.

On 11/30/07, Heiko Carstens [EMAIL PROTECTED] wrote:
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 1330061..b699ed5 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -537,4 +537,6 @@ source security/Kconfig
   
 source crypto/Kconfig
   
+source arch/s390/crypto/Kconfig
+
  
   With this there's no dependency on CRYPTO_HW anymore.
  
 
  Anyhow if CRYPTO_HW is not working in drivers/crypto/Kconfig
 
  have you tested this patch on S390. Is this giving errors ?
 
  And you can also add depends with CRYPTO_HW in arch/s390/crypto/Kconfig

 Jan just created a patch which moves everything from
 arch/s390/crypto/Kconfig
 to drivers/crypto/Kconfig. Probably will be merged during the 2.6.25 merge
 window.

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

Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

Yes, what is the use of keeping other arch, if I am not going to build those.

Thank you,

Jaswinder Singh.

On 11/30/07, Heiko Carstens [EMAIL PROTECTED] wrote:
 On Fri, Nov 30, 2007 at 01:44:56PM +0530, Jaswinder Singh wrote:
  2.6.24-rc3 git kernel's x86 make depends on s390 arch:
 
  1.   HOSTLD  scripts/kconfig/conf
  scripts/kconfig/conf -s arch/x86/Kconfig
  drivers/crypto/Kconfig:51: can't open file arch/s390/crypto/Kconfig
  make[2]: *** [silentoldconfig] Error 1
  make[1]: *** [silentoldconfig] Error 2
 
  2.  CC  kernel/sysctl_check.o
  kernel/sysctl_check.c:3:44: error: ../arch/s390/appldata/appldata.h:
  No such file or directory
  make[1]: *** [kernel/sysctl_check.o] Error 1
  make: *** [kernel] Error 2

 Could it be that you deleted half of the kernel tree? In specific
 arch/[everything besides x86]*/ ?

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

[BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

2.6.24-rc3 git kernel's x86 make depends on s390 arch:

1.   HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf -s arch/x86/Kconfig
drivers/crypto/Kconfig:51: can't open file arch/s390/crypto/Kconfig
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2

2.  CC  kernel/sysctl_check.o
kernel/sysctl_check.c:3:44: error: ../arch/s390/appldata/appldata.h:
No such file or directory
make[1]: *** [kernel/sysctl_check.o] Error 1
make: *** [kernel] Error 2

Thank you,

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

[PATCH] Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

This patch fixes s390 dependency for x86

Signed-off-by: Jaswinder Singh [EMAIL PROTECTED]


diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 1330061..b699ed5 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -537,4 +537,6 @@ source security/Kconfig

 source crypto/Kconfig

+source arch/s390/crypto/Kconfig
+
 source lib/Kconfig
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 5fd6688..5c2c7eb 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -48,8 +48,6 @@ config CRYPTO_DEV_PADLOCK_SHA
  If unsure say M. The compiled module will be
  called padlock-sha.ko

-source arch/s390/crypto/Kconfig
-
 config CRYPTO_DEV_GEODE
tristate Support for the Geode LX AES engine
depends on X86_32  PCI
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 6972f26..529be08 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -1,6 +1,8 @@
 #include linux/stat.h
 #include linux/sysctl.h
+#ifdef CONFIG_S390
 #include ../arch/s390/appldata/appldata.h
+#endif
 #include ../fs/xfs/linux-2.6/xfs_sysctl.h
 #include linux/sunrpc/debug.h
 #include linux/string.h


On 11/30/07, Jaswinder Singh [EMAIL PROTECTED] wrote:
 2.6.24-rc3 git kernel's x86 make depends on s390 arch:

 1.   HOSTLD  scripts/kconfig/conf
 scripts/kconfig/conf -s arch/x86/Kconfig
 drivers/crypto/Kconfig:51: can't open file arch/s390/crypto/Kconfig
 make[2]: *** [silentoldconfig] Error 1
 make[1]: *** [silentoldconfig] Error 2

 2.  CC  kernel/sysctl_check.o
 kernel/sysctl_check.c:3:44: error: ../arch/s390/appldata/appldata.h:
 No such file or directory
 make[1]: *** [kernel/sysctl_check.o] Error 1
 make: *** [kernel] Error 2

 Thank you,

 Jaswinder Singh.

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

Re: [PATCH] Re: [BUG] 2.6.24-rc3 x86 make depends on s390 arch

[Jaswinder Singh]

On 11/30/07, Heiko Carstens [EMAIL PROTECTED] wrote:
 On Fri, Nov 30, 2007 at 04:33:19PM +0530, Jaswinder Singh wrote:
  This patch fixes s390 dependency for x86
 
  Signed-off-by: Jaswinder Singh [EMAIL PROTECTED]

 Deleting random parts of the kernel tree is actually not
 supported.


I agree with you. I just did this to same some space because I keep
many kernel trees.

But i am curious if other arch do not depends on x86 then s390 ?

  diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
  index 1330061..b699ed5 100644
  --- a/arch/s390/Kconfig
  +++ b/arch/s390/Kconfig
  @@ -537,4 +537,6 @@ source security/Kconfig
 
   source crypto/Kconfig
 
  +source arch/s390/crypto/Kconfig
  +

 With this there's no dependency on CRYPTO_HW anymore.


Anyhow if CRYPTO_HW is not working in drivers/crypto/Kconfig

have you tested this patch on S390. Is this giving errors ?

And you can also add depends with CRYPTO_HW in arch/s390/crypto/Kconfig

Thank you,

Jaswinder Singh.


  +#ifdef CONFIG_S390
   #include ../arch/s390/appldata/appldata.h
  +#endif

 This include can go away.

 Since this pops up again and again we'll come up with a patch to fix this.

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

Re: [2.6.23-rt3] NMI watchdog trace of deadlock

[Jaswinder Singh]

Hello Ingo,

On 10/27/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> it's not atomic interrupt context but irq thread context - and -rt
> remaps kmap_atomic() to kmap() internally.
>
> the problem seems to be what Mike's patch works around: fiddling with
> irq flags in the ntfs code. That fiddling seems quite unnecessary at
> first sight.
>

Is this a nice idea to go inside device drivers and filesystem and
make changes in kernel source code to enable RT.

RT related change should be in header files, so that we don't need to
make changes for drivers or filesystem source files.

And when user will disable RT then these patches will again make problems.

We need to find some better alternative.

Thank you,

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

Re: [2.6.23-rt3] NMI watchdog trace of deadlock

[Jaswinder Singh]

Hello Ingo,

On 10/27/07, Ingo Molnar [EMAIL PROTECTED] wrote:

 it's not atomic interrupt context but irq thread context - and -rt
 remaps kmap_atomic() to kmap() internally.

 the problem seems to be what Mike's patch works around: fiddling with
 irq flags in the ntfs code. That fiddling seems quite unnecessary at
 first sight.


Is this a nice idea to go inside device drivers and filesystem and
make changes in kernel source code to enable RT.

RT related change should be in header files, so that we don't need to
make changes for drivers or filesystem source files.

And when user will disable RT then these patches will again make problems.

We need to find some better alternative.

Thank you,

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

Interrupt Latency test for intel machine

[Jaswinder Singh]

Hello all,

On my Intel Pentium 4 CPU 2.40 GHz machine by using attached file, I
am getting Interrupt latency as follows :-

Configuration   MAX (us)MIN (us)AVG (us)
 Samples
-   
  -
PREEMPT-NONE43.576  4.190   4.190   119343

Voluntary PREEMPT   44.414  4.190   4.190   108694

PREEMPT low-latency 39.398  4.190   5.028   112717

Thank you,

Jaswinder Singh.
/*
 * Interrupt latency test module
 *
 * (C) 2007 Jaswinder Singh <[EMAIL PROTECTED]>
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public Licence Version
 * 2 as published by the Free Software Foundation.
 *
 */

#include 
#include 
#include 
#include 

//#define DBG_IRQ_LAT		/* debug interrupt latency test */

/* getting global time from 8254 */
#define READ_CNT0(var) do {var = inb(0x40); var |= (inb(0x40) << 8);} while (0)

#ifdef DBG_IRQ_LAT
#define TEST_CNT	1000
static long lat_val[TEST_CNT + 1];
static long lat_val_num;
#endif

static volatile long count_c0;

static long lat_max = 0;
static long lat_min = 1;
static unsigned long irq_cnt = 0;
static unsigned long lat_avg = 0;

static void irq_lat_hdr(void)
{
	READ_CNT0(count_c0);
	count_c0 = (LATCH - count_c0);
	if (count_c0 > lat_max)
		lat_max = count_c0;
	if (count_c0 < lat_min)
		lat_min = count_c0;
	lat_avg = lat_avg + count_c0;
	irq_cnt++;

#ifdef DBG_IRQ_LAT
	if (irq_cnt <= TEST_CNT)
	{
		lat_val[irq_cnt] = count_c0;
	}
#endif
}

static int __init irq_lat_init(void)
{
	printk("*\n");
	printk("*  Interrupt Latency module loaded  *\n");
	printk("* When you remove this module you   *\n");
	printk("* will get interrupt latency result *\n");
	printk("*\n");

	irq_lat_ptr = irq_lat_hdr;	/* Install interrupt handler */

	return 0;
}

static void __exit irq_lat_exit(void)
{
	unsigned long nanosecs = 10;

	irq_lat_ptr = NULL;		/* Uninstall interrupt handler */

	nanosecs = (nanosecs/CLOCK_TICK_RATE);
	
	printk("Interrupt Latency result\n");
	printk("\n");

	if (lat_avg)
		lat_avg = lat_avg/irq_cnt;
	else
	{
		printk("Interrupt Latency test Failed\n");
		printk("send info to <[EMAIL PROTECTED]>\n");
		return;
	}

#ifdef DBG_IRQ_LAT
	if (irq_cnt < TEST_CNT)
		lat_val_num = irq_cnt;
	else
		lat_val_num = TEST_CNT;
	for (count_c0 = 1; count_c0 <= lat_val_num; count_c0++)
	{
		printk("%4lu: %6lu  ", count_c0, lat_val[count_c0]);
		if ((count_c0 % 5) == 0)
			printk("\n");
	}

	printk("\nCLOCK_TICK_RATE: %d TICK: %lu LATCH: %d\n", CLOCK_TICK_RATE, nanosecs, LATCH);
	printk("MAX latency : %lu ticks\n", lat_max);
	printk("MIN latency : %lu ticks\n", lat_min);
	printk("AVG latency : %lu ticks\n", lat_avg);
#endif
	printk("MAX latency : %5lu.%03lu micro-seconds\n", (nanosecs * lat_max)/1000, (nanosecs * lat_max) % 1000);
	printk("MIN latency : %5lu.%03lu micro-seconds\n", (nanosecs * lat_min)/1000, (nanosecs * lat_min) % 1000);
	printk("AVG latency : %5lu.%03lu micro-seconds\n", (nanosecs * lat_avg)/1000, (nanosecs * lat_avg) % 1000);
	printk("Total Samples : %lu\n", irq_cnt);
}

module_init(irq_lat_init);
module_exit(irq_lat_exit);

MODULE_LICENSE("GPL");
diff -Naur linux-2.3.23-org/arch/i386/kernel/time.c linux-2.3.23/arch/i386/kernel/time.c
--- linux-2.3.23-org/arch/i386/kernel/time.c	2007-10-26 19:16:38.0 +0530
+++ linux-2.3.23/arch/i386/kernel/time.c	2007-10-26 19:17:49.0 +0530
@@ -150,6 +150,10 @@
 }
 EXPORT_SYMBOL(profile_pc);
 
+/* Interrupt latency pointer */
+irqlatptr irq_lat_ptr = NULL;
+EXPORT_SYMBOL(irq_lat_ptr);
+
 /*
  * This is the same as the above, except we _also_ save the current
  * Time Stamp Counter value at the time of the timer interrupt, so that
@@ -173,6 +177,10 @@
 	}
 #endif
 
+	/* Interrupt latency pointer */
+	if (irq_lat_ptr)
+		irq_lat_ptr();
+
 	do_timer_interrupt_hook();
 
 	if (MCA_bus) {
diff -Naur linux-2.3.23-org/include/asm-i386/time.h linux-2.3.23/include/asm-i386/time.h
--- linux-2.3.23-org/include/asm-i386/time.h	2007-10-26 19:16:38.0 +0530
+++ linux-2.3.23/include/asm-i386/time.h	2007-10-26 19:18:10.0 +0530
@@ -28,6 +28,10 @@
 	return retval;
 }
 
+/* interrupt latency pointer */
+typedef void (*irqlatptr)(void);
+extern irqlatptr irq_lat_ptr;
+
 extern void (*late_time_init)(void);
 extern void hpet_time_init(void);
 


Makefile
Description: Binary data

Interrupt Latency test for intel machine

[Jaswinder Singh]

Hello all,

On my Intel Pentium 4 CPU 2.40 GHz machine by using attached file, I
am getting Interrupt latency as follows :-

Configuration   MAX (us)MIN (us)AVG (us)
 Samples
-   
  -
PREEMPT-NONE43.576  4.190   4.190   119343

Voluntary PREEMPT   44.414  4.190   4.190   108694

PREEMPT low-latency 39.398  4.190   5.028   112717

Thank you,

Jaswinder Singh.
/*
 * Interrupt latency test module
 *
 * (C) 2007 Jaswinder Singh [EMAIL PROTECTED]
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public Licence Version
 * 2 as published by the Free Software Foundation.
 *
 */

#include linux/module.h
#include linux/init.h
#include linux/bcd.h
#include asm/time.h

//#define DBG_IRQ_LAT		/* debug interrupt latency test */

/* getting global time from 8254 */
#define READ_CNT0(var) do {var = inb(0x40); var |= (inb(0x40)  8);} while (0)

#ifdef DBG_IRQ_LAT
#define TEST_CNT	1000
static long lat_val[TEST_CNT + 1];
static long lat_val_num;
#endif

static volatile long count_c0;

static long lat_max = 0;
static long lat_min = 1;
static unsigned long irq_cnt = 0;
static unsigned long lat_avg = 0;

static void irq_lat_hdr(void)
{
	READ_CNT0(count_c0);
	count_c0 = (LATCH - count_c0);
	if (count_c0  lat_max)
		lat_max = count_c0;
	if (count_c0  lat_min)
		lat_min = count_c0;
	lat_avg = lat_avg + count_c0;
	irq_cnt++;

#ifdef DBG_IRQ_LAT
	if (irq_cnt = TEST_CNT)
	{
		lat_val[irq_cnt] = count_c0;
	}
#endif
}

static int __init irq_lat_init(void)
{
	printk(*\n);
	printk(*  Interrupt Latency module loaded  *\n);
	printk(* When you remove this module you   *\n);
	printk(* will get interrupt latency result *\n);
	printk(*\n);

	irq_lat_ptr = irq_lat_hdr;	/* Install interrupt handler */

	return 0;
}

static void __exit irq_lat_exit(void)
{
	unsigned long nanosecs = 10;

	irq_lat_ptr = NULL;		/* Uninstall interrupt handler */

	nanosecs = (nanosecs/CLOCK_TICK_RATE);
	
	printk(Interrupt Latency result\n);
	printk(\n);

	if (lat_avg)
		lat_avg = lat_avg/irq_cnt;
	else
	{
		printk(Interrupt Latency test Failed\n);
		printk(send info to [EMAIL PROTECTED]\n);
		return;
	}

#ifdef DBG_IRQ_LAT
	if (irq_cnt  TEST_CNT)
		lat_val_num = irq_cnt;
	else
		lat_val_num = TEST_CNT;
	for (count_c0 = 1; count_c0 = lat_val_num; count_c0++)
	{
		printk(%4lu: %6lu  , count_c0, lat_val[count_c0]);
		if ((count_c0 % 5) == 0)
			printk(\n);
	}

	printk(\nCLOCK_TICK_RATE: %d TICK: %lu LATCH: %d\n, CLOCK_TICK_RATE, nanosecs, LATCH);
	printk(MAX latency : %lu ticks\n, lat_max);
	printk(MIN latency : %lu ticks\n, lat_min);
	printk(AVG latency : %lu ticks\n, lat_avg);
#endif
	printk(MAX latency : %5lu.%03lu micro-seconds\n, (nanosecs * lat_max)/1000, (nanosecs * lat_max) % 1000);
	printk(MIN latency : %5lu.%03lu micro-seconds\n, (nanosecs * lat_min)/1000, (nanosecs * lat_min) % 1000);
	printk(AVG latency : %5lu.%03lu micro-seconds\n, (nanosecs * lat_avg)/1000, (nanosecs * lat_avg) % 1000);
	printk(Total Samples : %lu\n, irq_cnt);
}

module_init(irq_lat_init);
module_exit(irq_lat_exit);

MODULE_LICENSE(GPL);
diff -Naur linux-2.3.23-org/arch/i386/kernel/time.c linux-2.3.23/arch/i386/kernel/time.c
--- linux-2.3.23-org/arch/i386/kernel/time.c	2007-10-26 19:16:38.0 +0530
+++ linux-2.3.23/arch/i386/kernel/time.c	2007-10-26 19:17:49.0 +0530
@@ -150,6 +150,10 @@
 }
 EXPORT_SYMBOL(profile_pc);
 
+/* Interrupt latency pointer */
+irqlatptr irq_lat_ptr = NULL;
+EXPORT_SYMBOL(irq_lat_ptr);
+
 /*
  * This is the same as the above, except we _also_ save the current
  * Time Stamp Counter value at the time of the timer interrupt, so that
@@ -173,6 +177,10 @@
 	}
 #endif
 
+	/* Interrupt latency pointer */
+	if (irq_lat_ptr)
+		irq_lat_ptr();
+
 	do_timer_interrupt_hook();
 
 	if (MCA_bus) {
diff -Naur linux-2.3.23-org/include/asm-i386/time.h linux-2.3.23/include/asm-i386/time.h
--- linux-2.3.23-org/include/asm-i386/time.h	2007-10-26 19:16:38.0 +0530
+++ linux-2.3.23/include/asm-i386/time.h	2007-10-26 19:18:10.0 +0530
@@ -28,6 +28,10 @@
 	return retval;
 }
 
+/* interrupt latency pointer */
+typedef void (*irqlatptr)(void);
+extern irqlatptr irq_lat_ptr;
+
 extern void (*late_time_init)(void);
 extern void hpet_time_init(void);
 


Makefile
Description: Binary data

Re: 2.6.23-rc9-rt2

[Jaswinder Singh]

Hi Steve,

On 10/8/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> --
> On Sun, 7 Oct 2007, Jaswinder Singh wrote:
>
> > Do you have any plans to support nested or reentrant Interrupt Handling 
> > schemes.
> >
>
> Hi Jaswinder,
>
> Not sure what you mean by this, since interrupt handlers are run as
> threads and are fully preemptible.
>

I think by nested or reentrant interrupt handling technique you can
further reduce latencies.
what you think.

Can we can get guaranteed realtime throughput by using these realtime patch.

Thank you,

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

Re: 2.6.23-rc9-rt2

[Jaswinder Singh]

Hi Steve,

On 10/8/07, Steven Rostedt [EMAIL PROTECTED] wrote:

 --
 On Sun, 7 Oct 2007, Jaswinder Singh wrote:

  Do you have any plans to support nested or reentrant Interrupt Handling 
  schemes.
 

 Hi Jaswinder,

 Not sure what you mean by this, since interrupt handlers are run as
 threads and are fully preemptible.


I think by nested or reentrant interrupt handling technique you can
further reduce latencies.
what you think.

Can we can get guaranteed realtime throughput by using these realtime patch.

Thank you,

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

Re: 2.6.23-rc9-rt2

[Jaswinder Singh]

Hello Steve,

Do you have any plans to support nested or reentrant Interrupt Handling schemes.

Thank you,

Jaswinder SIngh.

On 10/5/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> We are pleased to announce the 2.6.23-rc9-rt2 tree, which can be
> downloaded from the new location:
>
>  http://www.kernel.org/pub/linux/kernel/projects/rt/
>
> Changes since 2.6.23-rc9-rt1
>
>   - x86_64 disable IST for debug (Andi Kleen)
>
>   - Better handling of dynticks going bad in RCU (Steven Rostedt)
>
>   - Preempt RCU boosting (Steven Rostedt based on Paul E. McKenney's
> stuff)
>
> Again, this still holds experimental code. But I've been running it on a
> few boxes already (and even the box I'm writing this on).
>
> to build a 2.6.23-rc9-rt2 tree, the following patches should be applied:
>
>   http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2
>   http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.23-rc9.bz2
>   http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.23-rc9-rt2.bz2
>
> The broken out patches are also available.
>
> -- Steve
>
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.23-rc9-rt2

[Jaswinder Singh]

Hello Steve,

Do you have any plans to support nested or reentrant Interrupt Handling schemes.

Thank you,

Jaswinder SIngh.

On 10/5/07, Steven Rostedt [EMAIL PROTECTED] wrote:
 We are pleased to announce the 2.6.23-rc9-rt2 tree, which can be
 downloaded from the new location:

  http://www.kernel.org/pub/linux/kernel/projects/rt/

 Changes since 2.6.23-rc9-rt1

   - x86_64 disable IST for debug (Andi Kleen)

   - Better handling of dynticks going bad in RCU (Steven Rostedt)

   - Preempt RCU boosting (Steven Rostedt based on Paul E. McKenney's
 stuff)

 Again, this still holds experimental code. But I've been running it on a
 few boxes already (and even the box I'm writing this on).

 to build a 2.6.23-rc9-rt2 tree, the following patches should be applied:

   http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.tar.bz2
   http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.23-rc9.bz2
   http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.23-rc9-rt2.bz2

 The broken out patches are also available.

 -- Steve






 -
 To unsubscribe from this list: send the line unsubscribe linux-rt-users in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: realtime preemption performance difference

[Jaswinder Singh]

hello hufey,

I am not using montavista kernel, I am using standard linux kernel.

Realtime is known by worst case latencies. Ingo and team are claiming
for realtime support so their should be some samples and performance
numbers,

Can someone please share their samples and/or numbers.

Thank you,

Jaswinder Singh.

On 9/25/07, hufey <[EMAIL PROTECTED]> wrote:
> On 9/24/07, Jaswinder Singh <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I want to check performance difference by using realtime preemption patch :
> >
> > http://www.kernel.org/pub/linux/kernel/projects/rt/
> >
> > Please let me know from where I can download samples to test realtime
> > preemption performance difference.
> >
>
> As far as I know, some embedded linux vendors such as MontaVista
> provide kernel patch to export some interfaces to measure realtime
> performance.
>
> > Can someone please share performance numbers for your hardware:-
> >
> > 1. Interrupt latency
> > 2. Task switching time
> > 3. hard-realtime scheduling latency
> >
> > Thank you,
> >
> > Jaswinder Singh.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: realtime preemption performance difference

[Jaswinder Singh]

hello hufey,

I am not using montavista kernel, I am using standard linux kernel.

Realtime is known by worst case latencies. Ingo and team are claiming
for realtime support so their should be some samples and performance
numbers,

Can someone please share their samples and/or numbers.

Thank you,

Jaswinder Singh.

On 9/25/07, hufey [EMAIL PROTECTED] wrote:
 On 9/24/07, Jaswinder Singh [EMAIL PROTECTED] wrote:
  Hi all,
 
  I want to check performance difference by using realtime preemption patch :
 
  http://www.kernel.org/pub/linux/kernel/projects/rt/
 
  Please let me know from where I can download samples to test realtime
  preemption performance difference.
 

 As far as I know, some embedded linux vendors such as MontaVista
 provide kernel patch to export some interfaces to measure realtime
 performance.

  Can someone please share performance numbers for your hardware:-
 
  1. Interrupt latency
  2. Task switching time
  3. hard-realtime scheduling latency
 
  Thank you,
 
  Jaswinder Singh.
  -
  To unsubscribe from this list: send the line unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

Dear Sam,

On 9/24/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 24, 2007 at 03:50:43PM +0530, Jaswinder Singh wrote:
> > Hi all,
> >
> > 2.6.22.7's include/linux/autoconf.h is completely screwed up as
> > compare to 2.6.10's autoconf.h .
> >
> > 2.6.22.7 totally changed the meaning of autoconf.h
>
> autoconf.h has always been autogenerated. And autoconf.h has always
> been used to publish the configuration to .c files.
>
> What changed between 2.6.10 and 26.22 are the algorithm used to
> produce autoconf.h.

I just curious, how algorithm is written that it makes readable to non-readable.

Thank you,

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

realtime preemption performance difference

[Jaswinder Singh]

Hi all,

I want to check performance difference by using realtime preemption patch :

http://www.kernel.org/pub/linux/kernel/projects/rt/

Please let me know from where I can download samples to test realtime
preemption performance difference.

Can someone please share performance numbers for your hardware:-

1. Interrupt latency
2. Task switching time
3. hard-realtime scheduling latency

Thank you,

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

2.6.22.7 default kernel configuration

[Jaswinder Singh]

Hi all,

Can please someone let me know what is criteria for default kernel
configuration .

Is it based upon some survey or requested by Fedora or others.

By default configuration size of vmlinux is 41 MB and it includes
approx 75% of useless stuff for me.

what is the idea behind 'default kernel configuration'. Is it made for
developers's PC  or for someone else.

Thank you,

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

hello rday,

On 9/24/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007, Jaswinder Singh wrote:
>
> > hello rday,
> >
> > On 9/24/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > > On Mon, 24 Sep 2007, Jaswinder Singh wrote:
> > >
> > > > hello rday,
> > > >
> > > > In my view autoconf.h is the index of kernel you are using. By
> > > > reading autoconf.h you will know what Architecture, drivers is
> > > > selected.
> > > >
> > > > For example, If we are using some ARM based board, If you give me
> > > > your autoconf.h , I can replicate same environment as yours. If it
> > > > is not properly formatted it is very difficult to read and come to
> > > > some conclusion.
> > >
> > > no, the proper thing to do is give someone your .config file if you
> > > want them to reproduce your configuration, and leave autoconf.h out of
> > > it.
> > >
> >
> > yes, you are right. So autoconf.h is obsolete and replaced by .config
> > . And now autoconf.h looks so funny and scary that no body dares to
> > open autoconf.h in future ;-)
>
> no, you're missing the point.  the .config file represents your
> selection of kernel options, it's what you can hand to someone if they
> want to reproduce your configuration.  autoconf.h, on the other hand,
> is automatically generated from your .config file once you start the
> build process.  it is in no way "obsolete", it's used by the build
> process -- it's just not meant to be manipulated by users.
>
> don't worry about autoconf.h, just leave it alone -- the build process
> takes care of it.
>

So it is obsolete for user's point of view, right ?

That's why it is written in such a way that no human can read it (Not
human readable). right ?

Thank you,

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

hello rday,

On 9/24/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007, Jaswinder Singh wrote:
>
> > hello rday,
> >
> > In my view autoconf.h is the index of kernel you are using. By
> > reading autoconf.h you will know what Architecture, drivers is
> > selected.
> >
> > For example, If we are using some ARM based board, If you give me
> > your autoconf.h , I can replicate same environment as yours. If it
> > is not properly formatted it is very difficult to read and come to
> > some conclusion.
>
> no, the proper thing to do is give someone your .config file if you
> want them to reproduce your configuration, and leave autoconf.h out of
> it.
>

yes, you are right. So autoconf.h is obsolete and replaced by .config
. And now autoconf.h looks so funny and scary that no body dares to
open autoconf.h in future ;-)


Thank you,

Jaswinder Singh.

> rday
> --
> 
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
>
> http://crashcourse.ca
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

hello rday,

In my view autoconf.h is the index of kernel you are using. By reading
autoconf.h you will know what Architecture, drivers is selected.

For example, If we are using some ARM based board, If you give me your
autoconf.h , I can replicate same environment as yours. If it is not
properly formatted it is very difficult to read and come to some
conclusion.

Thank you,

Jaswinder Singh.


On 9/24/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> On Mon, 24 Sep 2007, Jaswinder Singh wrote:
>
> > Hi all,
> >
> > 2.6.22.7's include/linux/autoconf.h is completely screwed up as
> > compare to 2.6.10's autoconf.h .
> >
> > 2.6.22.7 totally changed the meaning of autoconf.h
> ... snip ...
>
>  why do you care what autoconf.h looks like?  it's automatically
> generated, it's not something you should be messing with.
>
> rday
>
> --
> 
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
>
> http://crashcourse.ca
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

Hi all,

2.6.22.7's include/linux/autoconf.h is completely screwed up as
compare to 2.6.10's autoconf.h .

2.6.22.7 totally changed the meaning of autoconf.h

By just reading autoconf.h of 2.6.10 , we can understand what is the
system and its configuration, it is properly arranged and divided into
categories :

/*
* Automatically generated C config: don't edit
* Linux kernel version: 2.6.10
* Mon Sep 24 20:56:59 2007
*/
#define AUTOCONF_INCLUDED
#define CONFIG_X86 1
#define CONFIG_MMU 1
#define CONFIG_UID16 1
#define CONFIG_GENERIC_ISA_DMA 1
#define CONFIG_GENERIC_IOMAP 1

/*
* Code maturity level options
*/
#define CONFIG_EXPERIMENTAL 1
#define CONFIG_CLEAN_COMPILE 1
#define CONFIG_LOCK_KERNEL 1

/*
* General setup
*/
#define CONFIG_LOCALVERSION ""
#define CONFIG_SWAP 1
#define CONFIG_SYSVIPC 1
#define CONFIG_POSIX_MQUEUE 1
#define CONFIG_BSD_PROCESS_ACCT 1
#undef CONFIG_BSD_PROCESS_ACCT_V3
#define CONFIG_SYSCTL 1


And on 2.6.22.7's autoconf.h is haphazard, not formatted , not
readable and looks totally funny.

/*
* Automatically generated C config: don't edit
* Linux kernel version: 2.6.22.7
* Mon Sep 24 20:49:40 2007
*/
#define AUTOCONF_INCLUDED
#define CONFIG_USB_SISUSBVGA_MODULE 1
#define CONFIG_VIDEO_V4L1_COMPAT 1
#define CONFIG_PCMCIA_FMVJ18X_MODULE 1
#define CONFIG_BLK_CPQ_DA_MODULE 1
#define CONFIG_BLK_DEV_FD_MODULE 1
#define CONFIG_ACPI_AC_MODULE 1
#define CONFIG_SECURITY_NETWORK 1
#define CONFIG_DEBUG_SPINLOCK_SLEEP 1
#define CONFIG_OSF_PARTITION 1
#define CONFIG_USB_LEGOTOWER_MODULE 1
#define CONFIG_FB_TRIDENT_MODULE 1
#define CONFIG_FB_RIVA_BACKLIGHT 1
#define CONFIG_DVB_PLUTO2_MODULE 1
#define CONFIG_GAMEPORT_NS558_MODULE 1
#define CONFIG_JOYSTICK_GRIP_MODULE 1
#define CONFIG_HISAX_ELSA 1
#define CONFIG_BONDING_MODULE 1
#define CONFIG_BLK_DEV_HPT366 1
#define CONFIG_MTD_ABSENT_MODULE 1


Can you please let me know what is the idea behind this latest
autoconf.h and who is creator of this ugly autoconf.h.

Thank you,

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

2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

Hi all,

2.6.22.7's include/linux/autoconf.h is completely screwed up as
compare to 2.6.10's autoconf.h .

2.6.22.7 totally changed the meaning of autoconf.h

By just reading autoconf.h of 2.6.10 , we can understand what is the
system and its configuration, it is properly arranged and divided into
categories :

/*
* Automatically generated C config: don't edit
* Linux kernel version: 2.6.10
* Mon Sep 24 20:56:59 2007
*/
#define AUTOCONF_INCLUDED
#define CONFIG_X86 1
#define CONFIG_MMU 1
#define CONFIG_UID16 1
#define CONFIG_GENERIC_ISA_DMA 1
#define CONFIG_GENERIC_IOMAP 1

/*
* Code maturity level options
*/
#define CONFIG_EXPERIMENTAL 1
#define CONFIG_CLEAN_COMPILE 1
#define CONFIG_LOCK_KERNEL 1

/*
* General setup
*/
#define CONFIG_LOCALVERSION 
#define CONFIG_SWAP 1
#define CONFIG_SYSVIPC 1
#define CONFIG_POSIX_MQUEUE 1
#define CONFIG_BSD_PROCESS_ACCT 1
#undef CONFIG_BSD_PROCESS_ACCT_V3
#define CONFIG_SYSCTL 1


And on 2.6.22.7's autoconf.h is haphazard, not formatted , not
readable and looks totally funny.

/*
* Automatically generated C config: don't edit
* Linux kernel version: 2.6.22.7
* Mon Sep 24 20:49:40 2007
*/
#define AUTOCONF_INCLUDED
#define CONFIG_USB_SISUSBVGA_MODULE 1
#define CONFIG_VIDEO_V4L1_COMPAT 1
#define CONFIG_PCMCIA_FMVJ18X_MODULE 1
#define CONFIG_BLK_CPQ_DA_MODULE 1
#define CONFIG_BLK_DEV_FD_MODULE 1
#define CONFIG_ACPI_AC_MODULE 1
#define CONFIG_SECURITY_NETWORK 1
#define CONFIG_DEBUG_SPINLOCK_SLEEP 1
#define CONFIG_OSF_PARTITION 1
#define CONFIG_USB_LEGOTOWER_MODULE 1
#define CONFIG_FB_TRIDENT_MODULE 1
#define CONFIG_FB_RIVA_BACKLIGHT 1
#define CONFIG_DVB_PLUTO2_MODULE 1
#define CONFIG_GAMEPORT_NS558_MODULE 1
#define CONFIG_JOYSTICK_GRIP_MODULE 1
#define CONFIG_HISAX_ELSA 1
#define CONFIG_BONDING_MODULE 1
#define CONFIG_BLK_DEV_HPT366 1
#define CONFIG_MTD_ABSENT_MODULE 1


Can you please let me know what is the idea behind this latest
autoconf.h and who is creator of this ugly autoconf.h.

Thank you,

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

hello rday,

In my view autoconf.h is the index of kernel you are using. By reading
autoconf.h you will know what Architecture, drivers is selected.

For example, If we are using some ARM based board, If you give me your
autoconf.h , I can replicate same environment as yours. If it is not
properly formatted it is very difficult to read and come to some
conclusion.

Thank you,

Jaswinder Singh.


On 9/24/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
 On Mon, 24 Sep 2007, Jaswinder Singh wrote:

  Hi all,
 
  2.6.22.7's include/linux/autoconf.h is completely screwed up as
  compare to 2.6.10's autoconf.h .
 
  2.6.22.7 totally changed the meaning of autoconf.h
 ... snip ...

  why do you care what autoconf.h looks like?  it's automatically
 generated, it's not something you should be messing with.

 rday

 --
 
 Robert P. J. Day
 Linux Consulting, Training and Annoying Kernel Pedantry
 Waterloo, Ontario, CANADA

 http://crashcourse.ca
 

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

hello rday,

On 9/24/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
 On Mon, 24 Sep 2007, Jaswinder Singh wrote:

  hello rday,
 
  In my view autoconf.h is the index of kernel you are using. By
  reading autoconf.h you will know what Architecture, drivers is
  selected.
 
  For example, If we are using some ARM based board, If you give me
  your autoconf.h , I can replicate same environment as yours. If it
  is not properly formatted it is very difficult to read and come to
  some conclusion.

 no, the proper thing to do is give someone your .config file if you
 want them to reproduce your configuration, and leave autoconf.h out of
 it.


yes, you are right. So autoconf.h is obsolete and replaced by .config
. And now autoconf.h looks so funny and scary that no body dares to
open autoconf.h in future ;-)


Thank you,

Jaswinder Singh.

 rday
 --
 
 Robert P. J. Day
 Linux Consulting, Training and Annoying Kernel Pedantry
 Waterloo, Ontario, CANADA

 http://crashcourse.ca
 

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

hello rday,

On 9/24/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
 On Mon, 24 Sep 2007, Jaswinder Singh wrote:

  hello rday,
 
  On 9/24/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
   On Mon, 24 Sep 2007, Jaswinder Singh wrote:
  
hello rday,
   
In my view autoconf.h is the index of kernel you are using. By
reading autoconf.h you will know what Architecture, drivers is
selected.
   
For example, If we are using some ARM based board, If you give me
your autoconf.h , I can replicate same environment as yours. If it
is not properly formatted it is very difficult to read and come to
some conclusion.
  
   no, the proper thing to do is give someone your .config file if you
   want them to reproduce your configuration, and leave autoconf.h out of
   it.
  
 
  yes, you are right. So autoconf.h is obsolete and replaced by .config
  . And now autoconf.h looks so funny and scary that no body dares to
  open autoconf.h in future ;-)

 no, you're missing the point.  the .config file represents your
 selection of kernel options, it's what you can hand to someone if they
 want to reproduce your configuration.  autoconf.h, on the other hand,
 is automatically generated from your .config file once you start the
 build process.  it is in no way obsolete, it's used by the build
 process -- it's just not meant to be manipulated by users.

 don't worry about autoconf.h, just leave it alone -- the build process
 takes care of it.


So it is obsolete for user's point of view, right ?

That's why it is written in such a way that no human can read it (Not
human readable). right ?

Thank you,

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

2.6.22.7 default kernel configuration

[Jaswinder Singh]

Hi all,

Can please someone let me know what is criteria for default kernel
configuration .

Is it based upon some survey or requested by Fedora or others.

By default configuration size of vmlinux is 41 MB and it includes
approx 75% of useless stuff for me.

what is the idea behind 'default kernel configuration'. Is it made for
developers's PC  or for someone else.

Thank you,

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

realtime preemption performance difference

[Jaswinder Singh]

Hi all,

I want to check performance difference by using realtime preemption patch :

http://www.kernel.org/pub/linux/kernel/projects/rt/

Please let me know from where I can download samples to test realtime
preemption performance difference.

Can someone please share performance numbers for your hardware:-

1. Interrupt latency
2. Task switching time
3. hard-realtime scheduling latency

Thank you,

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

Re: 2.6.22.7 autoconf.h is screwed up

[Jaswinder Singh]

Dear Sam,

On 9/24/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
 On Mon, Sep 24, 2007 at 03:50:43PM +0530, Jaswinder Singh wrote:
  Hi all,
 
  2.6.22.7's include/linux/autoconf.h is completely screwed up as
  compare to 2.6.10's autoconf.h .
 
  2.6.22.7 totally changed the meaning of autoconf.h

 autoconf.h has always been autogenerated. And autoconf.h has always
 been used to publish the configuration to .c files.

 What changed between 2.6.10 and 26.22 are the algorithm used to
 produce autoconf.h.

I just curious, how algorithm is written that it makes readable to non-readable.

Thank you,

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

_syscall0 exists or obsolete in 2.6

[Jaswinder Singh]

Hello all,

I am trying to add syscall in include/asm/unistd.h:

static inline _syscall0(int,my_sys_call);

But I am getting following errors :

  AS  arch/arm/kernel/entry-common.o
include/asm/unistd.h: Assembler messages:
include/asm/unistd.h:622: Error: bad instruction `static inline int
my_sys_call(void){register long __res_r0 __asm__("r0")'
include/asm/unistd.h:622: Error: bad instruction `long __res'
include/asm/unistd.h:622: Error: bad instruction `__asm__
__volatile__("swi\t""(0x90+322)""":"=r"(__res_r0)::"memory")'
include/asm/unistd.h:622: Error: bad instruction `do {if((unsigned
long)(__res)>=(unsigned long)(-129)){errno=-(__res)'
include/asm/unistd.h:622: Error: junk at end of line, first
unrecognized character is `}'
include/asm/unistd.h:622: Error: junk at end of line, first
unrecognized character is `}'
include/asm/unistd.h:622: Error: junk at end of line, first
unrecognized character is `}'
make[1]: *** [arch/arm/kernel/entry-common.o] Error 1
make: *** [arch/arm/kernel] Error 2


This was working in older versions.

I am curious _syscall0 still exists or obsolete in 2.6 linux.

And I have noticed even if I commented _syscall0 macro, I do not get
any errors so no body is using it , then why _syscall0 is in kernel
header files and what is the substitute of _syscall0.

Thanks for help,

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

_syscall0 exists or obsolete in 2.6

[Jaswinder Singh]

Hello all,

I am trying to add syscall in include/asm/unistd.h:

static inline _syscall0(int,my_sys_call);

But I am getting following errors :

  AS  arch/arm/kernel/entry-common.o
include/asm/unistd.h: Assembler messages:
include/asm/unistd.h:622: Error: bad instruction `static inline int
my_sys_call(void){register long __res_r0 __asm__(r0)'
include/asm/unistd.h:622: Error: bad instruction `long __res'
include/asm/unistd.h:622: Error: bad instruction `__asm__
__volatile__(swi\t(0x90+322):=r(__res_r0)::memory)'
include/asm/unistd.h:622: Error: bad instruction `do {if((unsigned
long)(__res)=(unsigned long)(-129)){errno=-(__res)'
include/asm/unistd.h:622: Error: junk at end of line, first
unrecognized character is `}'
include/asm/unistd.h:622: Error: junk at end of line, first
unrecognized character is `}'
include/asm/unistd.h:622: Error: junk at end of line, first
unrecognized character is `}'
make[1]: *** [arch/arm/kernel/entry-common.o] Error 1
make: *** [arch/arm/kernel] Error 2


This was working in older versions.

I am curious _syscall0 still exists or obsolete in 2.6 linux.

And I have noticed even if I commented _syscall0 macro, I do not get
any errors so no body is using it , then why _syscall0 is in kernel
header files and what is the substitute of _syscall0.

Thanks for help,

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

Re: Support 2.4 modules features in 2.6

[Jaswinder Singh]

On 12/12/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:

On Tue, 2006-12-12 at 20:41 +0530, Jaswinder Singh wrote:
> On 12/12/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > On Tue, 2006-12-12 at 19:36 +0530, Jaswinder Singh wrote:
> > > Hello,
> > >
> > > I want to support old 2.4 modules features in 2.6 kernel modules:-
> > > 1. no kernel source tree is required to build modules.
> >
> > this is a 2.6 not a 2.4 feature btw
> >
>
> Really!! , Please let me know what is the procedure to build the
> modules after deleting kernel linux-2.6*

you only need include/* for this in 2.6

you can't do this at all with 2.4 kernels, it needs the whole lot.

(in both cases the code and headers are needed so that your module can
use the data structures and compile in the kernel code you select to use
from inlines)
>
>


Really!!

This is my Makefile :-
obj-m += hello-1.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean


Now do one thing:-
# mv /lib/modules/$(uname -r)/build /lib/modules/$(uname -r)/build0

now make it.

If you want point to your header files in /usr/include and then try to build.

Regards,

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

Re: Support 2.4 modules features in 2.6

[Jaswinder Singh]

On 12/12/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote:

On Tue, 2006-12-12 at 19:36 +0530, Jaswinder Singh wrote:
> Hello,
>
> I want to support old 2.4 modules features in 2.6 kernel modules:-
> 1. no kernel source tree is required to build modules.

this is a 2.6 not a 2.4 feature btw



Really!! , Please let me know what is the procedure to build the
modules after deleting kernel linux-2.6*



> 2. support modular plugins.

?


modular plugins means :-

module2 uses symbols of module1.
module3 uses symbols of module1 & module2.

Regards,

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

Support 2.4 modules features in 2.6

[Jaswinder Singh]

Hello,

I want to support old 2.4 modules features in 2.6 kernel modules:-
1. no kernel source tree is required to build modules.
2. support modular plugins.
3. modules EXPORT by default.

Is any patch available, or somebody working on it ?

Thank you,

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

Support 2.4 modules features in 2.6

[Jaswinder Singh]

Hello,

I want to support old 2.4 modules features in 2.6 kernel modules:-
1. no kernel source tree is required to build modules.
2. support modular plugins.
3. modules EXPORT by default.

Is any patch available, or somebody working on it ?

Thank you,

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

Re: Support 2.4 modules features in 2.6

[Jaswinder Singh]

On 12/12/06, Arjan van de Ven [EMAIL PROTECTED] wrote:

On Tue, 2006-12-12 at 19:36 +0530, Jaswinder Singh wrote:
 Hello,

 I want to support old 2.4 modules features in 2.6 kernel modules:-
 1. no kernel source tree is required to build modules.

this is a 2.6 not a 2.4 feature btw



Really!! , Please let me know what is the procedure to build the
modules after deleting kernel linux-2.6*



 2. support modular plugins.

?


modular plugins means :-

module2 uses symbols of module1.
module3 uses symbols of module1  module2.

Regards,

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

Re: Support 2.4 modules features in 2.6

[Jaswinder Singh]

On 12/12/06, Arjan van de Ven [EMAIL PROTECTED] wrote:

On Tue, 2006-12-12 at 20:41 +0530, Jaswinder Singh wrote:
 On 12/12/06, Arjan van de Ven [EMAIL PROTECTED] wrote:
  On Tue, 2006-12-12 at 19:36 +0530, Jaswinder Singh wrote:
   Hello,
  
   I want to support old 2.4 modules features in 2.6 kernel modules:-
   1. no kernel source tree is required to build modules.
 
  this is a 2.6 not a 2.4 feature btw
 

 Really!! , Please let me know what is the procedure to build the
 modules after deleting kernel linux-2.6*

you only need include/* for this in 2.6

you can't do this at all with 2.4 kernels, it needs the whole lot.

(in both cases the code and headers are needed so that your module can
use the data structures and compile in the kernel code you select to use
from inlines)




Really!!

This is my Makefile :-
obj-m += hello-1.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean


Now do one thing:-
# mv /lib/modules/$(uname -r)/build /lib/modules/$(uname -r)/build0

now make it.

If you want point to your header files in /usr/include and then try to build.

Regards,

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

What happen when hangs !!

[Jaswinder Singh]

Hi,

Sometimes my machine hangs in userspace area like this :-

VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT:
<>

OR

VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT: version 2.85 booting
<>

How can I debug this hang, what are the cases.

Is this a deadlock.

Thank you,

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

What happen when hangs !!

[Jaswinder Singh]

Hi,

Sometimes my machine hangs in userspace area like this :-

VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT:
HANGS

OR

VFS: Mounted root (ext3 filesystem).
Freeing init memory: 124K
INIT: version 2.85 booting
RUNNING SMOOTHLY

How can I debug this hang, what are the cases.

Is this a deadlock.

Thank you,

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

Re: [PATCH] let WARN_ON() output the condition

[Jaswinder Singh]

Hi,

I am playing with linux kernel but kernel dumps on WARN_ON , when I
commented WARN_ON in my code my kernel starts working but I get two
sideeffects :-

1. During Boot kernel Hangs sometimes in :-
Updating /etc/motd...done.
INIT: Entering runlevel: 3
<>

2. Always Hangs in :-
cat /proc/interrupts
after showing interrupts
<>

Are these side-effects of commenting WARN_ON.

Sometimes I also gets :-

<1>Unable to handle kernel NULL pointer dereference at virtual address 0004
Unable to handle kernel NULL pointer dereference at virtual address 0004
<1>pgd = c581
pgd = c581
<1>[0004] *pgd=85844031[0004] *pgd=85844031, *pte=,
*pte=, *ppte=, *ppte=

Internal error: Oops: 17 [#1]
Internal error: Oops: 17 [#1]
Modules linked in:Modules linked in:

CPU: 0
CPU: 0
PC is at dequeue_task+0xc/0x78
PC is at dequeue_task+0xc/0x78
LR is at deactivate_task+0x24/0x30
LR is at deactivate_task+0x24/0x30
pc : []lr : []Not tainted
sp : c545ddcc  ip : c545dddc  fp : c545ddd8
pc : []lr : []Not tainted
sp : c545ddcc  ip : c545dddc  fp : c545ddd8
r10: c68fd340  r9 : c02e04d4  r8 : c028ccf8
r10: c68fd340  r9 : c02e04d4  r8 : c028ccf8
r7 : c028ded8  r6 : c028ccf4  r5 : c545c000  r4 : c68fd340
r7 : c028ded8  r6 : c028ccf4  r5 : c545c000  r4 : c68fd340
r3 : 0002  r2 :   r1 :   r0 : c68fd340
r3 : 0002  r2 :   r1 :   r0 : c68fd340
Flags: NzcvFlags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user
 IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F  Table: 8581  DAC: 0015
Control: 5317F  Table: 8581  DAC: 0015
Process X (pid: 1107, stack limit = 0xc545c198)
Process X (pid: 1107, stack limit = 0xc545c198)
Stack: (0xc545ddcc to 0xc545e000)
Stack: (0xc545ddcc to 0xc545e000)

How to get rid of dequeue_task issue.

Thanks

Jaswinder Singh.

On 12/6/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:


* Horst H. von Brand <[EMAIL PROTECTED]> wrote:

> Why not just:
>
> WARN_ON(debug_locks_off())
>
> here? Would give a more readable message too, IMHO.

debug_locks_off() has a side-effect, and in general we dont like to put
stuff with side-effects witin WARN_ON().

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


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

Re: [PATCH] let WARN_ON() output the condition

[Jaswinder Singh]

Hi,

I am playing with linux kernel but kernel dumps on WARN_ON , when I
commented WARN_ON in my code my kernel starts working but I get two
sideeffects :-

1. During Boot kernel Hangs sometimes in :-
Updating /etc/motd...done.
INIT: Entering runlevel: 3
hangs

2. Always Hangs in :-
cat /proc/interrupts
after showing interrupts
hangs

Are these side-effects of commenting WARN_ON.

Sometimes I also gets :-

1Unable to handle kernel NULL pointer dereference at virtual address 0004
Unable to handle kernel NULL pointer dereference at virtual address 0004
1pgd = c581
pgd = c581
1[0004] *pgd=85844031[0004] *pgd=85844031, *pte=,
*pte=, *ppte=, *ppte=

Internal error: Oops: 17 [#1]
Internal error: Oops: 17 [#1]
Modules linked in:Modules linked in:

CPU: 0
CPU: 0
PC is at dequeue_task+0xc/0x78
PC is at dequeue_task+0xc/0x78
LR is at deactivate_task+0x24/0x30
LR is at deactivate_task+0x24/0x30
pc : [c0037264]lr : [c003759c]Not tainted
sp : c545ddcc  ip : c545dddc  fp : c545ddd8
pc : [c0037264]lr : [c003759c]Not tainted
sp : c545ddcc  ip : c545dddc  fp : c545ddd8
r10: c68fd340  r9 : c02e04d4  r8 : c028ccf8
r10: c68fd340  r9 : c02e04d4  r8 : c028ccf8
r7 : c028ded8  r6 : c028ccf4  r5 : c545c000  r4 : c68fd340
r7 : c028ded8  r6 : c028ccf4  r5 : c545c000  r4 : c68fd340
r3 : 0002  r2 :   r1 :   r0 : c68fd340
r3 : 0002  r2 :   r1 :   r0 : c68fd340
Flags: NzcvFlags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user
 IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 5317F  Table: 8581  DAC: 0015
Control: 5317F  Table: 8581  DAC: 0015
Process X (pid: 1107, stack limit = 0xc545c198)
Process X (pid: 1107, stack limit = 0xc545c198)
Stack: (0xc545ddcc to 0xc545e000)
Stack: (0xc545ddcc to 0xc545e000)

How to get rid of dequeue_task issue.

Thanks

Jaswinder Singh.

On 12/6/06, Ingo Molnar [EMAIL PROTECTED] wrote:


* Horst H. von Brand [EMAIL PROTECTED] wrote:

 Why not just:

 WARN_ON(debug_locks_off())

 here? Would give a more readable message too, IMHO.

debug_locks_off() has a side-effect, and in general we dont like to put
stuff with side-effects witin WARN_ON().

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


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

Re: PREEMPT is messing with everyone

[Jaswinder Singh]

On 12/5/06, Michal Schmidt <[EMAIL PROTECTED]> wrote:

Jaswinder Singh wrote:
> Hi,
>
> preempt stuff SHOULD only stay in #ifdef CONFIG_PREEMP_* , but it is
> messing with everyone even though not defined.
>
> e.g.
>
> 1. linux-2.6.19/kernel/spinlock.c
>
> Line 18: #include 
>
> Line 26:  preempt_disable();
>
> Line 32:  preempt_disable();
>
> and so on .

Don't worry. These compile into "do { } while (0)" (i.e. nothing) when
CONFIG_PREEMPT is not set.



Yes, Compiler will remove it but this looks ugly and confusing.

Why dont we use like this :-

#ifdef CONFIG_PREEMPT
#include 
#endif

#ifdef CONFIG_PREEMPT
preempt_disable();
#endif

#ifdef CONFIG_PREEMPT
preempt_enable();
#endif

Regards,

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

PREEMPT is messing with everyone

[Jaswinder Singh]

Hi,

preempt stuff SHOULD only stay in #ifdef CONFIG_PREEMP_* , but it is
messing with everyone even though not defined.

e.g.

1. linux-2.6.19/kernel/spinlock.c

Line 18: #include 

Line 26:  preempt_disable();

Line 32:  preempt_disable();

and so on .

2. linux-2.6.19/kernel/sched.c

Line 1096:  int preempted;

Line 1104:   preempted = !task_running(rq, p);

Line 1106:   if (preempted)

Line 2059:  if (TASK_PREEMPTS_CURR(p, this_rq))

Line 3355:current->comm, preempt_count(), current->pid);

Line 3342:  preempt_disable();

Line 3375:  if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {

Line 3471:  preempt_enable_no_resched();

3. linux-2.6.19/kernel/timer.c

Line 444: int preempt_count = preempt_count();

Line 447: if (preempt_count != preempt_count()) {

4. linux-2.6.19/arch/i386/kernel/entry.S

Line 240:  preempt_stop

5. linux-2.6.19/arch/i386/irq.c

Line 111:irqctx->tinfo.preempt_count =

Line 112:(irqctx->tinfo.preempt_count & ~SOFTIRQ_MASK) |

Line 113:(curctx->tinfo.preempt_count & SOFTIRQ_MASK);

Line 160:  irqctx->tinfo.preempt_count = HARDIRQ_OFFSET;

and so on.

Similarly unnecessary preempt code is also written in other important files.

70 to 80 % of this code is removed when compiled.

but 20 to 30 % code left in binary kernel image.

Why Linux kernel is wasting its resources which is not defined at all.

Any solution ?

Thank you,

Best Regards,

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

PREEMPT is messing with everyone

[Jaswinder Singh]

Hi,

preempt stuff SHOULD only stay in #ifdef CONFIG_PREEMP_* , but it is
messing with everyone even though not defined.

e.g.

1. linux-2.6.19/kernel/spinlock.c

Line 18: #include linux/preempt.h

Line 26:  preempt_disable();

Line 32:  preempt_disable();

and so on .

2. linux-2.6.19/kernel/sched.c

Line 1096:  int preempted;

Line 1104:   preempted = !task_running(rq, p);

Line 1106:   if (preempted)

Line 2059:  if (TASK_PREEMPTS_CURR(p, this_rq))

Line 3355:current-comm, preempt_count(), current-pid);

Line 3342:  preempt_disable();

Line 3375:  if (prev-state  !(preempt_count()  PREEMPT_ACTIVE)) {

Line 3471:  preempt_enable_no_resched();

3. linux-2.6.19/kernel/timer.c

Line 444: int preempt_count = preempt_count();

Line 447: if (preempt_count != preempt_count()) {

4. linux-2.6.19/arch/i386/kernel/entry.S

Line 240:  preempt_stop

5. linux-2.6.19/arch/i386/irq.c

Line 111:irqctx-tinfo.preempt_count =

Line 112:(irqctx-tinfo.preempt_count  ~SOFTIRQ_MASK) |

Line 113:(curctx-tinfo.preempt_count  SOFTIRQ_MASK);

Line 160:  irqctx-tinfo.preempt_count = HARDIRQ_OFFSET;

and so on.

Similarly unnecessary preempt code is also written in other important files.

70 to 80 % of this code is removed when compiled.

but 20 to 30 % code left in binary kernel image.

Why Linux kernel is wasting its resources which is not defined at all.

Any solution ?

Thank you,

Best Regards,

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

Re: PREEMPT is messing with everyone

[Jaswinder Singh]

On 12/5/06, Michal Schmidt [EMAIL PROTECTED] wrote:

Jaswinder Singh wrote:
 Hi,

 preempt stuff SHOULD only stay in #ifdef CONFIG_PREEMP_* , but it is
 messing with everyone even though not defined.

 e.g.

 1. linux-2.6.19/kernel/spinlock.c

 Line 18: #include linux/preempt.h

 Line 26:  preempt_disable();

 Line 32:  preempt_disable();

 and so on .

Don't worry. These compile into do { } while (0) (i.e. nothing) when
CONFIG_PREEMPT is not set.



Yes, Compiler will remove it but this looks ugly and confusing.

Why dont we use like this :-

#ifdef CONFIG_PREEMPT
#include linux/preempt.h
#endif

#ifdef CONFIG_PREEMPT
preempt_disable();
#endif

#ifdef CONFIG_PREEMPT
preempt_enable();
#endif

Regards,

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

Re: Download process for a "split kernel" (was: obsolete code must die)

[Jaswinder Singh]

>
> Or as a simpler design, something like;
>
>   * a copy of the kernel maintained in a CVS tree
>   * kernel download would pull down:
> * the build script
> * a file containing the list of filenames depended on by
>   each config option
>   * build script builds the config and then cvs updates the file list
> and the files for each config option in question to the version as
> tagged in the build script
>
> Someone could relatively easily maintain this separate to all the kernel
> developers, and it would mean only ever having to download files you were
> actually using.

OR

50 % of kernel size is from /linux/drivers
25 % of kernel size is from machine dependent /linux/arch/ and
/linux/include/

If  we are able to divide Linux tree in such a way that everyone can
download it from from their personnal modems and enjoy linux.

may be i am wrong .

But i love downloading whole kernel and i usually refer different
architectures.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: obsolete code must die

[Jaswinder Singh]

Cleanup is a nice idea , but Linux should support old hardware and should
not affect them in any way.

Jaswinder.

- Original Message -
From: "Daniel" <[EMAIL PROTECTED]>
To: "Linux kernel" <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 5:44 PM
Subject: obsolete code must die


> Anyone concerned about the current size of the kernel source code? I am,
and
> I propose to start cleaning house on the x86 platform. I mean it's all
very
> well and good to keep adding features, but stuff needs to go if kernel
> development is to move forward. Before listing the gunk I want to get rid
> of, here's my justification for doing so:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.
> -- Simplifying the kernel means that it will be easier for newbies to
> understand and perhaps contribute.
> -- a simpler, cleaner kernel will also be of more use in an academic
> environment.
> -- a smaller kernel is easier to maintain and is easier to re-architect
> should the need arise.
> -- If someone really needs support for this junk, they will always have
the
> option of using the 2.0.x, 2.2.x or 2.4.x series.
>
> So without further ado here're the features I want to get rid of:
>
> i386, i486
> The Pentium processor has been around since 1995. Support for these older
> processors should go so we can focus on optimizations for the pentium and
> better processors.
>
> math-emu
> If support for i386 and i486 is going away, then so should math emulation.
> Every intel processor since the 486DX has an FPU unit built in. In fact
> shouldn't FPU support be a userspace responsibility anyway?
>
> ISA bus, MCA bus, EISA bus
> PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
> CONFIG_ISAPNP, etc
>
> ISA, MCA, EISA device drivers
> If support for the buses is gone, there's no point in supporting devices
for
> these buses.
>
> all code marked as CONFIG_OBSOLETE
> Since we're cleaning house we may as well get rid of this stuff.
>
> MFM/RLL/XT/ESDI hard drive support
> Does anyone still *have* an RLL drive that works? At the very least get
rid
> of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
> CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)
>
> parallel/serial/game ports
> More controversial to remove this, since they are *still* in pretty wide
> use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.
>
> a.out
> Who needs it anymore. I love ELF.
>
> I really think doing a clean up is worthwhile. Maybe while looking for
stuff
> to clean up we'll even be able to better comment the existing code. Any
> other features people would like to get rid of? Any comments or
suggestions?
> I'd love to start a good discussion about this going so please send me
your
> 2 cents.
>
> Daniel
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

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

Re: obsolete code must die

[Jaswinder Singh]

Cleanup is a nice idea , but Linux should support old hardware and should
not affect them in any way.

Jaswinder.

- Original Message -
From: Daniel [EMAIL PROTECTED]
To: Linux kernel [EMAIL PROTECTED]
Sent: Wednesday, June 13, 2001 5:44 PM
Subject: obsolete code must die


 Anyone concerned about the current size of the kernel source code? I am,
and
 I propose to start cleaning house on the x86 platform. I mean it's all
very
 well and good to keep adding features, but stuff needs to go if kernel
 development is to move forward. Before listing the gunk I want to get rid
 of, here's my justification for doing so:
 -- Getting rid of old code can help simplify the kernel. This means less
 chance of bugs.
 -- Simplifying the kernel means that it will be easier for newbies to
 understand and perhaps contribute.
 -- a simpler, cleaner kernel will also be of more use in an academic
 environment.
 -- a smaller kernel is easier to maintain and is easier to re-architect
 should the need arise.
 -- If someone really needs support for this junk, they will always have
the
 option of using the 2.0.x, 2.2.x or 2.4.x series.

 So without further ado here're the features I want to get rid of:

 i386, i486
 The Pentium processor has been around since 1995. Support for these older
 processors should go so we can focus on optimizations for the pentium and
 better processors.

 math-emu
 If support for i386 and i486 is going away, then so should math emulation.
 Every intel processor since the 486DX has an FPU unit built in. In fact
 shouldn't FPU support be a userspace responsibility anyway?

 ISA bus, MCA bus, EISA bus
 PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
 CONFIG_ISAPNP, etc

 ISA, MCA, EISA device drivers
 If support for the buses is gone, there's no point in supporting devices
for
 these buses.

 all code marked as CONFIG_OBSOLETE
 Since we're cleaning house we may as well get rid of this stuff.

 MFM/RLL/XT/ESDI hard drive support
 Does anyone still *have* an RLL drive that works? At the very least get
rid
 of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE,
 CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2)

 parallel/serial/game ports
 More controversial to remove this, since they are *still* in pretty wide
 use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

 a.out
 Who needs it anymore. I love ELF.

 I really think doing a clean up is worthwhile. Maybe while looking for
stuff
 to clean up we'll even be able to better comment the existing code. Any
 other features people would like to get rid of? Any comments or
suggestions?
 I'd love to start a good discussion about this going so please send me
your
 2 cents.

 Daniel

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


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

Re: Download process for a split kernel (was: obsolete code must die)

[Jaswinder Singh]

 Or as a simpler design, something like;

   * a copy of the kernel maintained in a CVS tree
   * kernel download would pull down:
 * the build script
 * a file containing the list of filenames depended on by
   each config option
   * build script builds the config and then cvs updates the file list
 and the files for each config option in question to the version as
 tagged in the build script

 Someone could relatively easily maintain this separate to all the kernel
 developers, and it would mean only ever having to download files you were
 actually using.

OR

50 % of kernel size is from /linux/drivers
25 % of kernel size is from machine dependent /linux/arch/ and
/linux/include/

If  we are able to divide Linux tree in such a way that everyone can
download it from from their personnal modems and enjoy linux.

may be i am wrong .

But i love downloading whole kernel and i usually refer different
architectures.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Task Switching in Linux

[Jaswinder Singh]

In Linux , If we assume that there are only 2 tasks A and B and both are
equal , this is correct or not :-

TASK A -> schedule -> switch_to -> TASK B -> schedule -> switch_to ->
schedule -> switch_to -> TASK A.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.




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

Task Switching in Linux

[Jaswinder Singh]

In Linux , If we assume that there are only 2 tasks A and B and both are
equal , this is correct or not :-

TASK A - schedule - switch_to - TASK B - schedule - switch_to -
schedule - switch_to - TASK A.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.




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

Re: rtl8139too in 2.4.5

[Jaswinder Singh]

<[EMAIL PROTECTED]> wrote :


> My RTL8139 (Identified 8139 chip type 'RTL-8139A')
> was fine in 2.4.3 and doesnt work in 2.4.5.
> Copying the 2.4.3 version of 8139too.c makes things work again.
> 

but my old RTL8139 is working fine under 2.4.5 , without any changes.

Jaswinder.
-- 
These are my opinions not 3Di.



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

Re: rtl8139too in 2.4.5

[Jaswinder Singh]

[EMAIL PROTECTED] wrote :


 My RTL8139 (Identified 8139 chip type 'RTL-8139A')
 was fine in 2.4.3 and doesnt work in 2.4.5.
 Copying the 2.4.3 version of 8139too.c makes things work again.
 

but my old RTL8139 is working fine under 2.4.5 , without any changes.

Jaswinder.
-- 
These are my opinions not 3Di.



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

Benchmarks for Linux kernel

[Jaswinder Singh]

Can please point me some nice benchmarks for linux kernel .

Which tells the performance of following , under Linux Kernel :-

1. CPU
2. Bus 
3. Cache 
4. DMA
5. Interrupts and Exceptions
6. File Systems
7. FPU
8. forking and pthread (Process Management)
9. IDE
10. Ethernet
11. Memory Management
12. PCI
13. USB
14. Serial
15. Clocks and Timers
16. Sound 
17. SMP
18. Virtual Memory Management
19. Networking
20. PCMCIA
21. RAID

Thank you,

Jaswinder.
-- 
These are my opinions not 3Di.


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

Benchmarks for Linux kernel

[Jaswinder Singh]

Can please point me some nice benchmarks for linux kernel .

Which tells the performance of following , under Linux Kernel :-

1. CPU
2. Bus 
3. Cache 
4. DMA
5. Interrupts and Exceptions
6. File Systems
7. FPU
8. forking and pthread (Process Management)
9. IDE
10. Ethernet
11. Memory Management
12. PCI
13. USB
14. Serial
15. Clocks and Timers
16. Sound 
17. SMP
18. Virtual Memory Management
19. Networking
20. PCMCIA
21. RAID

Thank you,

Jaswinder.
-- 
These are my opinions not 3Di.


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

Emulate RDTSC

[Jaswinder Singh]

Hi all,

What is the nice way (in accuracy and performance) to emulate RDTSC in Linux
for those architectures who dont support RDTSC like in Hitachi SH
Processors.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Emulate RDTSC

[Jaswinder Singh]

Hi all,

What is the nice way (in accuracy and performance) to emulate RDTSC in Linux
for those architectures who dont support RDTSC like in Hitachi SH
Processors.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: IDE Performance lack !

[Jaswinder Singh]

"Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote:

>
> Are you sure it is idle. It might be running something from cron-
> say 'updatedb' or similar. That will cause a lot of disk i/o,
> and _ofcourse_ performance will be bad then - the machine is
> doing a lot of other things.
>

I am the only user who use my linux boxes , i never use cron , and i have no
relation with database at all.

> It might also be that you don't have enough memory and the
> machine is swapping itself to death. Running netscape or
> mozilla perhaps? These are known to blow themselves up to
> 50-100 MB (!). That will cause the exact symptoms you're seeing.
>

I never go to X-Windows , i do all my work from console.

cat /proc/meminfo
total:used:free:  shared: buffers:  cached:
Mem:  114475008 111816704  2658304  5234688 68067328 24711168
Swap: 583954432  2654208 581300224
MemTotal:111792 kB
MemFree:   2596 kB
MemShared: 5112 kB
Buffers:  66472 kB
Cached:   24132 kB
SwapTotal:   570268 kB
SwapFree:567676 kB

>
> 2.4.2 isn't all that good either.. 2.4.x doesn't have VM sorted
> out just yet
>

may be this problem of VM as suggested by Mark Hahn.

Thank you,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: [kbuild-devel] Configure.help entries wanted

[Jaswinder Singh]

"Greg Banks" <[EMAIL PROTECTED]> wrote:

> 
>   Manufacturer = DataMyte, a division of Rockwell.
>   Machine = DataMyte Industrial Digital Assistant 4000
> (aka DMIDA, www.dmida.com)
> 

What is the companion chip in DMIDA ?

IrDA and USB are working properly in linux ?

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.




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

Re: CPU Dedicated Interrupts

[Jaswinder Singh]

> What is the easiest way to tell a CPU to ignore certain interrupts from
> module?
> Is there an IRQ mask for each processor? Is that symbol exported?
> 

I also what to know this :)

Please help us .

Thank you.

Jaswinder.
--
These are my opinions not 3Di.


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

Re: IDE Performance lack !

[Jaswinder Singh]

From: "Jakob Østergaard" <[EMAIL PROTECTED]> wrote :
>
> The answer for both of you is:
>
>   hdparm -d1 /dev/hd{whatever}
>
> Without DMA enabled, performance is going to suck.  1.9 MB/sec is actually
pretty
> good without DMA   ;)
>

i think DMA or PCI is not my solution , atleast :)

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.


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

Re: IDE Performance lack !

[Jaswinder Singh]

"Chris Wedgwood" <[EMAIL PROTECTED]> wrote:

> On Sat, May 26, 2001 at 05:16:42PM -0700, Jaswinder Singh wrote:
>
> When ever i copy big data (around 400 to 700 MB ) from one
> partion to another my machine do not response at all (i can not
> work on another shell) during data transfer.
>
> Both paritions on the same spindle? That's going to suck no matter
> what you do...

I am having only one harddisk of 20 Gb , so i made four partitions on it.

> but it shouldn't be as bad as you describe.

But it is more bad then i described , especially when i do telnet/ssh from
my home .

I am not able to understand why Linux read and/or write harddisk after some
time (after few hours ) , harddisk read/write leds keep on glowing for few
minutes , even though nobody working on it and machine is in idle state.

>Have you tried 2.2.x ?
>

yes i am taking about 2.2.12 .

And in my 2.4.2 :-

Harddisk read-write problem is also there , during harddisk read-write
activity i took two hdparams and i got :-
i . 963.76 kB/sec
ii. 1.05 MB/sec

and when my machine becomes normal i got :-

9.07 MB/sec

and after hdparam -d1 i got :-

9.55 MB/sec

But my problem is why linux boxes do not response for few seconds
(sometimes) and especially during telnet/ssh it looks more worst and looks
similar to Microsoft Windows :(

there is problem in scheduling or what ?

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.



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

Re: IDE Performance lack !

[Jaswinder Singh]

Chris Wedgwood [EMAIL PROTECTED] wrote:

 On Sat, May 26, 2001 at 05:16:42PM -0700, Jaswinder Singh wrote:

 When ever i copy big data (around 400 to 700 MB ) from one
 partion to another my machine do not response at all (i can not
 work on another shell) during data transfer.

 Both paritions on the same spindle? That's going to suck no matter
 what you do...

I am having only one harddisk of 20 Gb , so i made four partitions on it.

 but it shouldn't be as bad as you describe.

But it is more bad then i described , especially when i do telnet/ssh from
my home .

I am not able to understand why Linux read and/or write harddisk after some
time (after few hours ) , harddisk read/write leds keep on glowing for few
minutes , even though nobody working on it and machine is in idle state.

Have you tried 2.2.x ?


yes i am taking about 2.2.12 .

And in my 2.4.2 :-

Harddisk read-write problem is also there , during harddisk read-write
activity i took two hdparams and i got :-
i . 963.76 kB/sec
ii. 1.05 MB/sec

and when my machine becomes normal i got :-

9.07 MB/sec

and after hdparam -d1 i got :-

9.55 MB/sec

But my problem is why linux boxes do not response for few seconds
(sometimes) and especially during telnet/ssh it looks more worst and looks
similar to Microsoft Windows :(

there is problem in scheduling or what ?

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.



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