Symbios problems in recent -mm trees?

[Martin J. Bligh]

If you look on http://test.kernel.org/, you'll see in the rightmost
column there's a yellow box under elm3b70 for 2.6.13-rc4-mm1, but
current mainline kernels are all green (ie no problems). That means
one test failed, in this case making an fs on the spare partition. 
Odd. I went digging ...

Looks like this got introduced between 2.6.12-mm1 and 2.6.12-mm2
Sorry, should've caught it earlier. I'll blame OLS or something.
This is an 8x power4 box running "bare metal" (ie not on top of
the hypervisor).

seems /dev/sdc1 doesn't exist.
07/31/05-02:44:32 processing command: (5) 'fs --partition=1 --mkext2fs --mount 
-l /mnt/tmp'
n format
PARTITION='/dev/sdc1'
mke2fs 1.35 (28-Feb-2004)
mkfs.ext2: No such device or address while trying to determine filesystem size
07/31/05-02:44:32 fs: creating filesystem ext2 Failed rc = 1

Looking back at the bootlog (http://test.kernel.org/9609/debug/console.log),
I see it really not looking very happy (snapshot below).

Good bootlog is here for comparsion: 
(http://test.kernel.org/9445/debug/console.log)

sym0: <1010-66> rev 0x1 at pci 0001:01:01.0 irq 115
sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.2.1
 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
  Vendor: IBM   Model: IC35L036UCDY10-0  Rev: S25M
  Type:   Direct-Access  ANSI SCSI revision: 03
 target0:0:8: tagged command queuing enabled, command queue depth 16.
 target0:0:8: Beginning Domain Validation
 target0:0:8: asynchronous.
 target0:0:8: wide asynchronous.
 target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31)
sym0: unexpected disconnect
 target0:0:8: Write Buffer failure 700ff
 target0:0:8: Domain Validation Disabing Information Units
 target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
sym0: unexpected disconnect
 target0:0:8: Write Buffer failure 700ff
 target0:0:8: Domain Validation detected failure, dropping back
 target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
 target0:0:8: Ending Domain Validation
 target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
  Vendor: IBM   Model: IC35L036UCDY10-0  Rev: S25M
  Type:   Direct-Access  ANSI SCSI revision: 03
 target0:0:9: tagged command queuing enabled, command queue depth 16.
 target0:0:9: Beginning Domain Validation
 target0:0:9: asynchronous.
 target0:0:9: wide asynchronous.
 target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31)
sym0: unexpected disconnect
 target0:0:9: Write Buffer failure 700ff
 target0:0:9: Domain Validation Disabing Information Units
 target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
sym0: unexpected disconnect
 target0:0:9: Write Buffer failure 700ff
 target0:0:9: Domain Validation detected failure, dropping back
 target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
 target0:0:9: Ending Domain Validation
 target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
  Vendor: IBM   Model: IC35L036UCDY10-0  Rev: S25M
  Type:   Direct-Access  ANSI SCSI revision: 03
 target0:0:10: tagged command queuing enabled, command queue depth 16.
 target0:0:10: Beginning Domain Validation
 target0:0:10: asynchronous.
 target0:0:10: wide asynchronous.
 target0:0:10: Domain Validation skipping write tests
 target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31)
sym0: unexpected disconnect
 target0:0:10: Domain Validation Disabing Information Units
 target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
sym0: unexpected disconnect
 target0:0:10: Domain Validation detected failure, dropping back
 target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
 target0:0:10: Ending Domain Validation
  Vendor: IBM   Model: HSBPM2   PU2SCSI  Rev: 0016
  Type:   Enclosure  ANSI SCSI revision: 02
 target0:0:14: Beginning Domain Validation
 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 target0:0:14: Ending Domain Validation
  Vendor: IBM   Model: HSBPD4M  PU3SCSI  Rev: 0016
  Type:   Enclosure  ANSI SCSI revision: 02
 target0:0:15: Beginning Domain Validation
 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
 target0:0:15: Ending Domain Validation
sym1: <1010-66> rev 0x1 at pci 0001:01:01.1 irq 116
sym1: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym1: SCSI BUS has been reset.
scsi1 : sym-2.2.1
sym2: <1010-66> rev 0x1 at pci 0001:41:01.0 irq 119
sym2: No NVRAM, ID 7, Fast-80, LVD, parity checking
sym2: SCSI BUS has been reset.
scsi2 : sym-2.2.1
sym3: <1010-66> rev 0x1 at pci 0001:41:01.1 irq 120
sym3: N

Re: [PATCH] Speedup FAT filesystem directory reads

[Jan Engelhardt]

>We like a plain text, not attachment, see Documentation/SubmittingPatches.
>Anyway, thanks for nice work.

|Exception:  If your mailer is mangling patches then someone may ask
|you to re-send them using MIME.

from the doc ;)
-
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: Old api files, rewrite or delete?

[Jan Engelhardt]

> Nothing, I don't only want to rewrite driver, which others do not use.

Why rewrite? (unless it's an important api change) If it's some optimization 
patch that requires an almost-rewrite, well, do it and see if it gets 
accepted.



Jan Engelhardt
-- 
-
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: make modules Segfault

[Jan Engelhardt]

>> Gnu C  2.96
>
> Seriously, it seems like your machine is flaky.
> And even if it were a kernel source problem,
> gcc should never have an internal error.
> But gcc-2.96 is so old that it's not supported anymore.

Wasnot 2.96 the bugged one?


Jan Engelhardt
-- 
-
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: /proc question

[Jan Engelhardt]

> I have a zombie process which has apparently died for some unknown reason.. I
> know it was terminated by a signal (found that from the 9th field (sheduler
> flags) in /proc/pid/stat)

Start the process under the observation of strace.

> However, I'm trying to figure out what signal killed it.


Jan Engelhardt
-- 
-
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] kernel: use kcalloc instead kmalloc/memset

[Pekka J Enberg]

Hi Andrew,

Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > This patch converts kernel/ to use kcalloc instead of kmalloc/memset.

On Thu, 4 Aug 2005, Andrew Morton wrote:
> grr.

I am learning grep. Please don't eat me!

