date:20070221

On Wed, 2007-02-21 at 18:07 +0100, Thomas Gleixner wrote:
 On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
   The most interesting core change may be the dyntick/nohz one, where timer 
   ticks will only happen when needed. It's been brewing for a _loong_ time, 
   but it's in the standard kernel now as an option. 
  
  On i386 I get the following,
  
  TCP cubic registered
  
  NET: Registered protocol family 1   
  
  NET: Registered protocol family 17  
  
  Testing NMI watchdog ... CPU#0: NMI appears to be stuck (24-24)!   
  
  CPU#1: NMI appears to be stuck (0-0)!  
  
  CPU#2: NMI appears to be stuck (0-0)!  
  
  CPU#3: NMI appears to be stuck (0-0)!  
  
  when I add nmi_watchdog=1 to my boot args which worked on prior kernels.
  On closer inspection it looks like arch/i386/kernel/io_apic.c :
  check_timer() -- timer_irq_works() depends on IRQ0 incrementing jiffies
  which is no longer the case AFAIK.
 
 At this point the PIT / HPET _is_ active and incrementing jiffies. The
 switch to local apic timers happens afterwards. 

Could be the switch over then which confuses the NMI . 

  I'm not sure exactly how that relates to the NMI, but the check_timer()
  function disabled the NMI through the io-apic if it can't get the
  timer working through the io-apic.
 
 Boot log please.
 
   tglx
 

.config is in there too .

ftp://source.mvista.com/pub/dwalker/tglx/

-
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 03/18] Dont leak NT bit into next task

Giuseppe Bilotta wrote:
 On Wednesday 21 February 2007 02:49, Greg KH wrote:
 
  /* frame pointer must be last for get_wchan */
 -#define SAVE_CONTEXTpushq %%rbp ; movq %%rsi,%%rbp\n\t
 -#define RESTORE_CONTEXT movq %%rbp,%%rsi ; popq %%rbp\n\t
 +#define SAVE_CONTEXTpushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t
 +#define RESTORE_CONTEXT movq %%rbp,%%rsi ; popq %%rbp ; popf\t
 
 No idea if this is a problem or not, but you forgot a \n after popf.
 

It's that way in 2.6.21-rc1.
-
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: Expertise required:USB bulk-throughput and memory leak detection

2007-02-21 Thread Michael Richardson


[EMAIL PROTECTED] wrote:
1.) detecting memory leaks caused by our driver code. 


Your code will of course be allocating buffers. If you are allocating
from a specific slab, if you have leaks, they will show up in /proc/slabinfo

I wrote some code last month, which I called slabwatch, to track each
item from slabinfo over time and let me plot it. I knew I had a memory leak
which under heavy (network) test loads eventually brought down the kernel,
and I was able to determine what was leaking, and eventually where the leak was.

http://www.sandelman.ca/software/slabwatch-1.3.tgz

It's very rudamentary.

2.) Neither have we been able to find a tool which shows % 
utilisation of kernel memory used by our driver.(kernel 
memory monitoring)


if you know what pools you are allocating from, then you should be able
to see what is going on. If you are able to, you may want to allocate
(at least experimentally), your own slab, because then you can see precisely
what is going on. This isn't trivial for skb allocations, because you have
to use a custom destructor for the skb, as kfree_skb() otherwise would free
things into the wrong slab.

I wouldn't have minded having a per-interface pool of memory
(and I can see a lot of uses where it would be valuable to limit skb's
allocated to the capture port of a snort sensor, for instance, while not
starving the management port), but I don't know if the skb-destructor is 
sufficient
under-used to permit such a thing to be trivially implemented.

I don't know the situation with USB drivers.

-
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] Fix misspellings collected by members of KJ list.

2007-02-21 Thread Randy Dunlap

On Wed, 21 Feb 2007 12:10:44 -0500 (EST) Robert P. J. Day wrote:

 
   Fix the misspellings of propogate, writting and (oh, the shame
 :-) kenrel in the source tree.

We also knohow to spel depreciated.
(well, only 6 in 2.6.21-rc1)

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: securityfs_create_dir strange comment

On Wed, Feb 21, 2007 at 06:07:56PM +0100, Jan Engelhardt wrote:
 Hello Greg,
 
 
 On Feb 20 2007 20:05, Greg KH wrote:
 
 Try this instead:
  if (!de)
  return -ENOMEM;
  if ((IS_ERR(de))  (PTR_ERR(de) != -ENODEV))
  return PTR_ERR(de);
  return 0;
 
 That should cover everything properly, right?
 
 In case memory could not be allocated, why does not securityfs_*() return
 ERR_PTR(-ENOMEM) then? (I think, that's the quintessential question after
 all. And thanks for giving an example what to do in the ENODEV case.)

Actually, in reading the code (which might have helped in the first
place), we can never return NULL if securityfs is enabled.  So you can
just drop that first check entirely.

Which makes me wonder, it might be easier to just return NULL if
securityfs is not enabled in the kernel, as long as no one checks that
improperly...

Hope this helps,

greg k-h
-
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.20-git and 2.6.21-rc1, failed to boot on sata_via

2007-02-21 Thread Jean-Luc Coulon (f5ibh)


Le 21.02.2007 17:18:23, Markus Trippelsdorf a écrit :

On Wed, Feb 21, 2007 at 03:01:54PM +0100, Jean-Luc Coulon (f5ibh)
wrote:


At boot time, I've the following messages:

ACPI: PCI Interrupt :00:0f.0[B] GSI 20(level, low) - IRQ 20
sata_via :00:0f.0: failed on iomap PCI BAR 0
sata_via :00:0f.0: out of memory
ACPI: PCI interrupt for device :00:0f.0 is disabled
sata_via: probe of :00:0f.0 failed with error -12


I had the same problem, but the issue is already fixed. See:
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03945.html


Thanks Markus. I've applied the patch (and it works :)
I was puzzled because rc1 has been released today without this patch.

Regards

Jean-Luc


pgpRHDNymxlJe.pgp
Description: PGP signature

Re: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
  At this point the PIT / HPET _is_ active and incrementing jiffies. The
  switch to local apic timers happens afterwards. 
 
 Could be the switch over then which confuses the NMI . 

Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
and friends at all.

 ftp://source.mvista.com/pub/dwalker/tglx/

Nothing obvious. Bisect time :(

tglx


-
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: [stable] [patch 00/18] 2.6.18-stable review

On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??: 
  Responses should be made by Friday February 23 00:00 UTC.  Anything
  received after that time might be too late.
 
 We have still some CVEish patches in our package which maybe you want to 
 consider adding into -stable.
 
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Do you have a pointer to the patches for these fixes anywhere?

And are you sure they are all for 2.6.18?  The first one above is for
the 2.4 kernel tree :)

thanks,

greg k-h
-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 18:41 +0100, Thomas Gleixner wrote:
 On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
   At this point the PIT / HPET _is_ active and incrementing jiffies. The
   switch to local apic timers happens afterwards. 
  
  Could be the switch over then which confuses the NMI . 
 
 Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
 and friends at all.

I'm not an expert on the io-apic, but the check_timer() function seemed
to assume IRQ0 was happening regularly ..

  ftp://source.mvista.com/pub/dwalker/tglx/
 
 Nothing obvious. Bisect time :(

Well, I'm pretty sure it's HRT, cause in prior versions this only
happened when HRT is enabled. Then you guys went to the lapic all the
time, and now this is happening all the time ..

You can't reproduce this?

Daniel

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

[PATCH] cleanup up symlinks

2007-02-21 Thread James Simmons


When a device fails to register the class symlinks where not cleaned up. 
This left a symlink in the /sys/class/device/ directory that pointed to 
no where. This caused the sysfs_follow_link Oops I reported earlier. This 
patch cleanups up the symlink. Please apply. Thank you.

Signed-Off: James Simmons [EMAIL PROTECTED]

diff --git a/drivers/base/core.c b/drivers/base/core.c
index d04fd33..cf2a398 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -637,12 +637,41 @@ int device_add(struct device *dev)
 BUS_NOTIFY_DEL_DEVICE, dev);
device_remove_groups(dev);
  GroupError:
-   device_remove_attrs(dev);
+   device_remove_attrs(dev);
  AttrsError:
if (dev-devt_attr) {
device_remove_file(dev, dev-devt_attr);
kfree(dev-devt_attr);
}
+
+   if (dev-class) {
+   sysfs_remove_link(dev-kobj, subsystem);
+   /* If this is not a fake compatible device, remove the
+* symlink from the class to the device. */
+   if (dev-kobj.parent != dev-class-subsys.kset.kobj)
+   sysfs_remove_link(dev-class-subsys.kset.kobj,
+ dev-bus_id);
+#ifdef CONFIG_SYSFS_DEPRECATED
+   if (parent) {
+   char *class_name = make_class_name(dev-class-name,
+  dev-kobj);
+   if (class_name)
+   sysfs_remove_link(dev-parent-kobj,
+ class_name);
+   kfree(class_name);
+   sysfs_remove_link(dev-kobj, device);
+   }
+#endif
+
+   down(dev-class-sem);
+   /* notify any interfaces that the device is now gone */
+   list_for_each_entry(class_intf, dev-class-interfaces, node)
+   if (class_intf-remove_dev)
+   class_intf-remove_dev(dev, class_intf);
+   /* remove the device from the class list */
+   list_del_init(dev-node);
+   up(dev-class-sem);
+   }
  ueventattrError:
device_remove_file(dev, dev-uevent_attr);
  attrError:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/hid/hid-debug.c should #include linux/hid-debug.h

2007-02-21 Thread Adrian Bunk

Every file should include the headers containing the prototypes for
it's global functions.

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

---
--- linux-2.6.20-mm2/drivers/hid/hid-debug.c.old2007-02-20 
23:07:32.0 +0100
+++ linux-2.6.20-mm2/drivers/hid/hid-debug.c2007-02-21 00:00:41.0 
+0100
@@ -29,6 +29,7 @@
  */
 
 #include linux/hid.h
+#include linux/hid-debug.h
 
 struct hid_usage_entry {
unsigned  page;

-
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 patch] drivers/hid/hid-debug.c should #include linux/hid-debug.h

2007-02-21 Thread Jiri Kosina

On Wed, 21 Feb 2007, Adrian Bunk wrote:

 Every file should include the headers containing the prototypes for
 it's global functions.

Applied, thanks.

-- 
Jiri Kosina
-
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] UML utrace support, step 1

2007-02-21 Thread Roland McGrath

 Below is the first step in your Fix-Your-Broken-Arch-HOWTO for UML.

Great!  Thanks for tackling this.

 Do you want incremental patches as I go along, or replacement ones?

The way I've organized my patch series is with the arch support split up
along with the separate infrastructure patches in the series.  That is,
just asm/tracehook.h with no utrace_regset stuff in the first patch so that
the kernel builds with only utrace-tracehook.patch; then the regset stuff
but no arch_ptrace et al in another patch so that it builds with
utrace-regset.patch but without the later patches; then arch_ptrace et al
in the final arch patch.  Your patch is mostly just the first of these
(utrace-tracehook-um), but includes utrace_regset and arch_ptrace stubs
that won't compile without the later infrastructure patches applied.

If you want to divide things up this way, then I'd like just to see a
replacement utrace-tracehook-um.patch followed by utrace-regset-um.patch
and utrace-ptrace-compat-um.patch, replacing each one whole as needed until
it's merged into my trees, and then I can take incremental changes after
that.  If you don't want to bother with dividing things so it compiles in
between patches in the series, then just one big replacement patch is fine.

 +const struct utrace_regset_view utrace_um_native = {
 + .name   = um,

This name wants to be the subarch name--it's usually the $ARCH or
UTS_MACHINE, i.e. the canonical arch name (i386 not i686, but ppc64 or ppc,
not powerpc).  In fact, I'm sure you really want to define the
utrace_regset_view structs separately somewhere in arch/um/sys-$SUBARCH.
On biarch platforms you'll need more than one, as the native biarch
platforms have.  (But that is all part of the second step that isn't really
tackled in this patch.)

 +#define ARCH_HAS_SINGLE_STEP (1)

Note you'll eventually want to define the block-step macro and functions
depending on subarch.  (ia64 supports it, and x86 one day will.)

 +extern const struct utrace_regset_view utrace_um_native;
 +static inline const struct utrace_regset_view *
 +utrace_native_view(struct task_struct *tsk)
 +{
 + return utrace_um_native;
 +}

You probably just want an extern decl for utrace_native_view here,
since what it really does with depend on the subarch.

 BTW, UML runs on the utrace in -mm (i.e. utrace on the host), which it
 didn't with several Fedora kernels.

Oh, really?  That's good, but are you sure?  Have you tried a
CONFIG_PREEMPT=y host?  I reproduced a failure with the current code
recently after Alexey Dobriyan reported the problem.  But I didn't get
anywhere debugging it and got busy with other work.  I could use some help
tracking down what ptrace does differently that broke UML, if it does
indeed still come up.  I have plenty of experience debugging ptrace and
users of it, but I don't know much of anything about UML's usage pattern
and got quickly lost in its code trying to tell what it expected to happen.


Thanks,
Roland
-
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/

x86_64: PTRACE_[GS]ET_THREAD_AREA should be accepted

2007-02-21 Thread Paolo 'Blaisorblade' Giarrusso

This patch backports from 2.6.19 a fix to a 2.6.18 regression.

Like for PTRACE_OLDSETOPTIONS, we should fix PTRACE_[GS]ET_THREAD_AREA. This had
been done already for 2.6.19, so this is for 2.6.18-stable only.
This was tested with UML/32bit as API consumer, both before and after this
patch.

Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Paolo 'Blaisorblade' Giarrusso [EMAIL PROTECTED]
Index: linux-2.6.18/arch/x86_64/ia32/ptrace32.c
===
--- linux-2.6.18.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.18/arch/x86_64/ia32/ptrace32.c
@@ -241,6 +241,8 @@ asmlinkage long sys32_ptrace(long reques
case PTRACE_SYSCALL:
case PTRACE_OLDSETOPTIONS:
case PTRACE_SETOPTIONS:
+   case PTRACE_SET_THREAD_AREA:
+   case PTRACE_GET_THREAD_AREA:
return sys_ptrace(request, pid, addr, data); 
 
default:


-
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: securityfs_create_dir strange comment

2007-02-21 Thread Jan Engelhardt

Hi Greg,

 Try this instead:
 if (!de)
 return -ENOMEM;
 if ((IS_ERR(de))  (PTR_ERR(de) != -ENODEV))
 return PTR_ERR(de);
 return 0;
 
 That should cover everything properly, right?
 
 In case memory could not be allocated, why does not securityfs_*() return
 ERR_PTR(-ENOMEM) then? (I think, that's the quintessential question after
 all. And thanks for giving an example what to do in the ENODEV case.)

Actually, in reading the code (which might have helped in the first
place), we can never return NULL if securityfs is enabled.

So we're back to the confusing comment ;-)

So you can just drop that first check entirely.

Which makes me wonder, it might be easier to just return NULL if
securityfs is not enabled in the kernel, as long as no one checks that
improperly...

I have actually had a look into the tree who even uses securityfs.
The most prominent case are LSMs. They need CONFIG_SECURITY=y anyway,
so securityfs is always enabled for those. What remains seems to be
tpm_bios.c.


Jan
-- 
-
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] slab: ensure cache_alloc_refill terminates

On Wed, 21 Feb 2007, Pekka J Enberg wrote:

 +  */
 + BUG_ON(slabp-inuse  0 || slabp-inuse = cachep-num);
 +
   while (slabp-inuse  cachep-num  batchcount--) {

I think you only need to check for 0. If slabp-inuse  cachep-num then 
the loop will not be taken.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] slab: introduce krealloc

On Wed, 21 Feb 2007, Pekka Enberg wrote:

 On 2/21/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
  please mark this one __must_check.. not storing realloc() return values
  is one of the more nasty types of bugs... but gcc can help us greatly
  here ;)
 
 So I guess we want the same thing for the other allocator functions
 (__kmalloc et al) as well?