> >  -  struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
> >  +  struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL);
> 
> Notice how every conversion you did passes in `1' in the first argument?
> 
> And that's going to happen again and again and again.  Each callsite
> needlessly passing that silly third argument, adding more kernel text.
> 
> If we're going to do this, we should add a two-arg helper function first,
> and use that, no?

This was discussed some time ago [1] and here's a patch for you to do 
that.

Pekka

  1. http://marc.theaimsgroup.com/?l=linux-kernel&m=111279001428661&w=2

[PATCH] use kzalloc instead of kmalloc/memset

This patch introduces a kzalloc wrapper and converts kernel/ to use it.

Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---

 include/linux/slab.h |5 +
 kernel/intermodule.c |3 +--
 kernel/params.c  |4 ++--
 kernel/power/pm.c|3 +--
 kernel/resource.c|3 +--
 kernel/workqueue.c   |3 +--
 6 files changed, 11 insertions(+), 10 deletions(-)

Index: 2.6/kernel/resource.c
===
--- 2.6.orig/kernel/resource.c
+++ 2.6/kernel/resource.c
@@ -430,10 +430,9 @@ EXPORT_SYMBOL(adjust_resource);
  */
 struct resource * __request_region(struct resource *parent, unsigned long 
start, unsigned long n, const char *name)
 {
-   struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
+   struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL);
 
if (res) {
-   memset(res, 0, sizeof(*res));
res->name = name;
res->start = start;
res->end = start + n - 1;
Index: 2.6/kernel/intermodule.c
===
--- 2.6.orig/kernel/intermodule.c
+++ 2.6/kernel/intermodule.c
@@ -39,7 +39,7 @@ void inter_module_register(const char *i
struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
 
-   if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
+   if (!(ime_new = kzalloc(sizeof(*ime), GFP_KERNEL))) {
/* Overloaded kernel, not fatal */
printk(KERN_ERR
"Aiee, inter_module_register: cannot kmalloc entry for 
'%s'\n",
@@ -47,7 +47,6 @@ void inter_module_register(const char *i
kmalloc_failed = 1;
return;
}
-   memset(ime_new, 0, sizeof(*ime_new));
ime_new->im_name = im_name;
ime_new->owner = owner;
ime_new->userdata = userdata;
Index: 2.6/kernel/params.c
===
--- 2.6.orig/kernel/params.c
+++ 2.6/kernel/params.c
@@ -542,8 +542,8 @@ static void __init kernel_param_sysfs_se
 {
struct module_kobject *mk;
 
-   mk = kmalloc(sizeof(struct module_kobject), GFP_KERNEL);
-   memset(mk, 0, sizeof(struct module_kobject));
+   mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL);
+   BUG_ON(!mk);
 
mk->mod = THIS_MODULE;
kobj_set_kset_s(mk, module_subsys);
Index: 2.6/kernel/power/pm.c
===
--- 2.6.orig/kernel/power/pm.c
+++ 2.6/kernel/power/pm.c
@@ -60,9 +60,8 @@ struct pm_dev *pm_register(pm_dev_t type
   unsigned long id,
   pm_callback callback)
 {
-   struct pm_dev *dev = kmalloc(sizeof(struct pm_dev), GFP_KERNEL);
+   struct pm_dev *dev = kzalloc(sizeof(struct pm_dev), GFP_KERNEL);
if (dev) {
-   memset(dev, 0, sizeof(*dev));
dev->type = type;
dev->id = id;
dev->callback = callback;
Index: 2.6/kernel/workqueue.c
===
--- 2.6.orig/kernel/workqueue.c
+++ 2.6/kernel/workqueue.c
@@ -310,10 +310,9 @@ struct workqueue_struct *__create_workqu
 
BUG_ON(strlen(name) > 10);
 
-   wq = kmalloc(sizeof(*wq), GFP_KERNEL);
+   wq = kzalloc(sizeof(*wq), GFP_KERNEL);
if (!wq)
return NULL;
-   memset(wq, 0, sizeof(*wq));
 
wq->name = name;
/* We don't need the distraction of CPUs appearing and vanishing. */
Index: 2.6/include/linux/slab.h
===
--- 2.6.orig/include/linux/slab.h
+++ 2.6/include/linux/slab.h
@@ -103,6 +103,11 @@ extern void *kcalloc(size_t, size_t, uns
 extern void kfree(const void *);
 extern unsigned int ksize(const void *);
 
+static inline void *kzalloc(size_t size, unsigned int __nocast flags)
+{
+   return kcalloc(1, size, flags);
+}
+
 #ifdef CONFIG_NUMA
 extern void *kmem_cache_alloc_node(kmem_cache_t *, int 

Re: /proc question

[Davy Durham]

Jan Engelhardt wrote:


I have a zombie process which has apparently died for some unknown reason.. I
know it was terminated by a signal (found that from the 9th field (sheduler
flags) in /proc/pid/stat)
   



Start the process under the observation of strace.

 


However, I'm trying to figure out what signal killed it.
   




Jan Engelhardt
 

Wish I could.. but it's already happened (to a lot of processes for the 
same reason)


It's an intermittant problem and can't really reproduce it at will.

I've redeployed the binary now so I can hopefully attach to it with gdb 
to figure out some things next time it does happen.

-
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] kernel: use kcalloc instead kmalloc/memset

[Andrew Morton]

Pekka J Enberg <[EMAIL PROTECTED]> wrote:
>
> [PATCH] use kzalloc instead of kmalloc/memset
> 

dammit, I was hoping for akpmalloc()

>  
> +static inline void *kzalloc(size_t size, unsigned int __nocast flags)
> +{
> + return kcalloc(1, size, flags);
> +}
> +

That'll generate just as much code as simply using kcalloc(1, ...).  This
function should be out-of-line and EXPORT_SYMBOL()ed.  And kcalloc() can
call it too..

-
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: Power consumption HZ100, HZ250, HZ1000: new numbers

[James Bruce]

Ondrej Zary wrote:

James Bruce wrote:

Stephen Clark wrote:
Maybe new desktop systems - but what about the tens of millions of 
old systems that don't.


If it's an old system, it probably doesn't have working ACPI C-states 
though.  Without that, low HZ does not save you anything.  I should 
have said: 99% of desktops with the capability to do ACPI sleep have 
at least one USB device attached (usually a mouse).


[EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/power
active state:C2
max_cstate:  C8
bus master activity: 
states:
C1:  type[C1] promotion[C2] demotion[--] 
latency[000] usage[00052470]
   *C2:  type[C2] promotion[--] demotion[C1] 
latency[090] usage[02699149]


This is PCPartner TXB820DS motherboard (Socket 7, i430TX) with 1998 
Award BIOS and C-states seem to work fine. I've tested it in Windows 98 
some time ago - the CPU is almost cold when idle with ACPI enabled and 
hot with ACPI disabled (that's partly caused by the fact that Windows 9x 
does not HLT the CPU when idle). With Pentium 100MHz in the socket and 
ACPI enabled, I could even touch the CPU (without heatsink) without 
burning my fingers.


Ok I stand corrected, I had no idea there were machines that old where 
ACPI worked correctly in Linux.


Do you see the same kind of heat reduction in Linux as Win98?  What HZ 
value are you using, as the latency for entering C2 on your machine 
looks pretty substantial (Your C2 almost looks like a new machine's C3 
state, which is supposedly the first level where substantial power 
savings occur on a new machines).


 - Jim Bruce
-
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: Symbios problems in recent -mm trees?

[Andrew Morton]

"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
> If you look on http://test.kernel.org/, you'll see in the rightmost
> column there's a yellow box under elm3b70 for 2.6.13-rc4-mm1, but
> current mainline kernels are all green (ie no problems). That means
> one test failed, in this case making an fs on the spare partition. 
> Odd. I went digging ...

Don't you know that testing stuff just creates more work?

> Looks like this got introduced between 2.6.12-mm1 and 2.6.12-mm2
> Sorry, should've caught it earlier. I'll blame OLS or something.
> This is an 8x power4 box running "bare metal" (ie not on top of
> the hypervisor).

sym2 works OK on my little test box with latest -mm lineup, and I have zero
patches which touch that driver.

James, could some of the scsi core rework have caused this?

> seems /dev/sdc1 doesn't exist.
> 07/31/05-02:44:32 processing command: (5) 'fs --partition=1 --mkext2fs 
> --mount -l /mnt/tmp'
> n format
> PARTITION='/dev/sdc1'
> mke2fs 1.35 (28-Feb-2004)
> mkfs.ext2: No such device or address while trying to determine filesystem size
> 07/31/05-02:44:32 fs: creating filesystem ext2 Failed rc = 1
> 
> Looking back at the bootlog (http://test.kernel.org/9609/debug/console.log),
> I see it really not looking very happy (snapshot below).
> 
> Good bootlog is here for comparsion: 
> (http://test.kernel.org/9445/debug/console.log)
> 
> sym0: <1010-66> rev 0x1 at pci 0001:01:01.0 irq 115
> sym0: No NVRAM, ID 7, Fast-80, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.1
>  target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
>   Vendor: IBM   Model: IC35L036UCDY10-0  Rev: S25M
>   Type:   Direct-Access  ANSI SCSI revision: 03
>  target0:0:8: tagged command queuing enabled, command queue depth 16.
>  target0:0:8: Beginning Domain Validation
>  target0:0:8: asynchronous.
>  target0:0:8: wide asynchronous.
>  target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31)
> sym0: unexpected disconnect
>  target0:0:8: Write Buffer failure 700ff
>  target0:0:8: Domain Validation Disabing Information Units
>  target0:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
> sym0: unexpected disconnect
>  target0:0:8: Write Buffer failure 700ff
>  target0:0:8: Domain Validation detected failure, dropping back
>  target0:0:8: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
>  target0:0:8: Ending Domain Validation
>  target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
>   Vendor: IBM   Model: IC35L036UCDY10-0  Rev: S25M
>   Type:   Direct-Access  ANSI SCSI revision: 03
>  target0:0:9: tagged command queuing enabled, command queue depth 16.
>  target0:0:9: Beginning Domain Validation
>  target0:0:9: asynchronous.
>  target0:0:9: wide asynchronous.
>  target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31)
> sym0: unexpected disconnect
>  target0:0:9: Write Buffer failure 700ff
>  target0:0:9: Domain Validation Disabing Information Units
>  target0:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
> sym0: unexpected disconnect
>  target0:0:9: Write Buffer failure 700ff
>  target0:0:9: Domain Validation detected failure, dropping back
>  target0:0:9: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
>  target0:0:9: Ending Domain Validation
>  target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 31)
>   Vendor: IBM   Model: IC35L036UCDY10-0  Rev: S25M
>   Type:   Direct-Access  ANSI SCSI revision: 03
>  target0:0:10: tagged command queuing enabled, command queue depth 16.
>  target0:0:10: Beginning Domain Validation
>  target0:0:10: asynchronous.
>  target0:0:10: wide asynchronous.
>  target0:0:10: Domain Validation skipping write tests
>  target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT IU QAS (12.5 ns, offset 31)
> sym0: unexpected disconnect
>  target0:0:10: Domain Validation Disabing Information Units
>  target0:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 31)
> sym0: unexpected disconnect
>  target0:0:10: Domain Validation detected failure, dropping back
>  target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
>  target0:0:10: Ending Domain Validation
>   Vendor: IBM   Model: HSBPM2   PU2SCSI  Rev: 0016
>   Type:   Enclosure  ANSI SCSI revision: 02
>  target0:0:14: Beginning Domain Validation
>  0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
>  0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
>  0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
>  0:0:14:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
>  target0:0:14: Ending Domain Validation
>   Vendor: IBM   Model: HSBPD4M  PU3SCSI  Rev: 0016
>   Type:   Enclosure  ANSI SCSI revision: 02
>  target0:0:15: Beginning Domain Validation
>  0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
>  0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.
>  0:0:15:0: phase change 6-7 [EMAIL PROTECTED] resid=7.

Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems

[Vojtech Pavlik]

On Fri, Aug 05, 2005 at 12:07:55AM -0400, Michael Krufky wrote:

> >Sounds like a fun thing for post-2.6.13.
> >
> >What does usb-handoff do, precisely?
> >
> I just did a series tests.  This is necessary, because the problem was 
> intermittent for me.  usb-handoff fixes all of my problems!!!
> 
> without using usb-handoff, my ps/2 mouse works 1/10 times
> using usb-handoff, my ps/2 mouse works 10/10 times
> 
> I consider the problem solved... If Dmitry wants to make usb-handoff the 
> default, he has my support :-).
 
Here is a patch from the SuSE kernel CVS. It's been in SuSE's kernels
since 9.1 I believe, and that's a long time.

[usb-handoff-default.diff]

Date: Fri Mar  4 21:53:39 CET 2005
From: Vojtech Pavlik <[EMAIL PROTECTED]>
Subject: Make "usb-handoff" the default, "usb-no-handoff" turns it off.

=

 Documentation/kernel-parameters.txt |1 +
 drivers/pci/quirks.c|8 +++-
 2 files changed, 8 insertions(+), 1 deletion(-)

=

diff -ur linux-2.6.12/Documentation/kernel-parameters.txt 
linux-2.6.12-input/Documentation/kernel-parameters.txt
--- linux-2.6.12/Documentation/kernel-parameters.txt2005-06-24 
15:56:17.0 +0200
+++ linux-2.6.12-input/Documentation/kernel-parameters.txt  2005-06-24 
15:57:06.0 +0200
@@ -1456,6 +1456,7 @@
Format: ,
 
usb-handoff [HW] Enable early USB BIOS -> OS handoff
+   usb-no-handoff  [HW] Disable early USB BIOS -> OS handoff
 
usbhid.mousepoll=
[USBHID] The interval which mice are to be polled at.
diff -ur linux-2.6.12/drivers/pci/quirks.c 
linux-2.6.12-input/drivers/pci/quirks.c
--- linux-2.6.12/drivers/pci/quirks.c   2005-06-24 15:56:17.0 +0200
+++ linux-2.6.12-input/drivers/pci/quirks.c 2005-06-24 15:56:42.0 
+0200
@@ -902,13 +902,23 @@
 #define EHCI_USBLEGCTLSTS  4   /* legacy control/status */
 #define EHCI_USBLEGCTLSTS_SOOE (1 << 13)   /* SMI on ownership change */
 
+#if defined(__i386__) || defined(__x86_64__)
+int usb_early_handoff __devinitdata = 1;   /* Do handoff by default */
+#else
 int usb_early_handoff __devinitdata = 0;
+#endif
 static int __init usb_handoff_early(char *str)
 {
usb_early_handoff = 1;
return 0;
 }
 __setup("usb-handoff", usb_handoff_early);
+static int __init usb_no_handoff_early(char *str)
+{
+   usb_early_handoff = 0;
+   return 0;
+}
+__setup("usb-no-handoff", usb_no_handoff_early);
 
 static void __devinit quirk_usb_handoff_uhci(struct pci_dev *pdev)
 {

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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: [ck] [PATCH] Timer Top was: i386 No-Idle-Hz aka Dynamic-Ticks 3

[Jens Axboe]

On Thu, Aug 04 2005, Daniel Petrini wrote:
> +static LIST_HEAD(timer_list);
> +
> +struct timer_top_info {
> + unsigned intfunc_pointer;
> + unsigned int long   counter;
> + struct list_headlist;   
> +};
> +
> +struct timer_top_info top_info;
> +
> +int account_timer(unsigned int function, struct timer_top_info * top_info)
> +{
> + struct timer_top_info *top;
> +
> + list_for_each_entry (top, &timer_list, list) {
> + /* if it is in the list increment its count */
> + if (top->func_pointer == function) {
> + top->counter += 1;
> + return 0;
> + }
> + }

What protects this list?

> + 
> + /* if you are here then it didnt find so inserts in the list */
> +
> + top = kmalloc(sizeof(struct timer_top_info), GFP_KERNEL);
> + if (!top) 
> + return -ENOMEM;

You can't use GFP_KERNEL here, you are inside the timer base lock.

-- 
Jens Axboe

-
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] kernel: use kcalloc instead kmalloc/memset

[Pekka J Enberg]

On Thu, 4 Aug 2005, Andrew Morton wrote:
> That'll generate just as much code as simply using kcalloc(1, ...).  This
> function should be out-of-line and EXPORT_SYMBOL()ed.  And kcalloc() can
> call it too..

Yes, much better now. Thanks Andrew.

Pekka

[PATCH] introduce kzalloc

This patch introduces a kzalloc wrapper and converts kernel/ to use it.

Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---

 include/linux/slab.h |1 +
 kernel/intermodule.c |3 +--
 kernel/params.c  |4 ++--
 kernel/power/pm.c|3 +--
 kernel/resource.c|3 +--
 kernel/workqueue.c   |3 +--
 mm/slab.c|   19 +++
 7 files changed, 22 insertions(+), 14 deletions(-)

Index: 2.6/kernel/resource.c
===
--- 2.6.orig/kernel/resource.c
+++ 2.6/kernel/resource.c
@@ -430,10 +430,9 @@ EXPORT_SYMBOL(adjust_resource);
  */
 struct resource * __request_region(struct resource *parent, unsigned long 
start, unsigned long n, const char *name)
 {
-   struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
+   struct resource *res = kzalloc(sizeof(*res), GFP_KERNEL);
 
if (res) {
-   memset(res, 0, sizeof(*res));
res->name = name;
res->start = start;
res->end = start + n - 1;
Index: 2.6/kernel/intermodule.c
===
--- 2.6.orig/kernel/intermodule.c
+++ 2.6/kernel/intermodule.c
@@ -39,7 +39,7 @@ void inter_module_register(const char *i
struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
 
-   if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
+   if (!(ime_new = kzalloc(sizeof(*ime), GFP_KERNEL))) {
/* Overloaded kernel, not fatal */
printk(KERN_ERR
"Aiee, inter_module_register: cannot kmalloc entry for 
'%s'\n",
@@ -47,7 +47,6 @@ void inter_module_register(const char *i
kmalloc_failed = 1;
return;
}
-   memset(ime_new, 0, sizeof(*ime_new));
ime_new->im_name = im_name;
ime_new->owner = owner;
ime_new->userdata = userdata;
Index: 2.6/kernel/params.c
===
--- 2.6.orig/kernel/params.c
+++ 2.6/kernel/params.c
@@ -542,8 +542,8 @@ static void __init kernel_param_sysfs_se
 {
struct module_kobject *mk;
 
-   mk = kmalloc(sizeof(struct module_kobject), GFP_KERNEL);
-   memset(mk, 0, sizeof(struct module_kobject));
+   mk = kzalloc(sizeof(struct module_kobject), GFP_KERNEL);
+   BUG_ON(!mk);
 
mk->mod = THIS_MODULE;
kobj_set_kset_s(mk, module_subsys);
Index: 2.6/kernel/power/pm.c
===
--- 2.6.orig/kernel/power/pm.c
+++ 2.6/kernel/power/pm.c
@@ -60,9 +60,8 @@ struct pm_dev *pm_register(pm_dev_t type
   unsigned long id,
   pm_callback callback)
 {
-   struct pm_dev *dev = kmalloc(sizeof(struct pm_dev), GFP_KERNEL);
+   struct pm_dev *dev = kzalloc(sizeof(struct pm_dev), GFP_KERNEL);
if (dev) {
-   memset(dev, 0, sizeof(*dev));
dev->type = type;
dev->id = id;
dev->callback = callback;
Index: 2.6/kernel/workqueue.c
===
--- 2.6.orig/kernel/workqueue.c
+++ 2.6/kernel/workqueue.c
@@ -310,10 +310,9 @@ struct workqueue_struct *__create_workqu
 
BUG_ON(strlen(name) > 10);
 
-   wq = kmalloc(sizeof(*wq), GFP_KERNEL);
+   wq = kzalloc(sizeof(*wq), GFP_KERNEL);
if (!wq)
return NULL;
-   memset(wq, 0, sizeof(*wq));
 
wq->name = name;
/* We don't need the distraction of CPUs appearing and vanishing. */
Index: 2.6/include/linux/slab.h
===
--- 2.6.orig/include/linux/slab.h
+++ 2.6/include/linux/slab.h
@@ -100,6 +100,7 @@ found:
 }
 
 extern void *kcalloc(size_t, size_t, unsigned int __nocast);
+extern void *kzalloc(size_t, unsigned int __nocast);
 extern void kfree(const void *);
 extern unsigned int ksize(const void *);
 
Index: 2.6/mm/slab.c
===
--- 2.6.orig/mm/slab.c
+++ 2.6/mm/slab.c
@@ -2555,6 +2555,20 @@ void kmem_cache_free(kmem_cache_t *cache
 EXPORT_SYMBOL(kmem_cache_free);
 
 /**
+ * kzalloc - allocate memory. The memory is set to zero.
+ * @size: how many bytes of memory are required.
+ * @flags: the type of memory to allocate.
+ */
+void *kzalloc(size_t size, unsigned int __nocast flags)
+{
+   void *ret = kmalloc(size, flags);
+   if (ret)
+   memset(ret, 0, size);
+   return ret;
+}
+EXPORT_SYMBOL(kzalloc);
+
+/**
  * kcalloc - allocate memory for an array. The

Re: [linux-usb-devel] Re: Fw: ati-remote strangeness from 2.6.12 onwards

[Frank Loeffler]

Hi,

Andrew Morton wrote:

IOW: what does this (wordwrapped!) patch do?


It changes the keycode the kernel is sending for three keys. For normal 
keyboards there is usually no argument to which keycode to send. An 'a' 
would send the keycoe for an 'a'. This however is a remote control. The 
keys are labled 'OK', 'TV' and 'DVD'. Therefore the kernel currently 
sends the keycodes KEY_OK, KEY_TV and KEY_DVD. The patch changes this to 
KEY_ENTER, KEY_PROG1 and KEY_PROG2.


I do not know about the motivation of this patch, as the kernel 
currently _does_ send keycodes, maybe just not the ones the some users 
might want. IMHO this is an issue of remapping the keycodes in userspace 
and I would like to leave the kernel-codes alone. However, I might not 
see the whole problem here because it is working fine for me.


Btw, Pavel:

> No, I think that you can still diferentiate between them ... they come
> from different keyboard after all. See /dev/input/event*.

How can I tell the consoles of linux which keyboard to use? So far they 
all use all keyboards (which is my usual keyboard mixed with the remote 
control keys). (Yes, I searched google extensivly and no, I do not have 
X on that machine.)


Frank

-
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: question on memory map of process on i386

[Christopher Friesen]

Keith Owens wrote:


The gate page is a section of code that is generated as part of the
kernel build.  At run time, the gate page is mapped into all the user
space processes.  There is also a virtual dynamic .so (vdso) file that
is created by the kernel and picked up by the linker, the vdso maps the
kernel entries in the gate page.  Run this command and look for "gate".


Okay, I suspected it might be something like this.

Why does find_vma() fail for that page though?  This confuses some code 
that I wrote.  Do I have to teach my stuff about get_gate_vma() and 
in_gate_area()?


Chris
-
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] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Jim MacBaine]

I just borrowed a power meter to see (or not to see) real effects of
dyntick. The difference between static 1000 HZ and dynamic HZ is much
less than I expected, only a very little about noise.  With dyntick
disabled at 1000 HZ my laptop needs 31,3 W.  With dyntick enabled I
get 29.8 W, the pmstats-0.2 script shows me that the system is at
35-45 HZ when it is idle.

The power consumption difference between 250 HZ static and dyntick is
below the noise, so maybe hardly worth all the struggle.

Regards,
Jim
-
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] Fix HD activity LED with ahci

[Martin Wilck]

All right,

this looks like a pretty broad agreement on this issue.
Jeff, would you please apply this patch?

Regards,
Martin


Patch: fix wrong HD activity control by ahci driver
Signed-off-by: [EMAIL PROTECTED]

The ahci driver 1.0 sets the SActive bit on every transaction,
causing the LED to light up. The SActive bit is used only for
native command queuing (NCQ) which the current driver version 
doesn't implement. Resetting the SActive bit is the device's 
responsibility (by sending a "Set Device Bits FIS" to the
host adapter) but this is not required in response to 
non-NCQ commands, and (most) devices don't. Thus the LED 
stays always on. This patch fixes the LED behavior.

Spec references:
http://www.intel.com/technology/serialata/pdf/rev1_1.pdf, sec. 3.3.13, 5.5.1
http://www.serialata.org/docs/serialata10a.pdf
http://www.intel.com/design/storage/papers/25266401.pdf

--- linux-2.6.13-rc5/drivers/scsi/ahci.c.orig	2005-08-04 08:14:44.0 +0200
+++ linux-2.6.13-rc5/drivers/scsi/ahci.c	2005-08-04 08:19:06.0 +0200
@@ -696,9 +696,6 @@ static int ahci_qc_issue(struct ata_queu
 	struct ata_port *ap = qc->ap;
 	void *port_mmio = (void *) ap->ioaddr.cmd_addr;
 
-	writel(1, port_mmio + PORT_SCR_ACT);
-	readl(port_mmio + PORT_SCR_ACT);	/* flush */
-
 	writel(1, port_mmio + PORT_CMD_ISSUE);
 	readl(port_mmio + PORT_CMD_ISSUE);	/* flush */
 

[RFC][2.6.12.3] IRQ compression/sharing patch

[James Cleverdon]

Due to some device driver issues, I built this iteration of the patch 
vs. 2.6.12.3.

(Sorry about the attachment, but KMail is still word wrapping inserted 
files.)

Background:

Here's a patch that builds on Natalie Protasevich's IRQ compression 
patch and tries to work for MPS boots as well as ACPI.  It is meant for 
a 4-node IBM x460 NUMA box, which was dying because it had interrupt 
pins with GSI numbers > NR_IRQS and thus overflowed irq_desc.

The problem is that this system has 280 GSIs (which are 1:1 mapped with 
I/O APIC RTEs) and an 8-node box would have 560.  This is much bigger 
than NR_IRQS (224 for both i386 and x86_64).  Also, there aren't enough 
vectors to go around.  There are about 190 usable vectors, not counting 
the reserved ones and the unused vectors at 0x20 to 0x2F.  So, my patch 
attempts to compress the GSI range and share vectors by sharing IRQs.


-- 
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
diff -pruN 2.6.12.3/arch/i386/kernel/acpi/boot.c n12.3/arch/i386/kernel/acpi/boot.c
--- 2.6.12.3/arch/i386/kernel/acpi/boot.c	2005-07-15 14:18:57.0 -0700
+++ n12.3/arch/i386/kernel/acpi/boot.c	2005-08-04 00:01:10.199710211 -0700
@@ -42,6 +42,7 @@
 static inline void  acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
 extern void __init clustered_apic_check(void);
 static inline int ioapic_setup_disabled(void) { return 0; }
+extern int gsi_irq_sharing(int gsi);
 #include 
 
 #else	/* X86 */
@@ -51,6 +52,9 @@ static inline int ioapic_setup_disabled(
 #include 
 #endif	/* CONFIG_X86_LOCAL_APIC */
 
+static inline int gsi_irq_sharing(int gsi) { return gsi; }
+
+
 #endif	/* X86 */
 
 #define BAD_MADT_ENTRY(entry, end) (	\
@@ -453,7 +457,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
  		*irq = IO_APIC_VECTOR(gsi);
 	else
 #endif
-		*irq = gsi;
+		*irq = gsi_irq_sharing(gsi);
 	return 0;
 }
 
diff -pruN 2.6.12.3/arch/x86_64/Kconfig n12.3/arch/x86_64/Kconfig
--- 2.6.12.3/arch/x86_64/Kconfig	2005-07-15 14:18:57.0 -0700
+++ n12.3/arch/x86_64/Kconfig	2005-08-03 21:31:07.487451167 -0700
@@ -280,13 +280,13 @@ config HAVE_DEC_LOCK
 	default y
 
 config NR_CPUS
-	int "Maximum number of CPUs (2-256)"
-	range 2 256
+	int "Maximum number of CPUs (2-255)"
+	range 2 255
 	depends on SMP
-	default "8"
+	default "16"
 	help
 	  This allows you to specify the maximum number of CPUs which this
-	  kernel will support. Current maximum is 256 CPUs due to
+	  kernel will support. Current maximum is 255 CPUs due to
 	  APIC addressing limits. Less depending on the hardware.
 
 	  This is purely to save memory - each supported CPU requires
diff -pruN 2.6.12.3/arch/x86_64/kernel/io_apic.c n12.3/arch/x86_64/kernel/io_apic.c
--- 2.6.12.3/arch/x86_64/kernel/io_apic.c	2005-07-15 14:18:57.0 -0700
+++ n12.3/arch/x86_64/kernel/io_apic.c	2005-08-03 21:31:07.488451039 -0700
@@ -56,7 +56,7 @@ int nr_ioapic_registers[MAX_IO_APICS];
  * Rough estimation of how many shared IRQs there are, can
  * be changed anytime.
  */
-#define MAX_PLUS_SHARED_IRQS NR_IRQS
+#define MAX_PLUS_SHARED_IRQS NR_IRQ_VECTORS
 #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + NR_IRQS)
 
 /*
@@ -182,6 +182,8 @@ static void clear_IO_APIC (void)
 			clear_IO_APIC_pin(apic, pin);
 }
 
+static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] = 0xFF };
+
 /*
  * support for broken MP BIOSs, enables hand-redirection of PIRQ0-7 to
  * specific CPU-side IRQs.
@@ -581,6 +583,64 @@ static inline int irq_trigger(int idx)
 	return MPBIOS_trigger(idx);
 }
 
+static int next_irq = 16;
+
+/*
+ * gsi_irq_sharing -- Name overload!  "irq" can be either a legacy IRQ
+ * in the range 0-15, a linux IRQ in the range 0-223, or a GSI number
+ * from ACPI, which can reach 800 in large boxen.
+ *
+ * Compact the sparse GSI space into a sequential IRQ series and reuse
+ * vectors if possible.
+ */
+int gsi_irq_sharing(int gsi)
+{
+	int i, irq, vector;
+
+	BUG_ON(gsi >= NR_IRQ_VECTORS);
+
+	if (platform_legacy_irq(gsi)) {
+		gsi_2_irq[gsi] = gsi;
+		return gsi;
+	}
+
+	if (gsi_2_irq[gsi] != 0xFF)
+		return (int)gsi_2_irq[gsi];
+
+ retry_vector:
+	vector = assign_irq_vector(gsi);
+
+	/*
+	 * Sharing vectors means sharing IRQs, so scan irq_vectors for previous
+	 * use of vector and if found, return that IRQ.  However, we never want
+	 * to share legacy IRQs, which usually have a different trigger mode
+	 * than PCI.
+	 */
+	for (i = 0; i < NR_IRQS; i++)
+		if (IO_APIC_VECTOR(i) == vector) {
+			if (!platform_legacy_irq(i))
+break;			/* got one */
+			IO_APIC_VECTOR(gsi) = 0;
+			goto retry_vector;
+		}
+	if (i < NR_IRQS) {
+		irq = i;
+		gsi_2_irq[gsi] = i;
+		printk(KERN_INFO "GSI %d sharing vector 0x%02X and IRQ %d\n",
+gsi, vector, irq);
+		return irq;
+	}
+
+	irq = next_irq++;
+	BUG_ON(irq >= NR_IRQS);
+	gsi_2_irq[gsi] = irq;
+	IO_APIC_VECTOR(irq) = vector;
+	printk(KERN_INFO "GSI %d assigned vector 0x%02X and IRQ %d\n",
+			gsi, vector, irq);
+
+	return

Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Con Kolivas]

On Thu, 4 Aug 2005 04:59 pm, Jim MacBaine wrote:
> I just borrowed a power meter to see (or not to see) real effects of
> dyntick. The difference between static 1000 HZ and dynamic HZ is much
> less than I expected, only a very little about noise.  With dyntick
> disabled at 1000 HZ my laptop needs 31,3 W.  With dyntick enabled I
> get 29.8 W, the pmstats-0.2 script shows me that the system is at
> 35-45 HZ when it is idle.
>
> The power consumption difference between 250 HZ static and dyntick is
> below the noise, so maybe hardly worth all the struggle.

That's not the point. We want the power savings without sacrificing the extra 
ticks if we need them.

Cheers,
Con
-
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 disk and HPA

[Oliver Tennert]

On Friday, 22. July 2005 16:47, Alan Cox wrote:
> > Do I interpret it right that the following is done in the above function:
>
> Aside from the version in most kernels being buggy yes
>
> > My question is now: why is an HPA disabled i.e. disprotected when
> > detected? Why not let the HPA alone, because a certain set of disk
> > sectors shall not be accessible by the OS?
>
> Because the HPA is most commonly used to hide all but a fraction of a
> disk to work with older BIOSes.

But as to my knowledge, the HPA was had been introduced to allow HW vendors to 
store things like diagnostic programs in a part of the disk protected from 
partitioning and filesystems. The point is, IF there is an HPA, there MIGHT 
be a partitioning scheme and some filesystems on the disk which rely on the 
size of disk being the native size MINUS the HPA.

Also there might be some contents in the HPA which is vulnerable to deletion 
if exposed to the OS in such a transparent way.

So unconditionally disabling the HPA seems not an unconditionally good idea to 
me.

Why is the HPA not just left alone?

Best regards

Oliver

-- 
"She said, `I know you ... you cannot sing'.  I said, `That's nothing,
you should hear me play piano.'"
-- Morrisey
--
__
creating IT solutions

Dr. Oliver Tennert
Senior Solutions Engineer
CAx Professional Services
science + computing ag
phone   +49(0)7071 9457-598 Hagellocher Weg 71-75   
fax +49(0)7071 9457-411 D-72070 Tuebingen, Germany
[EMAIL PROTECTED]  www.science-computing.de


-
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] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Con Kolivas]

On Thu, 4 Aug 2005 05:04 pm, Con Kolivas wrote:
> On Thu, 4 Aug 2005 04:59 pm, Jim MacBaine wrote:
> > I just borrowed a power meter to see (or not to see) real effects of
> > dyntick. The difference between static 1000 HZ and dynamic HZ is much
> > less than I expected, only a very little about noise.  With dyntick
> > disabled at 1000 HZ my laptop needs 31,3 W.  With dyntick enabled I
> > get 29.8 W, the pmstats-0.2 script shows me that the system is at
> > 35-45 HZ when it is idle.
> >
> > The power consumption difference between 250 HZ static and dyntick is
> > below the noise, so maybe hardly worth all the struggle.
>
> That's not the point. We want the power savings without sacrificing the
> extra ticks if we need them.

Oh but thank you very much for confirming the power savings are around the 5% 
mark. If we don't measure we won't know (and everything else is mental 
masturbation according to Linus ;)).

Cheers,
Con
-
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] i386 No-Idle-Hz aka Dynamic-Ticks 3

[Tony Lindgren]

* Con Kolivas <[EMAIL PROTECTED]> [050804 00:16]:
> On Thu, 4 Aug 2005 05:04 pm, Con Kolivas wrote:
> > On Thu, 4 Aug 2005 04:59 pm, Jim MacBaine wrote:
> > > I just borrowed a power meter to see (or not to see) real effects of
> > > dyntick. The difference between static 1000 HZ and dynamic HZ is much
> > > less than I expected, only a very little about noise.  With dyntick
> > > disabled at 1000 HZ my laptop needs 31,3 W.  With dyntick enabled I
> > > get 29.8 W, the pmstats-0.2 script shows me that the system is at
> > > 35-45 HZ when it is idle.
> > >
> > > The power consumption difference between 250 HZ static and dyntick is
> > > below the noise, so maybe hardly worth all the struggle.
> >
> > That's not the point. We want the power savings without sacrificing the
> > extra ticks if we need them.
> 
> Oh but thank you very much for confirming the power savings are around the 5% 
> mark. If we don't measure we won't know (and everything else is mental 
> masturbation according to Linus ;)).

Dyntick on it's own does not do much. But it allows adding better PM code
later on.

Tony
-
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: Documentation - how to apply patches for various trees

[Rolf Eike Beer]

Jesper Juhl wrote:
>+The 2.6.x.y (-stable) and 2.6.x patches live at
>+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
>+
>+The -rc patches live at
>+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/
>+
>+The -git patches live at
>+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/
>+
>+The -mm kernels live at
>+ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
  ^

To be consistent you must add a space here.

Eike


pgp0fJOY0dFcA.pgp
Description: PGP signature

Re: 2.4.21: Sharing interrupts with serial console

[Russell King]

On Wed, Aug 03, 2005 at 06:36:51PM -0700, Chris Budd wrote:
> 1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> explicitly states "The interrupt of the serial console port can't be
> shared."  Does this include *ALL* interrupts?  The code checks for
> sharing only with other serial devices, not *ALL* types of devices
> like I2C, RTC, etc.

I think you'll find that older versions of the serial driver did not
allow the IRQ to be shared by other devices.  It probably got changed
with the addition of PCI card support.

> 2.  While the presence of the comment about not sharing was nice, it
> does not explain "why?"

Connecting a level-active interrupt output to an edge-triggered
interrupt controller input is Bad News(tm) for missing interrupts.

The situation is as follows:
- serial port asserts interrupt output which triggers an interrupt
  to the CPU.  You enter the serial handler.

- Before you clear the serial interrupt, the other device sharing
  this interrupt asserts its interrupt output - so there was no
  edge transition.

- You complete service the serial port, and move on to service the
  other device.

- Before you clear it's interrupt, the serial port re-asserts its
  interrupt output, and again there was no edge transition as far
  as the interrupt controller can tell.

- You complete servicing the other device and leave return from
  interrupt mode.

>From this point on, neither device can cause an interrupt to be sent
to the CPU again.

The above is rather long to put in a comment.

> Why can't we share the serial console interrupt?
> The serial console seems to work when I alter serial.c to
> skip this check for the sharing of interrupts with the serial console.

If the interrupt is shared, it's possible for the interrupt handler to
service the serial port while it's being used to send a kernel message,
and thereby disrupt the kernel message output.

> 3.  Does the hardware platform matter?  We are running Linux 2.4.21 on
> an embedded XScale(ARM)-based board.

Depends how you've connected the serial port interrupt.  Edge triggered
inputs bad, level triggered good.

If your Intel hardware doesn't have level triggered input capabilities,
please apply customer pressure to Intel to ensure that they consider it
for their future ARM-based designs.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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: Is anyone maintaining the smb filesystem?

[tvrtko . ursulin]

On 03/08/2005 17:03:04 linux-kernel-owner wrote:

>Is anyone maintaining the smb filesystem in the Linux kernel?

It probably won't help you much, but I had the same problem few months 
ago. There was a bug in smbfs which I tried to discuss with someone, and 
after failing to contact the maintainer, I sent the fix to Linus. I don't 
think even he managed to get a response from Urban or someone else. The 
fix went in so I stopped chasing it.

So it looks like smbfs is not maintained.


-
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] cpqarray: ioctl support to configure LUNs dynamically

[Arjan van de Ven]

On Thu, 2005-08-04 at 10:15 +0530, Saripalli, Venkata Ramanamurthy
(STSD) wrote:
> Patch 2 of 3
> This patch adds support for IDAREGNEWDISK, IDADEREGDISK, IDAGETLOGINFO
> ioctls required
> to configure LUNs dynamically on SA4200 controller using ACU.


I don't think it's a good idea to add new ioctls to drivers like 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: [PATCH linux-2.6.13-rc3] SATA: rewritten sil24 driver

[Tejun Heo]

 Hi, again, Edward.

 Bad news...

On Tue, Aug 02, 2005 at 03:56:05PM -0700, Edward Falk wrote:
> 
> Again, you would need to fetch them from the returned FIS structure. 
> Here's a code fragment derived from SiI's issue_soft_reset() function:
> 
>   struct Port_Registers *port_base = yadayada;
>   struct sil_port_priv *pp = ap->private_data;
>   struct Port_Registers *PR;  /* in memory */
>   dma_addr_t paddr = pp->pc_dma; /* physical address base */
> 
>   PR = (struct Port_Registers *) (&pp->pc->mregs);
>   port_base = yadayada;
>   slot = 0;
>   slotp = &PR->Slot[slot];
>   memset(&slotp->Prb, 0, sizeof(slotp->Prb));
>   slotp->Prb.Control = 0x80;  /* soft reset */
>   slotp->Prb.FisType == 0;
>   writel(paddr, &port_base->CmdActivate[slot].s.ActiveLow);
>   if (!sil_wait_for_completion(port_base)) {
>   /* timeout or error */
>   return ATA_DEV_NONE;
>   } else {
>   /* Examine slot for taskfile registers */
>   slotp = port_base->Slot[slot];
>   if (slotp->Prb.FisType != 0x34 &&
>   slotp->Prb.FisType != 0x5F) {
>   /* WTF?  Wrong FIS Type */
>   return ATA_DEV_NONE;
>   }
>   if (slotp->Prb.CylLow == 0 &&
>   slotp->Prb.CylHigh == 0)
>   return ATA_DEV_ATA;
>   if (slotp->Prb.CylLow == 0x14 &&
>   slotp->Prb.CylHigh == 0xEB)
>   return ATA_DEV_ATAPI;
>   if (slotp->Prb.CylLow == 0x69 &&
>   slotp->Prb.CylHigh == 0x96)
>   return ATA_DEV_PORT_MULTIPLIER;
>   printk(KERN_WARN "unknown ATA device signature %x.%x\n",
>   slotp->Prb.CylLow, slotp->Prb.CylHigh);
>   return ATA_DEV_NONE;
>   }

 Reading FIS off the cotroller's PRB doesn't seem to work.  I've added
the following code to the preview sil24 driver after completing soft
reset.

writel((u32) paddr, &port_base->CmdActivate[0].s.ActiveLow);
if (!sil_wait_for_completion(port_base)) {
struct Port_Request_Block *prb = &port_base->Slot[0].Prb;
printk("POSTRESET c:p=%04x:%04x rc=%08x\n"
   "fis=%08x:%08x:%08x:%08x\n",
   prb->Control, prb->Protocol, prb->ReceiveCount,
   prb->AsDword_1, prb->AsDword_2,
   prb->AsDword_3, prb->AsDword_4);
return ATA_DEV_ATA; 
} else  {
 printk("sata_sil24: Port Not Ready status=%x\n",
port_base->CtrlSetStatus);
return ATA_DEV_NONE;
}

 And, this is what I get.

sata_sil24: Issuing soft reset to phys=1f4f2000
POSTRESET c:p=0080: rc=
fis=0150:0001::0001

 Which, apparantly, isn't a valid D2H FIS.

 Here are some more dumps of contoller's PRB from my sil24 driver.
PRE ISSUE is the values of PRB regs before issueing a command.  CMD is
the command to issue in the consistent memory.  POST ISSUE and POST
INTR are respectively after issueing a command and processing a
interrupt.

** POST RESET
c:p=: rc=0200
fis=0050fc90:e000::
** PRE ISSUE
c:p=: rc=0200
fis=0050fc90:e000::
** CMD
c:p=: rc=
fis=00ec8027:a000::0800
** POST ISSUE
c:p=: rc=
fis=1f57d000::1f57d000:
** POST INTERRUPT
c:p=0200: rc=0200
fis=0050d000:a000:1f00:00ff
ata6: dev 0 ATA, max UDMA7, 312581808 sectors: lba48

 Is there something more to do to get received FIS from PRB?

 Thanks.

-- 
tejun
-
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] updated - Automatically enable bigsmp when we have more than 8 CPUs

[Andi Kleen]

On Wed, Aug 03, 2005 at 04:01:14PM -0700, Venkatesh Pallipadi wrote:
> 
> Below is the updated patch.

Looks good. Only minor nit.

> +++ linux-2.6.13-rc3-auto/arch/i386/kernel/setup.c2005-08-03 
> 14:33:34.450182216 -0700
> @@ -1593,8 +1594,13 @@ void __init setup_arch(char **cmdline_p)
>*/
>   acpi_boot_table_init();
>   acpi_boot_init();
> -#endif
>  
> +#ifdef CONFIG_X86_PC
> + if (def_to_bigsmp) {
> + printk(KERN_WARNING "More than 8 CPUs detected and 
> CONFIG_X86_PC cannot handle it. Use CONFIG_X86_GENERICARCH or 
> CONFIG_X86_BIGSMP.\n");

Isn't that printk line longer than 80 characters?  Will it even fit 
on the screen? 

-Andi
-
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: [RFC][2.6.12.3] IRQ compression/sharing patch

[Andi Kleen]

On Thu, Aug 04, 2005 at 12:05:50AM -0700, James Cleverdon wrote:

> diff -pruN 2.6.12.3/arch/i386/kernel/acpi/boot.c 
> n12.3/arch/i386/kernel/acpi/boot.c
> --- 2.6.12.3/arch/i386/kernel/acpi/boot.c 2005-07-15 14:18:57.0 
> -0700
> +++ n12.3/arch/i386/kernel/acpi/boot.c2005-08-04 00:01:10.199710211 
> -0700
> @@ -42,6 +42,7 @@
>  static inline void  acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
>  extern void __init clustered_apic_check(void);
>  static inline int ioapic_setup_disabled(void) { return 0; }
> +extern int gsi_irq_sharing(int gsi);
>  #include 
>  
>  #else/* X86 */
> @@ -51,6 +52,9 @@ static inline int ioapic_setup_disabled(
>  #include 
>  #endif   /* CONFIG_X86_LOCAL_APIC */
>  
> +static inline int gsi_irq_sharing(int gsi) { return gsi; }

Why is this different for i386/x86-64? It shouldn't.

As a unrelated note we really need to get rid of this whole ifdef block.

> +++ n12.3/arch/x86_64/Kconfig 2005-08-03 21:31:07.487451167 -0700
> @@ -280,13 +280,13 @@ config HAVE_DEC_LOCK
>   default y
>  
>  config NR_CPUS
> - int "Maximum number of CPUs (2-256)"
> - range 2 256
> + int "Maximum number of CPUs (2-255)"
> + range 2 255
>   depends on SMP
> - default "8"
> + default "16"

Don't change the default please.

> +static int next_irq = 16;

Won't this need a lock for hotplug later?

> +
> + retry_vector:
> + vector = assign_irq_vector(gsi);
> +
> + /*
> +  * Sharing vectors means sharing IRQs, so scan irq_vectors for previous
> +  * use of vector and if found, return that IRQ.  However, we never want
> +  * to share legacy IRQs, which usually have a different trigger mode
> +  * than PCI.
> +  */

Can we perhaps force such sharing early temporarily even when the table
is not filled up?  This way we would get better test coverage of all
of  this.

That would be later disabled of course.

Rest looks ok to me.

-Andi
-
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] push rounding up of relative request to schedule_timeout()

[Roman Zippel]

Hi,

Andrew, please drop this patch. 
Nish, please stop fucking around with kernel APIs.

On Wed, 3 Aug 2005, Nishanth Aravamudan wrote:

> > The "jiffies_to_msecs(msecs_to_jiffies(timeout_msecs) + 1)" case (when the 
> > process is immediately woken up again) makes the caller suspectible to 
> > timeout manipulations and requires constant reauditing, that no caller 
> > gets it wrong, so it's better to avoid this error source completely.

Nish, did you read this? Is my English this bad?

> --- 2.6.13-rc5/kernel/timer.c 2005-08-01 12:31:53.0 -0700
> +++ 2.6.13-rc5-dev/kernel/timer.c 2005-08-03 17:30:10.0 -0700
> @@ -1134,7 +1134,7 @@ fastcall signed long __sched schedule_ti
>   }
>   }
>  
> - expire = timeout + jiffies;
> + expire = timeout + jiffies + 1;
>  
>   init_timer(&timer);
>   timer.expires = expire;

And a little later it does:

timeout = expire - jiffies;

which means callers can get back a larger timeout.
Nish, did you check and fix _all_ users? I can easily find a number of 
users which immediately use the return value as next timeout.
There are _a_lot_ of schedule_timeout(1) for small busy loops, these are 
asking for "please schedule until next tick". Did you check that these are 
still ok?
schedule_timeout() is arguably a broken API, but can we please _first_ 
come up with a plan to fix this, before we break even more?

bye, Roman
-
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] Remove suspend() calls from shutdown path

[Benjamin Herrenschmidt]

Hi Andrew !

This patch remove the calls to device_suspend() from the shutdown path
that were added sometime during 2.6.13-rc*. They aren't working properly
on a number of configs (I got reports from both ppc powerbook users and
x86 users) causing the system to not shutdown anymore.

I think it isn't the right approach at the moment anyway. We have
already a shutdown() callback for the drivers that actually care about
shutdown and the suspend() code isn't yet in a good enough shape to be
so much generalized. Also, the semantics of suspend and shutdown are
slightly different on a number of setups and the way this was patched in
provides little way for drivers to cleanly differenciate. It should have
been at least a different message.

For 2.6.13, I think we should revert to 2.6.12 behaviour and have a
working suspend back.

Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Index: linux-work/kernel/sys.c
===
--- linux-work.orig/kernel/sys.c2005-08-01 14:03:46.0 +0200
+++ linux-work/kernel/sys.c 2005-08-04 11:32:51.0 +0200
@@ -404,7 +404,6 @@
 {
notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
system_state = SYSTEM_HALT;
-   device_suspend(PMSG_SUSPEND);
device_shutdown();
printk(KERN_EMERG "System halted.\n");
machine_halt();
@@ -415,7 +414,6 @@
 {
notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
system_state = SYSTEM_POWER_OFF;
-   device_suspend(PMSG_SUSPEND);
device_shutdown();
printk(KERN_EMERG "Power down.\n");
machine_power_off();


-
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/2] cpqfc: fix for "Using too much stach" in 2.6 kernel

[Rolf Eike Beer]

Saripalli, Venkata Ramanamurthy (STSD) wrote:
>Patch 1 of 2
>
>This patch fixes the "#error this is too much stack" in 2.6 kernel.
>Using kmalloc to allocate memory to ulFibreFrame.

Good idea.

>Please consider this for inclusion

Your patch is line-wrapped and can't be applied. Your second patch is also 
line wrapped. And it touches this file in a different way so they can't be 
applied cleanly over each other.

>diff -burpN old/drivers/scsi/cpqfcTScontrol.c
>new/drivers/scsi/cpqfcTScontrol.c
>--- old/drivers/scsi/cpqfcTScontrol.c  2005-07-12 22:52:29.0
>+0530
>+++ new/drivers/scsi/cpqfcTScontrol.c  2005-07-18 22:19:54.229947176
>+0530
>@@ -606,22 +606,25 @@ static int PeekIMQEntry( PTACHYON fcChip
> if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 )
> {
>   TachFCHDR_GCMND* fchs;
>-#error This is too much stack
>-  ULONG ulFibreFrame[2048/4];  // max DWORDS in incoming FC
>Frame
>+  ULONG *ulFibreFrame;  // max DWORDS in incoming FC Frame
> USHORT SFQpi = (USHORT)(fcChip->IMQ->QEntry[CI].word[0] &
>0x0fffL);

Why not use a void* here as type for the buffer? Or even better: remove this 
at all and directly use fchs as target, because this is the only place where 
this buffer goes to?

>+ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);

The size bug was already found by Dave Jones. This never should be written 
this way (not your fault). The array should have been [2048/sizeof(ULONG)].

> CpqTsGetSFQEntry( fcChip,
> SFQpi,// SFQ producer ndx
>   ulFibreFrame, // contiguous dest. buffer
>   FALSE);   // DON'T update chip--this is a "lookahead"

CpqTsGetSFQEntry() should be modified to take a void* as third argument IMHO.

>-fchs = (TachFCHDR_GCMND*)&ulFibreFrame;
>+fchs = (TachFCHDR_GCMND*)ulFibreFrame;
>   if( fchs->pl[0] == ELS_LILP_FRAME)
> {
>+  kfree(ulFibreFrame);
> return 1; // found the LILP frame!
> }
> else
> {
>+  kfree(ulFibreFrame);
>   // keep looking...
> }
>   }

What a ...

I would prefer if someone goes and really cleans up this driver.

-read Documentation/Codingstyle
-go through Lindent.
-kill this ULONG stuff. If you want __u32 use it.
-use void* for "just a buffer"
-don't use hardcoded type sizes. Use sizeof(type) to make clear what kind of 
magic is going on.
-this is C, not C++. No C++ comments, use fewer uppercase letters.

The way it is is very likely to cause people missing what's really going on at 
some places, which will cause errors afterwards.

Eike


pgpdH3O8o3ldS.pgp
Description: PGP signature

Re: opening linux char device file in user thread.

[Bhanu Kalyan Chetlapalli]

On 8/4/05, P.Manohar <[EMAIL PROTECTED]> wrote:
> 
> hai,
> 
>I have written a daemon which is running in user space, will send some
> data periodically to kernel space. This I have done with the help of a
> device file.
> 
>  It is working, but I want to apply threads mechanism in that daemon. But
> when I split that daemon functionality into a thread and a original
> process. I am unable to
> open the device file. This is happening in both places(either in thread or
> original process).

Try opening the device, get the FD and THEN spawn the thread. this
will help, as the device is opened only once as far as the driver is
concerned. The presence of usage from the thread is felt only in the
reference count of the fd (which should be transparent to user space
and the device driver). Race conditions are assumed to be taken care
of in the kernel module though.

The other way is to open device, write data, close device every time u
write something. This is beneficial if the time between the writes is
seperated by more than a minute. There will be no races etc to take
care of.
 
> The device is opening  when threading is not there.
> 
> Can anybody suggest me?
> 
> Regards,
> P.Manohar.
> 

Bhanu.

> -
> 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/
> 


-- 
The difference between Theory and Practice is more so in Practice than
in Theory.
-
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: [OT] util-linux 2.13-pre1

[Daniel Drake]

Adrian,

Adrian Bunk wrote:

util-linux 2.13-pre1 is available at
  
ftp://ftp.kernel.org/pub/linux/utils/util-linux/testing/util-linux-2.13-pre1.tar.gz


Any comments on the mount patch I sent to you?

Attaching it again now. Please apply.

Thanks,
Daniel
From: Daniel Drake <[EMAIL PROTECTED]>

Some filesystems such as FAT will default to using the umask of the current
process if the user did not specify a umask option.

Currently, mount.c calls umask(022) early on, removing the possibility of the
user-specified umask (at shell level) being used by default.

Removing the umask(022) call solves the problem.

This appears safe to do, because the code which creates files already does this
safely (saves umask, sets umask 022, creates file, restores umask).

Please apply.