I think so.

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

Re: [PATCH 1/3] slab: introduce krealloc

On Wed, 21 Feb 2007, Pekka J Enberg wrote:

 +void *krealloc(const void *p, size_t new_size, gfp_t flags)
 +{
 + void *ret;
 +
 + if (unlikely(!p))
 + return kmalloc_track_caller(new_size, flags);
 +
 + if (unlikely(!new_size)) {
 + kfree(p);
 + return NULL;
 + }
 +
 + ret = kmalloc_track_caller(new_size, flags);
 + if (!ret)
 + return NULL;
 +
 + memcpy(ret, p, min(new_size, ksize(p)));
 + kfree(p);
 + return ret;
 +}
 +EXPORT_SYMBOL(krealloc);

Well could you check ksize for the old object first and if ksize = new 
size then just skip the copy? I think this may allow you 
to get rid of the ksize callers.


-
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: High CPU usage with sata_nv

2007-02-21 Thread Lee Revell


On 2/21/07, Matthew Fredrickson [EMAIL PROTECTED] wrote:

It's a 2.6.18 kernel.  What we're seeing (by means of the interrupt pin
on another card) is extremely large interrupt latency (measured from
the time the interrupt pin goes low to the first couple lines of code
in the IRQ handler to clear it) occasionally, in the order of 500-700
microseconds.  I figured it was some other driver on the system
disabling irqs for a long period of time, but it's difficult to trace
what might be doing that.


Apply the -rt kernel patch and enable the latency tracer, it will tell
you what code path is responsible.

Lee
-
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 1/1] MM: detach_vmas_to_be_unmapped fix

2007-02-21 Thread akuster



---

 mm/mmap.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN mm/mmap.c~Avoiding-mmap-fragmentation_fixup mm/mmap.c
--- linux-2.6_clean/mm/mmap.c~Avoiding-mmap-fragmentation_fixup 2007-02-21 
09:49:32.0 -0800
+++ linux-2.6_clean-akuster/mm/mmap.c   2007-02-21 09:51:26.0 -0800
@@ -1720,9 +1720,9 @@ detach_vmas_to_be_unmapped(struct mm_str
*insertion_point = vma;
tail_vma-vm_next = NULL;
if (mm-unmap_area == arch_unmap_area)
-   addr = prev ? prev-vm_end : mm-mmap_base;
+   addr = prev ? prev-vm_start : mm-mmap_base;
else
-   addr = vma ?  vma-vm_start : mm-mmap_base;
+   addr = vma ?  vma-vm_end : mm-mmap_base;
mm-unmap_area(mm, addr);
mm-mmap_cache = NULL;  /* Kill the cache. */
 }
_
-
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: PCI riser cards and PCI irq routing, etc

2007-02-21 Thread Udo van den Heuvel

BTW:

Is the situation, with default DN setting of 19 as displayed below,
`normal` w.r.t. interrupts?
I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter
have the same irq although they are on different busses.

(...)
00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: TERRATEC Electronic GmbH Unknown device 1157
Flags: bus master, medium devsel, latency 32, IRQ 16
Memory at fdffc000 (32-bit, non-prefetchable) [size=512]

00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: TERRATEC Electronic GmbH Unknown device 1155
Flags: bus master, medium devsel, latency 32, IRQ 20
Memory at fdffb000 (32-bit, non-prefetchable) [size=512]

01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro
IGP (rev
 01) (prog-if 00 [VGA])
Subsystem: VIA Technologies, Inc. UniChrome Pro IGP
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
Memory at f400 (32-bit, prefetchable) [size=64M]
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
[virtual] Expansion ROM at fc00 [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Capabilities: [70] AGP version 3.0

How can I find out what INT_A/B/C/D line is mapped to what irq?
-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
   
   Could be the switch over then which confuses the NMI . 
  
  Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
  and friends at all.
 
 I'm not an expert on the io-apic, but the check_timer() function seemed
 to assume IRQ0 was happening regularly ..

Again: 

check_timer() is called _BEFORE_ we even touch the local APIC timers. At
this point PIT/HPET _IS_ firing IRQ0 with HZ frequency.

 Well, I'm pretty sure it's HRT, cause in prior versions this only
 happened when HRT is enabled. Then you guys went to the lapic all the
 time, and now this is happening all the time ..

The NMI is stuck:

if (nmi_count(cpu) - prev_nmi_count[cpu] = 5) {
printk(CPU#%d: NMI appears to be stuck (%d-%d)!\n,
cpu,
prev_nmi_count[cpu],
nmi_count(cpu));

This has nothing to do with jiffies.

There have been a bunch of changes in arch/i386/kernel/nmi.c as well. 

 You can't reproduce this?

Nope.

Also all my machines emit something like:
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])

In your boot log nothing to see.

tglx


-
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: freezer problems

2007-02-21 Thread Paul E. McKenney

On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
 On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
  On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
  Hm.  In the case discussed above we have a task that's right before calling
  frozen_process(), so we can't thaw it, because it's not frozen.  It will be
  frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have no
  way to check this.
  
  I think to close this race the refrigerator should check TIF_FREEZE and set
  PF_FROZEN _and_ reset TIF_FREEZE under a lock that would also have to be
  taken by try_to_freeze_tasks() in the beginning of the error path.  This 
  will
  ensure that all tasks either freeze themselves before the error path in
  try_to_freeze_tasks() is executed, or remain unfrozen.
  
  I'll try to prepare a patch to illustrate this, but right now I'm too tired 
  to
  do it. :-)
 
 Something like this, perhaps:
 
 ---
  include/linux/freezer.h |   10 +++---
  kernel/power/process.c  |   18 --
  2 files changed, 19 insertions(+), 9 deletions(-)
 
 Index: linux-2.6.20-mm2/include/linux/freezer.h
 ===
 --- linux-2.6.20-mm2.orig/include/linux/freezer.h
 +++ linux-2.6.20-mm2/include/linux/freezer.h
 @@ -58,17 +58,13 @@ static inline void frozen_process(struct
   clear_tsk_thread_flag(p, TIF_FREEZE);
  }
 
 -extern void refrigerator(void);
 +extern int refrigerator(void);
  extern int freeze_processes(void);
  extern void thaw_processes(void);
 
  static inline int try_to_freeze(void)
  {
 - if (freezing(current)) {
 - refrigerator();
 - return 1;
 - } else
 - return 0;
 + return refrigerator();
  }
 
  /*
 @@ -104,7 +100,7 @@ static inline void freeze(struct task_st
  static inline int thaw_process(struct task_struct *p) { return 1; }
  static inline void frozen_process(struct task_struct *p) { BUG(); }
 
 -static inline void refrigerator(void) {}
 +static inline int refrigerator(void) { return 0; }
  static inline int freeze_processes(void) { BUG(); return 0; }
  static inline void thaw_processes(void) {}
 
 Index: linux-2.6.20-mm2/kernel/power/process.c
 ===
 --- linux-2.6.20-mm2.orig/kernel/power/process.c
 +++ linux-2.6.20-mm2/kernel/power/process.c
 @@ -24,6 +24,8 @@
  #define FREEZER_KERNEL_THREADS 0
  #define FREEZER_USER_SPACE 1
 
 +spinlock_t refrigerator_lock;
 +
  static inline int freezeable(struct task_struct * p)
  {
   if ((p == current) ||
 @@ -34,15 +36,23 @@ static inline int freezeable(struct task
  }
 
  /* Refrigerator is place where frozen processes are stored :-). */
 -void refrigerator(void)
 +int refrigerator(void)
  {
   /* Hmm, should we be allowed to suspend when there are realtime
  processes around? */
   long save;
 +
 + spin_lock(refrigerator_lock);

I hope we can do this without a global lock that is acquired on each
try_to_freeze() call!

 + if (freezing(current)) {

Would it be possible to acquire the lock here instead, then recheck here?
Or use a per-thread lock?  (Yes, this would make the error checking path
have to acquire a very large number of threads, but...

Thanx, Paul

 + frozen_process(current);
 + spin_unlock(refrigerator_lock);
 + } else {
 + spin_unlock(refrigerator_lock);
 + return 0;
 + }
   save = current-state;
   pr_debug(%s entered refrigerator\n, current-comm);
 
 - frozen_process(current);
   spin_lock_irq(current-sighand-siglock);
   recalc_sigpending(); /* We sent fake signal, clean it up */
   spin_unlock_irq(current-sighand-siglock);
 @@ -53,6 +63,7 @@ void refrigerator(void)
   }
   pr_debug(%s left refrigerator\n, current-comm);
   current-state = save;
 + return 1;
  }
 
  static inline void freeze_process(struct task_struct *p)
 @@ -143,6 +154,7 @@ static unsigned int try_to_freeze_tasks(
   kernel threads,
   TIMEOUT / HZ, todo);
   read_lock(tasklist_lock);
 + spin_lock(refrigerator_lock);
   do_each_thread(g, p) {
   if (is_user_space(p) == !freeze_user_space)
   continue;
 @@ -152,6 +164,7 @@ static unsigned int try_to_freeze_tasks(
 
   cancel_freezing(p);
   } while_each_thread(g, p);
 + spin_unlock(refrigerator_lock);
   read_unlock(tasklist_lock);
   }
 
 @@ -169,6 +182,7 @@ int freeze_processes(void)
   unsigned int nr_unfrozen;
 
   printk(Stopping tasks ... );
 + spin_lock_init(refrigerator_lock);
   nr_unfrozen = try_to_freeze_tasks(FREEZER_USER_SPACE);
   if (nr_unfrozen)
   return nr_unfrozen;
-
To

Re: freezer problems

2007-02-21 Thread Rafael J. Wysocki

On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
 On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
  On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
   On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
   Hm.  In the case discussed above we have a task that's right before 
   calling
   frozen_process(), so we can't thaw it, because it's not frozen.  It will 
   be
   frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have no
   way to check this.
   
   I think to close this race the refrigerator should check TIF_FREEZE and 
   set
   PF_FROZEN _and_ reset TIF_FREEZE under a lock that would also have to be
   taken by try_to_freeze_tasks() in the beginning of the error path.  This 
   will
   ensure that all tasks either freeze themselves before the error path in
   try_to_freeze_tasks() is executed, or remain unfrozen.
   
   I'll try to prepare a patch to illustrate this, but right now I'm too 
   tired to
   do it. :-)
  
  Something like this, perhaps:
  
  ---
   include/linux/freezer.h |   10 +++---
   kernel/power/process.c  |   18 --
   2 files changed, 19 insertions(+), 9 deletions(-)
  
  Index: linux-2.6.20-mm2/include/linux/freezer.h
  ===
  --- linux-2.6.20-mm2.orig/include/linux/freezer.h
  +++ linux-2.6.20-mm2/include/linux/freezer.h
  @@ -58,17 +58,13 @@ static inline void frozen_process(struct
  clear_tsk_thread_flag(p, TIF_FREEZE);
   }
  
  -extern void refrigerator(void);
  +extern int refrigerator(void);
   extern int freeze_processes(void);
   extern void thaw_processes(void);
  
   static inline int try_to_freeze(void)
   {
  -   if (freezing(current)) {
  -   refrigerator();
  -   return 1;
  -   } else
  -   return 0;
  +   return refrigerator();
   }
  
   /*
  @@ -104,7 +100,7 @@ static inline void freeze(struct task_st
   static inline int thaw_process(struct task_struct *p) { return 1; }
   static inline void frozen_process(struct task_struct *p) { BUG(); }
  
  -static inline void refrigerator(void) {}
  +static inline int refrigerator(void) { return 0; }
   static inline int freeze_processes(void) { BUG(); return 0; }
   static inline void thaw_processes(void) {}
  
  Index: linux-2.6.20-mm2/kernel/power/process.c
  ===
  --- linux-2.6.20-mm2.orig/kernel/power/process.c
  +++ linux-2.6.20-mm2/kernel/power/process.c
  @@ -24,6 +24,8 @@
   #define FREEZER_KERNEL_THREADS 0
   #define FREEZER_USER_SPACE 1
  
  +spinlock_t refrigerator_lock;
  +
   static inline int freezeable(struct task_struct * p)
   {
  if ((p == current) ||
  @@ -34,15 +36,23 @@ static inline int freezeable(struct task
   }
  
   /* Refrigerator is place where frozen processes are stored :-). */
  -void refrigerator(void)
  +int refrigerator(void)
   {
  /* Hmm, should we be allowed to suspend when there are realtime
 processes around? */
  long save;
  +
  +   spin_lock(refrigerator_lock);
 
 I hope we can do this without a global lock that is acquired on each
 try_to_freeze() call!

Yes.  Here's the current version (try_to_freeze() is unchanged, so the lock
is only taken by the tasks that are going to freeze, or so they think):

---
 kernel/power/process.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Index: linux-2.6.20-mm2/kernel/power/process.c
===
--- linux-2.6.20-mm2.orig/kernel/power/process.c
+++ linux-2.6.20-mm2/kernel/power/process.c
@@ -24,6 +24,8 @@
 #define FREEZER_KERNEL_THREADS 0
 #define FREEZER_USER_SPACE 1
 
+static spinlock_t refrigerator_lock;
+
 static inline int freezeable(struct task_struct * p)
 {
if ((p == current) ||
@@ -39,10 +41,18 @@ void refrigerator(void)
/* Hmm, should we be allowed to suspend when there are realtime
   processes around? */
long save;
+
+   spin_lock(refrigerator_lock);
+   if (freezing(current)) {
+   frozen_process(current);
+   spin_unlock(refrigerator_lock);
+   } else {
+   spin_unlock(refrigerator_lock);
+   return;
+   }
save = current-state;
pr_debug(%s entered refrigerator\n, current-comm);
 
-   frozen_process(current);
spin_lock_irq(current-sighand-siglock);
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
@@ -143,6 +153,7 @@ static unsigned int try_to_freeze_tasks(
kernel threads,
TIMEOUT / HZ, todo);
read_lock(tasklist_lock);
+   spin_lock(refrigerator_lock);
do_each_thread(g, p) {
if (is_user_space(p) == !freeze_user_space)
continue;
@@

Re: [PATCH 1/3] slab: introduce krealloc


Christoph Lameter wrote:
Well could you check ksize for the old object first and if ksize = new 
size then just skip the copy? I think this may allow you 
to get rid of the ksize callers.


And not reallocate at all, right? I thought about that but then you 
wouldn't be able to use realloc() to make the buffer smaller.


Pekka

-
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] slab: ensure cache_alloc_refill terminates


On Wed, 21 Feb 2007, Pekka J Enberg wrote:

 +  */
 + BUG_ON(slabp-inuse  0 || slabp-inuse = cachep-num);
 +
   while (slabp-inuse  cachep-num  batchcount--) {


On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:

I think you only need to check for 0. If slabp-inuse  cachep-num then
the loop will not be taken.


...and batchcount is not decremented and we're effectively in an
infinite loop. Or am I missing something here?
-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 19:18 +0100, Thomas Gleixner wrote:
 On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:

Could be the switch over then which confuses the NMI . 
   
   Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
   and friends at all.
  
  I'm not an expert on the io-apic, but the check_timer() function seemed
  to assume IRQ0 was happening regularly ..
 
 Again: 
 
 check_timer() is called _BEFORE_ we even touch the local APIC timers. At
 this point PIT/HPET _IS_ firing IRQ0 with HZ frequency.

Right, but eventually there isn't a regular timer interrupt through the
io-apic. I don't think in the past IRQ0 stops without the system
crashing, so check_timer() could assume the timer (IRQ0) is _always_
regular.

do you know what the requirement are for routing the NMI through the
io-apic? 

  Well, I'm pretty sure it's HRT, cause in prior versions this only
  happened when HRT is enabled. Then you guys went to the lapic all the
  time, and now this is happening all the time ..
 
 The NMI is stuck:
 
 if (nmi_count(cpu) - prev_nmi_count[cpu] = 5) {
 printk(CPU#%d: NMI appears to be stuck (%d-%d)!\n,
 cpu,
 prev_nmi_count[cpu],
 nmi_count(cpu));
 
 This has nothing to do with jiffies.

I think it has to do with IRQ0 . Did I mention this doesn't happen in
2.6.20 .

 There have been a bunch of changes in arch/i386/kernel/nmi.c as well. 
 
  You can't reproduce this?
 
 Nope.

Do you use nmi_watchdog=1 ?

Daniel

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

Re: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to completion event

2007-02-21 Thread Zach Brown



On Feb 21, 2007, at 12:35 AM, Ken Chen wrote:


On 2/20/07, Ananiev, Leonid [EMAIL PROTECTED] wrote:

1) mem=1G in kernel boot param if you have more
2) unmount; mk2fs; mount
3) dd if=/dev/zero of=test_file bs=1M count=1200
4) aiostress -s 1200m -O -o 2 -i 1 -r 16k test_file
5) if i++50 goto 2).