--- util-linux-2.13-pre1/mount/mount.c.orig	2005-08-04 11:00:50.0 +0100
+++ util-linux-2.13-pre1/mount/mount.c	2005-08-04 11:00:58.0 +0100
@@ -1466,8 +1466,6 @@ main(int argc, char *argv[]) {
 	if ((p = strrchr(progname, '/')) != NULL)
 		progname = p+1;
 
-	umask(022);
-
 	/* People report that a mount called from init without console
 	   writes error messages to /etc/mtab
 	   Let us try to avoid getting fd's 0,1,2 */

[PATCH] tpm_infineon: Support for new TPM 1.2 and PNPACPI

[Marcel Selhorst]

Hello LKML,

Changelog:
This patch includes support for the new Infineon Trusted Platform Module
SLB 9635 TT 1.2 and does further include ACPI-support for both chip versions
(SLD 9630 TT 1.1 and SLB9635 TT 1.2). Since the ioports and configuration
registers are not correctly set on some machines, the configuration is now
done via PNPACPI, which reads out the correct values out of the DSDT-table.
Note that you have to have CONFIG_PNP, CONFIG_ACPI_BUS and CONFIG_PNPACPI
enabled to run this driver (assuming that mainbaords including a TPM do have
the need for ACPI anyway).

Signed-off-by: Marcel Selhorst <[EMAIL PROTECTED]>
---

diff -pruN linux-2.6.13-rc4-mm1/drivers/char/tpm/Kconfig
linux-new/drivers/char/tpm/Kconfig
--- linux-2.6.13-rc4-mm1/drivers/char/tpm/Kconfig   2005-08-03 
20:07:34.0 +0200
+++ linux-new/drivers/char/tpm/Kconfig  2005-08-04 10:39:08.0 +0200
@@ -17,6 +17,8 @@ config TCG_TPM
  obtained at: .  To
  compile this driver as a module, choose M here; the module
  will be called tpm. If unsure, say N.
+ Note: For more TPM drivers enable CONFIG_PNP, CONFIG_ACPI_BUS
+ and CONFIG_PNPACPI.

 config TCG_NSC
tristate "National Semiconductor TPM Interface"
@@ -36,12 +38,13 @@ config TCG_ATMEL
  as a module, choose M here; the module will be called tpm_atmel.

 config TCG_INFINEON
-   tristate "Infineon Technologies SLD 9630 TPM Interface"
-   depends on TCG_TPM
+   tristate "Infineon Technologies TPM Interface"
+   depends on TCG_TPM && PNPACPI
---help---
- If you have a TPM security chip from Infineon Technologies
- say Yes and it will be accessible from within Linux.  To
- compile this driver as a module, choose M here; the module
+ If you have a TPM security chip from Infineon Technologies
+ (either SLD 9630 TT 1.1 or SLB 9635 TT 1.2) say Yes and it
+ will be accessible from within Linux.
+ To compile this driver as a module, choose M here; the module
  will be called tpm_infineon.
  Further information on this driver and the supported hardware
  can be found at http://www.prosec.rub.de/tpm
diff -pruN linux-2.6.13-rc4-mm1/drivers/char/tpm/tpm_infineon.c
linux-new/drivers/char/tpm/tpm_infineon.c
--- linux-2.6.13-rc4-mm1/drivers/char/tpm/tpm_infineon.c2005-08-03
20:07:34.0 +0200
+++ linux-new/drivers/char/tpm/tpm_infineon.c   2005-08-04 12:19:47.0 
+0200
@@ -1,7 +1,7 @@
 /*
  * Description:
  * Device Driver for the Infineon Technologies
- * SLD 9630 TT Trusted Platform Module
+ * SLD 9630 TT 1.1 and SLB 9635 TT 1.2 Trusted Platform Module
  * Specifications at www.trustedcomputinggroup.org
  *
  * Copyright (C) 2005, Marcel Selhorst <[EMAIL PROTECTED]>
@@ -12,9 +12,10 @@
  * modify it under the terms of the GNU General Public License as
  * published by the Free Software Foundation, version 2 of the
  * License.
- *
  */

+#include 
+#include 
 #include "tpm.h"

 /* Infineon specific definitions */
@@ -26,8 +27,11 @@
 #defineTPM_MSLEEP_TIME 3
 /* gives number of max. msleep()-calls before throwing timeout */
 #defineTPM_MAX_TRIES   5000
-#defineTCPA_INFINEON_DEV_VEN_VALUE 0x15D1
-#defineTPM_DATA(TPM_ADDR + 1) & 0xff
+#defineTPM_INFINEON_DEV_VEN_VALUE  0x15D1
+
+/* These values will be filled after ACPI-call */
+static int TPM_INF_DATA = 0;
+static int TPM_INF_ADDR = 0;

 /* TPM header definitions */
 enum infineon_tpm_header {
@@ -305,9 +309,10 @@ static int tpm_inf_send(struct tpm_chip

 static void tpm_inf_cancel(struct tpm_chip *chip)
 {
-   /* Nothing yet!
-  This has something to do with the internal functions
-  of the TPM. Abort isn't really necessary...
+   /*
+  Since we are using the legacy mode to communicate
+  with the TPM, we have no cancel functions, but have
+  a workaround for interrupting the TPM through WTX.
 */
 }

@@ -345,6 +350,32 @@ static struct tpm_vendor_specific tpm_in
.miscdev = {.fops = &inf_ops,},
 };

+static const struct pnp_device_id tpm_pnp_tbl[] = {
+   /* Infineon TPMs */
+   {"IFX0101", 0},
+   {"IFX0102", 0},
+   {"", 0}
+};
+
+static int __devinit tpm_inf_acpi_probe(struct pnp_dev *dev,
+   const struct pnp_device_id *dev_id)
+{
+   TPM_INF_ADDR = (pnp_port_start(dev, 0) & 0xff);
+   TPM_INF_DATA = ((TPM_INF_ADDR + 1) & 0xff);
+   tpm_inf.base = pnp_port_start(dev, 1);
+   dev_info(&dev->dev, "Found %s with ID %s\n",
+dev->name, dev_id->id);
+   if (!((tpm_inf.base >> 8) & 0xff))
+   tpm_inf.base = 0;
+   return 0;
+}
+
+static struct pnp_driver tpm_inf_pnp = {
+   .name = "tpm_inf_pnp",
+   .id_table = tpm_pnp_tbl,
+   .probe = tpm_inf_acpi_probe,
+};
+
 

Re: 2.6.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918

[Herbert Xu]

On Thu, Aug 04, 2005 at 01:33:29PM +1000, herbert wrote:
> 
> So I suppose we should reset cwnd_quota after tcp_transmit_skb?

Please try this patch to see if this is really the problem or not.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1027,19 +1027,14 @@ static int tcp_write_xmit(struct sock *s
tcp_minshall_update(tp, mss_now, skb);
sent_pkts++;
 
-   /* Do not optimize this to use tso_segs. If we chopped up
-* the packet above, tso_segs will no longer be valid.
-*/
-   cwnd_quota -= tcp_skb_pcount(skb);
-
-   BUG_ON(cwnd_quota < 0);
-   if (!cwnd_quota)
-   break;
-
skb = sk->sk_send_head;
if (!skb)
break;
+
tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
+   cwnd_quota = tcp_cwnd_test(tp, skb);
+   if (!cwnd_quota)
+   break;
}
 
if (likely(sent_pkts)) {

Re: [patch 2/8] x86_64: create sysfs entries for cpu only for present cpus

[Andi Kleen]

On Mon, Aug 01, 2005 at 01:20:19PM -0700, Ashok Raj wrote:
> Need to create sysfs only for cpus that are present. Without which we see
> NR_CPUS entries created when we have CONFIG_HOTPLUG and CONFIG_HOTPLUG_CPU
> enabled.

Thanks looks good.

-Andi

> 
> Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
> --
>  arch/i386/mach-default/topology.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6.13-rc3-ak/arch/i386/mach-default/topology.c
> ===
> --- linux-2.6.13-rc3-ak.orig/arch/i386/mach-default/topology.c
> +++ linux-2.6.13-rc3-ak/arch/i386/mach-default/topology.c
> @@ -76,7 +76,7 @@ static int __init topology_init(void)
>   for_each_online_node(i)
>   arch_register_node(i);
>  
> - for_each_cpu(i)
> + for_each_present_cpu(i)
>   arch_register_cpu(i);
>   return 0;
>  }
> @@ -87,7 +87,7 @@ static int __init topology_init(void)
>  {
>   int i;
>  
> - for_each_cpu(i)
> + for_each_present_cpu(i)
>   arch_register_cpu(i);
>   return 0;
>  }
> 
> --
> 
-
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/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled

[Andi Kleen]

On Mon, Aug 01, 2005 at 01:20:20PM -0700, Ashok Raj wrote:
> No need to enforce_max_cpus when hotplug code is enabled. This
> nukes out cpu_present_map and cpu_possible_map making it impossible to add
> new cpus in the system.

Hmm - i think there was some reason for this early zeroing,
but I cannot remember it right now.

It might be related to some checks later that check max possible cpus.

So it would be still good to have some way to limit max possible cpus.
Maybe with a new option?

-Andi
-
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 4/8] x86_64:Fix cluster mode send_IPI_allbutself to use get_cpu()/put_cpu()

[Andi Kleen]

On Mon, Aug 01, 2005 at 01:20:21PM -0700, Ashok Raj wrote:
> Need to ensure we dont get prempted when we clear ourself from mask when using
> clustered mode genapic code.

It's not needed I think. If the caller wants to execute code
on the current CPU then it has to have disabled preemption
itself already to avoid races. And if not it doesn't care.

One could argue that this function should be always called
with preemption disabled though. Perhaps better a WARN_ON().

-Andi
-
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] Keys: Fix key management syscall interface bugs

[David Howells]

The attached patch fixes five bugs in the key management syscall interface:
  
 (1) add_key() returns 0 rather than EINVAL if the key type is "".  

 Checking the key type isn't "" should be left to lookup_user_key().
  
 (2) request_key() returns ENOKEY rather than EPERM if the key type begins
 with a ".".
  
 lookup_user_key() can't do this because internal key types begin with a
 ".".

 (3) Key revocation always returns 0, even if it fails.  

 (4) Key read can return EAGAIN rather than EACCES under some circumstances.  

 A key is permitted to by read by a process if it doesn't grant read
 access, but it does grant search access and it is in the process's
 keyrings. That search returns EAGAIN if it fails, and this needs
 translating to EACCES.

 (5) request_key() never adds the new key to the destination keyring if one is
 supplied.

 The wrong macro was being used to test for an error condition: PTR_ERR()
 will always return true, whether or not there's an error; this should've
 been IS_ERR().

Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---
warthog>diffstat -p1 keys-ui-fixes-2613rc2mm1.diff 
 security/keys/keyctl.c  |   11 +++
 security/keys/request_key.c |2 +-
 2 files changed, 8 insertions(+), 5 deletions(-)

diff -uNrp linux-2.6.13-rc2-mm1/security/keys/keyctl.c 
linux-2.6.13-rc2-mm1-keys/security/keys/keyctl.c
--- linux-2.6.13-rc2-mm1/security/keys/keyctl.c 2005-07-07 22:23:15.0 
+0100
+++ linux-2.6.13-rc2-mm1-keys/security/keys/keyctl.c2005-08-04 
11:48:12.0 +0100
@@ -49,9 +49,6 @@ asmlinkage long sys_add_key(const char _
goto error;
type[31] = '\0';
 
-   if (!type[0])
-   goto error;
-
ret = -EPERM;
if (type[0] == '.')
goto error;
@@ -144,6 +141,10 @@ asmlinkage long sys_request_key(const ch
goto error;
type[31] = '\0';
 
+   ret = -EPERM;
+   if (type[0] == '.')
+   goto error;
+
/* pull the description into kernel space */
ret = -EFAULT;
dlen = strnlen_user(_description, PAGE_SIZE - 1);
@@ -362,7 +363,7 @@ long keyctl_revoke_key(key_serial_t id)
 
key_put(key);
  error:
-   return 0;
+   return ret;
 
 } /* end keyctl_revoke_key() */
 
@@ -685,6 +686,8 @@ long keyctl_read_key(key_serial_t keyid,
goto can_read_key2;
 
ret = PTR_ERR(skey);
+   if (ret == -EAGAIN)
+   ret = -EACCES;
goto error2;
}
 
diff -uNrp linux-2.6.13-rc2-mm1/security/keys/request_key.c 
linux-2.6.13-rc2-mm1-keys/security/keys/request_key.c
--- linux-2.6.13-rc2-mm1/security/keys/request_key.c2005-07-07 
22:23:15.0 +0100
+++ linux-2.6.13-rc2-mm1-keys/security/keys/request_key.c   2005-08-04 
11:48:12.0 +0100
@@ -405,7 +405,7 @@ struct key *request_key_and_link(struct 
key_user_put(user);
 
/* link the new key into the appropriate keyring */
-   if (!PTR_ERR(key))
+   if (!IS_ERR(key))
request_key_link(key, dest_keyring);
}
 
-
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 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode.

[Andi Kleen]

>  static void flat_send_IPI_allbutself(int vector)
>  {
> +#ifndef CONFIG_HOTPLUG_CPU
>   if (((num_online_cpus()) - 1) >= 1)
>   __send_IPI_shortcut(APIC_DEST_ALLBUT, vector,APIC_DEST_LOGICAL);
> +#else
> + cpumask_t allbutme = cpu_online_map;
> + int me = get_cpu(); /* Ensure we are not preempted when we clear */
> + cpu_clear(me, allbutme);
> + flat_send_IPI_mask(allbutme, vector);
> + put_cpu();

This still needs the num_online_cpus()s check.

-Andi
-
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 8/8] x86_64: Choose physflat for AMD systems only when >8 CPUS.

[Andi Kleen]

On Mon, Aug 01, 2005 at 01:20:25PM -0700, Ashok Raj wrote:
> It is not required to choose the physflat mode when CPU hotplug is enabled 
> and CPUs <=8 case. Use of genapic_flat with the mask version is capable of 
> doing the same, instead of doing the send_IPI_mask_sequence() where its a 
> unicast.
> 
> This is another change that Andi introduced with the physflat mode. 
> 
> Andi: Do you think this is acceptable?

Yes it's ok.

-Andi
-
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.6.12.3] Deny chmod in /proc//

[Johan Veenhuizen]

Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> >Did you mean "chmod"?
>
> No, I really meant chown - which just turned up another should-not-be:
> no warning is generated when trying to chown;
> chmod is even _persistent_ - for the moment.
>

Did you even bother to read my first mail?  Quoting myself:

"The patch does also trigger an EPERM when someone tries
to chown/chgrp an entry (which is currently silently ignored)."
 ^^^

and

"... it is currently possible for the owner of a process to
temporarily chmod the entries."

Those are the problems that my patch fixes!  And NO, chmod is NOT
persistent.  It just appears to be.  The permissions are dropped
when the dentry for a file is released (and with it, the reference
to the temporary inode).  (You might have understood this.
I don't know what you mean by "for the moment".)

It's a very Bad Thing that the chmod succeeds for a while, because
it gives users the impression that the files can be protected
(e.g. /proc//cmdline).  As it is now, you'll have to look
at the kernel source to figure out which files will preserve
their permissions...

> >And I don't even have "smaps".
>
> Just take any file.

Not any file exists under /proc, so I'll rather take a file that
is there for my examples.

Johan
-
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 disk and HPA

[Alan Cox]

On Iau, 2005-08-04 at 09:14 +0200, Oliver Tennert wrote:
> partitioning and filesystems. The point is, IF there is an HPA, there MIGHT 
> be a partitioning scheme and some filesystems on the disk which rely on the 
> size of disk being the native size MINUS the HPA.

Thats fine, Linux is quite happy with such a partitioning table.

> Also there might be some contents in the HPA which is vulnerable to deletion 
> if exposed to the OS in such a transparent way.

By opening the raw disk file yes, but that is not a big concern

> Why is the HPA not just left alone?

As I said before - because in most cases the HPA is used just to fool an
old bios into booting a large disk. 

-
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.6.13-rc4-mm1] Re: Obsolete files in 2.6 tree

[Jiri Slaby]

Jiri Slaby napsal(a):


Alan Cox napsal(a):


drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c





Gamma is defunct certainly
 


Removes gamma sources, headers and pointers from Kconfig and Makefile.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

patch is here (about 70 KiB):
http://www.fi.muni.cz/~xslaby/lnx/gamma.txt


Removes gamma line from Documentation/kernel-parameters.txt

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt

--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -497,8 +497,6 @@ running once the system is up.
   Format: ,
   See also Documentation/input/joystick-parport.txt

-   gamma=  [HW,DRM]
-
   gdth=   [HW,SCSI]
   See header of drivers/scsi/gdth.c.

--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~  [EMAIL PROTECTED]  ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10


diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -497,8 +497,6 @@ running once the system is up.
Format: ,
See also Documentation/input/joystick-parport.txt
 
-   gamma=  [HW,DRM]
-
gdth=   [HW,SCSI]
See header of drivers/scsi/gdth.c.
 

Re: 2.4.21: Sharing interrupts with serial console

[linux-os \(Dick Johnson\)]

On Wed, 3 Aug 2005, Chris Budd wrote:

> I have read 
> http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/preparation-setport.html
> and http://www.linux-mips.org/archives/linux-mips/2004-04/msg00134.html
> and other items, but I still have not found the answers to the
> following questions:
>
> 1.  The rs_init function in ./linux-2.4.21/drivers/char/serial.c
> explicitly states "The interrupt of the serial console port can't be
> shared."  Does this include *ALL* interrupts?  The code checks for
> sharing only with other serial devices, not *ALL* types of devices
> like I2C, RTC, etc.
>
> 2.  While the presence of the comment about not sharing was nice, it
> does not explain "why?"  Why can't we share the serial console
> interrupt?  The serial console seems to work when I alter serial.c to
> skip this check for the sharing of interrupts with the serial console.
>
> 3.  Does the hardware platform matter?  We are running Linux 2.4.21 on
> an embedded XScale(ARM)-based board.
>
> Thanks,
> Chris.
> -

Only LEVEL interrupts can be shared, and all the drivers that
share that one interrupt need to be designed for sharing.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :


The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
-
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.13-rc3-mm3

[Richard Purdie]

On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> Could you try the following patch? I think the problem was that higher 
> addressses were not mappable via the page fault handler. This patch 
> inserts the pmd entry into the pgd as necessary if the pud level is 
> folded.

I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
still hung in memcpy as before and the cmpxchg_fail_flag_update just
increases...

Richard

-
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/

Getting rid of SHMMAX/SHMALL ?

[Andi Kleen]

I noticed that even 64bit architectures have a ridiculously low 
max limit on shared memory segments by default:

#define SHMMAX 0x200 /* max shared seg size (bytes) */
#define SHMMNI 4096  /* max num of segs system wide */
#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */

Even on 32bit architectures it is far too small and doesn't
make much sense. Does anybody remember why we even have this limit?

IMHO per process shm mappings should just be controlled by the normal
process and global mappings with the same heuristics as tmpfs
(by default max memory / 2 or more if shmfs is mounted with more)
Actually I suspect databases will usually want to use more 
so it might even make sense to support max memory - 1/8*max_memory

I would propose to get rid of of shmmax completely
and only keep the old shmall sysctl for compatibility.

Comments?

-Andi
-
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: [ck] [ANNOUNCE] Interbench 0.27

[Gabriel Devenyi]

Hi Con,

You must hate me by now...

The "Gaming" benchmark has the same issue with nan coming out of the 
STDEV calculations, probably requires the same fix as before.


Secondly, the benchmarking of loops_per_ms is running forever, and I 
managed to determine where its happening.


In calibrate loops you run a while loop and iterate to get 1000 for 
run_time, then you calculate it one more time to ensure it was right 
*however* you put a sleep(1) before that. It seems to seriously skew the 
results, as it consistently adds ~500 to run_time, as run_time is now 
1500, it jumps back up to redo because of the goto statement, and runs 
the while loop again, continue ad nausium. I added some simple debugging 
output which prints run time at the end of each while loop, and right 
before the goto if statement, this is the output.


--cut--
loops_per_ms unknown; benchmarking...
while: 224
while: 649
while: 993
while: 1025
while: 976
while: 1001
while: 1000
1494
while: 671
while: 997
while: 1000
1496
--cut--

The solution I used is of course to simply comment out the sleep 
statement, then everything works nicely, however your comments appear to 
indicate that the sleep is there to make the system settle a little, 
perhaps another method needs to be used. Thanks for your time!


--
Gabriel Devenyi
[EMAIL PROTECTED]

Con Kolivas wrote:
Interbench is a benchmark application is designed to benchmark interactivity 
in Linux.


Direct download link:
http://ck.kolivas.org/apps/interbench/interbench-0.27.tar.bz2

Web page:
http://interbench.kolivas.org

Changes:
Standard deviation and average latency calculation was corrected. Gaming 
standard deviation was implemented.


Cheers,
Con
___
[EMAIL PROTECTED]
ck mailing list. Please reply-to-all when posting.
If replying to an email please reply below the original message.
http://bhhdoa.org.au/mailman/listinfo/ck


-
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.6.13-rc4] fix get_user_pages bug

[Robin Holt]

On Wed, Aug 03, 2005 at 12:31:34PM +0100, Hugh Dickins wrote:
> On Wed, 3 Aug 2005, Robin Holt wrote:
> > On Mon, Aug 01, 2005 at 11:18:42AM -0700, Linus Torvalds wrote:
> > > 
> > > Can somebody who saw the problem in the first place please verify?

OK.  I took the three commits:
4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
f33ea7f404e592e4563b12101b7a4d17da6558d7
a68d2ebc1581a3aec57bd032651e013fa609f530

I back ported them to the SuSE SLES9SP2 kernel.  I will add them at
the end so you can tell me if I messed things up.  I was then able
to run the customer test application multiple times without issue.
Before the fix, we had never acheived three consecutive runs that did
not trip the fault.  After the change, it has been in excess of thirty.
I would say this has fixed the problem.  Did I miss anything which
needs to be tested?

Thanks,
Robin Holt


- Patches against SLES9SP2 7.191 kernel -


Adapted for SLES9 SP2 kernel from
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
Index: linux/mm/memory.c
===
--- linux.orig/mm/memory.c  2005-08-03 16:18:31.553626601 -0500
+++ linux/mm/memory.c   2005-08-03 16:24:08.905247901 -0500
@@ -674,7 +674,7 @@ follow_page(struct mm_struct *mm, unsign
pte = *ptep;
pte_unmap(ptep);
if (pte_present(pte)) {
-   if (write && !pte_write(pte))
+   if (write && !pte_dirty(pte))
goto out;
if (write && !pte_dirty(pte)) {
struct page *page = pte_page(pte);
@@ -814,8 +814,7 @@ int get_user_pages(struct task_struct *t
spin_lock(&mm->page_table_lock);
do {
struct page *map;
-   int lookup_write = write;
-   while (!(map = follow_page(mm, start, lookup_write))) {
+   while (!(map = follow_page(mm, start, write))) {
/*
 * Shortcut for anonymous pages. We don't want
 * to force the creation of pages tables for
@@ -823,8 +822,7 @@ int get_user_pages(struct task_struct *t
 * nobody touched so far. This is important
 * for doing a core dump for these mappings.
 */
-   if (!lookup_write &&
-   untouched_anonymous_page(mm,vma,start)) {
+   if (!write && 
untouched_anonymous_page(mm,vma,start)) {
map = ZERO_PAGE(start);
break;
}
@@ -843,14 +841,6 @@ int get_user_pages(struct task_struct *t
default:
BUG();
}
-   /*
-* Now that we have performed a write fault
-* and surely no longer have a shared page we
-* shouldn't write, we shouldn't ignore an
-* unwritable page in the page table if
-* we are forcing write access.
-*/
-   lookup_write = write && !force;
spin_lock(&mm->page_table_lock);
}
if (pages) {






Adapted for SLES9 SP2 kernel from
X-Git-Url: 
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f33ea7f404e592e4563b12101b7a4d17da6558d7
Index: linux/include/linux/mm.h
===
--- linux.orig/include/linux/mm.h   2005-08-03 16:22:55.905794491 -0500
+++ linux/include/linux/mm.h2005-08-03 16:24:48.123938110 -0500
@@ -651,10 +651,16 @@ static inline int page_mapped(struct pag
  * Used to decide whether a process gets delivered SIGBUS or
  * just gets major/minor fault counters bumped up.
  */
-#define VM_FAULT_OOM   (-1)
-#define VM_FAULT_SIGBUS0
-#define VM_FAULT_MINOR 1
-#define VM_FAULT_MAJOR 2
+#define VM_FAULT_OOM   0x00
+#define VM_FAULT_SIGBUS0x01
+#define VM_FAULT_MINOR 0x02
+#define VM_FAULT_MAJOR 0x03
+
+/* 
+ * Special case for get_user_pages.
+ * Must be in a distinct bit from the above VM_FAULT_ flags.
+ */
+#define VM_FAULT_WRITE 0x10
 
 #define offset_in_page(p)  ((unsigned long)(p) & ~PAGE_MASK)
 
@@ -704,7 +710,13 @@ extern pte_t *FASTCALL(pte_alloc_kernel(
 extern pte_t *FASTCALL(pte_alloc_map(struct mm_struct *mm, pmd_t *pmd, 
unsigned long address));
 extern int install_page(struct mm_struct *mm, struct vm_area_struct *vma, 
unsigned long addr, struct page *page, pgp

Re: [ck] [ANNOUNCE] Interbench 0.27

[Con Kolivas]

On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:
> Hi Con,
>
> You must hate me by now...

No. A bug report is a bug report. I hate the fact that I coded up 2000 lines 
of code and am still suffering from a problem in the same 10 lines that I did 
in version .01. PEBKAC. 

> The "Gaming" benchmark has the same issue with nan coming out of the
> STDEV calculations, probably requires the same fix as before.

Anyway Peter Williams has promised to fix it for me (yay!).

> Secondly, the benchmarking of loops_per_ms is running forever, and I
> managed to determine where its happening.
>
> In calibrate loops you run a while loop and iterate to get 1000 for
> run_time, then you calculate it one more time to ensure it was right
> *however* you put a sleep(1) before that. It seems to seriously skew the
> results, as it consistently adds ~500 to run_time, as run_time is now
> 1500, it jumps back up to redo because of the goto statement, and runs
> the while loop again, continue ad nausium. I added some simple debugging
> output which prints run time at the end of each while loop, and right
> before the goto if statement, this is the output.

> The solution I used is of course to simply comment out the sleep
> statement, then everything works nicely, however your comments appear to
> indicate that the sleep is there to make the system settle a little,
> perhaps another method needs to be used. Thanks for your time!

I have to think about it. This seems a problem only on one type of cpu for 
some strange reason (lemme guess; athlon?) and indeed leaving out the sleep 1 
followed by the check made results far less reliable. This way with the sleep 
1 I have not had spurious results returned by the calibration. I'm open to 
suggestions if anyone's got one.

Cheers,
Con
-
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: **SPAM** [PATCH 3/3] usb gadget driver for MQ11xx graphics chip

[Patrick McFarland]

On Wednesday 03 August 2005 05:49 pm, Nick Sillik wrote:
> Michael Krufky wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > The email subject. "Re: **SPAM** [PATCH 3/3] usb gadget driver for
> > MQ11xx graphics chip" ... Was that an accident, or did my email server
> > take over my headers?  (i'm not running any spam filering software or
> > anything)
> >
> > If this happened on your end, you might want to re-send that one...
> > Some email clients automatically filter messages containing "**SPAM**"
> > in subject line.
>
> Nope, isn't on your end. I'm seeing them too. I thought my mailserver
> had gone off its rocker. I'm glad to know that others are seeing this.

I see it too. Looks like maybe his ISP filters outgoing mail with their 
anti-spam stuff?

-- 
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989


pgp4AnAqe3dHt.pgp
Description: PGP signature

Re: Getting rid of SHMMAX/SHMALL ?

[linux-os \(Dick Johnson\)]

On Thu, 4 Aug 2005, Andi Kleen wrote:

>
> I noticed that even 64bit architectures have a ridiculously low
> max limit on shared memory segments by default:
>
> #define SHMMAX 0x200 /* max shared seg size (bytes) */
> #define SHMMNI 4096  /* max num of segs system wide */
> #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) 
> */
>
> Even on 32bit architectures it is far too small and doesn't
> make much sense. Does anybody remember why we even have this limit?
>
> IMHO per process shm mappings should just be controlled by the normal
> process and global mappings with the same heuristics as tmpfs
> (by default max memory / 2 or more if shmfs is mounted with more)
> Actually I suspect databases will usually want to use more
> so it might even make sense to support max memory - 1/8*max_memory
>
> I would propose to get rid of of shmmax completely
> and only keep the old shmall sysctl for compatibility.
>
> Comments?
>
> -Andi


It doesn't seem to be used very much. Here's the `grep` of the
entire 2.6.12 source-tree:


size_t  shm_ctlmax = SHMMAX;
./ipc/shm.c
 (actually only bits 25..16 get used since SHMMAX is so low)
./include/asm-m68k/shm.h
KERN_SHMMAX=34, /* long: Maximum shared memory segment */
./include/linux/sysctl.h
  * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
#define SHMMAX 0x200 /* max shared seg size (bytes) */
#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
./include/linux/shm.h
 (actually only bits 25..16 get used since SHMMAX is so low)
./include/asm-h8300/shm.h
#ifndef SHMMAX
#define SHMMAX  0x003fa000
./include/asm-arm26/shmparam.h
.ctl_name   = KERN_SHMMAX,
./kernel/sysctl.c



Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :


The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
-
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: [ck] [ANNOUNCE] Interbench 0.27

[Gabriel Devenyi]

Con Kolivas wrote:

On Thu, 4 Aug 2005 21:44, Gabriel Devenyi wrote:


Hi Con,

You must hate me by now...



No. A bug report is a bug report. I hate the fact that I coded up 2000 lines 
of code and am still suffering from a problem in the same 10 lines that I did 
in version .01. PEBKAC. 
I guess we all have our weaknesses, mine is off-by-one errors, which are 
a bad thing when writing code for a statistics class at school ;)






The "Gaming" benchmark has the same issue with nan coming out of the
STDEV calculations, probably requires the same fix as before.



Anyway Peter Williams has promised to fix it for me (yay!).



Secondly, the benchmarking of loops_per_ms is running forever, and I
managed to determine where its happening.

In calibrate loops you run a while loop and iterate to get 1000 for
run_time, then you calculate it one more time to ensure it was right
*however* you put a sleep(1) before that. It seems to seriously skew the
results, as it consistently adds ~500 to run_time, as run_time is now
1500, it jumps back up to redo because of the goto statement, and runs
the while loop again, continue ad nausium. I added some simple debugging
output which prints run time at the end of each while loop, and right
before the goto if statement, this is the output.




The solution I used is of course to simply comment out the sleep
statement, then everything works nicely, however your comments appear to
indicate that the sleep is there to make the system settle a little,
perhaps another method needs to be used. Thanks for your time!



I have to think about it. This seems a problem only on one type of cpu for 
some strange reason (lemme guess; athlon?) and indeed leaving out the sleep 1 
followed by the check made results far less reliable. This way with the sleep 
1 I have not had spurious results returned by the calibration. I'm open to 
suggestions if anyone's got one.
Yeah, thats right, it spins forever on both my athlon-tbird and my 
athlon64 (in x86_64 mode). I'll take another look at the code tonight, 
to see if I can figure out why its causing this, or another way of 
incurring the delay you're looking for.




Cheers,
Con



--
Gabriel Devenyi
[EMAIL PROTECTED]
-
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: **SPAM** [PATCH 3/3] usb gadget driver for MQ11xx graphics chip

[linux-os \(Dick Johnson\)]

On Thu, 4 Aug 2005, Patrick McFarland wrote:

> On Wednesday 03 August 2005 05:49 pm, Nick Sillik wrote:
>> Michael Krufky wrote:
>>> [EMAIL PROTECTED] wrote:
>>>
>>> The email subject. "Re: **SPAM** [PATCH 3/3] usb gadget driver for
>>> MQ11xx graphics chip" ... Was that an accident, or did my email server
>>> take over my headers?  (i'm not running any spam filering software or
>>> anything)
>>>
>>> If this happened on your end, you might want to re-send that one...
>>> Some email clients automatically filter messages containing "**SPAM**"
>>> in subject line.
>>
>> Nope, isn't on your end. I'm seeing them too. I thought my mailserver
>> had gone off its rocker. I'm glad to know that others are seeing this.
>
> I see it too. Looks like maybe his ISP filters outgoing mail with their
> anti-spam stuff?
>
> --

> Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]

It's some idiot's "anti-porn" mail trap.

About a year ago, the aic7xxx (Adaptec SCSI driver) couldn't
be referenced without anti-porno junk dropping it on the floor.

IT idiots think that porn file-names have Xes in them. Once
they find out that they have ".jpg" in them, no more pictures
for anybody!

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :


The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
-
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] PPC64: Fix UP kernel build

[Andreas Schwab]

Olof Johansson <[EMAIL PROTECTED]> writes:

> Index: 2.6/arch/ppc64/kernel/machine_kexec.c
> ===
> --- 2.6.orig/arch/ppc64/kernel/machine_kexec.c2005-08-03 
> 19:53:16.0 -0500
> +++ 2.6/arch/ppc64/kernel/machine_kexec.c 2005-08-03 20:39:49.0 
> -0500
> @@ -243,13 +243,17 @@ static void kexec_prepare_cpus(void)
>  
>  static void kexec_prepare_cpus(void)
>  {
> + extern void smp_release_cpus(void);

Please put this in a header.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
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 partition support driver methods

[Mukund JB.]

Dear corbet,

Here is the over idea about the driver status.
My driver supports 4 SD cards at a time. 
The driver works well when there are partitions are disabled.
i.e. when alloc_disk(1); - i.e. no partitions

Right now, I am working on getting the driver up with partitions
supported.
After making changes in the gendisk initialization, I am able to mount
the device in the socket 0 but I am NOT able mount the devices in the
rest of the sockets when partitions are enabled?

Also, there is nothing specific that I am implementing for partition IO
request support on the devices.

However, 
I am in bit confusion whether the following gendisk will suffice the
requirement or NOT?

Will u please verify the gendisk code below?
Here is how I am initializing the gendisk in my driver.

--gendisk impl 

gDisk->blkqueue = blk_init_queue(do_request, &gDisk->qlock);
if(gDisk->blkqueue == NULL) {
printk("FM ERROR | Queue Initialization failed!\n");
return FAILURE;
}

/* set sector size */
blk_queue_hardsect_size(gDisk->blkqueue, DEV_SECT_SIZE);

/* add gendisk: partitioning support */
gDisk->gd = alloc_disk(4); /* 3 -> 3 partitions */
if(! gDisk->gd) {
printk("FM ERROR | alloc_disk failed!\n");
return FAILURE;
}
gDisk->gd->major = major_num;
gDisk->gd->first_minor = (int_of(Dev->dName[2]) *
MAX_NUM_SOCKETS) +
(iSock * 4);
gDisk->gd->fops = &bd_op;
gDisk->gd->private_data = Dev;

for(i=0;i<3;i++)
devName[i] = Dev->dName[i];
devName[i] = char_of(iSock);
devName[i+1] = '\0';
strcpy(gDisk->gd->disk_name, devName);
PRINTK("Device Name under /dev/ = %s\n", devName);

/* removable media */
gDisk->gd->flags |= GENHD_FL_REMOVABLE;

set_capacity(gDisk->gd,
((dSize * 1024)/DEV_SECT_SIZE) *
(DEV_SECT_SIZE/KRNL_SECT_SIZE));

gDisk->gd->queue = gDisk->blkqueue;

add_disk(gDisk->gd);
--gendisk impl ENDS 

This gendisk is invoked at socket initialization.

For example, phy devices are 
/dev/tfa0 - 3:  socket 1
/dev/tfa4 - 7:  socket 2
/dev/tfa8 - 11: socket 3
/dev/tfa12 -15: socket 4

i.e, I have created the nodes like minors 0, 1, 2, 3 for socket0
I have created the nodes like minors 12, 13, 14, 15 for socket3.

With these physical nodes, I through it should work.
When a card is inserted in the socket 0, I am able to mount.

BUT, when a card is inserted in the socket 3, I am NOT able to mount and
it says.
Mount: /dev/tfa12 is not a valid block device

Can you convey me where exactly I am missing or why is it failing?

Regards,
Mukund Jampala


>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Thursday, August 04, 2005 12:35 AM
>To: Mukund JB.
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: 2.6 partition support driver methods
>
>> Do I need to handle any thing in the request function to handle
>> read/writes to the device partitions?
>
>It looks like you've done most of what you need; in 2.6, block drivers
>need not worry about the details of partitioning.
>
>Lots of details in the block drivers chapter of LDD3 if you need them:
>
>   http://lwn.net/Kernel/LDD3/
>
>jon
>
>Jonathan Corbet
>Executive editor, LWN.net
>[EMAIL PROTECTED]

-
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 disk and HPA

[Etienne Lorrain]

> > > My question is now: why is an HPA disabled i.e. disprotected when
> > > detected? Why not let the HPA alone, because a certain set of disk
> > > sectors shall not be accessible by the OS?
> >
> > Because the HPA is most commonly used to hide all but a fraction of a
> > disk to work with older BIOSes.
>
> But as to my knowledge, the HPA was had been introduced to allow HW
> vendors to store things like diagnostic programs in a part of the
> disk protected from partitioning and filesystems.
> The point is, IF there is an HPA, there MIGHT be a partitioning
> scheme and some filesystems on the disk which rely on the size of
> disk being the native size MINUS the HPA.

  If those HW vendors want to store software in the HPA of the IDE
 hard disk, and they employ people able to read the IDE specifications,
 they know that this HPA can be protected by password and so Linux
 just display a failure when trying to restore the capacity of the
 Hard Disk - because it lacks the unlocking password.

  Note that this HPA is a good place to store a bootloader too, in fact
 I like to think of it as the big floppy drive of the PC which no more
 have any floppy drive: create a FAT filesystem of 64 Mbytes there and
 copy all the floppy you used to have there. Your bootloader, if it
 is good enough, will be able to run software from this area.

  I also have to add that it is finally time to read the ATA 4
 specification (published in august 1998) or any newer version, for
 instance at:
 http://www.t13.org/project/d1153r18-ATA-ATAPI-4.pdf
 around page 30 / page 46 about "6.10 Security Mode feature set".
 Pay attentiong to the last sentense of "6.10.4 Frozen mode".
  If you are using the right bootloader someone has already taken care
 of that detail for you - you are not disk2brick virus sensitive, and
 you do not care much of the blankdisk virus neither - whatever the
 OSes you are using.

  Etienne.

--
 http://gujin.org

-
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] Remove suspend() calls from shutdown path

[Zilvinas Valinskas]

Hello Ben, Andrew, 

This patch helps me if I disconnect all USB peripherals before shutting
down notebook. With connected peripherals (USB mouse, PL2303
USB<->serial converter/port) - powering off process stops right after
unmounting filesystems but before hda power off ... 

There is a bug report for this too:
http://bugzilla.kernel.org/show_bug.cgi?id=4992

Z.

On Thu, Aug 04, 2005 at 11:36:26AM +0200, Benjamin Herrenschmidt wrote:
> Hi Andrew !
> 
> This patch remove the calls to device_suspend() from the shutdown path
> that were added sometime during 2.6.13-rc*. They aren't working properly
> on a number of configs (I got reports from both ppc powerbook users and
> x86 users) causing the system to not shutdown anymore.
> 
> I think it isn't the right approach at the moment anyway. We have
> already a shutdown() callback for the drivers that actually care about
> shutdown and the suspend() code isn't yet in a good enough shape to be
> so much generalized. Also, the semantics of suspend and shutdown are
> slightly different on a number of setups and the way this was patched in
> provides little way for drivers to cleanly differenciate. It should have
> been at least a different message.
> 
> For 2.6.13, I think we should revert to 2.6.12 behaviour and have a
> working suspend back.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> 
> Index: linux-work/kernel/sys.c
> ===
> --- linux-work.orig/kernel/sys.c  2005-08-01 14:03:46.0 +0200
> +++ linux-work/kernel/sys.c   2005-08-04 11:32:51.0 +0200
> @@ -404,7 +404,6 @@
>  {
>   notifier_call_chain(&reboot_notifier_list, SYS_HALT, NULL);
>   system_state = SYSTEM_HALT;
> - device_suspend(PMSG_SUSPEND);
>   device_shutdown();
>   printk(KERN_EMERG "System halted.\n");
>   machine_halt();
> @@ -415,7 +414,6 @@
>  {
>   notifier_call_chain(&reboot_notifier_list, SYS_POWER_OFF, NULL);
>   system_state = SYSTEM_POWER_OFF;
> - device_suspend(PMSG_SUSPEND);
>   device_shutdown();
>   printk(KERN_EMERG "Power down.\n");
>   machine_power_off();
> 
> 
> -
> 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: [ck] [ANNOUNCE] Interbench 0.27

[Gabriel Devenyi]

Con Kolivas wrote:
I'd appreciate it. It's almost like some power stepping that's responsible. 
I've never seen it happen on any intel processor (including the pentiumM ones 
which have truckloads of power saving features). I've asked many people if 
they're running some equivalent of cool'n'quiet or powernow* and they all 
insist they're not... I'm not that familiar with all the powersaving techs 
though.


I'm certainly not running any powersaving features on my athlon-tbird(it 
doesn't have any AFAIK, and its the hottest running AMD processor there 
is) However I've realized I did have cool n' quiet with the ondemand 
governor running on my athlon64, so that might indicate an issue, again, 
I'll look into that tonight.


--
Gabriel Devenyi
[EMAIL PROTECTED]
-
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/5 explicit-iopl

[Andi Kleen]

[EMAIL PROTECTED] writes:
> 
> Unfortunately, this added one field to the thread_struct.  But as a bonus, on
> P4, the fastest time measured for switch_to() went from 312 to 260 cycles, a
> win of about 17% in the fast case through this performance critical path.

Cool! Definitely want this on x86-64 too.

Can we perhaps get rid of the PUSHF/POPF in the SYSENTER syscall path too?
iirc they were only for single stepping. But SYSENTER doesn't disable
single stepping, so the debug handler could detect this and set
some magic flag that restores it on syscall exit.

-Andi
-
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] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01

[Andrzej Nowak]

On 7/30/05, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 
> i have released the -V0.7.52-01 Real-Time Preemption patch, which can be
> downloaded from the usual place:
> ...
> reports, patches, suggestions welcome.

I can't get it to run on x86_64. The kernel won't build with
"voluntary preemption" enabled, it's complaining about mce_read_sem
being undeclared. Including linux/semaphore.h in
arch/x86_64/kernel/mce.c does get the compilation past that point, but
later on mtrr and kprobes won't build. I can turn those off, but the
build stops on kernel/printk.c with a "console_sem undeclared" error.

Everything builds fine with "real-time preemption" enabled, though the
linux system as a whole still won't run, as init crashes on startup
(kernel panic).

I saw earlier postings on lkml related to RT and x86_64, but
unfortunately the suggestions made, such as turning off latency
timing, didn't help. I tried this on a dual Xeon HT server with SLES
9.1 64bit installed (config has SMP/SMT set to yes). I used the
2.6.13-rc4 kernel patched with
realtime-preempt-2.6.13-rc4-RT-V0.7.52-10.

Any suggestions or any extra info I've missed would be appreciated.

Andrzej Nowak
-
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: [ck] [ANNOUNCE] Interbench 0.27

[Con Kolivas]

On Thu, 4 Aug 2005 22:05, Gabriel Devenyi wrote:
> Con Kolivas wrote:
> > I have to think about it. This seems a problem only on one type of cpu
> > for some strange reason (lemme guess; athlon?) and indeed leaving out the
> > sleep 1 followed by the check made results far less reliable. This way
> > with the sleep 1 I have not had spurious results returned by the
> > calibration. I'm open to suggestions if anyone's got one.
>
> Yeah, thats right, it spins forever on both my athlon-tbird and my
> athlon64 (in x86_64 mode). I'll take another look at the code tonight,
> to see if I can figure out why its causing this, or another way of
> incurring the delay you're looking for.

I'd appreciate it. It's almost like some power stepping that's responsible. 
I've never seen it happen on any intel processor (including the pentiumM ones 
which have truckloads of power saving features). I've asked many people if 
they're running some equivalent of cool'n'quiet or powernow* and they all 
insist they're not... I'm not that familiar with all the powersaving techs 
though.

Cheers,
Con
-
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: File corruption on LVM2 on top of software RAID1

[Simon Matter]

> Once upon a time, "Simon Matter" <[EMAIL PROTECTED]> said:
>>In my tests I get corrupt files on LVM2 which is on top of software
>> raid1.
>>(This is a common setup even mentioned in the software RAID HOWTO and has
>>worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my
>>favourite configuration). Now, I tested two different distributions,
>> three
>>kernels, three different filesystems and three different hardware. I can
>>always reproduce it with the following easy scripts:
>
> See:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=4946
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152162
>
> There's a one-line patch in there; see if that fixes the problem for
> you.

Hi Chris,

Thank you for your help, indeed this oneliner fixes the corruption. I have
tested with 2.6.12.3 + bio_clone fix and also built an updated RedHat EL4
kernel with the fix included. No corruption anymore.
This fix should be applied to most kernels shipped with the latest Linux
distributions. At least those products called Enterprise something should
hurry in the interest of their customers. Do you think this will happen
anytime soon?

-- 
Simon Matter
Invoca Systems

-
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: [ACPI] Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet]

Hi,

Bjorn Helgaas wrote:

On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:


Bjorn Helgaas wrote:
>drivers/char/hpet.c
>This probably should be converted to PNP.  I'll
>look into doing this.
IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
memory adress for hpet correctly. But it would be nice if it works.



You're right, this was broken.  But I've been pushing a PNPACPI
patch to fix this.



Yes but is ACPI_RSTYPE_ADDRESS64 possible on 32 bit machine ?
In this case your patch won't work as res->mem_resource[i].start and 
res->mem_resource[i].end are unsigned long, and 64 bit value won't fit.


Matthieu
-
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 07/15] Basic x86_64 support

[Andi Kleen]

> > That doesn't make much sense here. tasklet will only run when interrupts
> > are enabled, and that is much later. You could move it to there.
> 
> Where?  Keep in mind it's really only x86_64 that isn't able to break
> sooner.

The local_irq_enable() call in init/main.c:start_kernel()

If you want to run gdb earlier you need to do it without a tasklet.

> > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite  
> > > 2005-07-29 13:19:10.0 -0700
> > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h2005-07-29 
> > > 13:19:10.0 -0700
> > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> > >  #define TASK_MIGRATION_VECTOR0xfb
> > >  #define CALL_FUNCTION_VECTOR 0xfa
> > >  #define KDB_VECTOR   0xf9
> > > +#define KGDB_VECTOR  0xf8
> > 
> > I already allocated these vectors for something else.
> 
> Is there another we can use?  Just following what looked to be the
> logical order.

How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
and then just check if kgdb is currently active? 

KDB can do the same.

I changed the assignment in my tree like this:

#define SPURIOUS_APIC_VECTOR0xff
#define ERROR_APIC_VECTOR   0xfe
#define RESCHEDULE_VECTOR   0xfd
#define CALL_FUNCTION_VECTOR0xfc
#define KDB_VECTOR  0xfb/* reserved for KDB */
#define THERMAL_APIC_VECTOR 0xfa
/* 0xf9 free */
#define INVALIDATE_TLB_VECTOR_END   0xf8
#define INVALIDATE_TLB_VECTOR_START 0xf0/* f0-f8 used for TLB flush */


but that can be merged later. THere will be probably more changes
with the per CPU IDT planned.

> > >   cfg = __prepare_ICR(shortcut, vector, dest);
> > > +if (vector == KGDB_VECTOR) {
> > > + /*
> > > +  * KGDB IPI is to be delivered as a NMI
> > > +  */
> > > + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI;
> > > + }
> > 
> > No way adding another ugly special case like this. I wanted
> > to rip out the KDB version for a long time.
> 
> I'd be happy to rework it in a cleaner manner, just point me at an
> example please.

The code is equivalent to passing shortcut|APIC_DM_NMI and vector == 0

> > > - asm volatile(SAVE_CONTEXT   
> > > \
> > > +   asm volatile(".globl __switch_to_begin\n\t"   
> > > \
> > > +  "__switch_to_begin:\n\t"   
> > >   \
> > > +  SAVE_CONTEXT   
> > >   \
> > 
> > Why is this needed?
> 
> So that backtraces show they're in switch_to rather than somewhere else
> (since it's a #define we wouldn't know otherwise).

Ok.

-Andi
-
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: Power consumption HZ100, HZ250, HZ1000: new numbers

[Hans Kristian Rosbach]

On Wed, 2005-08-03 at 08:57 -0500, Dmitry Torokhov wrote:
> On 8/3/05, Hans Kristian Rosbach <[EMAIL PROTECTED]> wrote:
> > On Tue, 2005-08-02 at 00:50 -0400, James Bruce wrote:
> > > Theodore Ts'o wrote:
> > >  > On Mon, Aug 01, 2005 at 12:18:18PM -0400, James Bruce wrote:
> > >  >>The tradeoff is a realistic 4.4% power savings vs a 300% increase in
> > >  >>the minimum sleep period.  A user will see zero power savings if they
> > >  >>have a USB mouse (probably 99% of desktops).  On top of that, we can
> > >  
> > >
> > >  > Most laptops (including mine, a Thinkpad T40) use a PS/2 mouse.  So in
> > >  > the places where power consumption savins matters most, it's usually
> > >  > quite possible to function without needing any USB devices.  The 90%
> > >  > figure isn't at all right; in fact, it may be that over 90% of the
> > >  > laptops still use PS/2 mice and keyboards.
> > >
> > > Yes, laptops are mostly PS/2, which is why I only claimed a statistic
> > > for desktops.  Desktops pretty much all use USB mice now.  If 250Hz were
> > > only being sold as an option for laptops, we could leave it at that, yet
> > > its being pushed as a default that's "good for everyone".  For desktops
> > > this is not currently true at all.  By the time USB is fixed to do power
> > > saving, we'll probably have a working tick-skipping patch which makes
> > > the whole HZ argument moot.
> > 
> > Most new laptops are moving away from PS/2 ports, for example my
> > shining (literally) new Acer Ferrari 4005 only has USB2 ports for mice
> > and keyboard inputs (unless in the optional pcie docking station maybe).
> > So my suggestion would be to fix USB power management.
> >
> 
> You are talking about external ports. I am pretty sure that installed
> keyboard and touchpad (or whattever pointing device it has) are plain
> old PS/2.

Well, yes..

But as I _never_ use the touchpad, it is quite necessary to keep USB
enabled for me at any time as an external PS2 mouse is not possible.

-HK

-
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] pmtmr and PRINTK_TIME timings display

[Borislav Petkov]

Hi,

on my laptop ASUS M6B00N PRINTK_TIME is enabled in order to show timing 
information in all the boottime printk's. However, all output looks like this


[4294667.997000] CPU: After generic identify, caps: a7e9fbbf   
 0180  
[4294667.997000] CPU: After vendor identify, caps: a7e9fbbf   
 0180  
[4294667.997000] CPU: L1 I cache: 32K, L1 D cache: 32K
[4294667.997000] CPU: L2 cache: 1024K
[4294667.997000] CPU: After all inits, caps: a7e9fbbf   
0040 0180  
[4294667.997000] CPU: Intel(R) Pentium(R) M processor 1500MHz stepping 05
[4294667.997000] Enabling fast FPU save and restore... done.
[4294667.997000] Enabling unmasked SIMD FPU exception support... done.
[4294667.997000] Checking 'hlt' instruction... OK.
[4294668.041000] ACPI: setting ELCR to 0200 (from 0c30)


If I'm not wrong, the time value that gets printed is actually the jiffies_64 
value set to INITIAL_JIFFIES, which in turn is set to wrap 5 minutes after 
boot so that "jiffies wrap bugs show up earlier." This is because 
sched_clock() in  returns the jiffies_64 
value converted to nanoseconds after checking use_tsc. This, in turn, is 0 
because my machine selects the power management timer as the high-res 
timesource before reading the timestamp counter for printk timing.

My desktop machine however, uses the tsc for printk timing and its boot 
messages look like this:


[4294667.296000] mapped APIC to d000 (fee0)
[4294667.296000] mapped IOAPIC to c000 (fec0)
[4294667.296000] Initializing CPU#0
[4294667.296000] CPU 0 irqstacks, hard=c0481000 soft=c047f000
[4294667.296000] PID hash table entries: 2048 (order: 11, 32768 bytes)
[0.00] Detected 2606.874 MHz processor.
[   20.523785] Using tsc for high-res timesource
[   20.524715] Console: colour VGA+ 80x25
[   20.751678] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[   20.760133] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[   20.778329] Memory: 514964k/524224k available (2127k kernel code, 8776k 
reserved, 1246k data, 180k init, 0k highmem)


where you see the deltas between the printk's printed once the tsc timer is 
initialized as opposed to the first bootlog where you see all times relative 
to a single point in time. The python script  in the 
kernel source converts between these two representations but there's a pretty 
simple solution IMHO to make PRINTK_TIME uniform and independent from the 
used timer. The one liner is against 2.6.12.3.

After applying it, printk timing looks like this:


[0.00] Detected 1500.132 MHz processor.
[0.00] Using pmtmr for high-res timesource
[0.00] Console: colour VGA+ 80x25
[1.89] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[1.891000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[1.906000] Memory: 513756k/523520k available (2839k kernel code, 9276k 
reserved, 1148k data, 152k init, 0k highmem)
[1.906000] Checking if this processor honours the WP bit even in 
supervisor mode... Ok.
[1.906000] Calibrating delay loop... 2973.69 BogoMIPS (lpj=1486848)
[1.928000] Security Framework v1.0.0 initialized



Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>

--- arch/i386/kernel/timers/timer_tsc.c.orig2005-08-04 12:57:37.0 
+0200
+++ arch/i386/kernel/timers/timer_tsc.c 2005-08-04 14:19:48.0 +0200
@@ -146,7 +146,7 @@ unsigned long long sched_clock(void)
if (!use_tsc)
 #endif
/* no locking but a rare wrong value is not a big deal */
-   return jiffies_64 * (10 / HZ);
+   return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ);
 
/* Read the Time Stamp Counter */
rdtscll(this_offset);


-- 
Regards,
Borislav Petkov.
-
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.6.13-rc4] fix get_user_pages bug

[Hugh Dickins]

On Thu, 4 Aug 2005, Robin Holt wrote:
> On Wed, Aug 03, 2005 at 12:31:34PM +0100, Hugh Dickins wrote:
> > On Wed, 3 Aug 2005, Robin Holt wrote:
> > > On Mon, Aug 01, 2005 at 11:18:42AM -0700, Linus Torvalds wrote:
> > > > 
> > > > Can somebody who saw the problem in the first place please verify?
> 
> OK.  I took the three commits:
> 4ceb5db9757aaeadcf8fbbf97d76bd42aa4df0d6
> f33ea7f404e592e4563b12101b7a4d17da6558d7
> a68d2ebc1581a3aec57bd032651e013fa609f530
> 
> I back ported them to the SuSE SLES9SP2 kernel.  I will add them at
> the end so you can tell me if I messed things up.  I was then able
> to run the customer test application multiple times without issue.
> Before the fix, we had never acheived three consecutive runs that did
> not trip the fault.  After the change, it has been in excess of thirty.
> I would say this has fixed the problem.  Did I miss anything which
> needs to be tested?

Great, thanks for the testing, the set of patches you tested is correct.

(I think there is one minor anomaly in your patch backport, which has no
effect on the validity of your testing: you've probably ended up with two
separate calls to set_page_dirty in your follow_page, because that moved
between 2.6.5 and 2.6.13.  It doesn't matter, but you might want to tidy
that up one way or the other if you're passing your patch on further.)

Hugh
-
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/2] cpqfc: fix for "Using too much stach" in 2.6 kernel

[Denis Vlasenko]

On Thursday 04 August 2005 12:38, Rolf Eike Beer wrote:
> Saripalli, Venkata Ramanamurthy (STSD) wrote:
> >Patch 1 of 2
> >
> >This patch fixes the "#error this is too much stack" in 2.6 kernel.
> >Using kmalloc to allocate memory to ulFibreFrame.
> 
> Good idea.
> 
> >Please consider this for inclusion
> 
> Your patch is line-wrapped and can't be applied. Your second patch is also 
> line wrapped. And it touches this file in a different way so they can't be 
> applied cleanly over each other.
> 
> >diff -burpN old/drivers/scsi/cpqfcTScontrol.c
> >new/drivers/scsi/cpqfcTScontrol.c
> >--- old/drivers/scsi/cpqfcTScontrol.c2005-07-12 22:52:29.0
> >+0530
> >+++ new/drivers/scsi/cpqfcTScontrol.c2005-07-18 22:19:54.229947176
> >+0530
> >@@ -606,22 +606,25 @@ static int PeekIMQEntry( PTACHYON fcChip
> > if( (fcChip->IMQ->QEntry[CI].type & 0x1FF) == 0x104 )
> > {
> >   TachFCHDR_GCMND* fchs;
> >-#error This is too much stack
> >-  ULONG ulFibreFrame[2048/4];  // max DWORDS in incoming FC
> >Frame
> >+  ULONG *ulFibreFrame;  // max DWORDS in incoming FC Frame
> >   USHORT SFQpi = (USHORT)(fcChip->IMQ->QEntry[CI].word[0] &
> >0x0fffL);
> 
> Why not use a void* here as type for the buffer? Or even better: remove this 
> at all and directly use fchs as target, because this is the only place where 
> this buffer goes to?
> 
> >+  ulFibreFrame = kmalloc((2048/4), GFP_KERNEL);
> 
> The size bug was already found by Dave Jones. This never should be written 
> this way (not your fault). The array should have been [2048/sizeof(ULONG)].

Also you need to check for NULL return.
--
vda 

-
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: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[linux-os \(Dick Johnson\)]

You are trying to do it backwards. You need to have your driver
use get_dma_pages() to acquire pages suitable for DMA. Your
driver then impliments mmap().

The user-mode application then mmaps() the dma-able pages into
its address-space. FYI, the pages may be from anywhere, some
archs can only DMA to/from memory below 16MB. The pages do not have
to be continuous because you will build a scatter-list for
the DMA engine and you will mmap() the pages so they are
contiguous to the user. Also 400 Megabytes is absurd.

On Thu, 4 Aug 2005, Clemens Koller wrote:

> Hello!
>
> This might be an FAQ - I've got several ideas from googling
> around for days and reading 'Linux Device Drivers' or
> 'Understanding The Linux Kernel' which are both really good
> books. However I am not really sure of how to do it on the latest
> linux-2.6.
>
> I am currently working on a dma driver for a ppc32 system.
> The idea is that a userspace app allocates a big contigous
> chunk of memory (i.e. 400MBytes, user virtual mem) and tells
> my dma's char driver via ioctl the pointer to that memory.
>
> In the driver I can now use that (void __user *) casted address
> as a kernel virtual address, right? It's contigous there and I can
> do a memcpy() to get data to userspace simliar to a copy_to_user().
> fine!
>
> But I want to setup a scatter/gather DMA list and blow my data
> directly into the applications physical pages.
>
> What's the best way to setup the dma_sg_list?
> I have checked several things to get the pages and physical addresses
> but with no real success now:
> get_user_page()
> vmalloc_to_page()
> kvirt_to_bus() (deprecated?)
> virt_to_phys()
> virt_to_bus()
>
> Or do I need to remap the whole thing before I can get all the pages and
> physical addresses?
> remap_page_range()
> remap_pfn_range()
> map_user_kiobuf()
> unmap_kiobuf()
>
> Or do I need the direct-io stuff or the block-io?
> How do I need to alloc the mem in my app? (get_pages()?)
> How do I need to lock the memory to make sure it's in phys memory? 
> (mlockall()?)
> Can somebody please put some light on what's _the_ way to do that on the
> latest 2.6 kernels? I am pretty much confused which functions are current
> and okay to use to solve my problem.
> Pointers to some code is also very welcome. But it should be _current_.
> I've spent already a lot of time reading outdated things. :-(
>
> Best regards,
>
> Clemens Koller
> ___
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
> -
> 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/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :


The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.
-
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: Getting rid of SHMMAX/SHMALL ?

[Hugh Dickins]

On Thu, 4 Aug 2005, Andi Kleen wrote:

> I noticed that even 64bit architectures have a ridiculously low 
> max limit on shared memory segments by default:
> 
> #define SHMMAX 0x200 /* max shared seg size (bytes) */
> #define SHMMNI 4096  /* max num of segs system wide */
> #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) 
> */
> 
> Even on 32bit architectures it is far too small and doesn't
> make much sense. Does anybody remember why we even have this limit?

To be like the UNIXes.

> IMHO per process shm mappings should just be controlled by the normal
> process and global mappings with the same heuristics as tmpfs
> (by default max memory / 2 or more if shmfs is mounted with more)
> Actually I suspect databases will usually want to use more 
> so it might even make sense to support max memory - 1/8*max_memory
> 
> I would propose to get rid of of shmmax completely
> and only keep the old shmall sysctl for compatibility.

Anton proposed raising the limits last autumn, but I was a bit
discouraging back then, having noticed that even Solaris 9 was more
restrictive than Linux.  They seem to be ancient traditional limits
which everyone knows must be raised to get real work done.

It's possible that if we raise the limits, installation
of this or that application will then lower them again?

I don't think my opinion is worth much on this:
what would the distro tuners like to see there?

Hugh
-
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] pmtmr and PRINTK_TIME timings display

[Steven Rostedt]

On Thu, 2005-08-04 at 14:59 +0200, Borislav Petkov wrote:

> 
> where you see the deltas between the printk's printed once the tsc timer is 
> initialized as opposed to the first bootlog where you see all times relative 
> to a single point in time. The python script  in the 
> kernel source converts between these two representations but there's a pretty 
> simple solution IMHO to make PRINTK_TIME uniform and independent from the 
> used timer. The one liner is against 2.6.12.3.
> 
> After applying it, printk timing looks like this:
> 
> 
> [0.00] Detected 1500.132 MHz processor.
> [0.00] Using pmtmr for high-res timesource
> [0.00] Console: colour VGA+ 80x25
> [1.89] Dentry cache hash table entries: 131072 (order: 7, 524288 
> bytes)
> [1.891000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [1.906000] Memory: 513756k/523520k available (2839k kernel code, 9276k 
> reserved, 1148k data, 152k init, 0k highmem)
> [1.906000] Checking if this processor honours the WP bit even in 
> supervisor mode... Ok.
> [1.906000] Calibrating delay loop... 2973.69 BogoMIPS (lpj=1486848)
> [1.928000] Security Framework v1.0.0 initialized
> 
> 

But if you are debugging problems with jiffies wrapping, wouldn't you
want to see the jiffies unmodified?  I understand your point, but the
tsc output (which I do prefer) seems to only be for the tsc (on x86),
and all else use jiffies (haven't looked at other archs). So debugging a
problem with jiffy wrap*, one would need to use something other than the
tsc, and then they would see the time the wrap occurred.

Also, the big number stands out more than the 3 zeros, so when I see
that, I know right away to go and change it back to use the tsc (since
my debugging usually needs higher resolutions).

* new product from Renolds ;-)

-- Steve


-
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: Getting rid of SHMMAX/SHMALL ?

[Andi Kleen]

On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote:
> On Thu, 4 Aug 2005, Andi Kleen wrote:
> 
> > I noticed that even 64bit architectures have a ridiculously low 
> > max limit on shared memory segments by default:
> > 
> > #define SHMMAX 0x200 /* max shared seg size (bytes) */
> > #define SHMMNI 4096  /* max num of segs system wide */
> > #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide 
> > (pages) */
> > 
> > Even on 32bit architectures it is far too small and doesn't
> > make much sense. Does anybody remember why we even have this limit?
> 
> To be like the UNIXes.

Ok, no other more fundamental reason  ? :) 
I cannot think of any at least.

> 
> > IMHO per process shm mappings should just be controlled by the normal
> > process and global mappings with the same heuristics as tmpfs
> > (by default max memory / 2 or more if shmfs is mounted with more)
> > Actually I suspect databases will usually want to use more 
> > so it might even make sense to support max memory - 1/8*max_memory
> > 
> > I would propose to get rid of of shmmax completely
> > and only keep the old shmall sysctl for compatibility.
> 
> Anton proposed raising the limits last autumn, but I was a bit
> discouraging back then, having noticed that even Solaris 9 was more
> restrictive than Linux.  They seem to be ancient traditional limits
> which everyone knows must be raised to get real work done.
> 
> It's possible that if we raise the limits, installation
> of this or that application will then lower them again?

I think we should just get rid of the per process limit and keep
the global limit, but make it auto tuning based on available memory.
That is still not very nice because that would likely keep it < available 
memory/2, but I suspect databases usually want more than that. So
I would even make it bigger than tmpfs for reasonably big machines.
Let's say

if (main memory >= 1GB)
maxmem = main memory - main memory/8 
else  
maxmem = main memory / 2

possible increase the 4096 segments limit too, it seems quite low,
or also auto tune based on memory.

One possible problem with getting rid of /proc/sys/kernel/shmmni 
would be that some programs might read it and fail if it's not available. i
So I would probably keep it read only but always return LONG_MAX.

> 
> I don't think my opinion is worth much on this:
> what would the distro tuners like to see there?

suse has shipped larger default limits for a long time.
And all the databases and some other software documents increasing these
values.

-Andi
-
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] IPMI driver update part 1, add per-channel IPMB addresses

[Corey Minyard]

Andrew Morton wrote:


Corey Minyard <[EMAIL PROTECTED]> wrote:
 


ipmi-per-channel-slave-address.patch  unknown/unknown (13533 bytes)]
   



Could you fix up the mimetype, please?  It makes it hard for various email
clients.
 


Dang, you switch to a new mail client and everything is screwed up.  Sorry.

 


IPMI allows multiple IPMB channels on a single interface, and
each channel might have a different IPMB address.  However, the
driver has only one IPMB address that it uses for everything.
This patch adds new IOCTLS and a new internal interface for
setting per-channel IPMB addresses and LUNs.  New systems are
coming out with support for multiple IPMB channels, and they
are broken without this patch.

...
+   for (i=0; i   



Preferred coding style is actually

for (i = 0; i < IPMI_MAX_CHANNELS; i++)

but we've kinda lost that fight in drivers :(
 

Ok, I'll see what I can do.  It's the wrong way all over the driver 
right now.


 


+#define IPMICTL_SET_MY_CHANNEL_ADDRESS_CMD _IOR(IPMI_IOC_MAGIC, 24, struct 
ipmi_channel_lun_address_set)
+#define IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD _IOR(IPMI_IOC_MAGIC, 25, struct 
ipmi_channel_lun_address_set)
+#define IPMICTL_SET_MY_CHANNEL_LUN_CMD_IOR(IPMI_IOC_MAGIC, 26, struct 
ipmi_channel_lun_address_set)
+#define IPMICTL_GET_MY_CHANNEL_LUN_CMD_IOR(IPMI_IOC_MAGIC, 27, struct 
ipmi_channel_lun_address_set)
   



Are these all OK wrt compat handling?
 

Yes, it is a structure of an unsigned short and an unsigned char, so it 
should be ok.


 


case IPMICTL_SET_MY_ADDRESS_CMD:
{
unsigned int val;
...
case IPMICTL_GET_MY_ADDRESS_CMD:
{
-   unsigned int val;
+   unsigned int  val;
+   unsigned char rval;
...
case IPMICTL_GET_MY_LUN_CMD:
{
-   unsigned int val;
+   unsigned int  val;
+   unsigned char rval;
+
...
+   case IPMICTL_SET_MY_CHANNEL_ADDRESS_CMD:
+   {
+   struct ipmi_channel_lun_address_set val;
...
+   case IPMICTL_GET_MY_CHANNEL_ADDRESS_CMD:
+   {
+   struct ipmi_channel_lun_address_set val;
...
+   case IPMICTL_SET_MY_CHANNEL_LUN_CMD:
+   {
+   struct ipmi_channel_lun_address_set val;
...
+   case IPMICTL_GET_MY_CHANNEL_LUN_CMD:
+   {
+   struct ipmi_channel_lun_address_set val;
...
case IPMICTL_SET_TIMING_PARMS_CMD:
{
struct ipmi_timing_parms parms;

   



Be aware that this function will use more stack space than it needs to: gcc
will create a separate stack slot for all the above locals.

Hence it would be better to declare them all at the start of the function. 
Faster, too - less dcache footprint.


Maybe not as nice from a purist point of view, but it does allow you to
lose those braces in the switch statement...
 

Hmm, I assumed that gcc would optimize and allocate the stack as it 
needed it without waste.  Ok, easy enough to fix.


Thanks,

-Corey
-
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] inotify: update help text

[Robert Love]

The inotify help text still refers to the character device.  Update it.

Fixes kernel bug #4993.

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 fs/Kconfig |   11 +++
 1 files changed, 7 insertions(+), 4 deletions(-)

--- linux-2.6.13-rc3-git8/fs/Kconfig2005-07-27 10:59:32.0 -0400
+++ linux/fs/Kconfig2005-08-04 09:26:46.0 -0400
@@ -363,12 +363,15 @@
bool "Inotify file change notification support"
default y
---help---
- Say Y here to enable inotify support and the /dev/inotify character
- device.  Inotify is a file change notification system and a
+ Say Y here to enable inotify support and the associated system
+ calls.  Inotify is a file change notification system and a
  replacement for dnotify.  Inotify fixes numerous shortcomings in
  dnotify and introduces several new features.  It allows monitoring
- of both files and directories via a single open fd.  Multiple file
- events are supported.
+ of both files and directories via a single open fd.  Other features
+ include multiple file events, one-shot support, and unmount
+ notification.
+
+ For more information, see Documentation/filesystems/inotify.txt
 
  If unsure, say Y.
 


-
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: Getting rid of SHMMAX/SHMALL ?

[Jakob Oestergaard]

On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote:
...
> > Even on 32bit architectures it is far too small and doesn't
> > make much sense. Does anybody remember why we even have this limit?
> 
> To be like the UNIXes.

 :)

...
> Anton proposed raising the limits last autumn, but I was a bit
> discouraging back then, having noticed that even Solaris 9 was more
> restrictive than Linux.  They seem to be ancient traditional limits
> which everyone knows must be raised to get real work done.

As I understand it (and I may be mistaken - if so please let me know) -
the limit is for SVR4 IPC shared memory (shmget() and friends), and not
shared memory in general.

It makes good sense to limit use of the old SVR4 shared memory
ressources, as they're generally administrator hell (doesn't free up
ressources on process exit), and just plain shouldn't be used.

It is my impression that SVR4 shmem is used in very few applications,
and that the low limit is more than sufficient in most cases.

Any proper application that really needs shared memory, can either
memory map /dev/null and share that map (swap backed shared memory) or
memory map a file on disk.

If the above makes sense and isn't too far from the truth, then I guess
that's a pretty good argument for maintaining status quo.

-- 

 / jakob

-
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] IPMI driver update part 1, add per-channel IPMB addresses

[Arjan van de Ven]

> >Be aware that this function will use more stack space than it needs to: gcc
> >will create a separate stack slot for all the above locals.
> >
> >Hence it would be better to declare them all at the start of the function. 
> >Faster, too - less dcache footprint.
> >
> >Maybe not as nice from a purist point of view, but it does allow you to
> >lose those braces in the switch statement...
> >  
> >
> Hmm, I assumed that gcc would optimize and allocate the stack as it 
> needed it without waste.  Ok, easy enough to fix.

latest gcc does the right thing; older gcc don't though.


-
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: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Clemens Koller]

Hello, Dick!

Thanks for your help so far!

linux-os (Dick Johnson) wrote:


You are trying to do it backwards. You need to have your driver
use get_dma_pages() to acquire pages suitable for DMA. Your
driver then impliments mmap().


Okay, I have seen that, too. I've seen that some drivers do it the other
way around as I do, but I still try to follow my idea that the
application allocs the memory and the dma / the driver fills it up.
Or are there fundamental problems I get with my approach which I haven't seen 
yet?


The user-mode application then mmaps() the dma-able pages into
its address-space. FYI, the pages may be from anywhere, some
archs can only DMA to/from memory below 16MB.


My DMA machine (ppc32, mpc8540 cpu) can do the whole 32bit phys address
space so, that's not an issue here.


The pages do not have
to be continuous because you will build a scatter-list for
the DMA engine and you will mmap() the pages so they are
contiguous to the user.


Yes, only virtual space is contigous. The DMA can do nice
sg_lists and chained sg_lists, so, this should not be a problem,
too.


Also 400 Megabytes is absurd.


Why?
Actually I am planning to alloc more than 1.5GByte at once,
lock that down, build a big sg_list for all that memory because
I need to _continously_ feed it with data from the DMA. I get
about 200MBytes/sec and I cannot stop in between!

Greets,

Clemens




On Thu, 4 Aug 2005, Clemens Koller wrote:



Hello!

This might be an FAQ - I've got several ideas from googling
around for days and reading 'Linux Device Drivers' or
'Understanding The Linux Kernel' which are both really good
books. However I am not really sure of how to do it on the latest
linux-2.6.

I am currently working on a dma driver for a ppc32 system.
The idea is that a userspace app allocates a big contigous
chunk of memory (i.e. 400MBytes, user virtual mem) and tells
my dma's char driver via ioctl the pointer to that memory.

In the driver I can now use that (void __user *) casted address
as a kernel virtual address, right? It's contigous there and I can
do a memcpy() to get data to userspace simliar to a copy_to_user().
fine!

But I want to setup a scatter/gather DMA list and blow my data
directly into the applications physical pages.

What's the best way to setup the dma_sg_list?
I have checked several things to get the pages and physical addresses
but with no real success now:
get_user_page()
vmalloc_to_page()
kvirt_to_bus() (deprecated?)
virt_to_phys()
virt_to_bus()

Or do I need to remap the whole thing before I can get all the pages and
physical addresses?
remap_page_range()
remap_pfn_range()
map_user_kiobuf()
unmap_kiobuf()

Or do I need the direct-io stuff or the block-io?
How do I need to alloc the mem in my app? (get_pages()?)
How do I need to lock the memory to make sure it's in phys memory? (mlockall()?)
Can somebody please put some light on what's _the_ way to do that on the
latest 2.6 kernels? I am pretty much confused which functions are current
and okay to use to solve my problem.
Pointers to some code is also very welcome. But it should be _current_.
I've spent already a lot of time reading outdated things. :-(

Best regards,

Clemens Koller
___
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
-
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/




Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :


The information transmitted in this message is confidential and may be 
privileged.  Any review, retransmission, dissemination, or other use of this 
information by persons or entities other than the intended recipient is 
prohibited.  If you are not the intended recipient, please notify Analogic 
Corporation immediately - by replying to this message or by sending an email to 
[EMAIL PROTECTED] - and destroy all copies of this information, including any 
attachments, without reading or disclosing them.

Thank you.


-
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: Old api files, rewrite or delete?

[Russell King]

On Thu, Aug 04, 2005 at 02:00:05PM +0200, Jiri Slaby wrote:
> drivers/parport/parport_pc.c

I think a fair number of people probably use this.

> REMOVE:
> drivers/video/pm3fb.c

I have one of these cards, and I believe it's only recently (2.5-ish)
been merged.  Why are you so keen to mark it as "remove"?

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/

Could you please check mail configuration?

[Tetsuo Handa]

Message to the moderators of this ML.

Please don't forward this mail to this ML.
I intendedly mailed using a non-subscriber's address
so that this mail only seen to the moderators.

-

Hello,

I found X-OUTRCPT-TO: header since
Linux-kernel-daily-digest Digest, Vol 8, Issue 21
(at Date: Thu, 21 Jul 2005 06:00:01 -0500).
The X-OUTRCPT-TO: header exposes recipient's mail addresses.
And recently I'm getting spam mails to the exposed address.
I want you to hide X-OUTRCPT-TO header if you can.

I sent to the person managing the list
([EMAIL PROTECTED])
on Mon, 1 Aug 2005 20:11:31 +0900, but no reply.
So I sent to you this time.

Regards...
-
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] latency logger for realtime-preempt-2.6.12-final-V0.7.51-30

[Ingo Molnar]

* Yang Yi <[EMAIL PROTECTED]> wrote:

> > looks pretty good! I'll look at merging your patch after KS/OLS.
> 
> Do you have any trouble while you merge that latency logger patch?

i've merged it to the -52-11 patch that, and i've uploaded it a couple 
of minutes ago.

i have done a number of cleanups on it - e.g. instead of latency logging 
it's now called latency histogram, and i've also fixed a number of 
coding style issues. Please double-check that it's still OK, seems to 
work here.

would be nice to clean up the impact of the latency-histogram code some 
more though: e.g. the #ifdef jungle check_critical_timing() is 
disgusting. Could be cleaned up by always recording the latency_type 
being currently traced into a new tr->latency_type field, and then using 
that in check_critical_timing().

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/

MCE problem on dual Opteron

[Martin Drab]

Hi,

I get the following problem with 2.6.13-rc5-git1 on a dual Opteron 
machine:

-
...
[   847.745921] CPU 0: Machine Check Exception:7 Bank 3: 
b400083b
[   847.746066] RIP 10: {pci_conf1_read+0xbe/0x110}
[   847.746149] TSC 189fe311d3f ADDR fdfc000cfe
[   847.746218] Kernel panic - not syncing: Uncorrected machine check
-

This appears during bootup and it hangs. So my question is: Is this a HW 
problem or is it some kernel (MCE ?) bug? If it is a HW problem is it 
possible to determine what's wrong somehow?

The above mentioned output I get also from 2.6.13-rc4-git4 and 2.6.12.3. 
When I run the original FC4 kernel 2.6.11-1.1369_FC4smp I get the same 
followed by the following call trace:

-
Call Trace: <#MC> {panic+133} 
{print_mce+159} {mce_panic+137} 
{pci_conf1_read+190} 
{pci_conf1_read+190} 
{machine_check+127} 
{selinux_d_instantiate+0} 
{pci_conf1_read+190}  
{pci_direct_init+119} {init+482} 
{child_rip+8} {init+0} 
{child_rip+0}


Interesting is, that FC4 automatically sets the 'nomce' option to the 
kernel command line by default (which leads me to that it may actually 
be a bug in the kernel). And when 'nomce' is used the system boots 
and runs quite normally.

Only recently with 2.6.12.3 (which the box was running past few 
months) from time to time (so far it happend 3 times in about a month) the 
box completly stops responding to the outside world (no network, display 
turns off (no signal), USB keyboard and mouse both go dead, however the 
comp isn't turned off because for instance the disks are still normally 
flashing with the LEDs, but that may be due to the intelligent LSI 1030 
controller with its own independent processor), so basically the box is 
dead to te outside world. There's nothing unusual in the kernel logs. The 
only thing that may be a result of that is that the IPMI server management 
card registers the following 4 system events, however I'm not very clever 
from that:

-
1)
SEL Entry Number = 5
SEL Record ID = 0050
SEL Record Type = 02 - System Event Record
Timestamp: 3.8.2005 02:31:59
Generator ID: 21 00
SEL Message Rev = 04
Sensor Type = 20 - OS Critical Stop
Sensor Number = 41 (unknown)
SEL Event Type = 6F - Sensor-specific, Assertion
SEL Event Data = A1 69 65
2)
SEL Entry Number = 6
SEL Record ID = 0060
SEL Record Type = 0F - OEM Defined
Timestamp:
Generator ID: 65 65
SEL Message Rev = 2C
Sensor Type = 20 - OS Critical Stop
Sensor Number = 6B - (unknown)
SEL Event Type = 69
SEL Event Data = 6C 6C 69
3)
SEL Entry Number = 7
SEL Record ID = 0070
SEL Record Type = 0F - OEM Defined
Timestamp:
Generator ID: 20 69
SEL Message Rev = 6E
Sensor Type = 74
Sensor Number = 65 - (unknown)
SEL Event Type = 72
SEL Event Data = 72 75 70
4)
SEL Entry Number = 8
SEL Record ID = 0080
SEL Record Type = 0F - OEM Defined
Timestamp:
Generator ID: 68 61
SEL Message Rev = 6E
Sensor Type = 64
Sensor Number = 6C - (unknown)
SEL Event Type = 65
SEL Event Data = 72 21 00
-