Would you please instrument the call chain of
invalidate_complete_page2() and tell us exactly where it returns zero
value in your failure case?

  invalidate_complete_page2
 try_to_release_page
ext3_releasepage
   journal_try_to_free_buffers
  ???


For what it's worth, Badari has explained this race in the past in a  
credible way.  I'll take the liberty of pasting a mail from him:



kjournald submited buffers for IO and waiting for them to finish.
Note that it has a ref. against the buffer.

journal_commit_transaction()
...
submited buffers for IO
/* Waiting for IO to complete */
while (commit_transaction-t_locked_list) {
...
get_bh(bh);
if (buffer_locked(bh)) {
spin_unlock(journal-j_list_lock);
wait_on_buffer(bh);  
spin_lock(journal-j_list_lock);
}

..
put_bh(bh);
}

Now, DIO process comes to frees the jh through  
journal_try_to_free_buffers()
but fails to drop_buffers() since kjournald() has a reference against  
it.

invalidate_inode_pages2_range()
..
ext3_releasepage()
journal_try_to_free_buffers()
journal_put_journal_head()
__journal_try_to_free_buffer()
--- freed jh

try_to_free_buffers()
drop_buffers()
if (buffer_busy(bh))
goto failed;
  --- returns EIO due to  
b_count




I don't mean to say that we shouldn't get traces to confirm the  
theory, just sharing.  And now we can point to this in the archives  
next time :).


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

Re: [PATCH 1/3] slab: introduce krealloc

On Wed, 21 Feb 2007, Pekka Enberg wrote:

 Christoph Lameter wrote:
  Well could you check ksize for the old object first and if ksize = new size
  then just skip the copy? I think this may allow you to get rid of the ksize
  callers.
 
 And not reallocate at all, right? I thought about that but then you wouldn't
 be able to use realloc() to make the buffer smaller.

I think there are two ways to address that:

1. Just do not allow shrinking via realloc. Probably no big loss and best 
performance.

2. Check if the size specified is larger than the next smallest general 
cache and only copy if we would really would allocate from a different 
cache.

-
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: freezer problems

2007-02-21 Thread Paul E. McKenney

On Wed, Feb 21, 2007 at 07:13:40PM +0100, Rafael J. Wysocki wrote:
 On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
  On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
   On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
Hm.  In the case discussed above we have a task that's right before 
calling
frozen_process(), so we can't thaw it, because it's not frozen.  It 
will be
frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have 
no
way to check this.

I think to close this race the refrigerator should check TIF_FREEZE and 
set
PF_FROZEN _and_ reset TIF_FREEZE under a lock that would also have to be
taken by try_to_freeze_tasks() in the beginning of the error path.  
This will
ensure that all tasks either freeze themselves before the error path in
try_to_freeze_tasks() is executed, or remain unfrozen.

I'll try to prepare a patch to illustrate this, but right now I'm too 
tired to
do it. :-)
   
   Something like this, perhaps:
   
   ---
include/linux/freezer.h |   10 +++---
kernel/power/process.c  |   18 --
2 files changed, 19 insertions(+), 9 deletions(-)
   
   Index: linux-2.6.20-mm2/include/linux/freezer.h
   ===
   --- linux-2.6.20-mm2.orig/include/linux/freezer.h
   +++ linux-2.6.20-mm2/include/linux/freezer.h
   @@ -58,17 +58,13 @@ static inline void frozen_process(struct
 clear_tsk_thread_flag(p, TIF_FREEZE);
}
   
   -extern void refrigerator(void);
   +extern int refrigerator(void);
extern int freeze_processes(void);
extern void thaw_processes(void);
   
static inline int try_to_freeze(void)
{
   - if (freezing(current)) {
   - refrigerator();
   - return 1;
   - } else
   - return 0;
   + return refrigerator();
}
   
/*
   @@ -104,7 +100,7 @@ static inline void freeze(struct task_st
static inline int thaw_process(struct task_struct *p) { return 1; }
static inline void frozen_process(struct task_struct *p) { BUG(); }
   
   -static inline void refrigerator(void) {}
   +static inline int refrigerator(void) { return 0; }
static inline int freeze_processes(void) { BUG(); return 0; }
static inline void thaw_processes(void) {}
   
   Index: linux-2.6.20-mm2/kernel/power/process.c
   ===
   --- linux-2.6.20-mm2.orig/kernel/power/process.c
   +++ linux-2.6.20-mm2/kernel/power/process.c
   @@ -24,6 +24,8 @@
#define FREEZER_KERNEL_THREADS 0
#define FREEZER_USER_SPACE 1
   
   +spinlock_t refrigerator_lock;
   +
static inline int freezeable(struct task_struct * p)
{
 if ((p == current) ||
   @@ -34,15 +36,23 @@ static inline int freezeable(struct task
}
   
/* Refrigerator is place where frozen processes are stored :-). */
   -void refrigerator(void)
   +int refrigerator(void)
{
 /* Hmm, should we be allowed to suspend when there are realtime
processes around? */
 long save;
   +
   + spin_lock(refrigerator_lock);
  
  I hope we can do this without a global lock that is acquired on each
  try_to_freeze() call!
 
 Yes.  Here's the current version (try_to_freeze() is unchanged, so the lock
 is only taken by the tasks that are going to freeze, or so they think):

Ah, OK, that should work much better from a lock-contention viewpoint!

Thanx, Paul

 ---
  kernel/power/process.c |   15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)
 
 Index: linux-2.6.20-mm2/kernel/power/process.c
 ===
 --- linux-2.6.20-mm2.orig/kernel/power/process.c
 +++ linux-2.6.20-mm2/kernel/power/process.c
 @@ -24,6 +24,8 @@
  #define FREEZER_KERNEL_THREADS 0
  #define FREEZER_USER_SPACE 1
 
 +static spinlock_t refrigerator_lock;
 +
  static inline int freezeable(struct task_struct * p)
  {
   if ((p == current) ||
 @@ -39,10 +41,18 @@ void refrigerator(void)
   /* Hmm, should we be allowed to suspend when there are realtime
  processes around? */
   long save;
 +
 + spin_lock(refrigerator_lock);
 + if (freezing(current)) {
 + frozen_process(current);
 + spin_unlock(refrigerator_lock);
 + } else {
 + spin_unlock(refrigerator_lock);
 + return;
 + }
   save = current-state;
   pr_debug(%s entered refrigerator\n, current-comm);
 
 - frozen_process(current);
   spin_lock_irq(current-sighand-siglock);
   recalc_sigpending(); /* We sent fake signal, clean it up */
   spin_unlock_irq(current-sighand-siglock);
 @@ -143,6 +153,7 @@ static unsigned int try_to_freeze_tasks(
   kernel threads,

Re: [PATCH] slab: ensure cache_alloc_refill terminates

On Wed, 21 Feb 2007, Pekka Enberg wrote:

 ...and batchcount is not decremented and we're effectively in an
 infinite loop. Or am I missing something here?

No you are right.

Acked-by: Christoph Lameter [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: [stable] [patch 00/18] 2.6.18-stable review

2007-02-21 Thread S.Çağlar Onur

Hi;

21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı: 
 On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
  21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??:
   Responses should be made by Friday February 23 00:00 UTC.  Anything
   received after that time might be too late.
 
  We have still some CVEish patches in our package which maybe you want to
  consider adding into -stable.
 
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

 Do you have a pointer to the patches for these fixes anywhere?

http://svn.pardus.org.tr/pardus/2007/kernel/kernel/files/CVE/ has all of them 
as you can see some of them backports grabbed from newer kernels/git trees

 And are you sure they are all for 2.6.18?  The first one above is for
 the 2.4 kernel tree :)

Yep, but that one still clearly applies on top of 2.6.18.7. I'm not sure they 
have _valid cases_, i'm simply following the CVE announcements :)

Cheers
-- 
S.Çağlar Onur [EMAIL PROTECTED]
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


pgpjmxgJMbagi.pgp
Description: PGP signature

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

2007-02-21 Thread Juan Piernas Canovas


Hi Jörn,

On Wed, 21 Feb 2007, [utf-8] Jörn Engel wrote:


On Wed, 21 February 2007 05:36:22 +0100, Juan Piernas Canovas wrote:


I don't see how you can guarantee 50% free segments.  Can you explain
that bit?

It is quite simple. If 50% of your segments are busy, and the other 50%
are free, and the file system needs a new segment, the cleaner starts
freeing some of busy ones. If the cleaner is unable to free one segment at
least, your file system gets full (and it returns a nice ENOSPC error).
This solution wastes the half of your storage device, but it is
deadlock-free. Obviously, there are better approaches.


Ah, ok.  It is deadlock free, if the maximal height of your tree is 2.
It is not 100% deadlock free if the height is 3 or more.

Also, I strongly suspect that your tree is higher than 2.  A medium
sized directory will have data blocks, indirect blocks and the inode
proper, which gives you a height of 3.  Your inodes need to get accessed
somehow and unless they have fixed positions like in ext2, you need a
further tree structure of some sorts, so you're more likely looking at a
height of 5.

With a height of 5, you would need to keep 80% of you metadata free.
That is starting to get wasteful.

So I suspect that my proposed alternate cleaner mechanism or the even
better hole plugging mechanism proposed in the paper a few posts above
would be a better path to follow.


I do not understand. Do you mean that if I have 10 segments, 5 busy and 5 
free, after cleaning I could need 6 segments? How? Where the extra blocks 
come from?


Juan.

--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.esop=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: [PATCH 2/3] slab: export ksize to modules

On Wed, 21 Feb 2007, Muli Ben-Yehuda wrote:

 On Wed, Feb 21, 2007 at 10:06:52AM +0200, Pekka J Enberg wrote:
  From: Pekka Enberg [EMAIL PROTECTED]
  
  This exports ksize in slab and slob allocators to modules.
 
 That's a pretty generic name... if it's going to be part of the module
 API, it should be renamed to something a bit more obvious.

Hmmm... The current names are

kmalloc
kcalloc
kzalloc
kfree
ksize

All are pretty terse and most are frequently used (except ksize and 
maybe kcalloc).

-
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: Linux 2.6.21-rc1

2007-02-21 Thread Andreas Schwab

I'm getting an undefined symbol with CONFIG_AGP=m:

WARNING: compat_agp_ioctl [drivers/char/agp/agpgart.ko] undefined!

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP 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: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to completion event

2007-02-21 Thread Zach Brown

This is an interesting trick, but I'd like to consider hard whether  
the added
complexity is worth it. Could you list the various other cases you  
have in mind

which would want to use it ?


I'm happy to report that the sync case and the  
invalidate_inode_pages2_range() case are the only two which try to  
rewrite 'ret'.  I audited all the call paths between aio_{read,write}  
and -EIOCBQUUEUED.


So, sure, maybe we can shuffle the house of cards a little in the  
direction away from having a fs/aio.c helper for the situation by  
simply removing the few current instances of the problem.  It won't  
scale as people add problems without knowing about the rule to not  
overwrite -EIOCBQUEUED, but hopefully that won't be a rule for much  
longer :) :).


For the O_SYNC case we could add another magical test to the is_async  
assignment which won't perform AIO on O_SYNC descriptors.



For the invalidate_inode_pages2_range() case, I wonder if the right
place to issue this is after the direct IO write has completed and  
before
aio_complete() is issued (somewhat like the way we do  
bio_check_pages_dirty
for DIO reads), rather than after submission when the IO may still  
not have
hit the disk. This would also make the behaviour uniform for  
synchronous and

async cases.


Hmm, I think I like that.  It solves the problem for the current sole  
user of -EIOCBQUEUED without too much disruption.


BTW, am I right in interpreting that with your change aio_complete 
() may
trigger an io_getevents() wakeup, before the corresponding event is  
placed

on the ring buffer ?


Hmm, yeah, it looks like I goofed that.

I'll roll a patch which does the invalidation down in fs/direct-io.c.

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

Re: [PATCH 1/3] slab: introduce krealloc


Hi Christoph,

Christoph Lameter wrote:
1. Just do not allow shrinking via realloc. Probably no big loss and best 
performance.


Not a big loss if you can afford the wasted memory. But, I don't think 
we should do this, there's no way for the caller to know that we will 
hold on to the memory indefinitely.


Christoph Lameter wrote:
2. Check if the size specified is larger than the next smallest general 
cache and only copy if we would really would allocate from a different 
cache.


Yeah, I was thinking about this too but decided against it (for now) as 
I am mostly concerned with removing the slab abuses from unionfs. Also, 
it is not immediately obvious we want to do this for all cases of 
krealloc so I'd prefer to keep the API for a while and decide to 
optimize or not optimize later. Note that we would only get rid of one 
of the kfree callers, the other one doesn't want to do krealloc(), it 
never reuses the old values.


Pekka

-
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: Linux 2.6.21-rc1

2007-02-21 Thread Dave Jones

On Wed, Feb 21, 2007 at 07:34:01PM +0100, Andreas Schwab wrote:
  I'm getting an undefined symbol with CONFIG_AGP=m:
  
  WARNING: compat_agp_ioctl [drivers/char/agp/agpgart.ko] undefined!

Fix went to Linus an hour ago.
It's been in -mm for a week, and agpgart.git for a day or so.

Dave

-- 
http://www.codemonkey.org.uk
-
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: Linux 2.6.21-rc1

2007-02-21 Thread Jiri Slaby


Faik Uygur napsal(a):

Hi,


Hi.

21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı: 

Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.


  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CHK include/linux/compile.h
  CC [M]  drivers/char/ip2/ip2main.o
In file included from drivers/char/ip2/ip2main.c:285:
drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in call 
to 'iiSendPendingMail': function body not available

drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
make[2]: *** [drivers/char/ip2] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

With cleanup changes in commit 40565f1962c5be9b9e285e05af01ab7771534868 
compilation fails.


What compiler?

thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
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: [stable] [patch 00/18] 2.6.18-stable review

2007-02-21 Thread Ismail Dönmez

On Wednesday 21 February 2007 19:34:45 Greg KH wrote:
 On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
  21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??:
   Responses should be made by Friday February 23 00:00 UTC.  Anything
   received after that time might be too late.
 
  We have still some CVEish patches in our package which maybe you want to
  consider adding into -stable.
 
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
  * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

 Do you have a pointer to the patches for these fixes anywhere?

 And are you sure they are all for 2.6.18?  The first one above is for
 the 2.4 kernel tree :)

Yep and Mandriva fixed that in their kernel release which is 2.6.x, I mailed 
[EMAIL PROTECTED] about it some time ago, but got no response so far.

Regards,
ismail

-- 
FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs
-
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.21-rc1] serial: serial_txx9 driver update (take 2)

2007-02-21 Thread Ralf Baechle

On Thu, Feb 22, 2007 at 02:17:28AM +0900, Atsushi Nemoto wrote:

 Update the serial_txx9 driver.
 
  * Use platform_device.
  * Fix and cleanup suspend/resume/initialization codes.
 
 Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
 Acked-by: Alan Cox [EMAIL PROTECTED]