Interesting is, however, that while the timestamp in the above event log 
says 3.8.2005 02:31:59, when I look into the /var/log/messages it looks 
like this:

-
Aug  3 02:25:01 neutron crond(pam_unix)[6257]: session opened for user root by 
(uid=0)
Aug  3 02:25:02 neutron crond(pam_unix)[6257]: session closed for user root
Aug  3 02:30:01 neutron crond(pam_unix)[6299]: session opened for user root by 
(uid=0)
Aug  3 02:30:01 neutron crond(pam_unix)[6300]: session opened for user root by 
(uid=0)
Aug  3 02:30:01 neutron crond(pam_unix)[6300]: session closed for user root
Aug  3 02:30:01 neutron crond(pam_unix)[6299]: session closed for user root
Aug  3 02:35:01 neutron crond(pam_unix)[6344]: session opened for user root by 
(uid=0)
Aug  3 02:35:01 neutron crond(pam_unix)[6344]: session closed for user root
...
Aug  3 04:01:02 neutron crond(pam_unix)[8132]: session closed for user root
Aug  3 04:02:01 neutron crond(pam_unix)[8171]: session opened for user root by 
(uid=0)
Aug  3 18:03:54 neutron syslogd 1.4.1: restart.
Aug  3 18:03:54 neutron kernel: klogd 1.4.1, log source = /proc/kmsg started.
-

So basically there are logs up until 04:02:01 and then the whole day 
nothing (which is strange) until at 18:03:54 I hit the reset button.

I'll be very glad if anyone could tell me what's going on.

Thanks,
Martin

P.S.: The system is an MSI MS-9245 (AMD8131+8111) with 2xOpteron 246 and 
2 GB of ECC memory.
-
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.

Re: Could you please check mail configuration?

[Jesper Juhl]

On 8/4/05, Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Message to the moderators of this ML.
> 
> Please don't forward this mail to this ML.
> I intendedly mailed using a non-subscriber's address
> so that this mail only seen to the moderators.
> 
No, you send it to linux-kernel@vger.kernel.org which is the list
address, and you don't need to be subscribed to post to the list so it
doesn't matter if you used a non-subscribers address. Also, the LKML
is not a moderated list.

Please go read  http://www.tux.org/lkml/

-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Steven Rostedt]

On Thu, 2005-08-04 at 15:39 +0200, Clemens Koller wrote:
> > You are trying to do it backwards. You need to have your driver
> > use get_dma_pages() to acquire pages suitable for DMA. Your
> > driver then impliments mmap().
> 
> Okay, I have seen that, too. I've seen that some drivers do it the other
> way around as I do, but I still try to follow my idea that the
> application allocs the memory and the dma / the driver fills it up.
> Or are there fundamental problems I get with my approach which I haven't seen 
> yet?

The driver doing the allocation would probably be easier.  Do you mean
that the application will do some large malloc and then pass that
address to the driver?  The driver would then need to map in those pages
since most of them would probably not be even allocated yet (no physical
memory associated to them).  Then there's always the point to prevent
abuse by the user.  If the driver did the allocation, it would just be
easier to control.

> 
> > The user-mode application then mmaps() the dma-able pages into
> > its address-space. FYI, the pages may be from anywhere, some
> > archs can only DMA to/from memory below 16MB.
> 
> My DMA machine (ppc32, mpc8540 cpu) can do the whole 32bit phys address
> space so, that's not an issue here.

I guess you don't mind that your driver will be locked to a specific
architecture. Or at least one that can handle these requirements. Is
this just for a single use?

> 
> > The pages do not have
> > to be continuous because you will build a scatter-list for
> > the DMA engine and you will mmap() the pages so they are
> > contiguous to the user.
> 
> Yes, only virtual space is contigous. The DMA can do nice
> sg_lists and chained sg_lists, so, this should not be a problem,
> too.
> 
> > Also 400 Megabytes is absurd.
> 
> Why?
> Actually I am planning to alloc more than 1.5GByte at once,
> lock that down, build a big sg_list for all that memory because
> I need to _continously_ feed it with data from the DMA. I get
> about 200MBytes/sec and I cannot stop in between!

Wow! what a system you must have :-)   With a 32 bit address space that
really does take a big chunck out of it.  Well I guess whatever device
this driver is for must be for some specific architecture.

-- Steve


-
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/2] cpqfc: fix for "Using too much stach" in 2.6 kernel

[Jesper Juhl]

On 8/4/05, Saripalli, Venkata Ramanamurthy (STSD) <[EMAIL PROTECTED]> wrote:
> Patch 1 of 2
> 
> This patch fixes the "#error this is too much stack" in 2.6 kernel.
> Using kmalloc to allocate memory to ulFibreFrame.
> 
[snip]
>if( fchs->pl[0] == ELS_LILP_FRAME)
>   {
> +   kfree(ulFibreFrame);
>  return 1; // found the LILP frame!
>   }
>   else
>   {
> +   kfree(ulFibreFrame);
> // keep looking...
>   }

The first thing you do in either branch is to call
kfree(ulFibreFrame); , so instead of having the call in both branches
you might as well just have one call before the if().  Ohh and this
looks like it could do with a CodingStyle cleanup as well.

kfree(ulFibreFrame);
if (fchs->pl[0] == ELS_LILP_FRAME)
return 1; /* found the LILP frame! */
/* keep looking */


-- 
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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/

[PATCH] ppc32: Fix MPC834x USB memory map offsets

[Kumar Gala]

The memory mappings for MPC8349 USB MPH and DR modules were reversed.

Signed-off-by: Li Yang <[EMAIL PROTECTED]>
Signed-off-by: Jiang Bo <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
commit a2227df6ac23000dff7d95411ae5bd8022437ad3
tree d22a59e837eb881b1292f70e51df561802b279df
parent 51904043565cdfb348f58ce99377427c5ffe25fd
author Kumar K. Gala <[EMAIL PROTECTED]> Thu, 04 Aug 2005 08:57:58 -0500
committer Kumar K. Gala <[EMAIL PROTECTED]> Thu, 04 Aug 2005 08:57:58 -0500

 arch/ppc/syslib/mpc83xx_devices.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/ppc/syslib/mpc83xx_devices.c 
b/arch/ppc/syslib/mpc83xx_devices.c
--- a/arch/ppc/syslib/mpc83xx_devices.c
+++ b/arch/ppc/syslib/mpc83xx_devices.c
@@ -191,8 +191,8 @@ struct platform_device ppc_sys_platform_
.num_resources   = 2,
.resource = (struct resource[]) {
{
-   .start  = 0x22000,
-   .end= 0x22fff,
+   .start  = 0x23000,
+   .end= 0x23fff,
.flags  = IORESOURCE_MEM,
},
{
@@ -208,8 +208,8 @@ struct platform_device ppc_sys_platform_
.num_resources   = 2,
.resource = (struct resource[]) {
{
-   .start  = 0x23000,
-   .end= 0x23fff,
+   .start  = 0x22000,
+   .end= 0x22fff,
.flags  = IORESOURCE_MEM,
},
{
-
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 07/15] Basic x86_64 support

[Tom Rini]

On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote:
> > > That doesn't make much sense here. tasklet will only run when interrupts
> > > are enabled, and that is much later. You could move it to there.
> > 
> > Where?  Keep in mind it's really only x86_64 that isn't able to break
> > sooner.
> 
> The local_irq_enable() call in init/main.c:start_kernel()

But as I say, only x86_64 needs this kind of delay.

> If you want to run gdb earlier you need to do it without a tasklet.

We really would like to try again once stacks are setup (IOW, once
if ((&__get_cpu_var(init_tss))[0].ist[0])) is true).

> > > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
> > > > 2005-07-29 13:19:10.0 -0700
> > > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h  2005-07-29 
> > > > 13:19:10.0 -0700
> > > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> > > >  #define TASK_MIGRATION_VECTOR  0xfb
> > > >  #define CALL_FUNCTION_VECTOR   0xfa
> > > >  #define KDB_VECTOR 0xf9
> > > > +#define KGDB_VECTOR0xf8
> > > 
> > > I already allocated these vectors for something else.
> > 
> > Is there another we can use?  Just following what looked to be the
> > logical order.
> 
> How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
> and then just check if kgdb is currently active? 

I can do the kgdb and generic changes at least.

[snip]
> > > > cfg = __prepare_ICR(shortcut, vector, dest);
> > > > +if (vector == KGDB_VECTOR) {
> > > > + /*
> > > > +  * KGDB IPI is to be delivered as a NMI
> > > > +  */
> > > > + cfg = (cfg&~APIC_VECTOR_MASK)|APIC_DM_NMI;
> > > > + }
> > > 
> > > No way adding another ugly special case like this. I wanted
> > > to rip out the KDB version for a long time.
> > 
> > I'd be happy to rework it in a cleaner manner, just point me at an
> > example please.
> 
> The code is equivalent to passing shortcut|APIC_DM_NMI and vector == 0

OK.  I'll see if I can change things around then, thanks.

-- 
Tom Rini
http://gate.crashing.org/~trini/
-
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.13-rc3-mm3

[Christoph Lameter]

On Thu, 4 Aug 2005, Richard Purdie wrote:

> On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > Could you try the following patch? I think the problem was that higher 
> > addressses were not mappable via the page fault handler. This patch 
> > inserts the pmd entry into the pgd as necessary if the pud level is 
> > folded.
> 
> I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
> still hung in memcpy as before and the cmpxchg_fail_flag_update just
> increases...

Is there some way you can give us more information about the problem? 
Something that would allow us to determine where the thing is looping?

-
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 07/15] Basic x86_64 support

[Andi Kleen]

On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote:
> On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote:
> > > > That doesn't make much sense here. tasklet will only run when interrupts
> > > > are enabled, and that is much later. You could move it to there.
> > > 
> > > Where?  Keep in mind it's really only x86_64 that isn't able to break
> > > sooner.
> > 
> > The local_irq_enable() call in init/main.c:start_kernel()
> 
> But as I say, only x86_64 needs this kind of delay.

I don't think that's correct. Interrupts should be disabled on all
architectures until that.

-Andi
-
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: Could you please check mail configuration?

[Matt Domsch]

On Thu, Aug 04, 2005 at 10:46:35PM +0900, Tetsuo Handa wrote:
> Message to the moderators of this ML.
> 
> Please don't forward this mail to this ML.
> I intendedly mailed using a non-subscriber's address
> so that this mail only seen to the moderators.
> 
> -
> 
> Hello,
> 
> I found X-OUTRCPT-TO: header since
> Linux-kernel-daily-digest Digest, Vol 8, Issue 21
> (at Date: Thu, 21 Jul 2005 06:00:01 -0500).
> The X-OUTRCPT-TO: header exposes recipient's mail addresses.
> And recently I'm getting spam mails to the exposed address.
> I want you to hide X-OUTRCPT-TO header if you can.
> 
> I sent to the person managing the list
> ([EMAIL PROTECTED])
> on Mon, 1 Aug 2005 20:11:31 +0900, but no reply.
> So I sent to you this time.

I run the daily-digest list.

I had a note from you that this was a configuration error on your
server's part, not on the list.  So I stopped worrying about it...

-Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
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.6.13-rc4] fix get_user_pages bug