Andrew, I've applied this patch on linux-mips.org and if nobody else
raises any issues I'll take care of merging this.

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

Re: [PATCH 1/3] slab: introduce krealloc

On Wed, 21 Feb 2007, Pekka Enberg wrote:

 Christoph Lameter wrote:
  2. Check if the size specified is larger than the next smallest general
  cache and only copy if we would really would allocate from a different
  cache.
 
 Yeah, I was thinking about this too but decided against it (for now) as I am
 mostly concerned with removing the slab abuses from unionfs. Also, it is not
 immediately obvious we want to do this for all cases of krealloc so I'd prefer

Why not? Its a realloc call and these are the classic semantics of 
realloc. Otherwise realloc will always move the memory.

 to keep the API for a while and decide to optimize or not optimize later. Note
 that we would only get rid of one of the kfree callers, the other one doesn't
 want to do krealloc(), it never reuses the old values.

Check that both sizes fall into the same general cache. Do the following 
at the beginning of the function

struct kmem_cache *cachep = page_get_slab(virt_to_page(object));

if (new_size  cachep == kmem_find_general_cachep(new_size, 
cachep-gfpflags))
/*
 * Old and new object size us the same general slab so we do not 
 * have to do anything
 */
return object;

-
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: Linux 2.6.21-rc1

2007-02-21 Thread Jiri Slaby


Jiri Slaby napsal(a):

Faik Uygur napsal(a):

Hi,


Hi.


21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:

Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.


  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CHK include/linux/compile.h
  CC [M]  drivers/char/ip2/ip2main.o
In file included from drivers/char/ip2/ip2main.c:285:
drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in 
call to 'iiSendPendingMail': function body not available

drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
make[2]: *** [drivers/char/ip2] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

With cleanup changes in commit 
40565f1962c5be9b9e285e05af01ab7771534868 compilation fails.


What compiler?


Oh, I can reproduce with gcc 3.4. Going to fix it.

thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
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: PCI riser cards and PCI irq routing, etc

2007-02-21 Thread Udo van den Heuvel

Lennart Sorensen wrote:
 On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote:
 Udo van den Heuvel wrote:
 So, if not (as in my situation) how can I find out what is wrong?
 Or find out if the BIOS works OK with the card?
 How can I verify that the correct routing for the IRQ is in place?
 The DN is the only variable so INT lines are hardwired on the riser card?
 Then same for the motherboard.
 
 It is quite likely that the interrupts are set based on the DN.  Now if
 they use whatever the parent slot uses as INTD as INTA for the second
 slot (since it is set to 19 which is 1 below 20 of the main slot), then
 that probably isn't what the BIOS is likely to assign.  It really sounds
 like via decided to do things their own way and only riser cards done
 their way, or riser cards with a pci to pci bridge are going to work
 with it.
 
 I.o.w.: how can I find the root cause?
 
 Does the documentation say which interrupts are INTA, B, C and D on the
 main board?  I would expect slot 20 to have INTA mapped to INTA but then
 again being a weird main board it doesn't have to be that way.  It is
 certainly possible via decided to just support DN19 and 20 and assign
 them both INTA, which would certainly make for a very simple riser card.

I found something:

EPIA-EN User's Manual v.1.10.pdf, chapter 2, Slots (page 26):

PCI Interrupt Request Routing

The IRQ (interrupt request line) are hardware lines over which devices
can send interrupt signals to the microprocessor. The “PCI  LAN” IRQ
pins are typically connected to the PCI bus INT A# ~ INT D# pins as follows:
Order 1 Order 2 Order 3 Order 4
PCI Slot 1  INT B#  INT C#  INT D#  INT A#
IEEE1394INT B#

`The slot` and IEEE1394 are indeed on the same IRQ 20 when I use the
default setting of DN19 for the extra slot.



00:00.0 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
Host Bridge
Subsystem: VIA Technologies, Inc. Unknown device aa08
Flags: bus master, 66MHz, medium devsel, latency 8
Memory at e800 (32-bit, prefetchable) [size=128M]
Capabilities: [80] AGP version 3.5
Capabilities: [50] Power Management version 2

00:00.1 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
Host Bridge
Flags: bus master, medium devsel, latency 0

00:00.2 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
Host Bridge
Flags: bus master, medium devsel, latency 0

00:00.3 Host bridge: VIA Technologies, Inc. PT890 Host Bridge
Flags: bus master, medium devsel, latency 0

00:00.4 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
Host Bridge
Flags: bus master, medium devsel, latency 0

00:00.7 Host bridge: VIA Technologies, Inc. CN700/VN800/P4M800CE/Pro
Host Bridge
Flags: bus master, medium devsel, latency 0

00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00
[Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: b000-bfff
Memory behind bridge: fb00-fcff
Prefetchable memory behind bridge: f400-f7ff
Capabilities: [70] Power Management version 2

00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller
Flags: bus master, stepping, medium devsel, latency 32, IRQ 20
Memory at fdfff000 (32-bit, non-prefetchable) [size=2K]
I/O ports at fc00 [size=128]
Capabilities: [50] Power Management version 2

00:0e.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122
Gigabit Ethernet Adapter (rev 11)
Subsystem: VIA Technologies, Inc. Unknown device 0110
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17
I/O ports at f800 [size=256]
Memory at fdffe000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2

00:0f.0 IDE interface: VIA Technologies, Inc. VIA VT6420 SATA RAID
Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller
Flags: bus master, medium devsel, latency 32, IRQ 18
I/O ports at f400 [size=8]
I/O ports at f000 [size=4]
I/O ports at ec00 [size=8]
I/O ports at e800 [size=4]
I/O ports at e400 [size=16]
I/O ports at e000 [size=256]
Capabilities: [c0] Power Management version 2

00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc.
VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE
Flags: bus master, medium devsel, latency 32, IRQ 18
[virtual] Memory at 01f0

Re: 2.6.21-rc1 build error on ARM with modular IPV6

2007-02-21 Thread Michael-Luke Jones


Kernel Bugzilla bug created:
http://bugzilla.kernel.org/show_bug.cgi?id=8050

Michael-Luke Jones

On 21 Feb 2007, at 14:36, Michael-Luke Jones wrote:


Apologies for brain failure, below should read 2.6.21-rc1.

Everything else should be correct.

Michael-Luke Jones

On 21 Feb 2007, at 10:50, M.L. Jones wrote:


NB: I'm not subscribed so please CC me in any reply! Thanks...

Hi there,

Just attempted a build of vanilla 2.6.20-rc1 and got a failure  
with our usual defconfig. Notably, we build IPV6 support as  
modular - this seems to be the source of the problem.


If any other info is required, please ask.

Thanks for your help,

Michael-Luke Jones
NSLU2-Linux Core Team

==Error==
 GEN .version
 CHK include/linux/compile.h
 UPD include/linux/compile.h
 CC  init/version.o
 LD  init/built-in.o
 LD  .tmp_vmlinux1
net/built-in.o: In function `svc_udp_recvfrom':
sysctl_net.c:(.text+0x79fb4): undefined reference to  
`__ipv6_addr_type'

make[1]: *** [.tmp_vmlinux1] Error 1



-
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/2] aio: propogate post-EIOCBQUEUED errors to completion event

2007-02-21 Thread Ananiev, Leonid I

 kjournald submited buffers for IO and waiting for them to finish.

It is means that the patch incorrectly moves internal kernel
synchronization
problem into user space as EIO instead of fixing a root cause or perform
iterative
synchronization.
After patching users will be surprised a lot of EIO
(remember 47% EIO in aio-stress runs after patching) will buy new
disk...
This patch is harmful.

Leonid
-Original Message-
From: Zach Brown [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 9:25 PM
To: Ken Chen
Cc: Ananiev, Leonid I; Chris Mason; linux-aio; Linux Kernel Mailing
List; Benjamin LaHaise; Suparna
bhattacharya; Andrew Morton; Badari Pulavarty
Subject: Re: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to
completion event


On Feb 21, 2007, at 12:35 AM, Ken Chen wrote:

 On 2/20/07, Ananiev, Leonid [EMAIL PROTECTED] wrote:
 1) mem=1G in kernel boot param if you have more
 2) unmount; mk2fs; mount
 3) dd if=/dev/zero of=test_file bs=1M count=1200
 4) aiostress -s 1200m -O -o 2 -i 1 -r 16k test_file
 5) if i++50 goto 2).

 Would you please instrument the call chain of
 invalidate_complete_page2() and tell us exactly where it returns zero
 value in your failure case?

   invalidate_complete_page2
  try_to_release_page
 ext3_releasepage
journal_try_to_free_buffers
   ???

For what it's worth, Badari has explained this race in the past in a
credible way.  I'll take the liberty of pasting a mail from him:


kjournald submited buffers for IO and waiting for them to finish.
Note that it has a ref. against the buffer.

journal_commit_transaction()
 ...
 submited buffers for IO
 /* Waiting for IO to complete */
 while (commit_transaction-t_locked_list) {
 ...
 get_bh(bh);
 if (buffer_locked(bh)) {
 spin_unlock(journal-j_list_lock);
 wait_on_buffer(bh);  
 spin_lock(journal-j_list_lock);
 }

 ..
 put_bh(bh);
 }

Now, DIO process comes to frees the jh through
journal_try_to_free_buffers()
but fails to drop_buffers() since kjournald() has a reference against
it.
invalidate_inode_pages2_range()
 ..
 ext3_releasepage()
 journal_try_to_free_buffers()
 journal_put_journal_head()
 __journal_try_to_free_buffer()
 --- freed jh

 try_to_free_buffers()
 drop_buffers()
 if (buffer_busy(bh))
 goto failed;
   --- returns EIO due to
b_count



I don't mean to say that we shouldn't get traces to confirm the
theory, just sharing.  And now we can point to this in the archives
next time :).

- z
-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
 Right, but eventually there isn't a regular timer interrupt through the
 io-apic. I don't think in the past IRQ0 stops without the system
 crashing, so check_timer() could assume the timer (IRQ0) is _always_
 regular.
 
 do you know what the requirement are for routing the NMI through the
 io-apic? 

Sorry. I checked. switching PIT off really breaks nmi_watchdog=1, as
this just mirrors IRQ#0 to the NMI. No IRQ#0 from PIT, no NMI

We could keep PIT running with an empty interrupt handler when
nmi_watchdog=1 is set, but this interferes nicely with broadcasting.

Does nmi_watchdog=2 work ? We might switch to that, when a local APIC is
available. 

tglx



-
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: Linux 2.6.21-rc1



On Wed, 21 Feb 2007, Faik Uygur wrote:
 
   CHK include/linux/version.h
   CHK include/linux/utsrelease.h
   CHK include/linux/compile.h
   CC [M]  drivers/char/ip2/ip2main.o
 In file included from drivers/char/ip2/ip2main.c:285:
 drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
 drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in call 
 to 'iiSendPendingMail': function body not available
 drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
 make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
 make[2]: *** [drivers/char/ip2] Error 2
 make[1]: *** [drivers/char] Error 2
 make: *** [drivers] Error 2

Yeah, that thing was crud.

Linus

---
commit 5fc7e655a50b0a19229a6b4a8a5e23bfedf700a4
Author: Linus Torvalds [EMAIL PROTECTED]
Date:   Wed Feb 21 11:18:26 2007 -0800

Fix bogus 'inline' in drivers/char/ip2/i2lib.c

Not only was the function way too big to be inlined in the first place,
it was used before it was even defined.