[Alexander Nyberg]

On Wed, Aug 03, 2005 at 09:12:37AM -0700 Linus Torvalds wrote:

> 
> 
> On Wed, 3 Aug 2005, Nick Piggin wrote:
> > 
> > Oh, it gets rid of the -1 for VM_FAULT_OOM. Doesn't seem like there
> > is a good reason for it, but might that break out of tree drivers?
> 
> Ok, I applied this because it was reasonably pretty and I liked the 
> approach. It seems buggy, though, since it was using "switch ()" to test 
> the bits (wrongly, afaik), and I'm going to apply the appended on top of 
> it. Holler quickly if you disagreee..
> 

x86_64 had hardcoded the VM_ numbers so it broke down when the numbers
were changed.

Signed-off-by: Alexander Nyberg <[EMAIL PROTECTED]>

Index: linux-2.6/arch/x86_64/mm/fault.c
===
--- linux-2.6.orig/arch/x86_64/mm/fault.c   2005-07-31 18:10:20.0 
+0200
+++ linux-2.6/arch/x86_64/mm/fault.c2005-08-04 16:04:59.0 +0200
@@ -439,13 +439,13 @@
 * the fault.
 */
switch (handle_mm_fault(mm, vma, address, write)) {
-   case 1:
+   case VM_FAULT_MINOR:
tsk->min_flt++;
break;
-   case 2:
+   case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
-   case 0:
+   case VM_FAULT_SIGBUS:
goto do_sigbus;
default:
goto out_of_memory;
-
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 07/15] Basic x86_64 support

[Tom Rini]

On Thu, Aug 04, 2005 at 04:06:20PM +0200, Andi Kleen wrote:
> On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote:
> > On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote:
> > > > > That doesn't make much sense here. tasklet will only run when 
> > > > > interrupts
> > > > > are enabled, and that is much later. You could move it to there.
> > > > 
> > > > Where?  Keep in mind it's really only x86_64 that isn't able to break
> > > > sooner.
> > > 
> > > The local_irq_enable() call in init/main.c:start_kernel()
> > 
> > But as I say, only x86_64 needs this kind of delay.
> 
> I don't think that's correct. Interrupts should be disabled on all
> architectures until that.

Right, but we can run sooner elsewhere.  It's only x86_64 where we can't
run when our commandline bits are parsed and need to wait.

-- 
Tom Rini
http://gate.crashing.org/~trini/
-
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: MCE problem on dual Opteron

[Roger Heflin]

If this does not happen immediately at boot up (before the machine
finished all init stuff), it is generally a hardware problem.  In
my experience with new machines 75% of the time it will be the cpu
itself, and another 25% it will be a serious memory error.

The machine I have dealt with are dual cpu with ECC's and we have
seen and eliminated a large number of these, that upon testing are 
duplicatable on a per machine basis with large numbers of identical
machines *NOT* having the same issue with all having the same os.

So in my experience this has always been hardware, except that after
a initial cold power on (with the kernel I was using at the time) there
seems to be some weird initial state that causes these to happen, we
would get MCE's on around 10% of machines on an improper power cycle
(150KW main breaker blew), and after a couple of reboots the machines 
that had the error would come up and be fine.

Fedora also sets quiet so the messages won't scare any of the common
desktop type people, so I would not count there use of nomce as being 
important on a server class machine, from the MCE's that I have got,
I don't think you would for the most part actually get any (someone
correct me if I am wrong on this) if you did not have ECC ram, as
all of the ones I have got (and I have dealt with a large sample of
dual cpu servers- >500) have been related to ECC (except for the 
weird initial power on one).

  Roger



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Martin Drab
> Sent: Thursday, August 04, 2005 8:55 AM
> To: Linux Kernel Mailing List
> Subject: MCE problem on dual Opteron
> 
> Hi,
> 
> I get the following problem with 2.6.13-rc5-git1 on a dual Opteron
> machine:
> 
> -
> ...
> [   847.745921] CPU 0: Machine Check Exception:   
>  7 Bank 3: b400083b
> [   847.746066] RIP 10: {pci_conf1_read+0xbe/0x110}
> [   847.746149] TSC 189fe311d3f ADDR fdfc000cfe
> [   847.746218] Kernel panic - not syncing: Uncorrected machine check
> -
> 
> This appears during bootup and it hangs. So my question is: 
> Is this a HW problem or is it some kernel (MCE ?) bug? If it 
> is a HW problem is it possible to determine what's wrong somehow?
> 
> The above mentioned output I get also from 2.6.13-rc4-git4 
> and 2.6.12.3. 
> When I run the original FC4 kernel 2.6.11-1.1369_FC4smp I get 
> the same followed by the following call trace:
> 
> -
> Call Trace: <#MC> {panic+133} 
> {print_mce+159} 
> {mce_panic+137} 
>  {pci_conf1_read+190}
> {pci_conf1_read+190}
> {machine_check+127}
> {selinux_d_instantiate+0}
> {pci_conf1_read+190}  
> {pci_direct_init+119} 
> {init+482} {child_rip+8} 
> {init+0} {child_rip+0}
> 
> 
> Interesting is, that FC4 automatically sets the 'nomce' 
> option to the kernel command line by default (which leads me 
> to that it may actually be a bug in the kernel). And when 
> 'nomce' is used the system boots and runs quite normally.
> 
> Only recently with 2.6.12.3 (which the box was running past few
> months) from time to time (so far it happend 3 times in about 
> a month) the box completly stops responding to the outside 
> world (no network, display turns off (no signal), USB 
> keyboard and mouse both go dead, however the comp isn't 
> turned off because for instance the disks are still normally 
> flashing with the LEDs, but that may be due to the 
> intelligent LSI 1030 controller with its own independent 
> processor), so basically the box is dead to te outside world. 
> There's nothing unusual in the kernel logs. The only thing 
> that may be a result of that is that the IPMI server 
> management card registers the following 4 system events, 
> however I'm not very clever from that:
> 
> -
> 1)
>   SEL Entry Number = 5
>   SEL Record ID = 0050
>   SEL Record Type = 02 - System Event Record
>   Timestamp: 3.8.2005 02:31:59
>   Generator ID: 21 00
>   SEL Message Rev = 04
>   Sensor Type = 20 - OS Critical Stop
>   Sensor Number = 41 (unknown)
>   SEL Event Type = 6F - Sensor-specific, Assertion
>   SEL Event Data = A1 69 65
> 2)
>   SEL Entry Number = 6
>   SEL Record ID = 0060
>   SEL Record Type = 0F - OEM Defined
>   Timestamp:
>   Generator ID: 65 65
>   SEL Message Rev = 2C
>   Sensor Type = 20 - OS Critical Stop
>   Sensor Number = 6B - (unknown)
>   SEL Event Type = 69
>   SEL Event Data = 6C 6C 69
> 3)
>   SEL Entry Number = 7
>   SEL Record ID = 0070
>   SEL Record Type = 0F - OEM Defined
>   Timestamp:
>   Generator ID: 20 69
>   SEL Message Rev = 6E
>   Sensor Type = 74
>   Sensor Number = 65 - (unknown)
>   SEL Event Type = 72
>   SEL Event Data = 72 75 70
> 4)
>   SEL Entry Number = 8
>   SEL Record ID = 0080
>   SEL Record Type = 0F - OEM Defined
>   Timestamp:
>   Generator ID: 68 61
>   SEL Message R

Re: [RFC,PATCH] RCU and CONFIG_PREEMPT_RT sane patch

[Ingo Molnar]

* Paul E. McKenney <[EMAIL PROTECTED]> wrote:

> Hello!
> 
> The attached patch passes 20 hours of the internal-to-RCU torture test 
> (see the code in the attached patch under CONFIG_RCU_TORTURE_TEST), 
> which is a good improvement over last week's version, which would fail 
> this test in less than two seconds -- this despite passing kernbench 
> with flying colors and passing LTP 90% of the time.  Sometimes there 
> is no substitute for a good in-kernel stress test...
> 
> The attached version of the patch seems to me to be ready for a larger 
> audience.

Cool! I've merged your patch to the -52-12 version of the -RT patch. You 
can get it from the usual place:

  http://redhat.com/~mingo/realtime-preempt/

also, i've attached a port against 2.6.13-rc4. I have done this because 
the PREEMPT_RCU patch in my tree is applied before the core-PREEMPT_RT 
patch. I have fixed up the CONFIG_PREEMPT compilation branch and have 
removed your #error define - it built and booted fine on an UP box but 
there are no guarantees ...

Ingo

make rcu_read_lock() critical sections preemptible.

 fs/proc/proc_misc.c  |   81 
 include/linux/rcupdate.h |   50 ++-
 include/linux/sched.h|5 
 kernel/Kconfig.preempt   |   36 ++
 kernel/rcupdate.c|  783 +--
 5 files changed, 918 insertions(+), 37 deletions(-)

Index: linux/fs/proc/proc_misc.c
===
--- linux.orig/fs/proc/proc_misc.c
+++ linux/fs/proc/proc_misc.c
@@ -563,6 +563,78 @@ void create_seq_entry(char *name, mode_t
entry->proc_fops = f;
 }
 
+#ifdef CONFIG_RCU_STATS
+int rcu_read_proc(char *page, char **start, off_t off,
+ int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_data(char *page);
+
+   len = rcu_read_proc_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_gp(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_gp_data(char *page);
+
+   len = rcu_read_proc_gp_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_ptrs(char *page, char **start, off_t off,
+  int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_ptrs_data(char *page);
+
+   len = rcu_read_proc_ptrs_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_ctrs(char *page, char **start, off_t off,
+  int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_ctrs_data(char *page);
+
+   len = rcu_read_proc_ctrs_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_torture_writer(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_torture_writer_data(char *page);
+
+   len = rcu_read_proc_torture_writer_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_torture_reader(char *page, char **start, off_t off,
+int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_torture_reader_data(char *page);
+
+   len = rcu_read_proc_torture_reader_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+
+int rcu_read_proc_torture_stats(char *page, char **start, off_t off,
+   int count, int *eof, void *data)
+{
+   int len;
+   extern int rcu_read_proc_torture_stats_data(char *page);
+
+   len = rcu_read_proc_torture_stats_data(page);
+   return proc_calc_metrics(page, start, off, count, eof, len);
+}
+#endif /* #ifdef CONFIG_RCU_STATS */
+
 void __init proc_misc_init(void)
 {
struct proc_dir_entry *entry;
@@ -585,6 +657,15 @@ void __init proc_misc_init(void)
{"cmdline", cmdline_read_proc},
{"locks",   locks_read_proc},
{"execdomains", execdomains_read_proc},
+#ifdef CONFIG_RCU_STATS
+   {"rcustats",rcu_read_proc},
+   {"rcugp",   rcu_read_proc_gp},
+   {"rcuptrs", rcu_read_proc_ptrs},
+   {"rcuctrs", rcu_read_proc_ctrs},
+   {"rcutw",   rcu_read_proc_torture_writer},
+   {"rcutr",   rcu_read_proc_torture_reader},
+   {"rcuts",   rcu_read_proc_torture_stats},
+#endif /* #ifdef CONFIG_RCU_STATS */
{NULL,}
};
for (p = simple_ones; p->name; p++)
Index: linux/include/linux/rcupdate.h
===
--- linux.orig/include/linux/rcupdate.h
+++ linux/include/linux/r

Re: How to get the physical page addresses from a kernel virtual address for DMA SG List?

[Arjan van de Ven]

On Thu, 2005-08-04 at 15:39 +0200, Clemens Koller wrote:
> Hello, Dick!
> 
> Thanks for your help so far!
> 
> linux-os (Dick Johnson) wrote:
> > 
> > You are trying to do it backwards. You need to have your driver
> > use get_dma_pages() to acquire pages suitable for DMA. Your
> > driver then impliments mmap().
> 
> Okay, I have seen that, too. I've seen that some drivers do it the other
> way around as I do, but I still try to follow my idea that the
> application allocs the memory and the dma / the driver fills it up.
> Or are there fundamental problems I get with my approach which I haven't seen 
> yet?

there are some very funamental problems with that;
say the user allocation is only half the page, and he uses the other
half of the page for something else.
during the DMA some other thread calls fork().

Now the stuff under DMA can't COW of course, so only one half gets it.
But.. what to do with the second half of the page?

this is just one of the many fine fundamental issues you'll face ;)


-
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] Speedup FAT filesystem directory reads

[OGAWA Hirofumi]

Karsten Wiese <[EMAIL PROTECTED]> writes:

> Please give this a try and commit to -mm or mainline, if approved.

Looks good. Thanks.  However, I tweaked the patch.

- replace __getblk() to sb_getblk()
- exclude root-dir of FAT12/FAT16 from readahead
- exclude (sec_per_clus == 1) from readahead
- move the all readahead stuff to one inline function

What do you think of the following patch?
-- 
OGAWA Hirofumi <[EMAIL PROTECTED]>


Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---

 fs/fat/dir.c |   28 ++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff -puN fs/fat/dir.c~fat-sb_breadahead fs/fat/dir.c
--- linux-2.6.13-rc4/fs/fat/dir.c~fat-sb_breadahead 2005-08-04 
21:21:59.0 +0900
+++ linux-2.6.13-rc4-hirofumi/fs/fat/dir.c  2005-08-04 23:05:58.0 
+0900
@@ -30,6 +30,29 @@ static inline loff_t fat_make_i_pos(stru
| (de - (struct msdos_dir_entry *)bh->b_data);
 }
 
+static inline void fat_dir_readahead(struct inode *dir, sector_t iblock,
+sector_t phys)
+{
+   struct super_block *sb = dir->i_sb;
+   struct msdos_sb_info *sbi = MSDOS_SB(sb);
+   struct buffer_head *bh;
+   int sec;
+
+   /* This is not a first sector of cluster, or sec_per_clus == 1 */
+   if ((iblock & (sbi->sec_per_clus - 1)) || sbi->sec_per_clus == 1)
+   return;
+   /* root dir of FAT12/FAT16 */
+   if ((sbi->fat_bits != 32) && (dir->i_ino == MSDOS_ROOT_INO))
+   return;
+
+   bh = sb_getblk(sb, phys);
+   if (bh && !buffer_uptodate(bh)) {
+   for (sec = 0; sec < sbi->sec_per_clus; sec++)
+   sb_breadahead(sb, phys + sec);
+   }
+   brelse(bh);
+}
+
 /* Returns the inode number of the directory entry at offset pos. If bh is
non-NULL, it is brelse'd before. Pos is incremented. The buffer header is
returned in bh.
@@ -58,6 +81,8 @@ next:
if (err || !phys)
return -1;  /* beyond EOF or error */
 
+   fat_dir_readahead(dir, iblock, phys);
+
*bh = sb_bread(sb, phys);
if (*bh == NULL) {
printk(KERN_ERR "FAT: Directory bread(block %llu) failed\n",
@@ -635,8 +660,7 @@ RecEnd:
 EODir:
filp->f_pos = cpos;
 FillFailed:
-   if (bh)
-   brelse(bh);
+   brelse(bh);
if (unicode)
free_page((unsigned long)unicode);
 out:
_
-
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/

[RFC] AMD64 @ K8T800/VT8237: Doubled IOAPIC-level-interrupt rate

[Karsten Wiese]

Hi,

this should likely be addressed to VIA Taiwan,
but I don't know their engineer's e-mail address and their forum
doesn't work for me.
Maybe somebody here has a clue?
Or maybe this is even motherboard specific?

To reproduce:
$ aplay -Dhw:0 -fdat /dev/zero

On a sane system (or here in PIC Mode) you'll see
around 12 Interrupts/s.
Here I see 24.

12 per s more is no big deal, but if you run low-latency audio,
the overhead becomes significant.

What exactly happens when i.e. the sounddevice (part of the VT8237)
triggers an interrupt (low level on interrupt pin) is this:

1. IOAPIC accepts interrupt, sends it to CPU's APIC.

2. Interrupt Routine runs,
   tells the sounddevice to deassert the interrupt pin.

3. When sounddevice deasserts pin (low to high transition),
   IOAPIC accepts an interrupt _again_ , tells APIC,
   which also accepts interrupt again (IRR-Bit set).
   _This should not happen_.
   Looks like the IOAPIC (Part of the VT8237) behaves like
   Level Triggered _AND_ Edge Triggered at once!?!

3. Interrupt Routine finishes with sending EOI to the CPU's APIC,
   which tells IOAPIC to accept Interrupts on the soundcards interrupt
   pin _now_.
   But the IOAPIC has already wrongly accepted the next interupt
   in step 2.

4. Processor accepts interrupts again and runs the soundcards
   interruptroutine again.
   Now the interrupt Routine sees a soundcard that doesn't need
   servicing and finishes, having done nothing,
   but clearing up the APIC/IOAPIC.
 
This bad behavior can be eliminated by masking the IOAPIC's interrupt pin
during the phase where the sounddevice's interrupt pin is deasserted.
But (Un)masking is also a cycle-costly operation,
which shouldn't be necessary on a sane system.

So my question here is:
Can the VT8237's IOAPIC (or other device) be programmed in a way
to behave sanely?
Or is this a known bug that can only be circumvented?
If it was an Intel/AMD chipsets I'd likely find those info's
in publicly available docs, but here the problem for me is
to get the docs...
(Or WTF do I buy stuff, which comes without public docs $%§!!grmbl!)

Thanks,
Karsten





___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
http://mail.yahoo.de

-
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 07/15] Basic x86_64 support

[Andi Kleen]

On Thu, Aug 04, 2005 at 07:14:37AM -0700, Tom Rini wrote:
> On Thu, Aug 04, 2005 at 04:06:20PM +0200, Andi Kleen wrote:
> > On Thu, Aug 04, 2005 at 07:04:45AM -0700, Tom Rini wrote:
> > > On Thu, Aug 04, 2005 at 02:39:00PM +0200, Andi Kleen wrote:
> > > > > > That doesn't make much sense here. tasklet will only run when 
> > > > > > interrupts
> > > > > > are enabled, and that is much later. You could move it to there.
> > > > > 
> > > > > Where?  Keep in mind it's really only x86_64 that isn't able to break
> > > > > sooner.
> > > > 
> > > > The local_irq_enable() call in init/main.c:start_kernel()
> > > 
> > > But as I say, only x86_64 needs this kind of delay.
> > 
> > I don't think that's correct. Interrupts should be disabled on all
> > architectures until that.
> 
> Right, but we can run sooner elsewhere.  It's only x86_64 where we can't
> run when our commandline bits are parsed and need to wait.

Why can't you run on x86-64 early? 

-Andi
-
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.6.13-rc4] fix get_user_pages bug

[Nick Piggin]

Alexander Nyberg wrote:

On Wed, Aug 03, 2005 at 09:12:37AM -0700 Linus Torvalds wrote:




Ok, I applied this because it was reasonably pretty and I liked the 
approach. It seems buggy, though, since it was using "switch ()" to test 
the bits (wrongly, afaik), and I'm going to apply the appended on top of 
it. Holler quickly if you disagreee..





x86_64 had hardcoded the VM_ numbers so it broke down when the numbers
were changed.



Ugh, sorry I should have audited this but I really wasn't expecting
it (famous last words). Hasn't been a good week for me.

parisc, cris, m68k, frv, sh64, arm26 are also broken.
Would you mind resending a patch that fixes them all?

Thanks,
Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 


-
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/