Noted-by: Faik Uygur [EMAIL PROTECTED]
Cc: Jiri Slaby [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

diff --git a/drivers/char/ip2/i2lib.c b/drivers/char/ip2/i2lib.c
index f86fa0c..e46120d 100644
--- a/drivers/char/ip2/i2lib.c
+++ b/drivers/char/ip2/i2lib.c
@@ -80,7 +80,7 @@ static int i2RetryFlushOutput(i2ChanStrPtr);
 // Not a documented part of the library routines (careful...) but the 
Diagnostic
 // i2diag.c finds them useful to help the throughput in certain limited
 // single-threaded operations.
-static inline void iiSendPendingMail(i2eBordStrPtr);
+static void iiSendPendingMail(i2eBordStrPtr);
 static void serviceOutgoingFifo(i2eBordStrPtr);
 
 // Functions defined in ip2.c as part of interrupt handling
@@ -166,7 +166,7 @@ static void iiSendPendingMail_t(unsigned long data)
 // If any outgoing mail bits are set and there is outgoing mailbox is empty,
 // send the mail and clear the bits.
 
//**
-static inline void
+static void
 iiSendPendingMail(i2eBordStrPtr pB)
 {
if (pB-i2eOutMailWaiting  (!pB-i2eWaitingForEmptyFifo) )
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] slab: introduce krealloc


On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:

Why not? Its a realloc call and these are the classic semantics of
realloc. Otherwise realloc will always move the memory.


Well, as a reference, the user-space equivalent is defined in SUSv3 as:

The realloc() function shall change the size of the memory object
pointed to by ptr to the size specified by size.

I think it is reasonable to expect krealloc() to not waste too much
space if I, say, reallocate a 128 byte buffer to 32 bytes.

On 2/21/07, Christoph Lameter [EMAIL PROTECTED] wrote:

Check that both sizes fall into the same general cache. Do the following
at the beginning of the function


Not available in the slob allocator AFAIK but yeah, I'll add this
optimization to the slab version. Thanks Christoph.

Pekka
-
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: cat problem in tiny_tty driver (the source included)

On Wed, Feb 21, 2007 at 06:03:16PM +0300, Mockern wrote:
 I tried to check cat operations for tiny_tty driver from LDD book. 
 
 What is wrong with cat operation here?
 
 Here is the output from strace cat hello  /dev/my_tty1
 
 [EMAIL PROTECTED]:/home# strace cat hello  /dev/my_tty1
 execve(/bin/cat, [cat, hello], [/* 12 vars */]) = 0
 brk(0)  = 0x7d000
 open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or 
 directory)
 open(/etc/ld.so.cache, O_RDONLY)  = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=5664, ...}) = 0
 old_mmap(NULL, 5664, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
 close(3)= 0
 open(/lib/libm.so.6, O_RDONLY)= 3
 read(3, \177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\250B\0\000..., 512) = 
 51
 2
 fstat64(3, {st_mode=S_IFREG|0755, st_size=480324, ...}) = 0
 old_mmap(NULL, 506412, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002
 mprotect(0x40093000, 35372, PROT_NONE)  = 0
 old_mmap(0x40098000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
 0x70
 000) = 0x40098000
 close(3)= 0
 open(/lib/libcrypt.so.1, O_RDONLY)= 3
 read(3, \177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\10\0..., 512) = 
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=19940, ...}) = 0
 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
 = 0
 x40019000
 old_mmap(NULL, 211220, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4009c000
 mprotect(0x400a1000, 190740, PROT_NONE) = 0
 old_mmap(0x400a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
 0) =
  0x400a4000
 old_mmap(0x400a9000, 157972, PROT_READ|PROT_WRITE, 
 MAP_PRIVATE|MAP_FIXED|MAP_ANO
 NYMOUS, -1, 0) = 0x400a9000
 close(3)= 0
 open(/lib/libc.so.6, O_RDONLY)= 3
 read(3, \177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\330p\1\000..., 512) = 
 51
 2
 fstat64(3, {st_mode=S_IFREG|0755, st_size=1240024, ...}) = 0
 old_mmap(NULL, 1257088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400d
 mprotect(0x401f5000, 56960, PROT_NONE)  = 0
 old_mmap(0x401f8000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
 0x12
 ) = 0x401f8000
 old_mmap(0x40201000, 7808, PROT_READ|PROT_WRITE, 
 MAP_PRIVATE|MAP_FIXED|MAP_ANONY
 MOUS, -1, 0) = 0x40201000
 close(3)= 0
 munmap(0x40017000, 5664)= 0
 getuid32()  = 0
 getgid32()  = 0
 setgid32(0) = 0
 setuid32(0) = 0
 brk(0)  = 0x7d000
 brk(0x9e000)= 0x9e000
 brk(0)  = 0x9e000
 open(hello, O_RDONLY) = 3
 read(3, 123456789, 8192)  = 9
 write(1, 123456789, 9)= -1 EINVAL (Invalid 
 argument)//??
 write(2, cat: , 5cat: )= 5
 write(2, Write Error, 11Write Error) = 11
 write(2, : Invalid argument\n, 19: Invalid argument
 )= 19
 close(3)= 0
 io_submit(0, 0x40200164, 0 unfinished ... exit status 0
 Process 1432 detached
 [EMAIL PROTECTED]:/home#
 
 
 
 /*
  * Tiny TTY driver
  *
  * Copyright (C) 2002-2004 Greg Kroah-Hartman ([EMAIL PROTECTED])
  *
  *This program is free software; you can redistribute it and/or modify
  *it under the terms of the GNU General Public License as published by
  *the Free Software Foundation, version 2 of the License.
  *
  * This driver shows how to create a minimal tty driver.  It does not rely on
  * any backing hardware, but creates a timer that emulates data being received
  * from some kind of hardware.
  */
 
 #include linux/config.h
 #include linux/kernel.h
 #include linux/errno.h
 #include linux/init.h
 #include linux/module.h
 #include linux/slab.h
 #include linux/wait.h
 #include linux/tty.h
 #include linux/tty_driver.h
 #include linux/tty_flip.h
 #include linux/serial.h
 #include asm/uaccess.h
 
 
 #define DRIVER_VERSION v2.0
 #define DRIVER_AUTHOR Greg Kroah-Hartman [EMAIL PROTECTED]
 #define DRIVER_DESC Tiny TTY driver
 
 /* Module information */
 MODULE_AUTHOR( DRIVER_AUTHOR );
 MODULE_DESCRIPTION( DRIVER_DESC );
 MODULE_LICENSE(GPL);
 
 #define DELAY_TIMEHZ * 2  /* 2 seconds per character */
 #define TINY_DATA_CHARACTER   't'
 
 #define TINY_TTY_MAJOR240 /* experimental range */
 #define TINY_TTY_MINORS   4   /* only have 4 devices */
 
 struct tiny_serial {
   struct tty_struct   *tty;   /* pointer to the tty for this 
 device */
   int open_count; /* number of times this port 
 has been opened */
   struct semaphoresem;/* locks this structure */
   struct timer_list   *timer;
 
   /* for tiocmget and

Re: PCI riser cards and PCI irq routing, etc

On Wed, Feb 21, 2007 at 03:59:51PM +0100, Udo van den Heuvel wrote:
 But the IRQ for the DVB-T card doesn't work.
 I would need to test the DVB-T card alone to be sure it has working IRQ.
 If so, what would be the conclusion?

Well the BIOS makes an assumption about the irq routing on the board,
and assigns the IRQ based on that assumption.  Via's assumptions are
different than the assumptions of the maker of your riser board.  That
certainly makes sense given how the via ext-pci riser is explicitly
labeled as only compatible with via mini-itx boards, which really also
implies that no other riser card would be compabitle with a via mini-itx
board unless it is a universal card with a proper pci bridge chip (And I
have seen embedded boards that don't work correctly with those either,
but those are simpler to deal with in software, which is actually what I
had to do).

 What IRQ rerouting would I need to try? 1 of 3 choices?
 Or one best bet?

Well best bet is to find out if INTA on the PCI controller matches INTA
on the PCI slot.  If it does then you want the interrupts on both slots
to match.  If it doesn't then you want to undo whatever the mapping to
the slot is to make it match INTA on the slot to INTA on the bus
(assuming that is what Via means by DN19 uses INTA).

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

Re: [PATCH 1/3] slab: introduce krealloc

On Wed, 21 Feb 2007, Pekka Enberg wrote:

 Well, as a reference, the user-space equivalent is defined in SUSv3 as:
 
 The realloc() function shall change the size of the memory object
 pointed to by ptr to the size specified by size.

The realloc functions intent is to leave the object in place if possible.
Otherwise one can simply alloc a new object and free the old one.
-
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: Linux 2.6.21-rc1



On Wed, 21 Feb 2007, Kok, Auke wrote:
 
 I think we need to drop this now. The report that says that this *fixes*
 something might have been on regular interrupts only. I currently suspect that
 it breaks all MSI interrupts, which would make sense if I look a the code.
 Very bad indeed.
 
 I'll try to come up with something else or send a patch that reverts it.

I'm going to be off-line for a couple of days, so I just reverted it.

Linus

---
commit b5bf28cde894b3bb3bd25c13a7647020562f9ea0
Author: Linus Torvalds [EMAIL PROTECTED]
Date:   Wed Feb 21 11:21:44 2007 -0800

Revert e1000: fix shared interrupt warning message

This reverts commit d2ed16356ff4fb9de23fbc5e5d582ce580390106.

As Thomas Gleixner reports:
  e1000 is not working anymore. ifup fails permanentely.
ADDRCONF(NETDEV_UP): eth0: link is not ready
   nothing else

The broken commit was identified with git bisect.

Auke Kok says:
  I think we need to drop this now.  The report that says that this
   *fixes* something might have been on regular interrupts only.  I
   currently suspect that it breaks all MSI interrupts, which would make
   sense if I look a the code.  Very bad indeed.

Cc: Jesse Brandeburg [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index a710237..98215fd 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1417,6 +1417,10 @@ e1000_open(struct net_device *netdev)
if ((err = e1000_setup_all_rx_resources(adapter)))
goto err_setup_rx;
 
+   err = e1000_request_irq(adapter);
+   if (err)
+   goto err_req_irq;
+
e1000_power_up_phy(adapter);
 
if ((err = e1000_up(adapter)))
@@ -1427,10 +1431,6 @@ e1000_open(struct net_device *netdev)
e1000_update_mng_vlan(adapter);
}
 
-   err = e1000_request_irq(adapter);
-   if (err)
-   goto err_req_irq;
-
/* If AMT is enabled, let the firmware know that the network
 * interface is now open */
if (adapter-hw.mac_type == e1000_82573 
@@ -1439,10 +1439,10 @@ e1000_open(struct net_device *netdev)
 
return E1000_SUCCESS;
 
-err_req_irq:
-   e1000_down(adapter);
 err_up:
e1000_power_down_phy(adapter);
+   e1000_free_irq(adapter);
+err_req_irq:
e1000_free_all_rx_resources(adapter);
 err_setup_rx:
e1000_free_all_tx_resources(adapter);
-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
 On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
  Right, but eventually there isn't a regular timer interrupt through the
  io-apic. I don't think in the past IRQ0 stops without the system
  crashing, so check_timer() could assume the timer (IRQ0) is _always_
  regular.
  
  do you know what the requirement are for routing the NMI through the
  io-apic? 
 
 Sorry. I checked. switching PIT off really breaks nmi_watchdog=1, as
 this just mirrors IRQ#0 to the NMI. No IRQ#0 from PIT, no NMI

That's what I suspected ..

 We could keep PIT running with an empty interrupt handler when
 nmi_watchdog=1 is set, but this interferes nicely with broadcasting.
 
 Does nmi_watchdog=2 work ? We might switch to that, when a local APIC is
 available. 

Oddly, nmi_watchdog=2 doesn't work in 2.6.21-rc1, but it works in
2.6.20-rt8 however I'm not sure of the config could have been PREEMPT_RT
was on.

Daniel

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

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

2007-02-21 Thread Jörn Engel

On Wed, 21 February 2007 19:31:40 +0100, Juan Piernas Canovas wrote:
 
 I do not understand. Do you mean that if I have 10 segments, 5 busy and 5 
 free, after cleaning I could need 6 segments? How? Where the extra blocks 
 come from?

This is a fairly complicated subject and I have trouble explaining it to
people - even though I hope that maybe one or two dozen understand it by
now.  So let me try to give you an example:

In LogFS, inodes are stored in an inode file.  There are no B-Trees yet,
so the regular unix indirect blocks are used.  My example will be
writing to a directory, so that should only involve metadata by your
definition and be a valid example for DualFS as well.  If it is not,
please tell me where the difference lies.

The directory is large, so appending to it involves writing a datablock
(D0), and indirect block (D1) and a doubly indirect block (D2).

Before:
Segment 1: [some data] [   D1  ] [more data]
Segment 2: [some data] [   D0  ] [more data]
Segment 3: [some data] [   D2  ] [more data]
Segment 4: [ empty ]
...

After:
Segment 1: [some data] [garbage] [more data]
Segment 2: [some data] [garbage] [more data]
Segment 3: [some data] [garbage] [more data]
Segment 4: [D0][D1][D2][  empty]
...

Ok.  After this, the position of D2 on the medium has changed.  So we
need to update the inode and write that as well.  If the inode number
for this directory is high, we will need to write the inode (I0), an
indirect block (I1) and a doubly indirect block (I2).  The picture
becomes a bit more complicates.

Before:
Segment 1: [some data] [   D1  ] [more data]
Segment 2: [some data] [   D0  ] [more data]
Segment 3: [some data] [   D2  ] [more data]
Segment 4: [ empty ]
Segment 5: [some data] [   I1  ] [more data]
Segment 6: [some data] [   I0  ] [more data]
Segment 7: [some data] [   I2  ] [more data]
...

After:
Segment 1: [some data] [garbage] [more data]
Segment 2: [some data] [garbage] [more data]
Segment 3: [some data] [garbage] [more data]
Segment 4: [D0][D1][D2][I0][I1][I2][ empty ]
Segment 5: [some data] [garbage] [more data]
Segment 6: [some data] [garbage] [more data]
Segment 7: [some data] [garbage] [more data]
...

So what has just happened?  The user did a single touch foo in a large
directory and has caused six objects to move.  Unless some of those
objects were in the same segment before, we now have six segments
containing a tiny amount of garbage.

And there is almost no way how you can squeeze that garbage back out.
The cleaner will fundamentally do the same thing as a regular write - it
will move objects.  So if you want to clean a segment containing the
block of a different directory, you may again have to move five
additional objects, the indirect blocks, inode and ifile indirect
blocks.

At this point, your cleaner is becoming a threat.  There is a real
danger that it will create more garbage in unrelated segments than it
frees up.  I claim that you cannot keep 50% clean segments, unless you
move away from the simplistic cleaner I described above.

Jörn

-- 
If you're willing to restrict the flexibility of your approach,
you can almost always do something better.
-- John Carmack
-
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: cat problem in tiny_tty driver (the source included)

2007-02-21 Thread Mockern

Thank you very much for you help.

BTW, for cat  /dev/my_tty1 can see here something wrong?
as I understand tiny_timer function sends data to tty level
by calling tty_flip_buffer_push(tty).

Is this enough to support cat  /dev/my_tty1?


On Wed, Feb 21, 2007 at 06:03:16PM +0300, Mockern wrote:
 I tried to check cat operations for tiny_tty driver from LDD book. 
 
 What is wrong with cat operation here?
 
 Here is the output from strace cat hello  /dev/my_tty1
 
 [EMAIL PROTECTED]:/home# strace cat hello  /dev/my_tty1
 execve(/bin/cat, [cat, hello], [/* 12 vars */]) = 0
 brk(0)  = 0x7d000
 open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or 
 directory)
 open(/etc/ld.so.cache, O_RDONLY)  = 3
 fstat64(3, {st_mode=S_IFREG|0644, st_size=5664, ...}) = 0
 old_mmap(NULL, 5664, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
 close(3)= 0
 open(/lib/libm.so.6, O_RDONLY)= 3
 read(3, \177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\250B\0\000..., 512) 
 = 51
 2
 fstat64(3, {st_mode=S_IFREG|0755, st_size=480324, ...}) = 0
 old_mmap(NULL, 506412, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002
 mprotect(0x40093000, 35372, PROT_NONE)  = 0
 old_mmap(0x40098000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
 0x70
 000) = 0x40098000
 close(3)= 0
 open(/lib/libcrypt.so.1, O_RDONLY)= 3
 read(3, \177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\10\0..., 512) = 
 512
 fstat64(3, {st_mode=S_IFREG|0755, st_size=19940, ...}) = 0
 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
 = 0
 x40019000
 old_mmap(NULL, 211220, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4009c000
 mprotect(0x400a1000, 190740, PROT_NONE) = 0
 old_mmap(0x400a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
 0) =
  0x400a4000
 old_mmap(0x400a9000, 157972, PROT_READ|PROT_WRITE, 
 MAP_PRIVATE|MAP_FIXED|MAP_ANO
 NYMOUS, -1, 0) = 0x400a9000
 close(3)= 0
 open(/lib/libc.so.6, O_RDONLY)= 3
 read(3, \177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\330p\1\000..., 512) 
 = 51
 2
 fstat64(3, {st_mode=S_IFREG|0755, st_size=1240024, ...}) = 0
 old_mmap(NULL, 1257088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400d
 mprotect(0x401f5000, 56960, PROT_NONE)  = 0
 old_mmap(0x401f8000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
 0x12
 ) = 0x401f8000
 old_mmap(0x40201000, 7808, PROT_READ|PROT_WRITE, 
 MAP_PRIVATE|MAP_FIXED|MAP_ANONY
 MOUS, -1, 0) = 0x40201000
 close(3)= 0
 munmap(0x40017000, 5664)= 0
 getuid32()  = 0
 getgid32()  = 0
 setgid32(0) = 0
 setuid32(0) = 0
 brk(0)  = 0x7d000
 brk(0x9e000)= 0x9e000
 brk(0)  = 0x9e000
 open(hello, O_RDONLY) = 3
 read(3, 123456789, 8192)  = 9
 write(1, 123456789, 9)= -1 EINVAL (Invalid 
 argument)//??
 write(2, cat: , 5cat: )= 5
 write(2, Write Error, 11Write Error) = 11
 write(2, : Invalid argument\n, 19: Invalid argument
 )= 19
 close(3)= 0
 io_submit(0, 0x40200164, 0 unfinished ... exit status 0
 Process 1432 detached
 [EMAIL PROTECTED]:/home#
 
 
 
 /*
  * Tiny TTY driver
  *
  * Copyright (C) 2002-2004 Greg Kroah-Hartman ([EMAIL PROTECTED])
  *
  *   This program is free software; you can redistribute it and/or modify
  *   it under the terms of the GNU General Public License as published by
  *   the Free Software Foundation, version 2 of the License.
  *
  * This driver shows how to create a minimal tty driver.  It does not rely on
  * any backing hardware, but creates a timer that emulates data being 
 received
  * from some kind of hardware.
  */
 
 #include linux/config.h
 #include linux/kernel.h
 #include linux/errno.h
 #include linux/init.h
 #include linux/module.h
 #include linux/slab.h
 #include linux/wait.h
 #include linux/tty.h
 #include linux/tty_driver.h
 #include linux/tty_flip.h
 #include linux/serial.h
 #include asm/uaccess.h
 
 
 #define DRIVER_VERSION v2.0
 #define DRIVER_AUTHOR Greg Kroah-Hartman [EMAIL PROTECTED]
 #define DRIVER_DESC Tiny TTY driver
 
 /* Module information */
 MODULE_AUTHOR( DRIVER_AUTHOR );
 MODULE_DESCRIPTION( DRIVER_DESC );
 MODULE_LICENSE(GPL);
 
 #define DELAY_TIME   HZ * 2  /* 2 seconds per character */
 #define TINY_DATA_CHARACTER  't'
 
 #define TINY_TTY_MAJOR   240 /* experimental range */
 #define TINY_TTY_MINORS  4   /* only have 4 devices */
 
 struct tiny_serial {
  struct tty_struct   *tty;   /* pointer to the tty for this 
 device */
  int

Re: [patch 00/21] 2.6.19-stable review

Greg KH wrote:
 This is the start of the stable review cycle for the 2.6.19.5 release.
 
 This will probably be the last release of the 2.6.19-stable series, so
 if there are patches that you feel should be applied to that tree,
 please let me know.
 
 There are 21 patches in this series, all will be posted as a response to
 this one.  If anyone has any issues with these being applied, please let
 us know.  If anyone is a maintainer of the proper subsystem, and wants
 to add a Signed-off-by: line to the patch, please respond with it.
 

What is the status of:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch

They fix a serious bug that causes machines to freeze up
or just run very slowly.

I'd like to see these in -stable if possible.
-
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: PCI riser cards and PCI irq routing, etc

2007-02-21 Thread Krzysztof Halasa

Udo van den Heuvel [EMAIL PROTECTED] writes:

 But the IRQ for the DVB-T card doesn't work.

That's because the card drives incorrect INT line. The system (BIOS,
Linux) thinks the card would drive INT_D (as seen at the MB PCI slot)
and and card drives (its INT_A) INT_B.

 I would need to test the DVB-T card alone to be sure it has working IRQ.
 If so, what would be the conclusion?

I'd expect it to work. Anyway, you'd need to change the mapping.
Of course, you have to select device # = 19 (0x13).

 What IRQ rerouting would I need to try? 1 of 3 choices?
 Or one best bet?

You can test if it works first by connecting lines INT B and INT D
on the motherboard (or on the device 0x14 slot). That's pins B7 and B8
(you may want to google PCI slot pinout, B is the component side).
I think a small piece of conductive film (aluminum or so) placed
carefully with the card would do. Make sure not to damage the
connector pins and not to short any additional connectors.

It can a) work, b) not work, c) give you interrupt stuck - disabled
messages (and perhaps make the system unusable until the film is
removed).

I'd verify my speculation WRT the riser card is correct and the lines
are indeed connected as follows:
   (device 0x13=19) ABCD - BCDA (MB slot = device 0x14=20).
That means pin A6 on device 0x13 connected to B7 on device 0x14 and on
edge connector going to MB slot, pin B7 on 0x13 to A7 on 0x14/MB,
pin A7 on 0x13 to B8 on 0x14/MB, pin B8 on 0x13 to pin A6 on 0x14/MB.

If that is the case and the alu film works, then (assuming you only
need a single IRQ for 0x13) you have to cut connection between A6 on
0x13 and B7 on 0x14 (B7 on 0x14 and B7 on edge connector should stay),
then connect that A6 on 0x13 to B8 on 0x14/MB.

I think the modification should rather be done by someone who knows
how to solder electronics.
-- 
Krzysztof Halasa
-
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 PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

2007-02-21 Thread Pavel Machek

Hi!

 Rafael,
 On Sat, Feb 17, 2007 at 12:24:45PM +0100, Rafael J. Wysocki wrote:
  
  Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, BTW?
 
 The create_workqueue by default marks the worker_threads to be
 non_freezable. For cpu hotplug, all workqueues can be frozen 
 except the kthread workqueue (which is single threaded, so won't 
 be frozen anyway).
 
 And a quick cscope scan shows that only the xfslogd and xfsdatad
 are the only freezable workqueues. Any particular reason
 for not marking rest of the non-single_threaded workqueues freezeable ??

As I said, go ahead.

bluetooth has absolutely no business running while we are writing
suspend image to disk.

(First person suggesting
suspend-to-file-on-nfs-filesystem-mounted-over-GPRS-line-connected-over-bluetooth
will be punished by only getting bread and water till he implements
it).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: Linux 2.6.21-rc1

On Wed, 21 Feb 2007 11:24:33 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:

 
 
 On Wed, 21 Feb 2007, Kok, Auke wrote:
  
  I think we need to drop this now. The report that says that this *fixes*
  something might have been on regular interrupts only. I currently suspect 
  that
  it breaks all MSI interrupts, which would make sense if I look a the code.
  Very bad indeed.
  
  I'll try to come up with something else or send a patch that reverts it.
 
 I'm going to be off-line for a couple of days,

And I'll be offline for five or six days.

 so I just reverted it.

OK, but this change was needed because the new IRQ-debugging code reliably
causes e1000 to explode.

So perhaps until e1000 gets sorted out we should disable the debug code:

--- a/lib/Kconfig.debug~a
+++ a/lib/Kconfig.debug
@@ -79,7 +79,7 @@ config DEBUG_KERNEL
 
 config DEBUG_SHIRQ
bool Debug shared IRQ handlers
-   depends on DEBUG_KERNEL  GENERIC_HARDIRQS
+   depends on DEBUG_KERNEL  GENERIC_HARDIRQS  BROKEN
help
  Enable this to generate a spurious interrupt as soon as a shared
  interrupt handler is registered, and just before one is deregistered.
_

-
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 00/21] 2.6.19-stable review

On Wed, 21 Feb 2007 14:31:41 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:

 Greg KH wrote:
  This is the start of the stable review cycle for the 2.6.19.5 release.
  
  This will probably be the last release of the 2.6.19-stable series, so
  if there are patches that you feel should be applied to that tree,
  please let me know.
  
  There are 21 patches in this series, all will be posted as a response to
  this one.  If anyone has any issues with these being applied, please let
  us know.  If anyone is a maintainer of the proper subsystem, and wants
  to add a Signed-off-by: line to the patch, please respond with it.
  
 
 What is the status of:
 
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch

That's mainly an Andi decision.  Let's cc him.

 They fix a serious bug that causes machines to freeze up
 or just run very slowly.
 
 I'd like to see these in -stable if possible.

They're not even in mainline yet.
-
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 05/05] Linux Kernel Markers, non optimized architectures

2007-02-21 Thread Karim Yaghmour

- KRYPTIVA PACKAGED MESSAGE -
PACKAGING TYPE: SIGNED

Hello Mathieu,

Mathieu Desnoyers wrote:
Yes, that was indeed the first way I implemented it, as a disable option. One of the
main thing we have to figure out before I modify this is if we want to have the generic version of
markers available in a forced manner at the marker site with the GEN_MARK macro instead of
the MARK macro (this is the actual implementation). It has proven to be useful to instrument lockdep.c
irq
enable/disable tracing functions. The reason why is because they are called
just before the trap handler returns and I need it to do XMC on x86 and x86_64. It
would therefore cause a recursive trap.

I think it makes sense to have this kind of support for hard-to-instrument
sites within the marker infrastructure, but the cost is to have two marker flavors
: MARK and GEN_MARK (but really GEN_MARK is only intended for a few sites).

I must admit that I'm unsure about the use of different marker macros.
How about bitwise flags that could be coded as part of the marker
at the marker site? Something like MARKER_TYPE_FORCED. This would
still allow some form of toplevel control at the macro definition.
Otherwise there's some digging to be done on a per-marker
basis ...

Karim
- KRYPTIVA SIGNED MESSAGE -
This email claims to have been packaged by Kryptiva.
To process this email and authenticate its origin, get
the free plugin from:
http://www.kryptiva.com/downloads

- KRYPTIVA SIGNATURE START -
AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2
+TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF
ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1
IVdBt6tKzhaPW8MOfncRABgAAABOIEXcozcACATMABkTAAQAggQA
mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV
yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85
nVh3hKiNPsw8DYs1NKb+KMON+4g=
- KRYPTIVA SIGNATURE END -
-
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: PCI riser cards and PCI irq routing, etc

2007-02-21 Thread Krzysztof Halasa

Udo van den Heuvel [EMAIL PROTECTED] writes:

 Is the situation, with default DN setting of 19 as displayed below,
 `normal` w.r.t. interrupts?
 I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter
 have the same irq although they are on different busses.

It's normal (and consistent with EPIA-M). The first UHCI USB (#0)
could get it, too (but it may be connected differently with IO-APIC,
I haven't checked).

 How can I find out what INT_A/B/C/D line is mapped to what irq?

That INT_A/B/C/D stuff depends on the point of view. In the BIOS
setup you can select some IRQs (which Linux could change anyway)
but it's a chipset-centric view (not very useful here).

Every PCI card have INT_A/B/C/D signals and they are (may be) remapped
on the riser card and on the motherboard.
-- 
Krzysztof Halasa
-
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.20-git15 BUG: soft lockup detected on CPU#0! - timers?

Michal,

On Wed, 2007-02-21 at 16:38 +0100, Michal Piotrowski wrote:
  But you still have those softirq pending messages, right ?
 
 Yes
 
 (+ new NOHZ: local_softirq_pending 02)

Yike, that's the timer softirq.

Can you add the patch below, maybe it gives us some useful info. Please
enable lockdep (your last config had it already)

Thanks,

tglx

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 512a4a9..cc705c7 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -165,9 +165,11 @@ void tick_nohz_stop_sched_tick(void)
goto end;
 
cpu = smp_processor_id();
-   if (unlikely(local_softirq_pending()))
-   printk(KERN_ERR NOHZ: local_softirq_pending %02x\n,
-  local_softirq_pending());
+   if (unlikely(local_softirq_pending())) {
+   print_irqtrace_events(current);
+   printk(KERN_ERR NOHZ: local_softirq_pending %02x, %08x\n,
+  local_softirq_pending(), preempt_count());
+   }
 
now = ktime_get();
/*


-
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: PCI riser cards and PCI irq routing, etc

On Wed, Feb 21, 2007 at 01:11:12AM +0100, Krzysztof Halasa wrote:
 [EMAIL PROTECTED] (Lennart Sorensen) writes:
 
  Via has a dual pci-ext card.  See EXT-PCI at
  http://www.via.com.tw/en/products/mainboards/accessories.jsp
 
 Right, and they say it's compatible with EPIA mini-ITX family.
 That means the mappings I just outlined should apply to all of them.
 
 BTW: any universal dual+ PCI riser card have to use a PCI bridge
 chip, and a bridge isn't a small 20 pin IC (I'd expect 144 pins or
 so). Active or passive - doesn't matter.
 -- 

Certainly.  The system I work with (which is not via based) has a PCI to
PCI bridge, which is 208pins (it supports 10 bus master loads behind it).
A cheap riser card that just does device number tricks will only work
on boards designed to use a riser card done that particular way.

--
Len Sorensen
-
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: PCI riser cards and PCI irq routing, etc

On Wed, Feb 21, 2007 at 10:24:28AM +0100, Udo van den Heuvel wrote:
 Udo van den Heuvel wrote:
  Any ideas about how to proceed?
  What to test?
 
 I found some info on the VIA dual PCI extender card at
 http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410.
 The text says:
 
 The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots.
 
 EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT)
 of the PCI slot of the motherboard.
 
 EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A.
 
 
 
 So if my non-VIA riser card can use DN 19 and also INT_A things should work?
 (assuming that VIA Epia EN BIOS 1.07 is enough to use this card)
 
 So, if not (as in my situation) how can I find out what is wrong?
 Or find out if the BIOS works OK with the card?
 How can I verify that the correct routing for the IRQ is in place?
 The DN is the only variable so INT lines are hardwired on the riser card?
 Then same for the motherboard.

It is quite likely that the interrupts are set based on the DN.  Now if
they use whatever the parent slot uses as INTD as INTA for the second
slot (since it is set to 19 which is 1 below 20 of the main slot), then
that probably isn't what the BIOS is likely to assign.  It really sounds
like via decided to do things their own way and only riser cards done
their way, or riser cards with a pci to pci bridge are going to work
with it.

 I.o.w.: how can I find the root cause?

Does the documentation say which interrupts are INTA, B, C and D on the
main board?  I would expect slot 20 to have INTA mapped to INTA but then
again being a weird main board it doesn't have to be that way.  It is
certainly possible via decided to just support DN19 and 20 and assign
them both INTA, which would certainly make for a very simple riser card.

--
Len Sorensen
-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
 On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
  Right, but eventually there isn't a regular timer interrupt through the
  io-apic. I don't think in the past IRQ0 stops without the system
  crashing, so check_timer() could assume the timer (IRQ0) is _always_
  regular.
  
  do you know what the requirement are for routing the NMI through the
  io-apic? 
 
 Sorry. I checked. switching PIT off really breaks nmi_watchdog=1, as
 this just mirrors IRQ#0 to the NMI. No IRQ#0 from PIT, no NMI
 
 We could keep PIT running with an empty interrupt handler when
 nmi_watchdog=1 is set, but this interferes nicely with broadcasting.
 
 Does nmi_watchdog=2 work ? We might switch to that, when a local APIC is
 available. 
 
   tglx
 
 


There's a compile failure during my bisect.

distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on dwalker3/120 
failed
kernel/hrtimer.c: In function 'hrtimer_cpu_notify':
kernel/hrtimer.c:884: warning: implicit declaration of function 
'clockevents_notify'
kernel/hrtimer.c:884: error: 'CLOCK_EVT_NOTIFY_CPU_DEAD' undeclared (first use 
in this function)
kernel/hrtimer.c:884: error: (Each undeclared identifier is reported only once 
kernel/hrtimer.c:884: error: for each function it appears in.)
drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
drivers/ide/setup-pci.c:866: warning: ignoring return value of 
'__pci_register_driver', declared with attribute warn_unused_result
make[1]: *** [kernel/hrtimer.o] Error 1


from this commit,

commit f8381cba04ba8173fd5a2b8e5cd8b3290ee13a98
Author: Thomas Gleixner [EMAIL PROTECTED]
Date:   Fri Feb 16 01:28:02 2007 -0800

[PATCH] tick-management: broadcast functionality

With Ingo Molnar [EMAIL PROTECTED]

Add broadcast functionality, so per cpu clock event devices can be registere
as dummy devices or switched from/to broadcast on demand.  The broadcast
function distributes the events via the broadcast function of the clock even
device.  This is primarily designed to replace the switch apic timer to / fr
IPI in power states, where the apic stops.



-
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: freezer problems

2007-02-21 Thread Oleg Nesterov

On 02/21, Rafael J. Wysocki wrote:

 On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
  On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
   On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
Hm.  In the case discussed above we have a task that's right before 
calling
frozen_process(), so we can't thaw it, because it's not frozen.  It 
will be
frozen just in a while, but try_to_freeze_tasks() and thaw_tasks() have 
no
way to check this.

I think to close this race the refrigerator should check TIF_FREEZE and 
set
PF_FROZEN _and_ reset TIF_FREEZE under a lock

I personally think this is good. Not only this allows us to close the race,
I think we can do more.

  that would also have to 
 be
taken by try_to_freeze_tasks() in the beginning of the error path.  
This will
ensure that all tasks either freeze themselves before the error path in
try_to_freeze_tasks() is executed, or remain unfrozen.

How about take this lock in thaw_tasks() instead/too ?

Currently we need a separate loop in thaw_tasks() to handle PF_FREEZER_SKIP. 
This
means that PF_FREEZER_SKIP is not so generic: thaw_tasks() can't tolerate if 
such
a task was woken in between. What if we change thaw_process() to clear 
TIF_FREEZE ?

Note also that we can use task_lock() instead of global refrigerator_lock. This
means that thaw_process() should take it too, probably this is slowdown, but I
think not too much because thaw_process() is going to write to p-flags anyway.
In this case thaw_process() works perfectly as cancel_freezing_and_thaw() and
can be used to fix exec/coredump in future.

Thoughts?

Oleg.

-
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: cat problem in tiny_tty driver (the source included)

On Wed, Feb 21, 2007 at 10:33:52PM +0300, Mockern wrote:
 Thank you very much for you help.
 
 BTW, for cat  /dev/my_tty1 can see here something wrong?
 as I understand tiny_timer function sends data to tty level
 by calling tty_flip_buffer_push(tty).
 
 Is this enough to support cat  /dev/my_tty1?

I don't really know the tty layer very much.  I just saw a very obvious
bug in the code.

Does cat from the device give an error or does it just not do anything?

What does strace say for that?

--
Len Sorensen
-
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 00/21] 2.6.19-stable review



On Wed, 21 Feb 2007, Andrew Morton wrote:
  
  http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
  http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch
 
 That's mainly an Andi decision.  Let's cc him.

Would be good to have Eric also ack them as safe and obvious.

Btw, that latter one has corrupted sign-offs from Andi (it's in the middle 
of the text, very confusing).

Linus
-
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: PCI riser cards and PCI irq routing, etc

On Wed, Feb 21, 2007 at 07:11:06PM +0100, Udo van den Heuvel wrote:
 BTW:
 
 Is the situation, with default DN setting of 19 as displayed below,
 `normal` w.r.t. interrupts?
 I mean: Both the DVB card with DN19 and the Unichrome Pro video adapter
 have the same irq although they are on different busses.

Unfortunately, on bus 0, which is always the main bus of a system, there
is no such thing as normal.  The BIOS knows how the mainboard is wired
and hence knows how to assign IRQs.  It is only ones you get past bus 0
and onto secondary busses behind bridges that fixed rules apply since
that is when things have to work universally.  So in your case, via can
do whatever they want with IRQs for each DN, since they know the layout
of the mainboard.  The problem with riser cards without a pci bridge
chip, is that they try to modify bus 0 without the knowledge of the
board maker, which means the bios won't have a clue how it is wired.
Use of any riser card not explicitly supported by the board is hence
unsupported and really not recommended.

 (...)
 00:13.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
 Subsystem: TERRATEC Electronic GmbH Unknown device 1157
 Flags: bus master, medium devsel, latency 32, IRQ 16
 Memory at fdffc000 (32-bit, non-prefetchable) [size=512]
 
 00:14.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
 Subsystem: TERRATEC Electronic GmbH Unknown device 1155
 Flags: bus master, medium devsel, latency 32, IRQ 20
 Memory at fdffb000 (32-bit, non-prefetchable) [size=512]
 
 01:00.0 VGA compatible controller: VIA Technologies, Inc. UniChrome Pro
 IGP (rev
  01) (prog-if 00 [VGA])
 Subsystem: VIA Technologies, Inc. UniChrome Pro IGP
 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16
 Memory at f400 (32-bit, prefetchable) [size=64M]
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 [virtual] Expansion ROM at fc00 [disabled] [size=64K]
 Capabilities: [60] Power Management version 2
 Capabilities: [70] AGP version 3.0
 
 How can I find out what INT_A/B/C/D line is mapped to what irq?

Read the manual/developer guide.

--
Len Sorensen
-
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] eCryptfs: resolve lower page unlocking problem

2007-02-21 Thread Michael Halcrow

On Wed, Feb 07, 2007 at 07:50:44PM +0300, Dmitriy Monakhov wrote:
 eCryptfs lower file handling code has several issues:
   - Retval from prepare_write()/commit_writ() was't checked to equality 
 to AOP_TRUNCATED_PAGE.
   - In some places page was't unmapped and unlocked after error.

I reworked Dmitriy's patch to apply cleanly against the more recent
version in the -mm tree.

---
eCryptfs lower file handling code has several issues:
  - Retval from prepare_write()/commit_write() wasn't checked to equality
to AOP_TRUNCATED_PAGE.
  - In some places page wasn't unmapped and unlocked after error.

Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
 fs/ecryptfs/mmap.c |   28 +++-
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 92a4147..09160ad 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -422,9 +422,11 @@ out:
return rc;
 }
 
-static void ecryptfs_release_lower_page(struct page *lower_page)
+static
+void ecryptfs_release_lower_page(struct page *lower_page, int page_locked)
 {
-   unlock_page(lower_page);
+   if (page_locked)
+   unlock_page(lower_page);
page_cache_release(lower_page);
 }
 
@@ -454,6 +456,13 @@ static int ecryptfs_write_inode_size_to_header(struct file 
*lower_file,
}
lower_a_ops = lower_inode-i_mapping-a_ops;
rc = lower_a_ops-prepare_write(lower_file, header_page, 0, 8);
+   if (rc) {
+   if (rc == AOP_TRUNCATED_PAGE)
+   ecryptfs_release_lower_page(header_page, 0);
+   else
+   ecryptfs_release_lower_page(header_page, 1);
+   goto out;
+   }
file_size = (u64)i_size_read(inode);
ecryptfs_printk(KERN_DEBUG, Writing size: [0x%.16x]\n, file_size);
file_size = cpu_to_be64(file_size);
@@ -465,7 +474,10 @@ static int ecryptfs_write_inode_size_to_header(struct file 
*lower_file,
if (rc  0)
ecryptfs_printk(KERN_ERR, Error commiting header page 
write\n);
-   ecryptfs_release_lower_page(header_page);
+   if (rc == AOP_TRUNCATED_PAGE)
+   ecryptfs_release_lower_page(header_page, 0);
+   else
+   ecryptfs_release_lower_page(header_page, 1);
lower_inode-i_mtime = lower_inode-i_ctime = CURRENT_TIME;
mark_inode_dirty_sync(inode);
 out:
@@ -572,7 +584,10 @@ int ecryptfs_get_lower_page(struct page **lower_page, 
struct inode *lower_inode,
}
 out:
if (rc  (*lower_page)) {
-   ecryptfs_release_lower_page(*lower_page);
+   if (rc == AOP_TRUNCATED_PAGE)
+   ecryptfs_release_lower_page(*lower_page, 0);
+   else
+   ecryptfs_release_lower_page(*lower_page, 1);
(*lower_page) = NULL;
}
return rc;
@@ -588,16 +603,19 @@ ecryptfs_commit_lower_page(struct page *lower_page, 
struct inode *lower_inode,
   struct file *lower_file, int byte_offset,
   int region_size)
 {
+   int page_locked = 1;
int rc = 0;
 
rc = lower_inode-i_mapping-a_ops-commit_write(
lower_file, lower_page, byte_offset, region_size);
+   if (rc == AOP_TRUNCATED_PAGE)
+   page_locked = 0;
if (rc  0) {
ecryptfs_printk(KERN_ERR,
Error committing write; rc = [%d]\n, rc);
} else
rc = 0;
-   ecryptfs_release_lower_page(lower_page);
+   ecryptfs_release_lower_page(lower_page, page_locked);
return rc;
 }
 
-- 
1.4.4.4

-
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] sched: fix idle load balancing in softirqd context

On Fri, 16 Feb 2007 18:03:35 -0800
Siddha, Suresh B [EMAIL PROTECTED] wrote:

 + int cpu = smp_processor_id(), idle_at_tick = idle_cpu(cpu);

argh.  Please, do

int cpu = smp_processor_id();
int idle_at_tick = idle_cpu(cpu);
-
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 00/21] 2.6.19-stable review

2007-02-21 Thread Eric W. Biederman

Andrew Morton [EMAIL PROTECTED] writes:

 On Wed, 21 Feb 2007 14:31:41 -0500
 Chuck Ebbert [EMAIL PROTECTED] wrote:
 What is the status of:
 

 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch

 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch

 That's mainly an Andi decision.  Let's cc him.

 They fix a serious bug that causes machines to freeze up
 or just run very slowly.
 
 I'd like to see these in -stable if possible.

 They're not even in mainline yet.

If you don't have it you at least want the patch below.  It generally
makes the bug non-fatal.

I'm still working my way through possible fixes...  Although the
patch in question is close, and normally fixes it in my utmost
paranoia I can still find problems with it.

Eric


commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8
Author: Eric W. Biederman [EMAIL PROTECTED]
Date:   Tue Feb 13 13:26:25 2007 +0100

[PATCH] x86-64: survive having no irq mapping for a vector

Occasionally the kernel has bugs that result in no irq being found for a
given cpu vector.  If we acknowledge the irq the system has a good chance
of continuing even though we dropped an irq message.  If we continue to
simply print a message and not acknowledge the irq the system is likely to
become non-responsive shortly there after.

AK: Fixed compilation for UP kernels

Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Cc: Luigi Genoni [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [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: 2.6.20 kernel hang with USB drive and vfat doing ftruncate

2007-02-21 Thread OGAWA Hirofumi

Kumar Gala [EMAIL PROTECTED] writes:

 I usually run the following twice to get the hang state:

 time ./trunc_test bar 1 
 time ./trunc_test baz 1 

 I was wondering if anyone had any suggestions on what to poke at next
 to try and figure out what is going on.

 So I realized I could use sysrq to provide some more debug  
 information.  When the system locks up I get the following output  
 from 't'

 [  497.499249] usb-storage   D  0   671  5
 773   670 (L-TLB)
 [  497.506930] Call Trace:
 [  497.509372] [C3F35A60] [C00083AC] __switch_to+0x28/0x40
 [  497.514608] [C3F35A80] [C01F4B78] schedule+0x324/0x6bc
 [  497.519756] [C3F35AC0] [C01F5D6C] schedule_timeout+0x6c/0xd0
 [  497.525426] [C3F35B00] [C01F5C9C] io_schedule_timeout+0x30/0x54
 [  497.531356] [C3F35B20] [C0050DE4] congestion_wait+0x64/0x8c
 [  497.536941] [C3F35B70] [C004A9F0] throttle_vm_writeout+0x1c/0x84
 [  497.542958] [C3F35B90] [C004F33C] shrink_zone+0xbb0/0xfe4
 [  497.548367] [C3F35D40] [C004F8F4] try_to_free_pages+0x184/0x2cc
 [  497.554298] [C3F35DB0] [C0049AA8] __alloc_pages+0x110/0x2c0
 [  497.559878] [C3F35E00] [C0060F84] cache_alloc_refill+0x394/0x694
 [  497.565900] [C3F35E30] [C00614A0] __kmalloc+0xc4/0xcc
 [  497.570961] [C3F35E40] [C01544D0] usb_alloc_urb+0x1c/0x5c
 [  497.576371] [C3F35E50] [C015520C] usb_sg_init+0x1a0/0x2f8
 [  497.581779] [C3F35EA0] [C0167318] usb_stor_bulk_transfer_sg+0x8c/ 
 0x138
 [  497.588317] [C3F35ED0] [C0167960] usb_stor_Bulk_transport+0x140/0x310
 [  497.594767] [C3F35F00] [C0167DCC] usb_stor_invoke_transport+0x2c/ 
 0x344
 [  497.601303] [C3F35F50] [C0166B2C] usb_stor_transparent_scsi_command 
 +0x10/0x20
 [  497.608449] [C3F35F60] [C0168498] usb_stor_control_thread+0x1f8/0x290
 [  497.614900] [C3F35FC0] [C0033E48] kthread+0xf4/0x130
 [  497.619876] [C3F35FF0] [C001093C] kernel_thread+0x44/0x60
 [  497.625285] shD 3009C7EC 0   718  1

[...]

 and from 'm'

 [  731.834529] Show Memory
 [  731.836968] Mem-info:
 [  731.839234] DMA per-cpu:
 [  731.841768] CPU0: Hot: hi:   18, btch:   3 usd:   3   Cold:  
 hi:6, btch:   1 usd:   2
 [  731.850206] Active:1510 inactive:11309 dirty:7188 writeback:3330  
 unstable:0 free:1009 slab:1671 mapped:110 pagetables:19
 [  731.861075] DMA free:4036kB min:4096kB low:5120kB high:6144kB  
 active:6040kB inactive:45236kB present:65024kB pages_scanned:292  
 all_unreclaimable? no
 [  731.874363] lowmem_reserve[]: 0 0
 [  731.877685] DMA: 1*4kB 0*8kB 0*16kB 0*32kB 1*64kB 1*128kB 1*256kB  
 1*512kB 1*1024kB 1*2048kB 0*4096kB = 4036kB
 [  731.887669] Free swap:0kB
 [  731.893913] 16384 pages of RAM
 [  731.896963] 798 reserved pages
 [  731.900011] 10946 pages shared
 [  731.903058] 0 pages swap cached

 It seems like usb-storage and aio are completely off in the weeds.   
 Ideas?

It seems usb-storage should remove some kmalloc and use mempool() for
urb...  Is someone working on this? And idea?
-- 
OGAWA Hirofumi [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: Linux 2.6.21-rc1



On Wed, 21 Feb 2007, Daniel Walker wrote:
 
 There's a compile failure during my bisect.

When that happens, you need to pick another commit to try than the one git 
selected for you automatically. You can do that by doing

git bisect visualize

and select another commit somewhere fairly close to a mid-point, and try 
that with

git reset --hard commit-sha1

instead.

Linus
-
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: cat problem in tiny_tty driver (the source included)

2007-02-21 Thread Mockern

cat  /dev/my_tty does nothing, just stopped for reading. I tried to send a 
data,
but there was no respond, just waiting.


On Wed, Feb 21, 2007 at 10:33:52PM +0300, Mockern wrote:
 Thank you very much for you help.
 
 BTW, for cat  /dev/my_tty1 can see here something wrong?
 as I understand tiny_timer function sends data to tty level
 by calling tty_flip_buffer_push(tty).
 
 Is this enough to support cat  /dev/my_tty1?

I don't really know the tty layer very much.  I just saw a very obvious
bug in the code.

Does cat from the device give an error or does it just not do anything?

What does strace say for that?

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


-- 
Сегодня удачный день, чтобы завести почту на Яндексе http://mail.yandex.ru
-
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/2] sched: dynticks idle load balancing - v2

On Fri, 16 Feb 2007 18:08:42 -0800
Siddha, Suresh B [EMAIL PROTECTED] wrote:

 Changes since v1:
 
   - Move the idle load balancer selection from schedule()
 to the first busy scheduler_tick() after restarting the tick.
 This will avoid the unnecessay ownership changes when 
 softirq's(which are run in softirqd context in certain -rt
 configurations) like timer, sched are invoked for every idle tick
 that happens.
 
   - Misc cleanups.
 
 ---
 Fix the process idle load balancing in the presence of dynticks.
 cpus for which ticks are stopped will sleep till the next event wakes it up.
 Potentially these sleeps can be for large durations and during which today,
 there is no periodic idle load balancing being done.
 
 This patch nominates an owner among the idle cpus, which does the idle load
 balancing on behalf of the other idle cpus. And once all the cpus are
 completely idle, then we can stop this idle load balancing too. Checks added
 in fast path are minimized.  Whenever there are busy cpus in the system, there
 will be an owner(idle cpu) doing the system wide idle load balancing.
 
 Open items:
 1. Intelligent owner selection (like an idle core in a busy package).
 2. Merge with rcu's nohz_cpu_mask?
 

I spose I'll hold my nose and merge this, but it creates too much of a mess
to be mergeable into the CPU scheduler, IMO.

Can we please do something to reduce the ifdef density?  And if possible,
all the newly-added returns-from-the-middle-of-a-function?


 +#ifdef CONFIG_NO_HZ
 +static struct {
 + int load_balancer;
 + cpumask_t  cpu_mask;
 +} nohz cacheline_aligned = {
 + .load_balancer = -1,
 + .cpu_mask = CPU_MASK_NONE,
 +};
 +
 +/*
 + * This routine will try to nominate the ilb (idle load balancing)
 + * owner among the cpus whose ticks are stopped. ilb owner will do the idle
 + * load balancing on behalf of all those cpus. If all the cpus in the system
 + * go into this tickless mode, then there will be no ilb owner (as there is
 + * no need for one) and all the cpus will sleep till the next wakeup event
 + * arrives...
 + *
 + * For the ilb owner, tick is not stopped. And this tick will be used
 + * for idle load balancing. ilb owner will still be part of
 + * nohz.cpu_mask..
 + *
 + * While stopping the tick, this cpu will become the ilb owner if there
 + * is no other owner. And will be the owner till that cpu becomes busy
 + * or if all cpus in the system stop their ticks at which point
 + * there is no need for ilb owner.
 + *
 + * When the ilb owner becomes busy, it nominates another owner, during the
 + * next busy scheduler_tick()
 + */
 +int select_nohz_load_balancer(int stop_tick)
 +{
 + int cpu = smp_processor_id();
 +
 + if (stop_tick) {
 + cpu_set(cpu, nohz.cpu_mask);
 + cpu_rq(cpu)-in_nohz_recently = 1;
 +
 + /*
 +  * If we are going offline and still the leader, give up!
 +  */
 + if (cpu_is_offline(cpu)  nohz.load_balancer == cpu) {
 + if (cmpxchg(nohz.load_balancer,  cpu, -1) != cpu)

So we require that architectures which implement CONFIG_NO_HZ also
implement cmpxchg.

 + BUG();
 + return 0;
 + }
 +
 + /* time for ilb owner also to sleep */
 + if (cpus_weight(nohz.cpu_mask) == num_online_cpus()) {
 + if (nohz.load_balancer == cpu)
 + nohz.load_balancer = -1;
 + return 0;
 + }
 +
 + if (nohz.load_balancer == -1) {
 + /* make me the ilb owner */
 + if (cmpxchg(nohz.load_balancer, -1, cpu) == -1)
 + return 1;
 + } else if (nohz.load_balancer == cpu)
 + return 1;
 + } else {
 + if (!cpu_isset(cpu, nohz.cpu_mask))
 + return 0;
 +
 + cpu_clear(cpu, nohz.cpu_mask);
 +
 + if (nohz.load_balancer == cpu)
 + if (cmpxchg(nohz.load_balancer,  cpu, -1) != cpu)
 + BUG();
 + }
 + return 0;
 +}
 +#endif
 +
  /*
   * run_rebalance_domains is triggered when needed from the scheduler tick.
   *
 @@ -3347,15 +3437,46 @@ static DEFINE_SPINLOCK(balancing);
  
  static void run_rebalance_domains(struct softirq_action *h)
  {
 - int this_cpu = smp_processor_id(), balance = 1;
 - struct rq *this_rq = cpu_rq(this_cpu);
 - unsigned long interval;
 + int balance_cpu = smp_processor_id(), balance;
 + struct rq *balance_rq = cpu_rq(balance_cpu);
 + unsigned long interval, next_balance;

One definition per line is preferred.

   struct sched_domain *sd;
 - enum idle_type idle = this_rq-idle_at_tick ? SCHED_IDLE : NOT_IDLE;
 + enum idle_type idle;
 +
 +#ifdef CONFIG_NO_HZ
 + cpumask_t cpus = nohz.cpu_mask;
 + int local_cpu = balance_cpu;
 +

Re: [patch 00/21] 2.6.19-stable review

Eric W. Biederman wrote:
 Andrew Morton [EMAIL PROTECTED] writes:
 
 On Wed, 21 Feb 2007 14:31:41 -0500
 Chuck Ebbert [EMAIL PROTECTED] wrote:
 What is the status of:


 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch

 That's mainly an Andi decision.  Let's cc him.

 They fix a serious bug that causes machines to freeze up
 or just run very slowly.

 I'd like to see these in -stable if possible.
 They're not even in mainline yet.
 
 If you don't have it you at least want the patch below.  It generally
 makes the bug non-fatal.
 
 I'm still working my way through possible fixes...  Although the
 patch in question is close, and normally fixes it in my utmost
 paranoia I can still find problems with it.

We've tested it and found no problems so far.  It's definitely
better than what's there now. :)
-
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: cat problem in tiny_tty driver (the source included)

On Wed, Feb 21, 2007 at 11:21:10PM +0300, Mockern wrote:
 cat  /dev/my_tty does nothing, just stopped for reading. I tried to send a 
 data,
 but there was no respond, just waiting.

Well certainly using the jsm driver (which is what I use for the pci
card I play with), doing cat to the port send data and cat from the port
receives, as long as both ports are set to the right baud rates and with
sensible stty settings.

Here are the stty settings I was using when cat worked fine:

speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon
-ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
-isig -icanon iexten -echo -echoe echok -echonl -noflsh -xcase -tostop
-echoprt echoctl echoke

You can read yours using 'stty -a -F /dev/serialdevice'.

Maybe you can find something that has to be changed to do raw reads.

Also make sure there are newlines in the stuff you send, otherwise cat
might not show it for a while, if at all since I think it tries to wait
for a newline before showing the line.

--
Len Sorensen
-
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] Kwatch: kernel watchpoints using CPU debug registers

2007-02-21 Thread Alan Stern

Going back to something you mentioned earlier...

On Fri, 9 Feb 2007, Roland McGrath wrote:

 I don't think I really object to the ABI change of clearing %dr6 after an
 exception so that it does not accumulate multiple results.  But first I'll
 have to convince myself that we never actually do want to accumulate
 multiple results.  Hmm, I think we can, so maybe I do object.  If you set
 two watchpoints inside a user buffer and then do a system call that touches
 both those addresses (e.g. read), then you will go through do_debug (to
 send_sigtrap) twice before returning to user mode.  When the syscall is
 done, you'll have a pending SIGTRAP for the debugger to handle.  By looking
 at your %dr6 the debugger can see that both watchpoints hit.  (gdb does not
 handle this case, but it should.)  Am I wrong?

Yes, you are wrong -- although perhaps you shouldn't be.

The current version of do_debug() clears dr7 when a debug interrupt is 
fielded.  As a result, if a system call touches two watchpoint addresses 
in userspace only the first access will be noticed.

This is probably a bug in do_debug().  It would be better to disable each
individual userspace watchpoint as it is triggered (or even not to disable
it at all).  dr7 would be restored when the SIGTRAP is delivered.  (But
what if the user is blocking or ignoring SIGTRAP?)


Moving on...

I've worked out a plan for implementing combined user/kernel mode 
breakpoints and watchpoints (call them debugpoints as a catch-all 
term).  It should work transparently with ptrace and should accomodate 
whatever scheme utrace decides to adopt.  There won't need to be a 
separate kwatch facility on top of it; the new combined facility will 
handle debugpoints in both userspace and kernelspace.

The idea is that callers can register and unregister a struct debugpoint, 
which contains fields for the type, length, address, and priority as well 
as three callback pointers (for installed, uninstalled, and triggered).  
The debug core will keep these structures sorted by priority and will 
allocate the available debug registers based on the priorities of the 
userspace and kernelspace requests.  Each CPU will have its own array of 
pointers to these structures, indicating which debugpoints are currently 
enabled.

To work with ptrace, the new scheme will completely virtualize the debug
registers.  So for example, a ptrace call might request a debugpoint in
dr0, but it could end up that the physical register used is really dr2
instead.  The various bits in dr6 and dr7 will be mapped in such a way
that the entire procedure is transparent to the user.  Debugpoints 
registered in kernelspace or by utrace won't care, of course.

There are two things I am uncertain about: vm86 mode and kprobes.  I don't
know anything about how either of them works.  Judging from the current
code, nothing much should be needed -- debug traps in vm86 mode are
handled by calling handle_vm86_trap(), and kprobes puts itself at the
start of the notify_die() chain so it can handle single-step traps.  
Eventually it will be necessary to check with someone who really 
understands the issues.

Alan Stern

-
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: Linux 2.6.21-rc1

On Wed, 2007-02-21 at 12:00 -0800, Daniel Walker wrote:
 There's a compile failure during my bisect.
 
 distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on dwalker3/120 
 failed
 kernel/hrtimer.c: In function 'hrtimer_cpu_notify':
 kernel/hrtimer.c:884: warning: implicit declaration of function 
 'clockevents_notify'
 kernel/hrtimer.c:884: error: 'CLOCK_EVT_NOTIFY_CPU_DEAD' undeclared (first 
 use in this function)
 kernel/hrtimer.c:884: error: (Each undeclared identifier is reported only 
 once 
 kernel/hrtimer.c:884: error: for each function it appears in.)
 drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
 drivers/ide/setup-pci.c:866: warning: ignoring return value of 
 '__pci_register_driver', declared with attribute warn_unused_result
 make[1]: *** [kernel/hrtimer.o] Error 1

hrmpf. we made it bisectable at some point.

tglx


-
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: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
 YOSHIFUJI Hideaki / ?$B5HF#1QL@ [EMAIL PROTECTED] writes:
 
  In article [EMAIL PROTECTED] (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), 
  Linus Torvalds [EMAIL PROTECTED] says:
 
  But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
  name it), ACPI updates, and lots of driver work. And just a lot of 
  cleanups.
 
  I cannot boot 2.6.21-rc1; it falls into OOM-Killer.
 
  Interesting error message I can see is:
 request_module: runaway loop modprobe net-pf-1
 
  After bisecting, the commit
Driver core: let request_module() send a /sys/modules/kmod/-uevent
  (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame.
 
  Reverting it fixes the issue to me.
 
 /sbin/hotplug needs some module, but request_module() call /sbin/hotplug loop?
 Hm.. does the patch fix the problem?

How does it loop?

 BTW, mod_request_helper alias of /proc/sys/kernel/modprobe is really needed?

What do you mean?

 -- 
 OGAWA Hirofumi [EMAIL PROTECTED]
 
 
 Don't use uevent until udevd or something like other setup done.
 
 Signed-off-by: OGAWA Hirofumi [EMAIL PROTECTED]
 ---
 
  kernel/kmod.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff -puN kernel/kmod.c~kmod-uevent-fix kernel/kmod.c
 --- linux-2.6/kernel/kmod.c~kmod-uevent-fix   2007-02-22 03:42:37.0 
 +0900
 +++ linux-2.6-hirofumi/kernel/kmod.c  2007-02-22 03:42:48.0 +0900
 @@ -90,11 +90,11 @@ int request_module(const char *fmt, ...)
   if (ret = MODULE_NAME_LEN)
   return -ENAMETOOLONG;
  
 - strcpy(modalias[strlen(MODALIAS=)], module_name);
 - kobject_uevent_env(kmod_mk.kobj, KOBJ_CHANGE, uevent_envp);
 -
 - if (modprobe_path[0] == '\0')
 + if (modprobe_path[0] == '\0') {
 + strcpy(modalias[strlen(MODALIAS=)], module_name);
 + kobject_uevent_env(kmod_mk.kobj, KOBJ_CHANGE, uevent_envp);
   goto out;
 + }

No, we want to still emit these messgages, even if we have a real
helper application.  I don't see how this would fix the problem.

thanks,

greg k-h
-
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 00/21] 2.6.19-stable review

On Wed, Feb 21, 2007 at 02:31:41PM -0500, Chuck Ebbert wrote:
 Greg KH wrote:
  This is the start of the stable review cycle for the 2.6.19.5 release.
  
  This will probably be the last release of the 2.6.19-stable series, so
  if there are patches that you feel should be applied to that tree,
  please let me know.
  
  There are 21 patches in this series, all will be posted as a response to
  this one.  If anyone has any issues with these being applied, please let
  us know.  If anyone is a maintainer of the proper subsystem, and wants
  to add a Signed-off-by: line to the patch, please respond with it.
  
 
 What is the status of:
 
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch
 
 They fix a serious bug that causes machines to freeze up
 or just run very slowly.
 
 I'd like to see these in -stable if possible.

-stable for 2.6.19 and/or .18?

I haven't pushed out the next round of patches for the 2.6.20-stable
tree, I have a _lot_ of them there to catch up on still...

thanks,

greg k-h
-
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: libsata doesn't like bus without master

2007-02-21 Thread Vincent Legoll


I logged:
http://bugzilla.kernel.org/show_bug.cgi?id=8051

That is looking very similar to what this thread is about.

But the fact that this bites on a laptop, where you cannot
modify cabling/jumpering of the drives is annoying.

The drive is even properly recognized when booting from
a cd inserted in it. The BIOS may initialize it differently then.

--
Vincent Legoll
-
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 00/21] 2.6.19-stable review

Greg KH wrote:
 What is the status of:

 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-simplfy-__assign_irq_vector.patch
 http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/broken-out/x86_64-mm-handle-irqs-pending-in-irr-during-irq-migration.patch

 They fix a serious bug that causes machines to freeze up
 or just run very slowly.

 I'd like to see these in -stable if possible.
 
 -stable for 2.6.19 and/or .18?
 

The bug is new in .19 and is still in .20 and .21-rc.

-
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: libsata doesn't like bus without master

2007-02-21 Thread Vincent Legoll


Argh I think I screwed the mail threading, I was refering to:

http://ussg.iu.edu/hypermail/linux/kernel/0702.1/1060.html

From: Patrick Ale
Date: Sun Feb 11 2007 - 05:28:21 EST

Sorry

--
Vincent Legoll
-
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 05/05] Linux Kernel Markers, non optimized architectures

2007-02-21 Thread Mathieu Desnoyers

* Karim Yaghmour ([EMAIL PROTECTED]) wrote:
 - KRYPTIVA PACKAGED MESSAGE -
 PACKAGING TYPE: SIGNED
 
 Hello Mathieu,
 
 Mathieu Desnoyers wrote:
  Yes, that was indeed the first way I implemented it, as a disable 
 option. One of the main thing we have to figure out before I modify this is 
 if we want to have the generic version of markers available in a forced 
 manner at the marker site with the GEN_MARK macro instead of the MARK macro 
 (this is the actual implementation). It has proven to be useful to 
 instrument lockdep.c irq
  enable/disable tracing functions. The reason why is because they are 
 called just before the trap handler returns and I need it to do XMC on x86 
 and x86_64. It would therefore cause a recursive trap.
 
  I think it makes sense to have this kind of support for 
 hard-to-instrument sites within the marker infrastructure, but the cost is 
 to have two marker flavors : MARK and GEN_MARK (but really GEN_MARK is only 
 intended for a few sites).
 
 I must admit that I'm unsure about the use of different marker macros.
 How about bitwise flags that could be coded as part of the marker
 at the marker site? Something like MARKER_TYPE_FORCED. This would
 still allow some form of toplevel control at the macro definition.
 Otherwise there's some digging to be done on a per-marker
 basis ...
 

The problem with your proposal, I guess, is that people will have to
add a supplementary parameter to the macro.

It is not uncommon to have two slightly versions of macros/functions in
the kernel (preempt_enable()/preempt_enable_no_resched(), or macros
starting with underscores). Normally, the underscore states that the
macro does not do the proper locking itself (this is not our case).
Therefore, I would suggest using a name that suggests against what the
macro is protected. For instance, a marker pointing to the generic
version is only needed to protect against the debug trap handler and
should only be used on x86 and x86_64.

So, something like MARK_NO_TRAP() would be appropriate : it would be an
optimized version for every architecture except x86 and x86_64. The
meaning of this macro is : This is a marker that will never generate a
trap because of its activation (just as a precision : it doesn't say
anything about the probe connected to the marker). It also acts as a
strong suggestion about what *should not* be done within the probe.

Mathieu

 Karim
 - KRYPTIVA SIGNED MESSAGE -
 This email claims to have been packaged by Kryptiva.
 To process this email and authenticate its origin, get
 the free plugin from:
 http://www.kryptiva.com/downloads
 
 - KRYPTIVA SIGNATURE START -
 AvWVqAIBTiACAQC3AQAIAgECABTXxT4xHdR4/1uU1hL2
 +TaPrqNB0wMAFNa8GHXZWJH5Dz+D76vfh6JhvWLvBAAUpuIZcCAkCC+ldyaBuoAWxK50HiQF
 ABRI38gc/foDHQsS6X3W0VP4xTukBwYAFB0lithGcxNZYBHaLDONjp6eo/LoBwAU6OwGS0m1
 IVdBt6tKzhaPW8MOfncRABgAAABOIEXcozcACATMABkTAAQAggQA
 mHAJeFbYUzxSX+zkI0DtoVKcqqSp2Ztc9GtY7ZtuLBmeqg5pW0rIbkhutQiztTXlJQ0Ye9bV
 yzEVWd/m7GhDAgRBmyg3kCOt7g7potr1l5J3X5K8TiqtWXbNo3k6AHRlGZyn0190iIBSvf85
 nVh3hKiNPsw8DYs1NKb+KMON+4g=
 - KRYPTIVA SIGNATURE END -

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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: Linux 2.6.21-rc1