Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:
> Christoph Hellwig wrote:
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include "scsi.h"
> >
> >
> >pleaese don't include "scsi.h" in new drivers.  It will go away soon.
> >Use the  headers and get rid of usage of obsolete constucts
> >in your driver.
> 
> 
> It stays until the rest of the libata drivers lose the include.
> 
> After ATAPI support is done, I can stop 2.4.x support, and this and 
> several other compat-isms will go away.

NACK.  Jeff, I accept that you don't want to convert old drivers yet,
but this is not acceptable for new drivers.  We don't allow it for any
new scsi LLDDs, and that includes libata 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/

[PATCH 2/4] m68k: sys_ptrace cleanup

[Roman Zippel]

- create helper function singlestep_disable()
- move variable definitions to the top of the function
- use "out_eio" label as common error destination
- don't clear failure value for PTRACE_SETREGS/PTRACE_GETREGS

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 arch/m68k/kernel/ptrace.c |  175 --
 1 files changed, 64 insertions(+), 111 deletions(-)

Index: linux-2.6/arch/m68k/kernel/ptrace.c
===
--- linux-2.6.orig/arch/m68k/kernel/ptrace.c2005-08-30 16:19:46.290131062 
+0200
+++ linux-2.6/arch/m68k/kernel/ptrace.c 2005-08-30 16:25:52.175519382 +0200
@@ -103,48 +103,56 @@ static inline int put_reg(struct task_st
 }
 
 /*
- * Called by kernel/ptrace.c when detaching..
- *
  * Make sure the single step bit is not set.
  */
-void ptrace_disable(struct task_struct *child)
+static inline void singlestep_disable(struct task_struct *child)
 {
-   unsigned long tmp;
-   /* make sure the single step bit is not set. */
-   tmp = get_reg(child, PT_SR) & ~(TRACE_BITS << 16);
+   unsigned long tmp = get_reg(child, PT_SR) & ~(TRACE_BITS << 16);
put_reg(child, PT_SR, tmp);
child->thread.work.delayed_trace = 0;
+}
+
+/*
+ * Called by kernel/ptrace.c when detaching..
+ */
+void ptrace_disable(struct task_struct *child)
+{
+   singlestep_disable(child);
child->thread.work.syscall_trace = 0;
 }
 
 asmlinkage int sys_ptrace(long request, long pid, long addr, long data)
 {
struct task_struct *child;
-   int ret;
+   unsigned long tmp;
+   int i, ret = 0;
 
lock_kernel();
-   ret = -EPERM;
if (request == PTRACE_TRACEME) {
/* are we already being traced? */
-   if (current->ptrace & PT_PTRACED)
+   if (current->ptrace & PT_PTRACED) {
+   ret = -EPERM;
goto out;
+   }
/* set the ptrace bit in the process flags. */
current->ptrace |= PT_PTRACED;
-   ret = 0;
goto out;
}
-   ret = -ESRCH;
read_lock(_lock);
child = find_task_by_pid(pid);
if (child)
get_task_struct(child);
read_unlock(_lock);
-   if (!child)
+   if (unlikely(!child)) {
+   ret = -ESRCH;
goto out;
+   }
 
-   ret = -EPERM;
-   if (pid == 1)   /* you may not mess with init */
+   /* you may not mess with init */
+   if (unlikely(pid == 1)) {
+   ret = -EPERM;
goto out_tsk;
+   }
 
if (request == PTRACE_ATTACH) {
ret = ptrace_attach(child);
@@ -152,86 +160,62 @@ asmlinkage int sys_ptrace(long request, 
}
 
ret = ptrace_check_attach(child, request == PTRACE_KILL);
-   if (ret < 0)
+   if (ret)
goto out_tsk;
 
switch (request) {
/* when I and D space are separate, these will need to be fixed. */
case PTRACE_PEEKTEXT:   /* read word at location addr. */
-   case PTRACE_PEEKDATA: {
-   unsigned long tmp;
-   int copied;
-
-   copied = access_process_vm(child, addr, , sizeof(tmp), 0);
-   ret = -EIO;
-   if (copied != sizeof(tmp))
-   break;
+   case PTRACE_PEEKDATA:
+   i = access_process_vm(child, addr, , sizeof(tmp), 0);
+   if (i != sizeof(tmp))
+   goto out_eio;
ret = put_user(tmp, (unsigned long *)data);
break;
-   }
 
/* read the word at location addr in the USER area. */
-   case PTRACE_PEEKUSR: {
-   unsigned long tmp;
-
-   ret = -EIO;
-   if ((addr & 3) || addr < 0 ||
-   addr > sizeof(struct user) - 3)
-   break;
+   case PTRACE_PEEKUSR:
+   if (addr & 3)
+   goto out_eio;
+   addr >>= 2; /* temporary hack. */
 
-   tmp = 0;  /* Default return condition */
-   addr = addr >> 2; /* temporary hack. */
-   ret = -EIO;
-   if (addr < 19) {
+   if (addr >= 0 && addr < 19) {
tmp = get_reg(child, addr);
if (addr == PT_SR)
tmp >>= 16;
} else if (addr >= 21 && addr < 49) {
tmp = child->thread.fp[addr - 21];
-#ifdef CONFIG_M68KFPU_EMU
/* Convert internal fpu reg representation
 * into long double format
 */
if (FPU_IS_EMU && (addr < 45) && !(addr % 3))
tmp = ((tmp & 0x) << 15) |
  ((tmp & 0x) << 16);
-#endif
} 

RE: [RFC/PATCH]reconfigure MSI registers after resume

[Nguyen, Tom L]

On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
> So what is the alternative to Shaohua's fix?  Restore all the msi 
> registers on resume?

Yes, the PCIe port bus driver, for example, did that.

Thanks,
Tom
-
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 3/4] m68k: move cache functions into separate file

[Roman Zippel]

Move a few cache functions into its own file and fix flush_icache_range() 
so it can handle both kernel and user addresses correctly (assuming 
context is set correctly).
Turn copy_to_user_page/copy_from_user_page into inline functions and add a 
missing cache flush.

Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>

---

 arch/m68k/mm/Makefile |2 
 arch/m68k/mm/cache.c  |  118 ++
 arch/m68k/mm/memory.c |  104 -
 include/asm-m68k/cacheflush.h |   31 ++-
 4 files changed, 137 insertions(+), 118 deletions(-)

Index: linux-2.6/arch/m68k/mm/Makefile
===
--- linux-2.6.orig/arch/m68k/mm/Makefile2004-03-11 19:29:38.0 
+0100
+++ linux-2.6/arch/m68k/mm/Makefile 2005-08-30 02:36:04.862428281 +0200
@@ -2,7 +2,7 @@
 # Makefile for the linux m68k-specific parts of the memory manager.
 #
 
-obj-y  := init.o fault.o hwtest.o
+obj-y  := cache.o init.o fault.o hwtest.o
 
 obj-$(CONFIG_MMU_MOTOROLA) += kmap.o memory.o motorola.o
 obj-$(CONFIG_MMU_SUN3) += sun3kmap.o sun3mmu.o
Index: linux-2.6/arch/m68k/mm/cache.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-2.6/arch/m68k/mm/cache.c  2005-08-30 02:45:50.289417938 +0200
@@ -0,0 +1,118 @@
+/*
+ *  linux/arch/m68k/mm/cache.c
+ *
+ *  Instruction cache handling
+ *
+ *  Copyright (C) 1995  Hamish Macdonald
+ */
+
+#include 
+#include 
+#include 
+
+
+static unsigned long virt_to_phys_slow(unsigned long vaddr)
+{
+   if (CPU_IS_060) {
+   unsigned long paddr;
+
+   /* The PLPAR instruction causes an access error if the 
translation
+* is not possible. To catch this we use the same exception 
mechanism
+* as for user space accesses in . */
+   asm volatile (".chip 68060\n"
+ "1: plpar (%0)\n"
+ ".chip 68k\n"
+ "2:\n"
+ ".section .fixup,\"ax\"\n"
+ "   .even\n"
+ "3: sub.l %0,%0\n"
+ "   jra 2b\n"
+ ".previous\n"
+ ".section __ex_table,\"a\"\n"
+ "   .align 4\n"
+ "   .long 1b,3b\n"
+ ".previous"
+ : "=a" (paddr)
+ : "0" (vaddr));
+   return paddr;
+   } else if (CPU_IS_040) {
+   unsigned long mmusr;
+
+   asm volatile (".chip 68040\n\t"
+ "ptestr (%1)\n\t"
+ "movec %%mmusr, %0\n\t"
+ ".chip 68k"
+ : "=r" (mmusr)
+ : "a" (vaddr));
+
+   if (mmusr & MMU_R_040)
+   return (mmusr & PAGE_MASK) | (vaddr & ~PAGE_MASK);
+   } else {
+   unsigned short mmusr;
+   unsigned long *descaddr;
+
+   asm volatile ("ptestr %3,%2@,#7,%0\n\t"
+ "pmove %%psr,%1@"
+ : "=a&" (descaddr)
+ : "a" (), "a" (vaddr), "d" (get_fs().seg));
+   if (mmusr & (MMU_I|MMU_B|MMU_L))
+   return 0;
+   descaddr = phys_to_virt((unsigned long)descaddr);
+   switch (mmusr & MMU_NUM) {
+   case 1:
+   return (*descaddr & 0xfe00) | (vaddr & 0x01ff);
+   case 2:
+   return (*descaddr & 0xfffc) | (vaddr & 0x0003);
+   case 3:
+   return (*descaddr & PAGE_MASK) | (vaddr & ~PAGE_MASK);
+   }
+   }
+   return 0;
+}
+
+/* Push n pages at kernel virtual address and clear the icache */
+/* RZ: use cpush %bc instead of cpush %dc, cinv %ic */
+void flush_icache_range(unsigned long address, unsigned long endaddr)
+{
+
+   if (CPU_IS_040_OR_060) {
+   address &= PAGE_MASK;
+
+   do {
+   asm volatile ("nop\n\t"
+ ".chip 68040\n\t"
+ "cpushp %%bc,(%0)\n\t"
+ ".chip 68k"
+ : : "a" (virt_to_phys_slow(address)));
+   address += PAGE_SIZE;
+   } while (address < endaddr);
+   } else {
+   unsigned long tmp;
+   asm volatile ("movec %%cacr,%0\n\t"
+ "orw %1,%0\n\t"
+ "movec %0,%%cacr"
+ : "=" (tmp)
+ : "di" 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:


Christoph Hellwig wrote:


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "scsi.h"



pleaese don't include "scsi.h" in new drivers.  It will go away soon.
Use the  headers and get rid of usage of obsolete constucts
in your driver.



It stays until the rest of the libata drivers lose the include.

After ATAPI support is done, I can stop 2.4.x support, and this and 
several other compat-isms will go away.



NACK.  Jeff, I accept that you don't want to convert old drivers yet,
but this is not acceptable for new drivers.  We don't allow it for any
new scsi LLDDs, and that includes libata drivers.


Sorry, you don't get to NAK that change, since it affects 2.4.x 
maintenance of this new driver.


As I said, the include does away simultaneously for all libata drivers.

Jeff



-
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 2.6.13] Warning in the e1000 driver

[Daniel Walker]

This should fix a small warning in the e1000 driver. It casts to the
largest possible type dma field. This was found while compiling for
X86_64 .

Signed-Off-By: Daniel Walker <[EMAIL PROTECTED]>

Index: linux-2.6.13/drivers/net/e1000/e1000_main.c
===
--- linux-2.6.13.orig/drivers/net/e1000/e1000_main.c2005-08-30 
18:28:41.0 +
+++ linux-2.6.13/drivers/net/e1000/e1000_main.c 2005-08-30 19:42:45.0 
+
@@ -2767,7 +2767,7 @@ e1000_clean_tx_irq(struct e1000_adapter 
"  next_to_use  <%x>\n"
"  next_to_clean<%x>\n"
"buffer_info[next_to_clean]\n"
-   "  dma  <%zx>\n"
+   "  dma  <%llx>\n"
"  time_stamp   <%lx>\n"
"  next_to_watch<%x>\n"
"  jiffies  <%lx>\n"
@@ -2776,7 +2776,7 @@ e1000_clean_tx_irq(struct e1000_adapter 
E1000_READ_REG(>hw, TDT),
tx_ring->next_to_use,
i,
-   tx_ring->buffer_info[i].dma,
+   (unsigned long long)tx_ring->buffer_info[i].dma,
tx_ring->buffer_info[i].time_stamp,
eop,
jiffies,


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

Re: 2.6.13-rt3

[Ingo Molnar]

* Steven Rostedt <[EMAIL PROTECTED]> wrote:

> Ingo,
> 
> I just found a __MAJOR__ bug in my code.  Below is the patch that 
> fixes this bug, zaps the WARN_ON in check_pi_list_present, and changes 
> ALL_TASKS_PI to a booleon instead of just a define.
> 
> The major bug was in __down_trylock.  See anything wrong with this 
> code :-) I'm surprised that this worked as well as it did!

ok, i've released -rt4 with this fix included. The 8-way box boots fine 
now.

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

Re: [RFC][CFLART] ipmi procfs bogosity

[Corey Minyard]

[EMAIL PROTECTED] wrote:


On Thu, Sep 01, 2005 at 11:41:42AM -0500, Corey Minyard wrote:
 


Indeed, this function is badly written.  In rewriting, I couldn't find a
nice function for reading integers from userspace, and the proc_dointvec
stuff didn't seem terribly suitable.  So I wrote my own general
function, which I can move someplace else if someone likes.  Patch is
attached.  It should not affect correct usage of this file.
   



Eeeek...  Much, _much_ simpler approach would be to have

char buf[10];
if (count > 9)
return -EINVAL;
if (copy_from_user(buf, buffer, count))
return -EFAULT;
buf[count] = '\0';
/* use sscanf() or anything normal */

Would that change behaviour in any cases you care about?
 


Because then, for a general solution that avoids integer
perversion, you need something like:

   char buf[10];
   char *end;

   if (count > (sizeof(buf) - 1))
   return -EINVAL;
   if (copy_from_user(buf, buffer, count))
   return -EFAULT;
   buf[count] = '\0';
   newval = simple_strtoul(buf, , 0);
   if (buf == end)
   /* Empty string or first char not a number */
   return -EINVAL;
   if (*end && ! isspace(*end))
   /* Bogus number. */
   return -EINVAL;


To me, It's a lot nicer to do:

   rv = user_strtoul();
   if (rv < 0)
   return rv;

Plus the scanning function I wrote handles arbitrary leading and 
trailing space, etc.  Not a big deal, but a little nicer.


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

Re: [RFC/PATCH]reconfigure MSI registers after resume

[Andrew Morton]

"Nguyen, Tom L" <[EMAIL PROTECTED]> wrote:
>
> On Thursday, September 01, 2005 12:32 PM Andrew Morton wrote:
> > So what is the alternative to Shaohua's fix?  Restore all the msi 
> > registers on resume?
> 
> Yes, the PCIe port bus driver, for example, did that.
> 

So you're saying that each individual driver which uses MSI is responsible
for the restore?  Is it not possible to do this in some single centralised
place?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-rc7-git2 crashes on iBook

[Stelian Pop]

Le jeudi 01 septembre 2005 à 20:26 +0100, Daniel Drake a écrit :
> Hi,
> 
> Stelian Pop wrote:
> > Confirmed on an Apple Powerbook too.
> > 
> > For reference, the (already reverted) patch which needs to be applied is
> > below.
> > 
> > Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
> > 
> > Index: linux-2.6.git/drivers/pci/setup-res.c
[...]

> Sorry for my ignorance. Which tree was this reverted in? You are probably 
> aware that this bug made it into 2.6.13 (patch was not reverted there).

It must be my bad english but I wasn't implying that the patch was
reverted in 2.6.13 but that one should apply it (just apply, without -R,
because I didn't attach the original patch but a reversed version of it)
on a clean 2.6.13 tree in order to make it work. :)

However, a different fix (a real fix, not the workaround proposed above)
was discussed on lkml this week and BenH proposed a patch I haven't had
the chance to test yet (see http://lkml.org/lkml/2005/8/31/1 ).

Stelian.
-- 
Stelian Pop <[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/

[PATCH] Documentation/sparse snapshot URL

[Ben Dooks]

The URL for Documentation/sparse is wrong now that it is
in git.

Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>
diff -urN -X ../dontdiff linux-2.6.13/Documentation/sparse.txt 
linux-2.6.13-bjd1/Documentation/sparse.txt
--- linux-2.6.13/Documentation/sparse.txt   2005-06-17 20:48:29.0 
+0100
+++ linux-2.6.13-bjd1/Documentation/sparse.txt  2005-09-01 21:28:27.0 
+0100
@@ -57,7 +57,7 @@
 
 and DaveJ has tar-balls at
 
-   http://www.codemonkey.org.uk/projects/bitkeeper/sparse/
+   http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
 
 
 Once you have it, just do

Re: GFS, what's remaining

[Andrew Morton]

Alan Cox <[EMAIL PROTECTED]> wrote:
>
> On Iau, 2005-09-01 at 03:59 -0700, Andrew Morton wrote:
> > - Why the kernel needs two clustered fileystems
> 
> So delete reiserfs4, FAT, VFAT, ext2, and all the other "junk". 

Well, we did delete intermezzo.

I was looking for technical reasons, please.

> > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> >   possibly gain (or vice versa)
> > 
> > - Relative merits of the two offerings
> 
> You missed the important one - people actively use it and have been for
> some years. Same reason with have NTFS, HPFS, and all the others. On
> that alone it makes sense to include.

Again, that's not a technical reason.  It's _a_ reason, sure.  But what are
the technical reasons for merging gfs[2], ocfs2, both or neither?

If one can be grown to encompass the capabilities of the other then we're
left with a bunch of legacy code and wasted effort.

I'm not saying it's wrong.  But I'd like to hear the proponents explain why
it's right, please.
-
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] 8139cp: Catch all interrupts

[Pierre Ossman]

Register interrupt handler when net device is registered. Avoids missing
interrupts if the interrupt mask gets out of sync.

Signed-off-by: Pierre Ossman <[EMAIL PROTECTED]>

---

The reason this patch is needed for me is that the resume function is
broken. It enables interrupts unconditionally, but the interrupt handler
is only registered when the device is up.

I don't have enough knowledge about the driver to fix the resume
function so this patch will instead make sure that the interrupt handler
is registered at all times (which can be a nice safeguard even when the
resume function gets fixed).
Index: linux-wbsd/drivers/net/8139cp.c
===
--- linux-wbsd/drivers/net/8139cp.c	(revision 165)
+++ linux-wbsd/drivers/net/8139cp.c	(working copy)
@@ -1204,20 +1204,11 @@
 
 	cp_init_hw(cp);
 
-	rc = request_irq(dev->irq, cp_interrupt, SA_SHIRQ, dev->name, dev);
-	if (rc)
-		goto err_out_hw;
-
 	netif_carrier_off(dev);
 	mii_check_media(>mii_if, netif_msg_link(cp), TRUE);
 	netif_start_queue(dev);
 
 	return 0;
-
-err_out_hw:
-	cp_stop_hw(cp);
-	cp_free_rings(cp);
-	return rc;
 }
 
 static int cp_close (struct net_device *dev)
@@ -1238,7 +1229,6 @@
 	spin_unlock_irqrestore(>lock, flags);
 
 	synchronize_irq(dev->irq);
-	free_irq(dev->irq, dev);
 
 	cp_free_rings(cp);
 	return 0;
@@ -1813,6 +1803,10 @@
 	if (rc)
 		goto err_out_iomap;
 
+	rc = request_irq(dev->irq, cp_interrupt, SA_SHIRQ, dev->name, dev);
+	if (rc)
+		goto err_out_unreg;
+
 	printk (KERN_INFO "%s: RTL-8139C+ at 0x%lx, "
 		"%02x:%02x:%02x:%02x:%02x:%02x, "
 		"IRQ %d\n",
@@ -1832,6 +1826,8 @@
 
 	return 0;
 
+err_out_unreg:
+	unregister_netdev(dev);
 err_out_iomap:
 	iounmap(regs);
 err_out_res:
@@ -1852,6 +1848,7 @@
 
 	if (!dev)
 		BUG();
+	free_irq(dev->irq, dev);
 	unregister_netdev(dev);
 	iounmap(cp->regs);
 	if (cp->wol_enabled) pci_set_power_state (pdev, PCI_D0);

[PATCH][RESEND] Remove non-arch consumers of asm/segment.h

[Kumar Gala]

asm/segment.h varies greatly on different architectures but is clearly
deprecated.  Removing all non-architecture consumers will make it easier
for us to get ride of asm/segment.h all together.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
commit 2ce31e41967fc58548561a601ffa671c0864d3b8
tree dc693869ee136e6fd06ca4792991d1e0984ec8dd
parent 58d478e75ac5d6cb3a1f738a22555c3841445264
author Kumar K. Gala <[EMAIL PROTECTED]> Wed, 24 Aug 2005 10:15:41 -0500
committer Kumar K. Gala <[EMAIL PROTECTED]> Wed, 24 Aug 2005 10:15:41 -0500

 drivers/char/mxser.c  |1 -
 drivers/isdn/hisax/hisax.h|1 -
 drivers/media/video/adv7170.c |1 -
 drivers/media/video/adv7175.c |1 -
 drivers/media/video/bt819.c   |1 -
 drivers/media/video/bt856.c   |1 -
 drivers/media/video/saa7111.c |1 -
 drivers/media/video/saa7114.c |1 -
 drivers/media/video/saa7185.c |1 -
 drivers/serial/68328serial.c  |1 -
 drivers/serial/crisv10.c  |1 -
 drivers/serial/icom.c |1 -
 drivers/serial/mcfserial.c|1 -
 drivers/video/q40fb.c |1 -
 include/linux/isdn.h  |1 -
 sound/oss/os.h|3 ---
 16 files changed, 0 insertions(+), 18 deletions(-)

diff --git a/drivers/char/mxser.c b/drivers/char/mxser.c
--- a/drivers/char/mxser.c
+++ b/drivers/char/mxser.c
@@ -63,7 +63,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/isdn/hisax/hisax.h b/drivers/isdn/hisax/hisax.h
--- a/drivers/isdn/hisax/hisax.h
+++ b/drivers/isdn/hisax/hisax.h
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/media/video/adv7170.c b/drivers/media/video/adv7170.c
--- a/drivers/media/video/adv7170.c
+++ b/drivers/media/video/adv7170.c
@@ -43,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/media/video/adv7175.c b/drivers/media/video/adv7175.c
--- a/drivers/media/video/adv7175.c
+++ b/drivers/media/video/adv7175.c
@@ -39,7 +39,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/media/video/bt819.c b/drivers/media/video/bt819.c
--- a/drivers/media/video/bt819.c
+++ b/drivers/media/video/bt819.c
@@ -43,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/media/video/bt856.c b/drivers/media/video/bt856.c
--- a/drivers/media/video/bt856.c
+++ b/drivers/media/video/bt856.c
@@ -43,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/media/video/saa7111.c b/drivers/media/video/saa7111.c
--- a/drivers/media/video/saa7111.c
+++ b/drivers/media/video/saa7111.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/media/video/saa7114.c b/drivers/media/video/saa7114.c
--- a/drivers/media/video/saa7114.c
+++ b/drivers/media/video/saa7114.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/media/video/saa7185.c b/drivers/media/video/saa7185.c
--- a/drivers/media/video/saa7185.c
+++ b/drivers/media/video/saa7185.c
@@ -39,7 +39,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
diff --git a/drivers/serial/68328serial.c b/drivers/serial/68328serial.c
--- a/drivers/serial/68328serial.c
+++ b/drivers/serial/68328serial.c
@@ -40,7 +40,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/serial/crisv10.c b/drivers/serial/crisv10.c
--- a/drivers/serial/crisv10.c
+++ b/drivers/serial/crisv10.c
@@ -446,7 +446,6 @@ static char *serial_version = "$Revision
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/serial/icom.c b/drivers/serial/icom.c
--- a/drivers/serial/icom.c
+++ b/drivers/serial/icom.c
@@ -56,7 +56,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/serial/mcfserial.c b/drivers/serial/mcfserial.c
--- a/drivers/serial/mcfserial.c
+++ b/drivers/serial/mcfserial.c
@@ -40,7 +40,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/q40fb.c b/drivers/video/q40fb.c
--- a/drivers/video/q40fb.c
+++ b/drivers/video/q40fb.c
@@ -21,7 +21,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/isdn.h b/include/linux/isdn.h
--- a/include/linux/isdn.h
+++ b/include/linux/isdn.h
@@ -150,7 +150,6 @@ typedef struct {
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/sound/oss/os.h b/sound/oss/os.h
--- a/sound/oss/os.h
+++ b/sound/oss/os.h
@@ -19,9 +19,6 @@
 #include 
 #include 
 #include 
-#ifdef __alpha__
-#include 
-#endif
 #include 
 #include 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

[PATCH] Add hacks for IPMI chassis poweroff for certain Dell servers

[Corey Minyard]

This patch allows Dell servers with IPMI controllers that predate IPMI
1.5 to use the standard poweroff or powercycle commands.  These
systems firmware don't set the chassis capability bit in the Get
Device ID, but they do implement the standard poweroff and powercycle
commands.

Tested on RHEL3 kernel 2.4.21-20.ELsmp on a PowerEdge 2600.  The
standard ipmi_poweroff driver cannot drive these systems.  With this
patch, they power off or powercycle as expected.

 drivers/char/ipmi/ipmi_poweroff.c |   24 
 1 files changed, 24 insertions(+)

Signed-off-by: Matt Domsch <[EMAIL PROTECTED]>
Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>

Index: linux-2.6.13/drivers/char/ipmi/ipmi_poweroff.c
===
--- linux-2.6.13.orig/drivers/char/ipmi/ipmi_poweroff.c
+++ linux-2.6.13/drivers/char/ipmi/ipmi_poweroff.c
@@ -64,6 +64,7 @@ MODULE_PARM_DESC(poweroff_control, " Set
 static unsigned int mfg_id;
 static unsigned int prod_id;
 static unsigned char capabilities;
+static unsigned char ipmi_version;
 
 /* We use our own messages for this operation, we don't let the system
allocate them, since we may be in a panic situation.  The whole
@@ -339,6 +340,25 @@ static void ipmi_poweroff_cpi1 (ipmi_use
 }
 
 /*
+ * ipmi_dell_chassis_detect()
+ * Dell systems with IPMI < 1.5 don't set the chassis capability bit
+ * but they can handle a chassis poweroff or powercycle command.
+ */
+
+#define DELL_IANA_MFR_ID {0xA2, 0x02, 0x00}
+static int ipmi_dell_chassis_detect (ipmi_user_t user)
+{
+	const char ipmi_version_major = ipmi_version & 0xF;
+	const char ipmi_version_minor = (ipmi_version >> 4) & 0xF;
+	const char mfr[3]=DELL_IANA_MFR_ID;
+	if (!memcmp(mfr, _id, sizeof(mfr)) &&
+	ipmi_version_major <= 1 &&
+	ipmi_version_minor < 5)
+		return 1;
+	return 0;
+}
+
+/*
  * Standard chassis support
  */
 
@@ -415,6 +435,9 @@ static struct poweroff_function poweroff
 	{ .platform_type	= "CPI1",
 	  .detect		= ipmi_cpi1_detect,
 	  .poweroff_func	= ipmi_poweroff_cpi1 },
+	{ .platform_type	= "chassis",
+	  .detect		= ipmi_dell_chassis_detect,
+	  .poweroff_func	= ipmi_poweroff_chassis },
 	/* Chassis should generally be last, other things should override
 	   it. */
 	{ .platform_type	= "chassis",
@@ -500,6 +523,7 @@ static void ipmi_po_new_smi(int if_num)
 	prod_id = (halt_recv_msg.msg.data[10]
 		   | (halt_recv_msg.msg.data[11] << 8));
 	capabilities = halt_recv_msg.msg.data[6];
+	ipmi_version = halt_recv_msg.msg.data[5];
 
 
 	/* Scan for a poweroff method */

[PATCH 1/1] 8250_kgdb driver reworked

[Tom Rini]

Andrew, I'll probably repost the whole series next week in hope you'll
grab it for 2.6.13-mm2.

This is the I/O driver for any 8250-compatible UARTs.  This also adds some
small hooks into the normal serial core so that we can take away the uart and
make sure only KGDB is trying to use it.  We also make sure that if KGDB_8250
is enabled, SERIAL_8250_NR_UARTS is set to the default of 4.  This is so that
if we can always depend on that constant in the 8250 driver for giving our
table a size.  To make it easier (or in some cases, possible) to free up ports
on a shared irq system, we add a line member to plat_serial8250_port.

Since the last time this was submitted, I've reworked the commandline param,
kgdb8250=, to be of the form ,,,
for all platforms to always work as an override of the compiled in port.
To compile in a port you either go by number and baud rate, or compile
in the port information the same as you would pass it in on the command
line.  The config options are pared way down as well now (don't ask me
why I forgot 'int' exists, I can't say...).


CC: Russell King <[EMAIL PROTECTED]>, Bjorn Helgaas <[EMAIL PROTECTED]>
This is the I/O driver for any 8250-compatible UARTs.  This also adds some
small hooks into the normal serial core so that we can take away the uart and
make sure only KGDB is trying to use it.  We also make sure that if KGDB_8250
is enabled, SERIAL_8250_NR_UARTS is set to the default of 4.  This is so that
if we can always depend on that constant in the 8250 driver for giving our
table a size.  To make it easier (or in some cases, possible) to free up ports
on a shared irq system, we add a line member to plat_serial8250_port.

Since the last time this was submitted, I've reworked the commandline param,
kgdb8250=, to be of the form ,,,
for all platforms to always work as an override of the compiled in port.
To compile in a port you either go by number and baud rate, or compile
in the port information the same as you would pass it in on the command
line.

---

 linux-2.6.13-trini/drivers/serial/8250.c  |   21 +
 linux-2.6.13-trini/drivers/serial/8250.h  |1 
 linux-2.6.13-trini/drivers/serial/8250_kgdb.c |  538 ++
 linux-2.6.13-trini/drivers/serial/Kconfig |2 
 linux-2.6.13-trini/drivers/serial/Makefile|1 
 linux-2.6.13-trini/lib/Kconfig.debug  |   60 ++
 6 files changed, 621 insertions(+), 2 deletions(-)

diff -puN drivers/serial/8250.c~8250 drivers/serial/8250.c
--- linux-2.6.13/drivers/serial/8250.c~8250 2005-09-01 12:00:37.0 
-0700
+++ linux-2.6.13-trini/drivers/serial/8250.c2005-09-01 12:00:37.0 
-0700
@@ -2516,6 +2516,27 @@ void serial8250_unregister_port(int line
 }
 EXPORT_SYMBOL(serial8250_unregister_port);
 
+/**
+ * serial8250_unregister_by_port - remove a 16x50 serial port
+ * at runtime.
+ * @port: A  uart_port that describes the port to remove.
+ *
+ * Remove one serial port.  This may not be called from interrupt
+ * context.  We hand the port back to the our control.
+ */
+void serial8250_unregister_by_port(struct uart_port *port)
+{
+   struct uart_8250_port *uart;
+
+   down(_sem);
+   uart = serial8250_find_match_or_unused(port);
+   up(_sem);
+
+   if (uart)
+   serial8250_unregister_port(uart->port.line);
+}
+EXPORT_SYMBOL(serial8250_unregister_by_port);
+
 static int __init serial8250_init(void)
 {
int ret, i;
diff -puN drivers/serial/8250.h~8250 drivers/serial/8250.h
--- linux-2.6.13/drivers/serial/8250.h~8250 2005-09-01 12:00:37.0 
-0700
+++ linux-2.6.13-trini/drivers/serial/8250.h2005-09-01 12:00:37.0 
-0700
@@ -19,6 +19,7 @@
 
 int serial8250_register_port(struct uart_port *);
 void serial8250_unregister_port(int line);
+void serial8250_unregister_by_port(struct uart_port *port);
 void serial8250_suspend_port(int line);
 void serial8250_resume_port(int line);
 
diff -puN drivers/serial/Kconfig~8250 drivers/serial/Kconfig
--- linux-2.6.13/drivers/serial/Kconfig~82502005-09-01 12:00:37.0 
-0700
+++ linux-2.6.13-trini/drivers/serial/Kconfig   2005-09-01 12:00:37.0 
-0700
@@ -87,7 +87,7 @@ config SERIAL_8250_ACPI
 
 config SERIAL_8250_NR_UARTS
int "Maximum number of 8250/16550 serial ports"
-   depends on SERIAL_8250
+   depends on SERIAL_8250 || KGDB_8250
default "4"
help
  Set this to the number of serial ports you want the driver
diff -L drivers/serial/kgdb_8250.c -puN /dev/null /dev/null
diff -puN drivers/serial/Makefile~8250 drivers/serial/Makefile
--- linux-2.6.13/drivers/serial/Makefile~8250   2005-09-01 12:00:37.0 
-0700
+++ linux-2.6.13-trini/drivers/serial/Makefile  2005-09-01 12:00:37.0 
-0700
@@ -57,3 +57,4 @@ obj-$(CONFIG_SERIAL_JSM) += jsm/
 obj-$(CONFIG_SERIAL_TXX9) += serial_txx9.o
 obj-$(CONFIG_SERIAL_VR41XX) += vr41xx_siu.o
 obj-$(CONFIG_SERIAL_SGI_IOC4) += ioc4_serial.o
+obj-$(CONFIG_KGDB_8250) += 

[PATCH] 2.6.13: Filesystem capabilities 0.16

[Olaf Dietsche]

This patch implements filesystem capabilities. It allows to run
privileged executables without the need for suid root.

Changes:
- updated to 2.6.13

This patch is available at:


Regards, Olaf.
-
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-cluster] Re: GFS, what's remaining

[Hua Zhong \(hzhong\)]

I just started looking at gfs. To understand it you'd need to look at it
from the entire cluster solution point of view.

This is a good document from David. It's not about GFS in particular but
about the architecture of the cluster.

http://people.redhat.com/~teigland/sca.pdf 

Hua

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Christoph Hellwig
> Sent: Thursday, September 01, 2005 10:56 AM
> To: Alan Cox
> Cc: Christoph Hellwig; Andrew Morton; 
> linux-fsdevel@vger.kernel.org; [EMAIL PROTECTED]; 
> linux-kernel@vger.kernel.org
> Subject: [Linux-cluster] Re: GFS, what's remaining
> 
> On Thu, Sep 01, 2005 at 04:28:30PM +0100, Alan Cox wrote:
> > > That's GFS.  The submission is about a GFS2 that's 
> on-disk incompatible
> > > to GFS.
> > 
> > Just like say reiserfs3 and reiserfs4 or ext and ext2 or 
> ext2 and ext3
> > then. I think the main point still stands - we have always taken
> > multiple file systems on board and we have benefitted 
> enormously from
> > having the competition between them instead of a dictat 
> from the kernel
> > kremlin that 'foofs is the one true way'
> 
> I didn't say anything agains a particular fs, just that your previous
> arguments where utter nonsense.  In fact I think having two 
> or more cluster
> filesystems in the tree is a good thing.  Whether the gfs2 
> code is mergeable
> is a completely different question, and it seems at least debatable to
> submit a filesystem for inclusion that's still pretty new.
> 
> While we're at it I can't find anything describing what gfs2 is about,
> what is lacking in gfs, what structual changes did you make, etc..
> 
> p.s. why is gfs2 in fs/gfs in the kernel tree?
> 
> --
> Linux-cluster mailing list
> [EMAIL PROTECTED]
> http://www.redhat.com/mailman/listinfo/linux-cluster
-
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] acpi-cpufreq: Remove P-state read after a P-state write in normal path

[Brown, Len]

>How can we handle it, if we do not even know that it failed? 
>How should the user recognize something is broken?

We probably shouldn't have used the word "fail" here.

I expect the IO and MSR accesses will always "succeed",
but they may not always have the exact effect the OS requested.
I think we (the OS) need to get used to this.

The HW reserves the right to second guess the OS for a
variety of reasons, including temperature, power,
reliability, or dependencies between different hardware
units that may not be exposed to the OS.  I think as
hardware becomes more complex and more power-optimized,
we'll see more of this, not less.

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

Re: 2.6.13-mm1

[John Stoffel]

Dominik> Why should I check for newer firmware!? I don't understand
Dominik> that point of view.  The device works without any problems
Dominik> with 2.6.13-ck1 as 2.6.13-rc6-mm1 and before kernels. So
Dominik> there is no need to check the firmware imho.

That's on point of view.  In my experience, it simplifies debugging to
make sure the unit is at the latest firmware, since bugs in the
enclosure's IDE driver could be causing the problem.  As I said
before, when my enclosure was upgraded, all my problems went away.  

So that's why I was asking you to make sure your firmware was upto
date.  Is that so hard to understand?  

Dominik> I don't think that it makes any difference if I power up
Dominik> first or plug in first. The device is recognized when I power
Dominik> it on, so it would be the same when I power it on and connect
Dominik> after that imho.

Sure it can make a difference.  If the enclosure puts out crap signals
on the USB bus when it's powered up, and the older versions of the
Linux kernel dealt with them because of an oversight, but now we're
closer to the USB specs... it could the issue.  

In any case, it's a *simple* test to do, unless you're not physically
at the system with this device, or if you can't be bothered to:

1. unplug enclosure from USB.
2. power it off.
3. power it on.
4. wait 30 seconds.
5. plug in the USB cable.
6. what happens?

That tells us useful stuff.  

Dominik> I will try to get the backtraces from the kernel, this should
Dominik> make debugging easier.

That will help people debug this for sure.

In any case, I'm not going to be much help from here on.
-
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: reboot vs poweroff

[Brown, Len]

 
>Patch tested and works fine here. You should probably make a 
>note in the bugzilla so we don't get a conflicting merge
>from the ACPI folks.

One might also consider that it would be a good idea to
send patches that break ACPI files to the ACPI maintainer
and [EMAIL PROTECTED] before sending them
to Linus...

-Len
-
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: reboot vs poweroff

[Eric W. Biederman]

Pierre Ossman <[EMAIL PROTECTED]> writes:
>
> Patch tested and works fine here. You should probably make a note in the
> bugzilla so we don't get a conflicting merge from the ACPI folks.

Thanks.

If I can figure out bugzilla...

> I suppose Nigel should use this function in swsusp2 aswell?

If he is doing the same thing yes.

Eric

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

Consolidate dprintk and friends?

[David Härdeman]

A case-insensitive grep through the 2.6.13 tree for "define printk" 
yields 378 hits ("define dbg": 736, "define warn": 50, "define info": 
65).


Maybe it would be a good idea to create include/linux/debug.h as 
included inline below (or to add the content in include/linux/kernel.h 
where pr_debug is already located)? 


Then a module could simply do:

#include 
MODULE_DEBUG;

and then sprinkle debug() statements where appropriate.

It would also make the name and description of the debug variable in 
sysfs more consistent. 

I tried searching the lkml archives, but couldn't find any discussion on 
the topic...so is it a good idea?


Re,
David


--- /dev/null   2005-09-01 20:05:20.395616648 +0200
+++ linux-2.6.13/include/linux/debug.h  2005-09-01 20:01:56.0 +0200
@@ -0,0 +1,52 @@
+#ifndef _LINUX_DEBUG_H
+#define _LINUX_DEBUG_H
+
+/*
+ * unconditional messages 
+ */

+
+/* unc(onditional)_debug should not be used, but rather debug or pr_debug */
+#define unc_debug(fmt,arg...) printk(KERN_DEBUG fmt, ##arg)
+
+/* convenience macros */
+#define info(fmt,arg...) printk(KERN_INFO fmt, ##arg)
+#define warn(fmt,arg...) printk(KERN_WARN fmt, ##arg)
+#define err(fmt,arg...) printk(KERN_EMERG fmt, ##arg)
+
+
+
+/*
+ * debug messages (de)activated at runtime 
+ */

+
+/* the variable which (de)activates debugging messages */
+#ifndef DEBUG_VARIABLE
+#define DEBUG_VARIABLE debug
+#endif
+
+/* quick macro to add a debug parameter to a module */
+#define MODULE_DEBUG \
+do { \
+   static unsigned int DEBUG_VARIABLE = 0; \
+   module_param(DEBUG_VARIABLE, uint, 0644); \
+   MODULE_PARM_DESC(DEBUG_VARIABLE, "Enable debug messages"); \
+} while(0)
+
+/* regular debug messages */
+#define debug(fmt,arg...) do { if (DEBUG_VARIABLE) unc_debug(fmt, ##arg); } 
while (0)
+
+/* different levels of debug messages (only output if DEBUG_VARIABLE is large 
enough) */
+#define ldebug(level,fmt,arg...) do { if (DEBUG_VARIABLE >= level) 
unc_debug(fmt, ##arg); } while (0)
+
+
+
+/* 
+ * debug messages (de)activated by the preprocessor 
+ */

+#ifdef DEBUG
+#define pr_debug(fmt,arg...) unc_debug(fmt, ##arg)
+#else
+#define pr_debug(fmt,arg...) do { } while (0)
+#endif
+
+#endif /* _LINUX_DEBUG_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: reboot vs poweroff

[Pierre Ossman]

Eric W. Biederman wrote:

>Thanks.
>
>This is clearly a code path I missed when I was fixing things.
>
>When I made the final acpi change I checked for any other users
>of device_suspend and it seems I was blind and missed this one.
>Looking again...
>
>The patch in the bug report looks correct.  However it is still
>a little incomplete.  In particular the reboot notifier is not
>being called, and since not everything has been converted into
>using shutdown methods that could lead to some other inconsistent
>behavior.
>
>Does anyone have any problems with the patch below?
>If not I will send this off to Linus..
>
>  
>

Patch tested and works fine here. You should probably make a note in the
bugzilla so we don't get a conflicting merge from the ACPI folks.

I suppose Nigel should use this function in swsusp2 aswell?

Rgds
Pierre

-
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: Whither klists?

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 02:09:19PM -0400, Alan Stern wrote:
> Patrick and Greg:
> 
> To put it baldly: Should klists be replaced with regular lists, each 
> protected by an rwsem (or even a mutex)?
> 
> The advantage of klists is that threads can remove or add nodes while 
> other threads iterate through the list.  With an rwsem, only one thread 
> would be able to add or remove a node at a time, and only when no other 
> thread was using the list.  Considering that klists are currently used 
> to hold:
> 
>   the set of all devices on a bus,
> 
>   the set of all drivers for a bus, and
> 
>   the set of all children of a device,
> 
>   (not counting the set of all devices bound to a driver, since
>   there's already a patch to replace that with a mutex-protected
>   regular list)
> 
> this limitation on adding or removing doesn't seem significant.  There
> aren't many places where these lists are iterated over or altered.  We
> could remove most of the overhead associated with klists and get rid of an
> extra API for people to learn.
> 
> Note that this would be very different from the old bus subsystem rwsem.  
> That protected too much -- everything associated with the bus subsystem -- 
> making it a pronounced chokepoint.  My suggestion involves a separate 
> rwsem for each of these lists, so that none of them would be subject to 
> much contention.

Might also be worth to do a micro-benchmark for it (maybe in userland).
The current klist code is far too complex for it's own good.

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

[PATCH] ppc32: Added cputable entry for 7448

[Kumar Gala]

Added cputable entry for 7448 as well adding it to checks for saving and
restoring of cpu state.

Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

---
commit 10c7d4720428b8b8486a45e5c4086b8ab7088967
tree ec3b0bda4cf730b6872b62a7a8b33acca1d95dd0
parent 18428d3c5db638b3d92e662890bedbc95737e052
author Kumar K. Gala <[EMAIL PROTECTED]> Thu, 01 Sep 2005 13:13:03 -0500
committer Kumar K. Gala <[EMAIL PROTECTED]> Thu, 01 Sep 2005 13:13:03 -0500

 arch/ppc/kernel/cpu_setup_6xx.S |4 
 arch/ppc/kernel/cputable.c  |   16 
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/kernel/cpu_setup_6xx.S b/arch/ppc/kernel/cpu_setup_6xx.S
--- a/arch/ppc/kernel/cpu_setup_6xx.S
+++ b/arch/ppc/kernel/cpu_setup_6xx.S
@@ -327,6 +327,7 @@ _GLOBAL(__save_cpu_setup)
cmplwi  cr4,r3,0x8002   /* 7457 */
cmplwi  cr5,r3,0x8003   /* 7447A */
cmplwi  cr6,r3,0x7000   /* 750FX */
+   cmplwi  cr7,r3,0x8004   /* 7448 */
/* cr1 is 7400 || 7410 */
cror4*cr1+eq,4*cr1+eq,4*cr2+eq
/* cr0 is 74xx */
@@ -334,6 +335,7 @@ _GLOBAL(__save_cpu_setup)
cror4*cr0+eq,4*cr0+eq,4*cr4+eq
cror4*cr0+eq,4*cr0+eq,4*cr1+eq
cror4*cr0+eq,4*cr0+eq,4*cr5+eq
+   cror4*cr0+eq,4*cr0+eq,4*cr7+eq
bne 1f
/* Backup 74xx specific regs */
mfspr   r4,SPRN_MSSCR0
@@ -396,6 +398,7 @@ _GLOBAL(__restore_cpu_setup)
cmplwi  cr4,r3,0x8002   /* 7457 */
cmplwi  cr5,r3,0x8003   /* 7447A */
cmplwi  cr6,r3,0x7000   /* 750FX */
+   cmplwi  cr7,r3,0x8004   /* 7448 */
/* cr1 is 7400 || 7410 */
cror4*cr1+eq,4*cr1+eq,4*cr2+eq
/* cr0 is 74xx */
@@ -403,6 +406,7 @@ _GLOBAL(__restore_cpu_setup)
cror4*cr0+eq,4*cr0+eq,4*cr4+eq
cror4*cr0+eq,4*cr0+eq,4*cr1+eq
cror4*cr0+eq,4*cr0+eq,4*cr5+eq
+   cror4*cr0+eq,4*cr0+eq,4*cr7+eq
bne 2f
/* Restore 74xx specific regs */
lwz r4,CS_MSSCR0(r5)
diff --git a/arch/ppc/kernel/cputable.c b/arch/ppc/kernel/cputable.c
--- a/arch/ppc/kernel/cputable.c
+++ b/arch/ppc/kernel/cputable.c
@@ -536,6 +536,22 @@ struct cpu_speccpu_specs[] = {
.num_pmcs   = 6,
.cpu_setup  = __setup_cpu_745x
},
+   {   /* 7448 */
+   .pvr_mask   = 0x,
+   .pvr_value  = 0x8004,
+   .cpu_name   = "7448",
+   .cpu_features   = CPU_FTR_COMMON |
+   CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+   CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_L2CR |
+   CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE |
+   CPU_FTR_SPEC7450 | CPU_FTR_NAP_DISABLE_L2_PR |
+   CPU_FTR_HAS_HIGH_BATS | CPU_FTR_NEED_COHERENT,
+   .cpu_user_features  = COMMON_PPC | PPC_FEATURE_ALTIVEC_COMP,
+   .icache_bsize   = 32,
+   .dcache_bsize   = 32,
+   .num_pmcs   = 6,
+   .cpu_setup  = __setup_cpu_745x
+   },
{   /* 82xx (8240, 8245, 8260 are all 603e cores) */
.pvr_mask   = 0x7fff,
.pvr_value  = 0x0081,
-
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/

Whither klists?

[Alan Stern]

Patrick and Greg:

To put it baldly: Should klists be replaced with regular lists, each 
protected by an rwsem (or even a mutex)?

The advantage of klists is that threads can remove or add nodes while 
other threads iterate through the list.  With an rwsem, only one thread 
would be able to add or remove a node at a time, and only when no other 
thread was using the list.  Considering that klists are currently used 
to hold:

the set of all devices on a bus,

the set of all drivers for a bus, and

the set of all children of a device,

(not counting the set of all devices bound to a driver, since
there's already a patch to replace that with a mutex-protected
regular list)

this limitation on adding or removing doesn't seem significant.  There
aren't many places where these lists are iterated over or altered.  We
could remove most of the overhead associated with klists and get rid of an
extra API for people to learn.

Note that this would be very different from the old bus subsystem rwsem.  
That protected too much -- everything associated with the bus subsystem -- 
making it a pronounced chokepoint.  My suggestion involves a separate 
rwsem for each of these lists, so that none of them would be subject to 
much contention.

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: Very strange Marvell/Yukon Gigabit NIC networking problems

[Stephen Hemminger]

On Tue, 30 Aug 2005 12:54:31 +0100
Daniel Drake <[EMAIL PROTECTED]> wrote:

> Hi Stephen,
> 
> This looks like an issue I reported previously. After you use a recent skge, 
> you can't use any older drivers or the windows driver, but skge still works 
> fine every time.
> 
>   http://marc.theaimsgroup.com/?l=linux-netdev=112268414417743=2
> 
> The Gentoo bug report is here:
> 
>   http://bugs.gentoo.org/show_bug.cgi?id=100258
> 
> I closed the Gentoo bug as I hoped this patch would solve it:
> 
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=0eedf4ac5b536c7922263adf1b1d991d2e2397b9;hp=acdd80d514a08800380c9f92b1bf4d4c9e818125
> 
> But according to Steve Kieu, the problem is still there in 2.6.13. It's 
> slightly odd as Steve was previously a sk98lin user and initially reported 
> this problem for sk98lin in 2.6.13 whereas it did not happen with sk98lin in 
> 2.6.12.
> 
> Any ideas?
> 
> Thanks.
> 
> Steve Kieu wrote:
> > Tested , not broken, working now but the same problem,
> > that is if I reboot to winXP or 2.6.12, 2.6.11, the
> > NIC is unusaeble. In XP it always says link is down,
> > or media disconnected (from ipconfig command output in
> > XP)
> > is it because the firmware of NIC has changed or any
> > reason?
> > 
> > 
> > I noticed  warning messages only with 2.6.13 
> > 
> > PCI: Failed to allocate mem resource #10:[EMAIL PROTECTED] for
> > :02:01.0
> > 
> > and modem device in 2.6.13 IRQ is disabled.

This is a different problem related to ACPI and other bus
changes in 2.6.13.


> > ACPI: PCI Interrupt Link [LKMO] enabled at IRQ 20
> > ACPI: PCI Interrupt :00:06.1[B] -> Link [LKMO] ->
> > GSI 20 (level, low) -> IRQ
> >  17
> > ACPI: PCI interrupt for device :00:06.1 disabled
> > 
> > not sure if it gives more information.
> > 
> > skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
> > skge eth0: addr 00:11:d8:f2:1f:18
> > ACPI: PCI Interrupt :02:01.0[A] -> Link [LNKB] ->
> > GSI 18 (level, low) -> IRQ
> >  16
> > Yenta: CardBus bridge found at :02:01.0
> > [1043:1987]
> > skge eth0: enabling interface
> > 
> > skge eth0: Link is up at 10 Mbps, half duplex, flow
> > control none
> > 
> > Not sure how can I restore this thing back to normal
> > (sigh)


Is this the correct summary of the problem scenarios.
Assume each one starts from cold boot (power off).

* 2.6.13(skge) boot=> Good
* 2.6.13(sk98lin) boot => Good
* 2.6.13 + SK version of sk98lin   => Good
* XP boot  => Good

Okay, now the cases where one OS is run first and
a reboot is done to a second, or in the case of
just Linux, this should be the same as rmmoding on
driver and modprobing

Second
First   | skge | sk98lin | XP
skge| OK   |  BAD| BAD
sk98lin | ok   |  OK | ok 
XP  | ok   |  ok | OK


-
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-2.6.13-git1 and git2 MIA

[David R. Wilson]

Hello Gang

Third time around on this (posted by others)

There is no patch-2.6.13-git1* or git2* files on ftp.kernel.org.

All that is there is an empty file.

Did Katrina visit the server too?

Linus?  Can you fix this?

Thanks,

Dave

-
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.13 freezes during acpi wakup with wake-on-lan

[Thomas S. Heydt-Benjamin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I am working with an IBM X31 laptop running Redhat FC5 with 2.6.13
kernel.  I need to get wake-on-lan working for mobile systems power
management experiments that we are performing in my lab.

The kernel is configured to use ACPI (pertinent kernel configuration
excerpt follows message).

When I put the laptop into "mem" suspend state (exact procedure follows
message), and then wake it up with a magic packet to it's NIC, I get an
infinite number of error messages and a frozen computer.

The error message is: "evgpe-0700: *** Error: acpi_ev_gpe_dispatch: No
handler or method for GPE[ B], disabling event" which repeats forever in
an infinite loop.  I have googled extensively for a solution,
unfortunately all published answers that I have found simply say "use
APM instead of ACPI".  When we use APM, we find that power is cut to the
NIC when in mem suspend state, thus preventing the possibility of
wake-on-lan.

Any suggestions greatly appreciated.  Several people in my lab have
tried to get this working, and all have failed.

---Tom Heydt-Benjamin

- -- Procedure for mem suspend --
[EMAIL PROTECTED] acpi]# uname -a
Linux csdhcp173.csdhcp.cs.local 2.6.13 #1 Wed Aug 31 11:58:14 EDT 2005
i686 i686 i386 GNU/Linux
[EMAIL PROTECTED] acpi]# cd /proc/acpi
[EMAIL PROTECTED] acpi]# cat wakeup
Device  Sleep state Status
 LID   3*enabled
SLPB   3*enabled
PCI0   3disabled
UART   3disabled
PCI1   4disabled
DOCK   4disabled
USB0   3disabled
USB1   3disabled
USB2   3disabled
AC9M   4disabled
[EMAIL PROTECTED] acpi]# echo "PCI0" > wakeup
[EMAIL PROTECTED] acpi]# echo "PCI1" > wakeup
[EMAIL PROTECTED] acpi]# ethtool -s eth0 wol g
[EMAIL PROTECTED] acpi]# echo "mem" > /sys/power/state
- -- Pertinant .config excerpt ---
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_DEBUG=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_HOTKEY=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=y
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=2001
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set


#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

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

Re: 2.6.13-mm1

[Dominik Karall]

On Thursday 01 September 2005 19:34, John Stoffel wrote:
> Dominik,
>
> So what is the chipset inside the enclosure?  Looking at your output,
> the 'Argosy' stuff doesn't tell me anything.  You might have to open
> up the case to look in there to find more details.
>
> Again, check with your vendor and see if there is newer firmware.  And
> have you powered up the device without having it plugged into the
> system, then plug it in?  What happens then?

Why should I check for newer firmware!? I don't understand that point of view. 
The device works without any problems with 2.6.13-ck1 as 2.6.13-rc6-mm1 and 
before kernels. So there is no need to check the firmware imho.

I don't think that it makes any difference if I power up first or plug in 
first. The device is recognized when I power it on, so it would be the same 
when I power it on and connect after that imho.

I will try to get the backtraces from the kernel, this should make debugging 
easier.

greets,
dominik


pgpxzSRXdjy8T.pgp
Description: PGP signature

Re: Very strange Marvell/Yukon Gigabit NIC networking problems

[Stephen Hemminger]

On Wed, 31 Aug 2005 10:09:48 +1000 (EST)
Steve Kieu <[EMAIL PROTECTED]> wrote:

> 
> --- Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
> 
> > > 
> > > install-8_23.tar.bz2
> > 
> > Just look for references to CHIP_REV_YU_LITE_A3 in
> > the driver
> > sk98lin/skgeinit.c and sk98lin/skxmac2.c
> > The comparison should always be:
> 
> Have a look but no clue to patch it, there are one
> instance of comparing

I don't fix the out of tree vendor driver. sorry.
-
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: GFS, what's remaining

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 04:28:30PM +0100, Alan Cox wrote:
> > That's GFS.  The submission is about a GFS2 that's on-disk incompatible
> > to GFS.
> 
> Just like say reiserfs3 and reiserfs4 or ext and ext2 or ext2 and ext3
> then. I think the main point still stands - we have always taken
> multiple file systems on board and we have benefitted enormously from
> having the competition between them instead of a dictat from the kernel
> kremlin that 'foofs is the one true way'

I didn't say anything agains a particular fs, just that your previous
arguments where utter nonsense.  In fact I think having two or more cluster
filesystems in the tree is a good thing.  Whether the gfs2 code is mergeable
is a completely different question, and it seems at least debatable to
submit a filesystem for inclusion that's still pretty new.

While we're at it I can't find anything describing what gfs2 is about,
what is lacking in gfs, what structual changes did you make, etc..

p.s. why is gfs2 in fs/gfs in the kernel tree?
-
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/1] Hot plug CPU to support physical add of new processors (i386)

[Ashok Raj]

On Thu, Sep 01, 2005 at 10:45:10AM +0200, Andi Kleen wrote:
> Hallo Natalie,
> 
> On Wednesday 31 August 2005 14:13, [EMAIL PROTECTED] wrote:
> > Current IA32 CPU hotplug code doesn't allow bringing up processors that
> > were not present in the boot configuration. To make existing hot plug
> > facility more practical for physical hot plug, possible processors should
> > be encountered during boot for potentual hot add/replace/remove. On ES7000,
> > ACPI marks all the sockets that are empty or not assigned to the
> > partitionas as "disabled". 
> 
> Good idea. In fact I always hated the behaviour of the existing
> hotplug code that assumes all possible CPUs can be hotplugged.
> It would be much nicer to be told be the firmware what CPUs
> are hotpluggable. It would be great if all ia32/x86-64 hotplug capable 
> BIOS behaved like your.
> 

Andi, you are getting mixed up with software only ability to offline with 
hardware eject capability. ACPI indicates ability to hotplug by the presence
of _EJD in the appropriate scope of the object. So ACPI does have ability to 
do what you mention above precicely, but the entire namespace is not known 
upfront since some could be dynamically loaded. Which is why we need to show 
the entire NR_CPUS as hotpluggable. 

Possibly we can keep cpu_possible_map as NR_CPUS only when support for 
PHYSICAL_CPU_HOTPLUG is present, otherwise we can keep it
cloned as cpu_present_map. (we dont have a generic PHYSICAL hotplug CONFIG
option today)

What CONFIG_HOTPLUG_CPU=y indicates is ability to offline a processor from the
kernel. It DOES NOT indicate physical hotpluggablity.  So we dont need any
hardware support (apart arch/kernel support) for this to work. Support
for physical hotplug is indicated via CONFIG_ACPI_HOTPLUG_CPU.

Be aware that suspend/resume folks using CPU hotplug to offline CPUS except
BSP need just the kernel support to offline. BIOS has nothing to do with 
being able to offline a CPU (preferably called as soft-removal).

Cheers,
ashok

-
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][FAT] FAT dirent scan with hin take #3

[OGAWA Hirofumi]

"Machida, Hiroyuki" <[EMAIL PROTECTED]> writes:

> Once concern about global URL in general, it tends to be occupied
> by specific pattern, like accesses from one process or to on dir.
> It prevents to realize locality.
>
> I think it's better to have limitations like;
>   entries for same process would be limited to 2/3
>   entries for same dir would be limited to 1/3

[...]

> Does this mean for each process recording last recent 16
> accesses to FAT file system ? If true, pid would be eliminated.
>
> I guess it's better to record nr_slots for this entry.

The fat_lookup_hint is one per task. And fat_lookup_hint is tracking
the task's access. If access is sequential, it returns the hint, and
if not, it returns 0.  I made the dirty patch just for explaining what
I said.

However, these lookup-hint approaches seems the hack after all
Hhmmm...
-- 
OGAWA Hirofumi <[EMAIL PROTECTED]>



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

 fs/fat/dir.c   |  166 +++--
 fs/fat/inode.c |2 
 2 files changed, 164 insertions(+), 4 deletions(-)

diff -puN fs/fat/dir.c~fat_lookup-hint fs/fat/dir.c
--- linux-2.6.13/fs/fat/dir.c~fat_lookup-hint	2005-09-02 01:04:47.0 +0900
+++ linux-2.6.13-hirofumi/fs/fat/dir.c	2005-09-02 01:06:50.0 +0900
@@ -22,6 +22,148 @@
 #include 
 #include 
 
+#define FAT_LOOKUP_HINT_MAX	16
+
+struct fat_lookup_hint {
+	struct list_head lru_list;
+	pid_t pid;
+	struct super_block *sb;
+	struct inode *dir;
+	loff_t last_pos;
+#define HINT_STATE_RANDOM	1
+	int state;
+};
+
+static spinlock_t fat_lookup_hint_lock = SPIN_LOCK_UNLOCKED;
+static LIST_HEAD(fat_lookup_hint_head);
+static int fat_lookup_hint_count;
+
+#if 0
+static int fat_lkup_hint_init(void)
+{
+	/* replace with kmem_cache */
+	return 0;
+}
+#endif
+
+static inline struct fat_lookup_hint *fat_lkup_hint_alloc(void)
+{
+	struct fat_lookup_hint *hint;
+
+	/* replace with kmem_cache */
+	hint = kmalloc(sizeof(*hint), GFP_KERNEL);
+	if (hint) {
+		INIT_LIST_HEAD(>lru_list);
+		hint->pid = 0;
+		hint->sb = NULL;
+		hint->dir = NULL;
+		hint->last_pos = 0;
+	}
+	return hint;
+}
+
+static inline void fat_lkup_hint_free(struct fat_lookup_hint *hint)
+{
+	/* replace with kmem_cache */
+	BUG_ON(!list_empty(>lru_list));
+	kfree(hint);
+}
+
+void fat_lkup_hint_inval(struct inode *dir)
+{
+	struct super_block *sb = dir->i_sb;
+	struct fat_lookup_hint *hint, *n;
+
+	spin_lock(_lookup_hint_lock);
+	list_for_each_entry_safe(hint, n, _lookup_hint_head, lru_list) {
+		if (hint->sb == sb && hint->dir == dir) {
+			list_del_init(>lru_list);
+			fat_lkup_hint_free(hint);
+			fat_lookup_hint_count--;
+		}
+	}
+	spin_unlock(_lookup_hint_lock);
+}
+
+#define WIN_TOP		(2 * MSDOS_SLOTS * sizeof(struct msdos_dir_entry))
+#define WIN_BOTTOM	(5 * MSDOS_SLOTS * sizeof(struct msdos_dir_entry))
+static loff_t fat_lkup_hint_get(struct inode *dir)
+{
+	struct super_block *sb = dir->i_sb;
+	struct fat_lookup_hint *hint;
+	loff_t pos = 0;
+
+	spin_lock(_lookup_hint_lock);
+	list_for_each_entry(hint, _lookup_hint_head, lru_list) {
+		if (hint->pid == current->pid &&
+		hint->sb == sb &&
+		hint->dir == dir) {
+			if (!(hint->state & HINT_STATE_RANDOM))
+pos = hint->last_pos;
+			break;
+		}
+	}
+	spin_unlock(_lookup_hint_lock);
+	return max(0LL, pos - WIN_TOP);
+}
+
+/* caller must hold dir->i_sem */
+static void fat_lkup_hint_add(struct inode *dir, loff_t pos)
+{
+	struct super_block *sb = dir->i_sb;
+	struct fat_lookup_hint *p, *hint = NULL;
+	loff_t win_start, win_end;
+
+	spin_lock(_lookup_hint_lock);
+	list_for_each_entry(p, _lookup_hint_head, lru_list) {
+		if (p->pid == current->pid) {
+			hint = p;
+			break;
+		}
+	}
+	if (hint == NULL) {
+		if (fat_lookup_hint_count < FAT_LOOKUP_HINT_MAX) {
+			fat_lookup_hint_count++;
+			spin_unlock(_lookup_hint_lock);
+
+			hint = fat_lkup_hint_alloc();
+			if (hint == NULL)
+return;
+			spin_lock(_lookup_hint_lock);
+			/* don't need to recheck hint */
+		} else {
+			struct list_head *p = fat_lookup_hint_head.prev;
+			hint = list_entry(p, struct fat_lookup_hint, lru_list);
+		}
+		hint->pid = current->pid;
+		hint->sb = sb;
+		hint->dir = dir;
+	}
+
+	if (hint->sb != sb || hint->dir != dir) {
+		hint->sb = sb;
+		hint->dir = dir;
+		hint->state |= HINT_STATE_RANDOM;
+	} else {
+		win_start = hint->last_pos - WIN_TOP;
+		win_end = hint->last_pos + WIN_BOTTOM;
+		if (win_start <= pos && pos <= win_end) {
+			hint->state &= ~HINT_STATE_RANDOM;
+			hint->last_pos = pos;
+		} else {
+			/* seems random access */
+			hint->last_pos = pos;
+			hint->state |= HINT_STATE_RANDOM;
+		}
+	}
+	hint->last_pos = pos;
+
+	/* update LRU */
+	list_del(>lru_list);
+	list_add(>lru_list, _lookup_hint_head);
+	spin_unlock(_lookup_hint_lock);
+}
+
 static inline loff_t fat_make_i_pos(struct super_block *sb,
 struct buffer_head *bh,
 struct msdos_dir_entry *de)
@@ -243,13 +385,23 @@ int fat_search_long(struct inode *inode,
 	int 

Re: [PATCH] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Dipankar Sarma]

On Thu, Sep 01, 2005 at 05:48:28PM +0200, Eric Dumazet wrote:
> dentry cache uses sophisticated RCU technology (and prefetching if 
> available) but touches 2 cache lines per dentry during hlist lookup.
> 
> This patch moves d_hash in the same cache line than d_parent and d_name 
> fields so that :
> 
> 1) One cache line is needed instead of two.
> 2) the hlist_for_each_rcu() prefetching has a chance to bring all the 
> needed data in advance, not only the part that includes d_hash.next.
> 
> I also changed one old comment that was wrong for 64bits.
> 
> A further optimisation would be to separate dentry in two parts, one that 
> is mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
> SMP/NUMA but this would need different field placement depending on 32bits 
> or 64bits platform.

Do you have performance numbers that show the benefits ? In the
past, I did try some optimizations like this but found no demonstrable
benefits. If it ain't broken .

Thanks
Dipankar
-
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.13-mm1 - drivers/isdn/i4l/isdn_tty broken

[Damir Perisa]

hi Andrew,
hi Alan,

updating the kernel26mm package for archlinux to 2.6.13-mm1 i found the 
isdn-tty to be broken:

  CC [M]  drivers/isdn/i4l/isdn_tty.o
drivers/isdn/i4l/isdn_tty.c: In function 'isdn_tty_try_read':
drivers/isdn/i4l/isdn_tty.c:71: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:86: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:86: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:88: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:89: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:90: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:91: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:96: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:97: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c: In function 'isdn_tty_readmodem':
drivers/isdn/i4l/isdn_tty.c:134: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:137: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:138: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:141: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:142: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:143: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:144: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c:146: error: 'struct tty_struct' has no member named 
'flip'
drivers/isdn/i4l/isdn_tty.c: In function 'isdn_tty_at_cout':
drivers/isdn/i4l/isdn_tty.c:2372: error: 'struct tty_struct' has no member 
named 'flip'
drivers/isdn/i4l/isdn_tty.c:2403: error: 'struct tty_struct' has no member 
named 'flip'
drivers/isdn/i4l/isdn_tty.c:2418: error: 'struct tty_struct' has no member 
named 'flip'
make[3]: *** [drivers/isdn/i4l/isdn_tty.o] Error 1
make[2]: *** [drivers/isdn/i4l] Error 2
make[1]: *** [drivers/isdn] Error 2
make: *** [drivers] Error 2

greetings,
Damir

Le Thursday 01 September 2005 12:55, Andrew Morton a écrit :
| ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.
|6.13-mm1/
|
| - Included Alan's big tty layer buffering rewrite.  This breaks the
| build on lots of more obscure character device drivers.  Patches
| welcome (please cc Alan).

-- 
  Gentlemen, I want you to know that I am not always right, but I am
  never wrong. -Samuel Goldwyn


pgp3ZbYlWJB6V.pgp
Description: PGP signature

Re: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

[Ashok Raj]

On Wed, Aug 31, 2005 at 05:13:10AM -0700, [EMAIL PROTECTED] wrote:

Hi Natalie,

sorry for the late catchup... 

Just to make sure we use the cpu maps properly here is the current definition
iam not sure if you are breaking any of these assumptions, cause if you do
you will break existing implementations... so pardon for the verbosity.

cpu_possible_map - must include all possible cpus that can ever exist in this
   instance of boot. This map is static, i.e you can grow
   or remove bits without causing confution to the rest of the 
   subsystem. We attempted to change, but there was not much
   in return for the savings, for the complexity we would
   add to make this map dynamic.

cpu_present_map - indicates that these are present and operational. OS
  can decide if they should be brought up or not.

when CONFIG_HOTPLUG_CPU is *not* defined, then cpu_possible_map and 
cpu_present_map are the same. When CONFIG_HOTPLUG_CPU=y, then we extend
cpu_possible_map to cover the range of NR_CPUS, but cpu_present_map still shows
what is real. 

When a physical hotplug happens, cpu_present_map is updated by who ever manages
the physical hotplug. 
> 
> Current IA32 CPU hotplug code doesn't allow bringing up processors that were 
> not present in the boot configuration. 
> To make existing hot plug facility more practical for physical hot plug, 
> possible processors should be encountered 
> during boot for potentual hot add/replace/remove. On ES7000, ACPI marks all 
> the sockets that are empty or not assigned
> to the partitionas as "disabled". The patch allows arrays/masks with APIC 
> info for disabled processors to be 

This sounds like a cluge to me. The correct implementation would be you would 
need some sysmgmt deamon or something that works with the kernel to notify of 
new cpus and populate apicid and grow cpu_present_map. Making an assumption that
disabled APICID are valid for ES7000 sake is not a safe assumption.

> initialized. Then the OS can bring up a processor that was inserted in the 
> socked and brought into configuration 
> during runtime. 
> To test the code, one can boot the system with maxcpu=1 and then bring the 
> rest of the processors up, which was not 
> possible so far (only maxcpus number of nodes were created).
> The patch also makes proc entry for interrupts dynamically change to only 
> show current onlined processors.
> 
> Signed-off-by: Natalie Protasevich  <[EMAIL PROTECTED]>
> ---
> 
>  arch/i386/kernel/acpi/boot.c  |2 ++
>  arch/i386/kernel/irq.c|8 
>  arch/i386/kernel/mpparse.c|4 
>  arch/i386/kernel/smpboot.c|3 ++-
>  arch/i386/mach-default/topology.c |4 ++--
>  kernel/cpu.c  |4 
>  6 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff -puN arch/i386/kernel/acpi/boot.c~hotcpu-i386 
> arch/i386/kernel/acpi/boot.c
> --- linux-2.6.13-rc6-mm2/arch/i386/kernel/acpi/boot.c~hotcpu-i386 
> 2005-08-31 04:17:20.832038600 -0700
> +++ linux-2.6.13-rc6-mm2-root/arch/i386/kernel/acpi/boot.c2005-08-31 
> 04:19:35.259602504 -0700
> @@ -255,9 +255,11 @@ acpi_parse_lapic(acpi_table_entry_header
>  
>   acpi_table_print_madt_entry(header);
>  
> +#ifndef CONFIG_HOTPLUG_CPU
>   /* no utility in registering a disabled processor */
>   if (processor->flags.enabled == 0)
>   return 0;
> +#endif

On same lines, the above config code seems not appropriate. When your platform
needs to hot-add a cpu, find a way to set these flags, you cant break
current behaviour as for a platform quirk!
>  
>   x86_acpiid_to_apicid[processor->acpi_id] = processor->id;
>  
> diff -puN arch/i386/kernel/mpparse.c~hotcpu-i386 arch/i386/kernel/mpparse.c
> --- linux-2.6.13-rc6-mm2/arch/i386/kernel/mpparse.c~hotcpu-i386   
> 2005-08-31 04:17:20.877031760 -0700
> +++ linux-2.6.13-rc6-mm2-root/arch/i386/kernel/mpparse.c  2005-08-31 
> 04:20:49.297347056 -0700
> @@ -125,8 +125,10 @@ static void __init MP_processor_info (st
>   int ver, apicid, cpu, found_bsp = 0;
>   physid_mask_t tmp;
>   
> +#ifndef CONFIG_HOTPLUG_CPU
>   if (!(m->mpc_cpuflag & CPU_ENABLED))
>   return;
> +#endif

Same here... platform quirk!

>  
>   apicid = mpc_apic_id(m, translation_table[mpc_record]);
>  
> @@ -190,11 +192,13 @@ static void __init MP_processor_info (st
>   return;
>   }
>  
> +#ifndef CONFIG_HOTPLUG_CPU
>   if (num_processors >= maxcpus) {
>   printk(KERN_WARNING "WARNING: maxcpus limit of %i reached."
>   " Processor ignored.\n", maxcpus); 
>   return;
>   }
> +#endif
>   num_processors++;
>   ver = m->mpc_apicver;
>  
> diff -puN arch/i386/kernel/smpboot.c~hotcpu-i386 arch/i386/kernel/smpboot.c
> --- linux-2.6.13-rc6-mm2/arch/i386/kernel/smpboot.c~hotcpu-i386   
> 2005-08-31 04:17:20.924024616 

Re: 2.6.13-mm1

[John Stoffel]

Dominik,

So what is the chipset inside the enclosure?  Looking at your output,
the 'Argosy' stuff doesn't tell me anything.  You might have to open
up the case to look in there to find more details.  

Again, check with your vendor and see if there is newer firmware.  And
have you powered up the device without having it plugged into the
system, then plug it in?  What happens then?

John
-
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: State of Linux graphics

[Keith Whitwell]

Ian Romanick wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Paul wrote:



It's other (non-orientation) texture state I had in mind:

- the texel format (OpenGL has over 30 possible texture formats).
- texture size and borders
- the filtering mode (linear, nearest, etc)
- coordinate wrap mode (clamp, repeat, etc)
- env/combine mode
- multi-texture state



Which is why it's such a good target for code generation.  You'd
generate the texel fetch routine, use that to generate the wraped texel
fetch routine, use that to generate the filtered texel fetch routine,
use that to generate the env/combine routines.

Once-upon-a-time I had the first part and some of the second part
written.  Doing just that little bit was slightly faster on a Pentium 3
and slightly slower on a Pentium 4.  I suspect the problem was that I
wasn't caching the generated code smart enough, so it was it trashing
the CPU cache.  The other problem is that, in the absence of an
assembler in Mesa, it was really painful to change the code stubs.


Note that the last part is now partially addressed at least - Mesa has 
an integrated and simple runtime assembler for x86 and sse.  There are 
some missing pieces and rough edges, but it's working and useful as it 
stands.


Keith
-
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: GFS, what's remaining

[Daniel Phillips]

On Thursday 01 September 2005 06:46, David Teigland wrote:
> I'd like to get a list of specific things remaining for merging.

Where are the benchmarks and stability analysis?  How many hours does it 
survive cerberos running on all nodes simultaneously?  Where are the 
testimonials from users?  How long has there been a gfs2 filesystem?  Note 
that Reiser4 is still not in mainline a year after it was first offered, why 
do you think gfs2 should be in mainline after one month?

So far, all catches are surface things like bogus spinlocks.  Substantive 
issues have not even begun to be addressed.  Patience please, this is going 
to take a while.

Regards,

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: [Jackit-devel] Re: jack, PREEMPT_DESKTOP, delayed interrupts?

[Jack O'Quin]

Ingo Molnar <[EMAIL PROTECTED]> writes:

> i suspect the confusion comes from the API hacks i'm using: user-space 
> tracing is started/stopped via:
>
>   gettimeofday(0,1);
>   gettimeofday(0,0);
>
> while 'jackd does not want to be scheduled' flag is switched on/off via:
>
>   gettimeofday(1,1);
>   gettimeofday(1,0);

D'oh!  No wonder I was confused.

Sorry to have mixed up the conversation with erroneous information,
but glad to have the gettimeofday() API clarified.
-- 
  joq
-
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: [SOLVED] USB Storage speed regression since 2.6.12

[DervishD]

Hi Mark :)

 * Mark Lord <[EMAIL PROTECTED]> dixit:
> >the new implementation seems to rewrite the fat on every single
> >write (that's the reason of the slowdown, probably), and since I'm
> >not sure about the quality of the flash memory present in the
> >device, it is very probable that it would wear the first sectors
> >:( So I have to mount it 'async' under 2.6.13; I didn't have to do
> >that on older
> Nearly all flashcard devices (CompactFlash, SD, MMC, ..)
> have built-in wear-leveling in the on-card controller logic.

I know, but this device is a very cheap MP3 player, and I'm
afraid that the builtin flash memory is not good enough to have
leveling circuitry... Just in case, using async is good.

Thanks for the advice :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
-
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: GFS, what's remaining

[Daniel Phillips]

On Thursday 01 September 2005 10:49, Alan Cox wrote:
> On Iau, 2005-09-01 at 03:59 -0700, Andrew Morton wrote:
> > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> >   possibly gain (or vice versa)
> >
> > - Relative merits of the two offerings
>
> You missed the important one - people actively use it and have been for
> some years. Same reason with have NTFS, HPFS, and all the others. On
> that alone it makes sense to include.

I thought that gfs2 just appeared last month.  Or is it really still just gfs?  
If there are substantive changes from gfs to gfs2 then obviously they have 
had practically zero testing, let alone posted benchmarks, testimonials, etc.  
If it is really still just gfs then the silly-rename should be undone.

Regards,

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: State of Linux graphics

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Paul wrote:

> It's other (non-orientation) texture state I had in mind:
> 
> - the texel format (OpenGL has over 30 possible texture formats).
> - texture size and borders
> - the filtering mode (linear, nearest, etc)
> - coordinate wrap mode (clamp, repeat, etc)
> - env/combine mode
> - multi-texture state

Which is why it's such a good target for code generation.  You'd
generate the texel fetch routine, use that to generate the wraped texel
fetch routine, use that to generate the filtered texel fetch routine,
use that to generate the env/combine routines.

Once-upon-a-time I had the first part and some of the second part
written.  Doing just that little bit was slightly faster on a Pentium 3
and slightly slower on a Pentium 4.  I suspect the problem was that I
wasn't caching the generated code smart enough, so it was it trashing
the CPU cache.  The other problem is that, in the absence of an
assembler in Mesa, it was really painful to change the code stubs.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDFziUX1gOwKyEAw8RAhmFAJ9QJ7RTrB2dHV/hwb8ktwLyqKSM4wCdGtbS
b0A2N2jFcLeg8HRm53jMyrI=
=Ygkd
-END PGP SIGNATURE-
-
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: Swap areas lose their signatures after reboot

[Christoph Pleger]

Hello,


> swsusp plays with them... Are you using swsusp?

I am not using swsusp.

I found out that as I had alredy guessed the swap signature
("SWAPSPACE2" at address 0xFF6 of the swap partition) has been deleted
after a reboot.


Christoph
-
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: reboot vs poweroff

[Eric W. Biederman]

Pierre Ossman <[EMAIL PROTECTED]> writes:

> Eric W. Biederman wrote:
>
>>Hmm.  Looking at that bug report it specifies 2.6.11.  Does this
>>problem really happen in 2.6.13?
>>
>>  
>>
>
> I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
> only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
> for 2.6.13 which fixes the problem again.

Thanks.

This is clearly a code path I missed when I was fixing things.

When I made the final acpi change I checked for any other users
of device_suspend and it seems I was blind and missed this one.
Looking again...

The patch in the bug report looks correct.  However it is still
a little incomplete.  In particular the reboot notifier is not
being called, and since not everything has been converted into
using shutdown methods that could lead to some other inconsistent
behavior.

Does anyone have any problems with the patch below?
If not I will send this off to Linus..

Eric


---

 include/linux/reboot.h |1 +
 kernel/power/disk.c|7 ++-
 kernel/sys.c   |   10 ++
 3 files changed, 13 insertions(+), 5 deletions(-)

6afa3b66c6b3b135442886b80913e80f10ae886d
diff --git a/include/linux/reboot.h b/include/linux/reboot.h
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -63,6 +63,7 @@ extern void kernel_restart(char *cmd);
 extern void kernel_halt(void);
 extern void kernel_power_off(void);
 extern void kernel_kexec(void);
+extern int kernel_suspend(void);
 
 /*
  * Emergency restart, callable from an interrupt handler.
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -17,12 +17,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "power.h"
 
 
 extern suspend_disk_method_t pm_disk_mode;
-extern struct pm_ops * pm_ops;
 
 extern int swsusp_suspend(void);
 extern int swsusp_write(void);
@@ -49,14 +49,11 @@ dev_t swsusp_resume_device;
 
 static void power_down(suspend_disk_method_t mode)
 {
-   unsigned long flags;
int error = 0;
 
-   local_irq_save(flags);
switch(mode) {
case PM_DISK_PLATFORM:
-   device_shutdown();
-   error = pm_ops->enter(PM_SUSPEND_DISK);
+   error = kernel_suspend();
break;
case PM_DISK_SHUTDOWN:
kernel_power_off();
diff --git a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -420,6 +421,15 @@ void kernel_power_off(void)
 }
 EXPORT_SYMBOL_GPL(kernel_power_off);
 
+int kernel_suspend(void)
+{
+   notifier_call_chain(_notifier_list, SYS_POWER_OFF, NULL);
+   system_state = SYSTEM_POWER_OFF;
+   device_shutdown();
+   return pm_ops->enter(PM_SUSPEND_DISK);
+}
+EXPORT_SYMBOL_GPL(kernel_suspend);
+
 /*
  * Reboot system call: for obvious reasons only root may call it,
  * and even root needs to set up some magic numbers in the registers

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

Re: 2.6.13-rt3

[Steven Rostedt]

On Thu, 2005-09-01 at 12:24 -0400, Steven Rostedt wrote:
> 
> Note: I compiled this, but I haven't run it yet. I'll run it right after
> I send this note and respond how it worked.
> 

I'm currently sending this message while running the kernel with this
patch.  But I haven't compiled with RT_DEADLOCK_DETECT. Instead I'm
recompiling with my changes to turn on all TRACE_{WARN,BUG} to be real
WARN and BUG without the deadlock detect code.  This way I can run it
without the trace_lock helping.

-- Steve


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

Re: [RFC][CFLART] ipmi procfs bogosity

[Corey Minyard]

Indeed, this function is badly written.  In rewriting, I couldn't find a
nice function for reading integers from userspace, and the proc_dointvec
stuff didn't seem terribly suitable.  So I wrote my own general
function, which I can move someplace else if someone likes.  Patch is
attached.  It should not affect correct usage of this file.

Thank you for pointing this out.

Andrew, can you include this?  Matt, can you test?

-Corey

On Thu, 2005-09-01 at 07:43 +0100, [EMAIL PROTECTED] wrote:
> drivers/char/ipmi/ipmi_poweroff.c::proc_write_chassctrl()
>   a) does sscanf on userland pointer
>   b) does sscanf on array that is not guaranteed to have NUL in it
>   c) interprets input in incredibly cretinous way:
> if strings doesn't start with a decimal number => as if it was "0".
> if it starts with decimal number equal to 0 (e.g. is "-splat") - as if
> it was "0".
> if it starts with decimal number equal to 2 (e.g. is "2FOAD") - as if
> it was "2".
> otherwise - -EINVAL.
>   In any case that doesn't end up with -EINVAL, pretend that entire
> buffer had been written.
> 
> (a) and (b) are immediate bugs; (c) is a valid reason for immediate severe
> LARTing of the pervert who had done _that_ in a user-visible API.
> 
> Note that API _is_ user-visible, so we can't blindly change it - not without
> checking WTF do its users actually write to /proc/ipmi/poweroff_control.
> 
> Could somebody comment on the actual uses of that FPOS?  My preference would
> be to remove the damn thing completely - it's too ugly to live.
The IPMI power control function proc_write_chassctrl was badly
written, it directly used userspace pointers, it assumed that
strings were NULL terminated, and it used the evil sscanf function.
This adds a new function to read integers from userspace and
uses this function to get the integer in question.

Signed-off-by: Corey Minyard <[EMAIL PROTECTED]>

Index: linux-2.6.13/drivers/char/ipmi/ipmi_poweroff.c
===
--- linux-2.6.13.orig/drivers/char/ipmi/ipmi_poweroff.c
+++ linux-2.6.13/drivers/char/ipmi/ipmi_poweroff.c
@@ -40,6 +40,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define PFX "IPMI poweroff: "
 
@@ -545,27 +547,179 @@ static int proc_read_chassctrl(char *pag
 			poweroff_control);
 }
 
+/*
+ * Convert a character to an integer, returning -1 if the character is
+ * not a valid digit for "base".
+ */
+static int convdigit(char ch, int base)
+{
+	int v;
+	if ((ch >= '0') && (ch <= '9'))
+		v = ch - '0';
+	else if ((ch >= 'A') && (ch <= 'Z'))
+		v = ch - 'A' + 10;
+	else if ((ch >= 'a') && (ch <= 'z'))
+		v = ch - 'a' + 10;
+	else
+		return -1;
+	if (v >= base)
+		return -1;
+	return v;
+}
+
+/*
+ * Get a unsigned long from userspace, much like strtoul, but getting
+ * the data from userspace.  This is a little complicated to use, but
+ * is quite flexible.
+ *
+ * @buffer - is a pointer to the start of the user buffer.  Basically,
+ * this will read from buffer+*pos up to buffer+count-1.
+ * @pos - points to the start offset in buffer to start reading at.
+ * pos will be updated to the current location after the scan upon return.
+ * May be NULL, where it is assumed to be zero.
+ * @count - the total buffer length.
+ * @fbase - forces the base.  If this value is zero 0, the base will be
+ * hex if the string starts with 0x, octal if it starts with 0, and
+ * decimal otherwise.
+ * @stop_at_inval - a flag that, if true, causes the function to
+ * return if it already has a valid number and has reached an invalid
+ * character.  "pos" will be set to the offset of the invalid
+ * character upon return.  If false, the entire buffer is expected to
+ * be a single integer value surrounded by optional space characters.
+ *
+ * Unlike strtoul, the value is returned in the "val" parameter.  The
+ * return value of this function is a errno if negative or the number
+ * of characters processed if positive.
+ */
+static ssize_t user_strtoul(const char __user *buffer, loff_t *ppos,
+			size_t count, int fbase, int stop_at_inval,
+			unsigned long *val)
+{
+	unsigned long newval = 0;
+	char  buf[20];
+	unsigned int  rc;
+	unsigned int  i;
+	enum { SC_ST, SC_ST2, SC_AFTPRE, SC_DAT, SC_END } state = SC_ST;
+	int   base = fbase;
+	loff_tstart;
+	loff_tpos;
+
+	if (ppos)
+		pos = *ppos;
+	else
+		pos = 0;
+	start = pos;
+	count -= pos;
+	if (base == 0)
+		base = 10;
+	while (count > 0) {
+		rc = min(count, (size_t) sizeof(buf));
+		if (copy_from_user(buf, buffer + pos, rc))
+			return -EFAULT;
+		for (i = 0; i < rc; i++) {
+			char ch = buf[i];
+			int  chval;
+
+			switch(state) {
+			case SC_ST:
+if (isspace(ch))
+	break;
+if (ch == '0') {
+	if (fbase == 0)
+		base = 8;
+	state = SC_ST2;
+	break;
+}
+goto aftpre;
+
+			case SC_ST2:
+if (ch == 'x') {
+	if (fbase == 0)
+		base = 16;
+	else if (fbase != 16)
+		return 

Re: [PATCH 01/14] GFS: headers

[Jörn Engel]

On Thu, 1 September 2005 22:59:48 +0800, David Teigland wrote:
> 
> We offered to removed this when I explained it before.  It sounds like it
> would give you some comfort so I'll just go ahead and do it barring any
> pleas otherwise.

Please do.  Just have one test machine with an endianness different
from the on-disk format.

Having the on-disk format always be big-endian would serve this
purpose quite well, btw.  But buying an (before-intel) apple machine
also would.

Jörn

-- 
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf 
-
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: State of Linux graphics

[Andreas Hauser]

jg wrote @ Thu, 01 Sep 2005 11:59:33 -0400:

> Legacy hardware and that being proposed/built for the developing world
> is tougher; we have code in hand for existing chips, and the price point
> is even well below cell phones on those devices. They don't have
> anything beyond basic blit and, miracles of miracles, alpha blending.
> These are built on one or two generation back fabs, again for cost.
> And as there are no carriers subsidizing the hardware cost, the real
> hardware cost has to be met, at very low price points.  They don't come
> with the features Allen admires in the latest cell phone chips.

So you suggest, that we, that have capable cards, which can be had for
< 50 Euro here, see that we find something better than X.org to run
on them because X.org is concentrating on < 10 Euro chips?
Somehow i always thought that older xfree86 trees were just fine for them.

Andy
-
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: multiple independent keyboard kernel support

[Vojtech Pavlik]

On Thu, Sep 01, 2005 at 04:48:12PM +0200, Martin Mares wrote:
> Hello!
> 
> > Btw, Aivils Stoss created a nice way to make several X instances have
> > separate keyboards - see the linux-console archives for the faketty
> > driver.
> 
> I haven't looked recently, but when I tried that several years ago,
> the biggest problem was to make two simultaneously running X servers
> not switch off each other's video card I/O ports off :)

That is still the biggest issue. Some modern cards don't need the legacy
I/O for working, however.

> All other things looked solvable with a reasonably small effort.

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

Re: [SOLVED] USB Storage speed regression since 2.6.12

[Mark Lord]

DervishD wrote:
..

the new implementation seems to rewrite the fat on every single write
(that's the reason of the slowdown, probably), and since I'm not sure
about the quality of the flash memory present in the device, it is
very probable that it would wear the first sectors :( So I have to
mount it 'async' under 2.6.13; I didn't have to do that on older


Nearly all flashcard devices (CompactFlash, SD, MMC, ..)
have built-in wear-leveling in the on-card controller logic.
So continuously rewriting the FAT will NOT rewrite the same
on-card physical pages over and over, but rather it will
try to spread those writes out over the entire (available)
span of physical sectors on the device.

So no worries about "wearing out the FAT sectors",
but I'd still use "async" just to reduce the overall
wear and tear regardless.

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

Re: 2.6.13-rt3

[Steven Rostedt]

Ingo,

Here's a patch to fix some of the problems when defining ALL_TASKS_PI.
The pi_setprio logic is currently incorrect.  This should fix that. I
converted ALL_TASKS_PI to a constant number, so that it can be used in
if statements.

-- Steve

Note: I compiled this, but I haven't run it yet. I'll run it right after
I send this note and respond how it worked.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux_realtime_goliath/kernel/rt.c
===
--- linux_realtime_goliath/kernel/rt.c  (revision 314)
+++ linux_realtime_goliath/kernel/rt.c  (working copy)
@@ -104,7 +104,7 @@
  * in the system fall under PI handling. Normally only SCHED_FIFO/RR
  * tasks are PI-handled:
  */
-#define ALL_TASKS_PI
+#define ALL_TASKS_PI 1
 
 #ifdef CONFIG_RT_DEADLOCK_DETECT
 # define __EIP_DECL__ , unsigned long eip
@@ -663,7 +663,7 @@
 
 #endif
 
-#if defined(ALL_TASKS_PI) && defined(CONFIG_RT_DEADLOCK_DETECT)
+#if ALL_TASKS_PI && defined(CONFIG_RT_DEADLOCK_DETECT)
 
 static void
 check_pi_list_present(struct rt_mutex *lock, struct rt_mutex_waiter *waiter,
@@ -674,7 +674,6 @@
 
__raw_spin_lock(_owner->task->pi_lock);
TRACE_WARN_ON_LOCKED(plist_empty(>pi_list));
-   TRACE_WARN_ON_LOCKED(lock_owner(lock));
 
plist_for_each(curr1, _owner->task->pi_waiters) {
w = plist_entry(curr1, struct rt_mutex_waiter, pi_list);
@@ -851,7 +850,7 @@
__raw_spin_lock(>wait_lock);
 
TRACE_BUG_ON_LOCKED(!lock_owner(l));
-   if (rt_task(p) && plist_empty(>pi_list)) {
+   if ((ALL_TASKS_PI || rt_task(p)) && plist_empty(>pi_list)) {
TRACE_BUG_ON_LOCKED(was_rt);
plist_init(>pi_list, prio);
plist_add(>pi_list, 
_owner(l)->task->pi_waiters);
@@ -868,7 +867,7 @@
 * (TODO: this can be unfair to SCHED_NORMAL tasks if they
 *get PI handled.)
 */
-   if (!rt_task(p) && !plist_empty(>pi_list)) {
+   if (!ALL_TASKS_PI && !rt_task(p) && !plist_empty(>pi_list)) {
TRACE_BUG_ON_LOCKED(!was_rt);
plist_del(>pi_list, 
_owner(l)->task->pi_waiters);
plist_del(>list, >wait_list);
@@ -970,7 +969,7 @@
 */
TRACE_BUG_ON_LOCKED(!spin_is_locked(>pi_lock));
TRACE_BUG_ON_LOCKED(!spin_is_locked(>wait_lock));
-#ifndef ALL_TASKS_PI
+#if !ALL_TASKS_PI
if (!rt_task(task)) {
plist_add(>list, >wait_list);
set_lock_owner_pending(lock);
@@ -1083,7 +1082,7 @@
 #endif
trace_special_pid(waiter->ti->task->pid, waiter->ti->task->prio, 0);
 
-#ifdef ALL_TASKS_PI
+#if ALL_TASKS_PI
check_pi_list_present(lock, waiter, old_owner);
 #endif
new_owner = waiter->ti;
@@ -1543,7 +1542,7 @@
list_del_init(>held_list);
 #endif
 
-#ifdef ALL_TASKS_PI
+#if ALL_TASKS_PI
if (plist_empty(>wait_list))
check_pi_list_empty(lock, lock_owner(lock));
 #endif


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

PCI: IRQ 0 for device 0000:00:1f.3 doesn't match PIRQ mask - try pci=usepirqmask

[Martin MOKREJŠ]

Hi,
  what does this message really mean? I did what it suggests and the "IRQ 0"
is gone then. Is that a problem in kernel or should I just use for my hardware
pci=usepirqmask when acpi=off? Should I report somewhere else? Should I care at 
all?
I use 2.6.13 kernel with the patch for pcmcia from here:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=81d4af1340badcd2100c84fbd1bfd13156de41aa

--- acpioff.txt 2005-09-01 17:52:45.787890500 +0200
+++ useirqmask.txt  2005-09-01 17:58:21.294486250 +0200
@@ -16,22 +16,23 @@
 DMI 2.3 present.
 Allocating PCI resources starting at 4000 (gap: 4000:bfff)
 Built 1 zonelists
-Kernel command line: udev root=/dev/hda2 idebus=66 console=ttyS0,57600n8 
console=tty0 pcmcia_core.pc_debug=9 pcmcia.pc_debug=9 sa11xx_core.pc_debug=9 
acpi=off
+Kernel command line: udev root=/dev/hda2 idebus=66 console=ttyS0,57600n8 
console=tty0 pcmcia_core.pc_debug=9 pcmcia.pc_debug=9 sa11xx_core.pc_debug=9 
acpi=off pci=usepirqmask
 ide_setup: idebus=66
 Unknown boot option `sa11xx_core.pc_debug=9': ignoring
 Local APIC disabled by BIOS -- you can enable it with "lapic"
 mapped APIC to d000 (01803000)
 Initializing CPU#0
 CPU 0 irqstacks, hard=c05c1000 soft=c05c
 PID hash table entries: 4096 (order: 12, 65536 bytes)
-Detected 1800.362 MHz processor.
+Detected 1800.261 MHz processor.
 Using tsc for high-res timesource
 Console: colour VGA+ 80x25
 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
 Memory: 1033480k/1048548k available (3061k kernel code, 14316k reserved, 1585k 
data, 192k init, 131044k highmem)
 Checking if this processor honours the WP bit even in supervisor mode... Ok.
-Calibrating delay using timer specific routine.. 3606.04 BogoMIPS (lpj=7212086)
+Calibrating delay using timer specific routine.. 3606.00 BogoMIPS (lpj=7212016)
 Mount-cache hash table entries: 512
 CPU: After generic identify, caps: bfebf9ff    
  
 CPU: After vendor identify, caps: bfebf9ff     
 
@@ -175,7 +176,6 @@
 PCI: Scanning behind PCI bridge :00:1e.0, config 0a0200, pass 1
 PCI: Bus scan for :00 returning with max=0a
 PCI: Using IRQ router PIIX/ICH [8086/248c] at :00:1f.0
-PCI: IRQ 0 for device :00:1f.3 doesn't match PIRQ mask - try 
pci=usepirqmask
 PCI: Found IRQ 11 for device :00:1f.3
 PCI: Sharing IRQ 11 with :00:1f.5
 PCI: Sharing IRQ 11 with :00:1f.6


The HW is ASUS L3C/S laptop. More details on the HW in 
http://bugzilla.kernel.org/show_bug.cgi?id=4889
Please cc: me in replies.
Martin
-
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] nfsacl: Solaris VxFS compatibility fix

[Andreas Gruenbacher]

Trond,

here is a compatibility fix between Linux and Solaris when used with VxFS 
filesystems: Solaris
usually accepts acl entries in any order, but with VxFS it replies with 
NFSERR_INVAL when it
sees a four-entry acl that is not in canonical form. It may also fail with 
other non-canonical
acls -- I can't tell, because that case never triggers: We only send 
non-canonical acls
when we fake up an ACL_MASK entry.

Instead of adding fake ACL_MASK entries at the end, inserting them in the 
correct position makes
Solaris+VxFS happy. The Linux client and server sides don't care about entry 
order. The three-entry-acl
special case in which we need a fake ACL_MASK entry was handled in 
xdr_nfsace_encode. The patch
moves this into nfsacl_encode.

Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>

Index: linux-2.6.13-nfsacl-fix/fs/nfs_common/nfsacl.c
===
--- linux-2.6.13-nfsacl-fix.orig/fs/nfs_common/nfsacl.c
+++ linux-2.6.13-nfsacl-fix/fs/nfs_common/nfsacl.c
@@ -48,43 +48,26 @@ xdr_nfsace_encode(struct xdr_array2_desc
(struct nfsacl_encode_desc *) desc;
u32 *p = (u32 *) elem;
 
-   if (nfsacl_desc->count < nfsacl_desc->acl->a_count) {
-   struct posix_acl_entry *entry =
-   _desc->acl->a_entries[nfsacl_desc->count++];
+   struct posix_acl_entry *entry =
+   _desc->acl->a_entries[nfsacl_desc->count++];
 
-   *p++ = htonl(entry->e_tag | nfsacl_desc->typeflag);
-   switch(entry->e_tag) {
-   case ACL_USER_OBJ:
-   *p++ = htonl(nfsacl_desc->uid);
-   break;
-   case ACL_GROUP_OBJ:
-   *p++ = htonl(nfsacl_desc->gid);
-   break;
-   case ACL_USER:
-   case ACL_GROUP:
-   *p++ = htonl(entry->e_id);
-   break;
-   default:  /* Solaris depends on that! */
-   *p++ = 0;
-   break;
-   }
-   *p++ = htonl(entry->e_perm & S_IRWXO);
-   } else {
-   const struct posix_acl_entry *pa, *pe;
-   int group_obj_perm = ACL_READ|ACL_WRITE|ACL_EXECUTE;
-
-   FOREACH_ACL_ENTRY(pa, nfsacl_desc->acl, pe) {
-   if (pa->e_tag == ACL_GROUP_OBJ) {
-   group_obj_perm = pa->e_perm & S_IRWXO;
-   break;
-   }
-   }
-   /* fake up ACL_MASK entry */
-   *p++ = htonl(ACL_MASK | nfsacl_desc->typeflag);
-   *p++ = htonl(0);
-   *p++ = htonl(group_obj_perm);
+   *p++ = htonl(entry->e_tag | nfsacl_desc->typeflag);
+   switch(entry->e_tag) {
+   case ACL_USER_OBJ:
+   *p++ = htonl(nfsacl_desc->uid);
+   break;
+   case ACL_GROUP_OBJ:
+   *p++ = htonl(nfsacl_desc->gid);
+   break;
+   case ACL_USER:
+   case ACL_GROUP:
+   *p++ = htonl(entry->e_id);
+   break;
+   default:  /* Solaris depends on that! */
+   *p++ = 0;
+   break;
}
-
+   *p++ = htonl(entry->e_perm & S_IRWXO);
return 0;
 }
 
@@ -105,11 +88,28 @@ nfsacl_encode(struct xdr_buf *buf, unsig
.gid = inode->i_gid,
};
int err;
+   struct posix_acl *acl2 = NULL;
 
if (entries > NFS_ACL_MAX_ENTRIES ||
xdr_encode_word(buf, base, entries))
return -EINVAL;
+   if (encode_entries && acl && acl->a_count == 3) {
+   /* Fake up an ACL_MASK entry. */
+   acl2 = posix_acl_alloc(4, GFP_KERNEL);
+   if (!acl2)
+   return -ENOMEM;
+   /* Insert entries in canonical order: other orders seem
+to confuse Solaris VxFS. */
+   acl2->a_entries[0] = acl->a_entries[0];  /* ACL_USER_OBJ */
+   acl2->a_entries[1] = acl->a_entries[1];  /* ACL_GROUP_OBJ */
+   acl2->a_entries[2] = acl->a_entries[1];  /* ACL_MASK */
+   acl2->a_entries[2].e_tag = ACL_MASK;
+   acl2->a_entries[3] = acl->a_entries[2];  /* ACL_OTHER */
+   nfsacl_desc.acl = acl2;
+   }
err = xdr_encode_array2(buf, base + 4, _desc.desc);
+   if (acl2)
+   posix_acl_release(acl2);
if (!err)
err = 8 + nfsacl_desc.desc.elem_size *
  nfsacl_desc.desc.array_len;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: 2.6.13-mm1

[Dominik Karall]

On Thursday 01 September 2005 18:09, John Stoffel wrote:
> > "Dominik" == Dominik Karall <[EMAIL PROTECTED]> writes:
>
> Dominik> When I switch on my external harddisk, which is connected
> Dominik> through usb, the kernel hangs. First time I did that at
> Dominik> bootup there were a lot of backtraces printed on the screen
> Dominik> but they did not find the way in the logfile :/ Now I
> Dominik> switched the drive on while running and everything freezes
> Dominik> after those messages:
>
> Dominik> usb 1-2.2: new high speed USB device using ehci_hcd and address 3
> Dominik> scsi2 : SCSI emulation for USB Mass Storage devices
> Dominik> usb-storage: device found at 3
> Dominik> usb-storage: waiting for device to settle before scanning
> Dominik>   Vendor: ST325082  Model: 3ARev: 3.02
> Dominik>   Type:   Direct-Access  ANSI SCSI revision:
> 00 Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> Dominik> sda: assuming drive cache: write through
> Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
> Dominik> sda: assuming drive cache: write through
>
> Have you updated the firmware on the USB enclosure?  I have one using
> the Prolific chipset for both USB/Firewire and it was crappy until I
> upgraded the firmware on there.  It made all the difference.
>
> Also, can you use this USB enclosure on Windows or another computer?
> And which kernel version are you running?  It's not clear if your on
> 2.6.13-mm1 or some other version.

2.6.13-mm1, as mentioned in subject.
The external hdd worked with 2.6.13-rc6-mm1 and 2.6.13-ck1, which were the 
last versions I ran. Didn't test 2.6.13-rc6-mm2.

> More details would be good too, such as:
>
>   lsusb

Bus 001 Device 004: ID 0840:009c Argosy Research, Inc.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0840 Argosy Research, Inc.
  idProduct  0x009c
  bcdDevice0.01
  iManufacturer   1 Generic
  iProduct2 USB 2.0 Mass Storage Device
  iSerial 3 009C49BD
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   32
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xc0
  Self Powered
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk (Zip)
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  bNumConfigurations  1


dominik


pgpH2pzokhhE8.pgp
Description: PGP signature

[SOLVED] USB Storage speed regression since 2.6.12

[DervishD]

Hi Brice, again :)

 * Brice Goglin <[EMAIL PROTECTED]> dixit:
> Are you mounting this storage with vfat and 'sync' option ?
> IIRC, sync support for vfat was added around 2.6.12, making
> write way slower since it's now really synchron.

That seems to be the problem. Mounting without 'sync' the speed
of transfers is almost infinite ;) but when doing a manual sync it
gives the usual speed of about 800Kb/sec (a little bit less, in
fact...). I've took a look at the ChangeLog for 2.6.12 and I cannot
find any reference to vfat and sync options, but the patch contains a
couple of references to MS_SYNCHRONIZE (or something like that), so
maybe was then when the "-o sync" honouring was added.

I don't feel comfortable with an vfat mounted asynchronously, but
the new implementation seems to rewrite the fat on every single write
(that's the reason of the slowdown, probably), and since I'm not sure
about the quality of the flash memory present in the device, it is
very probable that it would wear the first sectors :( So I have to
mount it 'async' under 2.6.13; I didn't have to do that on older
kernels because the 'sync' was not honoured by vfat, so the fat was
updated asynchronously but the data were written synchronously (not
cached, at least).

Thanks a lot for your help :))

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-mm1

[John Stoffel]

> "Dominik" == Dominik Karall <[EMAIL PROTECTED]> writes:

Dominik> When I switch on my external harddisk, which is connected
Dominik> through usb, the kernel hangs. First time I did that at
Dominik> bootup there were a lot of backtraces printed on the screen
Dominik> but they did not find the way in the logfile :/ Now I
Dominik> switched the drive on while running and everything freezes
Dominik> after those messages:

Dominik> usb 1-2.2: new high speed USB device using ehci_hcd and address 3
Dominik> scsi2 : SCSI emulation for USB Mass Storage devices
Dominik> usb-storage: device found at 3
Dominik> usb-storage: waiting for device to settle before scanning
Dominik>   Vendor: ST325082  Model: 3ARev: 3.02
Dominik>   Type:   Direct-Access  ANSI SCSI revision: 00
Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
Dominik> sda: assuming drive cache: write through
Dominik> SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
Dominik> sda: assuming drive cache: write through

Have you updated the firmware on the USB enclosure?  I have one using
the Prolific chipset for both USB/Firewire and it was crappy until I
upgraded the firmware on there.  It made all the difference.  

Also, can you use this USB enclosure on Windows or another computer?
And which kernel version are you running?  It's not clear if your on
2.6.13-mm1 or some other version.  

More details would be good too, such as:

lsusb
cat /proc/version


What happens if you unplug the drive when the system hangs?  Does it
recover?  And try powering up the enclosure without it being hooked to
anything, then once 30 seconds have passed, hook it upto the Linux box
and see what happens then.  Maybe the power on stuff is doing strange
things.

John
-
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: State of Linux graphics

[Brian Paul]

Alan Cox wrote:

On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:

If the blending is for screen-aligned rects, glDrawPixels would be a 
far easier path to optimize than texturing.  The number of state 
combinations related to texturing is pretty overwhelming.



As doom showed however once you can cut down some of the combinations
particularly if you know the texture orientation is limited you can
really speed it up.

Blending is going to end up using textures onto flat surfaces facing the
viewer which are not rotated or skewed.


Hi Alan,

It's other (non-orientation) texture state I had in mind:

- the texel format (OpenGL has over 30 possible texture formats).
- texture size and borders
- the filtering mode (linear, nearest, etc)
- coordinate wrap mode (clamp, repeat, etc)
- env/combine mode
- multi-texture state

It basically means that the driver may have to do state checks similar 
to this to determine if it can use optimized code.  An excerpt from Mesa:


 if (ctx->Texture._EnabledCoordUnits == 0x1
 && !ctx->FragmentProgram._Active
 && ctx->Texture.Unit[0]._ReallyEnabled == TEXTURE_2D_BIT
 && texObj2D->WrapS == GL_REPEAT
 && texObj2D->WrapT == GL_REPEAT
 && texObj2D->_IsPowerOfTwo
 && texImg->Border == 0
 && texImg->Width == texImg->RowStride
 && (format == MESA_FORMAT_RGB || format == MESA_FORMAT_RGBA)
 && minFilter == magFilter
 && ctx->Light.Model.ColorControl == GL_SINGLE_COLOR
 && ctx->Texture.Unit[0].EnvMode != GL_COMBINE_EXT) {
if (ctx->Hint.PerspectiveCorrection==GL_FASTEST) {
   if (minFilter == GL_NEAREST
   && format == MESA_FORMAT_RGB
   && (envMode == GL_REPLACE || envMode == GL_DECAL)
   && ((swrast->_RasterMask == (DEPTH_BIT | TEXTURE_BIT)
&& ctx->Depth.Func == GL_LESS
&& ctx->Depth.Mask == GL_TRUE)
   || swrast->_RasterMask == TEXTURE_BIT)
   && ctx->Polygon.StippleFlag == GL_FALSE
   && ctx->Visual.depthBits <= 16) {
  if (swrast->_RasterMask == (DEPTH_BIT | TEXTURE_BIT)) {
 USE(simple_z_textured_triangle);
  }
  else {
 USE(simple_textured_triangle);
  }
   }
 [...]

That's pretty ugly.  Plus the rasterization code for textured 
triangles is fairly complicated.


But the other significant problem is the application has to be sure it 
has set all the GL state correctly so that the fast path is really 
used.  If it gets one thing wrong, you may be screwed.  If different 
drivers optimize slightly different paths, that's another problem.


glDrawPixels would be simpler for both the implementor and user.

-Brian
-
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: i2c via686a.c: save at least 0.5k of space by long v[256] -> u16 v[256]

[Greg KH]

On Thu, Sep 01, 2005 at 09:10:14AM +0300, Denis Vlasenko wrote:
> Not tested, but it's rather obvious.

Except you forgot a "Signed-off-by:" line...

> --- linux-2.6.12.src/drivers/i2c/chips/via686a.c.orig Sun Jun 19 16:10:10 2005
> +++ linux-2.6.12.src/drivers/i2c/chips/via686a.c  Tue Aug 30 00:21:39 2005
> @@ -205,7 +205,7 @@ static inline u8 FAN_TO_REG(long rpm, in
>   but the function is very linear in the useful range (0-80 deg C), so 
>   we'll just use linear interpolation for 10-bit readings.)  So, tempLUT 
>   is the temp at via register values 0-255: */
> -static const long tempLUT[] =
> +static const int16_t tempLUT[] =

int16_t is not a proper kernel type.  Do you really mean s16 instead?
Care to redo this?

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: [Hotplug_sig] [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

[Protasevich, Natalie]

> Protasevich, Natalie wrote:
> > > > +#ifdef CONFIG_HOTPLUG_CPU
> > > > +   if (cpu_online(cpu)) {
> > > > +#else
> > > > if (cpu_online(cpu) || !cpu_present(cpu)) {
> > > > +#endif
> > > > ret = -EINVAL;
> > > > goto out;
> > > > }
> > > 
> > > Why this change?  I think the cpu_present check is needed for
> > > ppc64 since it has non-present cpus in sysfs.
> > > 
> > 
> > The new processor was never brought up, its bit is only set in 
> > cpu_possible_map, but not in present map.
> 
> If a cpu is physically present and is capable of being 
> onlined it should be marked in cpu_present_map, please.  This 
> change would break ppc64; can you rework it?
>
OK, that has to be reworked then. That's what probably Shaohua meant
when mentioned that cpu_present_map has to be cleaned up... 
Thanks,
--Natalie
-
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: State of Linux graphics

[Jim Gettys]

On Thu, 2005-09-01 at 09:24 -0600, Brian Paul wrote:

> 
> If the blending is for screen-aligned rects, glDrawPixels would be a 
> far easier path to optimize than texturing.  The number of state 
> combinations related to texturing is pretty overwhelming.
> 
> 
> Anyway, I think we're all in agreement about the desirability of 
> having a single, unified driver in the future.
> 

Certainly for most hardware in the developed world I think we all agree
with this. The argument is about when we get to one driver model, not if
we get there, and not what the end state is.

In my view, the battle is on legacy systems and the very low end, not in
hardware we hackers use that might run Windows Vista or Mac OS X  

I've had the (friendly) argument with Allen Akin for 15 years that due
to reduction of hardware costs we can't presume OpenGL.  Someday, he'll
be right, and I'll be wrong.  I'm betting I'll be right for a few more
years, and I nothing would tickle me pink more to lose the argument
soon...

Legacy hardware and that being proposed/built for the developing world
is tougher; we have code in hand for existing chips, and the price point
is even well below cell phones on those devices. They don't have
anything beyond basic blit and, miracles of miracles, alpha blending.
These are built on one or two generation back fabs, again for cost.
And as there are no carriers subsidizing the hardware cost, the real
hardware cost has to be met, at very low price points.  They don't come
with the features Allen admires in the latest cell phone chips.

I think the onus of proof that we can immediately completely ditch a
second driver framework in favor of everything being OpenGL, even a
software tuned one, is in my view on those who claim that is viable.
Waving one's hands and claiming there are 100 kbyte closed source
OpenGL/ES implementations doesn't cut it in my view, given where we are
today with the code we already have in hand.  So far, the case hasn't
been made.

Existence proof that we're wrong and can move *entirely* to OpenGL
sooner rather than later would be gratefully accepted..
Regards,
Jim


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

Re: [Hotplug_sig] [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

[Nathan Lynch]

Protasevich, Natalie wrote:
> > > +#ifdef CONFIG_HOTPLUG_CPU
> > > + if (cpu_online(cpu)) {
> > > +#else
> > >   if (cpu_online(cpu) || !cpu_present(cpu)) {
> > > +#endif
> > >   ret = -EINVAL;
> > >   goto out;
> > >   }
> > 
> > Why this change?  I think the cpu_present check is needed for 
> > ppc64 since it has non-present cpus in sysfs.
> > 
> 
> The new processor was never brought up, its bit is only set in
> cpu_possible_map, but not in present map. 

If a cpu is physically present and is capable of being onlined it
should be marked in cpu_present_map, please.  This change would break
ppc64; can you rework it?
-
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] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Eric Dumazet]

dentry cache uses sophisticated RCU technology (and prefetching if available) 
but touches 2 cache lines per dentry during hlist lookup.


This patch moves d_hash in the same cache line than d_parent and d_name fields 
so that :


1) One cache line is needed instead of two.
2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed 
data in advance, not only the part that includes d_hash.next.


I also changed one old comment that was wrong for 64bits.

A further optimisation would be to separate dentry in two parts, one that is 
mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
SMP/NUMA but this would need different field placement depending on 32bits or 
64bits platform.


with the patch this time :)

Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>

--- linux-2.6.13/include/linux/dcache.h 2005-08-29 01:41:01.0 +0200
+++ linux-2.6.13-ed/include/linux/dcache.h  2005-09-01 17:22:32.0 
+0200
@@ -88,8 +88,9 @@
 * negative */
/*
 * The next three fields are touched by __d_lookup.  Place them here
-* so they all fit in a 16-byte range, with 16-byte alignment.
+* so they all fit in a cache line.
 */
+   struct hlist_node d_hash;   /* lookup hash list */  
struct dentry *d_parent;/* parent directory */
struct qstr d_name;
 
@@ -103,7 +104,6 @@
void *d_fsdata; /* fs-specific data */
struct rcu_head d_rcu;
struct dcookie_struct *d_cookie; /* cookie, if any */
-   struct hlist_node d_hash;   /* lookup hash list */  
int d_mounted;
unsigned char d_iname[DNAME_INLINE_LEN_MIN];/* small names */
 };

RE: [Hotplug_sig] [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

[Protasevich, Natalie]

> > +#ifdef CONFIG_HOTPLUG_CPU
> > +   if (cpu_online(cpu)) {
> > +#else
> > if (cpu_online(cpu) || !cpu_present(cpu)) {
> > +#endif
> > ret = -EINVAL;
> > goto out;
> > }
> 
> Why this change?  I think the cpu_present check is needed for 
> ppc64 since it has non-present cpus in sysfs.
> 

The new processor was never brought up, its bit is only set in
cpu_possible_map, but not in present map. 

... 
if (boot_error) {
/* Try to put things back the way they were before ...
*/
unmap_cpu_to_logical_apicid(cpu);
cpu_clear(cpu, cpu_callout_map); /* was set here
(do_boot_cpu()) */
cpu_clear(cpu, cpu_initialized); /* was set by
cpu_init() */
cpucount--;
} else {
x86_cpu_to_apicid[cpu] = apicid;
cpu_set(cpu, cpu_present_map);  <=
}
...
So if someone tries to boot a CPU up first time during runtime it always
fails this check.
Thanks,
--Natalie
-
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: FW: [RFC] A more general timeout specification

[Joe Korty]

On Thu, Sep 01, 2005 at 04:32:49PM +0200, Roman Zippel wrote:
> On Thu, 1 Sep 2005, Joe Korty wrote:

> > Kernel time sucks.  It is just a single clock, it may not have
> > the attributes of the clock that the user really wished to use.
> 
> Wrong. The kernel time is simple and effective for almost all users.
> We are talking about _timeouts_ here, what fancy "attributes" does that 
> need that are just not overkill?

The name should be changed from 'struct timeout' to something like
'struct timeevent'.

Joe
-
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] : struct dentry : place d_hash close to d_parent and d_name to speedup lookups

[Eric Dumazet]

dentry cache uses sophisticated RCU technology (and prefetching if available) 
but touches 2 cache lines per dentry during hlist lookup.


This patch moves d_hash in the same cache line than d_parent and d_name fields 
so that :


1) One cache line is needed instead of two.
2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed 
data in advance, not only the part that includes d_hash.next.


I also changed one old comment that was wrong for 64bits.

A further optimisation would be to separate dentry in two parts, one that is 
mostly read, and one writen (d_count/d_lock) to avoid false sharing on 
SMP/NUMA but this would need different field placement depending on 32bits or 
64bits platform.


Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>

Re: State of Linux graphics

[Alan Cox]

On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
> If the blending is for screen-aligned rects, glDrawPixels would be a 
> far easier path to optimize than texturing.  The number of state 
> combinations related to texturing is pretty overwhelming.

As doom showed however once you can cut down some of the combinations
particularly if you know the texture orientation is limited you can
really speed it up.

Blending is going to end up using textures onto flat surfaces facing the
viewer which are not rotated or skewed.

-
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: [Hotplug_sig] [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

[Nathan Lynch]

[EMAIL PROTECTED] wrote:

> +#ifdef CONFIG_HOTPLUG_CPU
> + if (cpu_online(cpu)) {
> +#else
>   if (cpu_online(cpu) || !cpu_present(cpu)) {
> +#endif
>   ret = -EINVAL;
>   goto out;
>   }

Why this change?  I think the cpu_present check is needed for ppc64
since it has non-present cpus in sysfs.

-
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,RFC] Move Cell platform code to arch/powerpc

[Arnd Bergmann]

On Dunnersdag 01 September 2005 16:11, Kumar Gala wrote:

> I'm not 100% sure if this is the right time for introducing a  
> platform into arch/powerpc.  My concern is around that fact that we  
> have not tried to move any "code" from arch/ppc or arch/ppc64 into  
> arch/powerpc and so havent figured out how we are going to do that  
> will not breaking arch/ppc & arch/ppc64.  By introducing cell this
> way we create a dependency between ppc64 and powerpc that might
> constrain decisions we want to make.

I understand that there are good reasons for merging all the headers
first and only then start with the architecture code, that also
was my idea at first.

At least from the Kbuild side, it should not cause trouble
to refer to different architecture directories from
arch/ppc64/kernel/Makefile, that does not introduce any strong
dependency.

For the code itself, we probably need to make substantial changes
at some point, e.g. when we merge arch/powerpc/kernel/setup.c.
However, I don't think it makes much difference wether that
is done while the code resides in arch/ppc64 or arch/powerpc.

> > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
> >
> > --
> >  arch/powerpc/platforms/cell/Makefile |1
> >  arch/ppc64/kernel/Makefile   |5
> >  arch/powerpc/platforms/cell/pic.c|  269 ++
> >  arch/ppc64/kernel/bpa_iic.c  |  270 --
> >  include/asm-powerpc/cell-pic.h   |   62 +
> >  arch/ppc64/kernel/bpa_iic.h  |   62 -
> >  arch/powerpc/platforms/cell/iommu.c  |  377 
> > +++
> >  arch/ppc64/kernel/bpa_iommu.c|  377 
> > ---
> >  arch/powerpc/platforms/cell/iommu.h  |   65 +
> >  arch/ppc64/kernel/bpa_iommu.h|   65 -
> >  arch/powerpc/platforms/cell/nvram.c  |  118 +
> >  arch/ppc64/kernel/bpa_nvram.c|  118 -
> 
> Should pic, iommu, and nvram really be in arch/powerpc/sysdev/

The pic and iommu are defined in the CBE Architecture documents
and different from all others, so I would prefer to keep them
here. Both the internal interrupt controller (IIC) and the
IO page tables are part of the CPU itself, so you will always
see them together with Cell based hardware.

For nvram, you are probably right that it belongs to a more
generic place, as I just wrote in my reply to Murali.

With regard to the arch/powerpc/sysdev/ location for putting
the drivers, I'm not sure if we should first find a better
definition of what goes in there. I remember that some people
did not like the current split between arch/ppc/kernel and
arch/ppc/syslib.
Do you think of arch/powerpc/sysdev/ as a different thing from
the current syslib (e.g. stuff using include/linux/sysdev.h),
or just a different name for the same thing?
 
> Also, since your renaming things any chance there is a better name  
> for iic? (just wondering since its way to similar to what some people  
> use for I2C).

Yes, Ben has expressed the same concern to me, therefore I have renamed
the file to 'pic' instead of 'iic'. However, the architecture is very
specifically calling it IIC, so my idea was to keep the identifiers
with that name, hoping that this does not cause trouble when the files
are clearly marked as belonging to one specific platform.
If you have a better idea for naming it, I can change it of course.

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

Re: 2.6.13-mm1

[Dominik Karall]

On Thursday 01 September 2005 12:55, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13
>-mm1/

When I switch on my external harddisk, which is connected through usb, the 
kernel hangs. First time I did that at bootup there were a lot of backtraces 
printed on the screen but they did not find the way in the logfile :/
Now I switched the drive on while running and everything freezes after those 
messages:

usb 1-2.2: new high speed USB device using ehci_hcd and address 3
scsi2 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
  Vendor: ST325082  Model: 3ARev: 3.02
  Type:   Direct-Access  ANSI SCSI revision: 00
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: assuming drive cache: write through
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: assuming drive cache: write through

dominik


pgpxqTloiyy1L.pgp
Description: PGP signature

Re: State of Linux graphics

[Brian Paul]

Just a few comments...

Keith Packard wrote:


Again, the question is whether a mostly-software OpenGL implementation
can effectively compete against the simple X+Render graphics model for
basic 2D application operations, and whether there are people interested
in even trying to make this happen.


I don't know of anyone who's writen a "2D-centric" Mesa driver, but 
it's feasible.  The basic idea would be to simply fast-path a handful 
of basic OpenGL paths that correspond to the basic X operations:


1. Solid rect fill: glScissor + glClear
2. Blit/copy: glCopyPixels
3. Monochrome glyphs: glBitmap
4. PutImage: glDrawPixels

Those OpenGL commands could be directly implemented with whatever 
mechanism is used in conventional X drivers.  I don't think the 
overhead of going through the OpenGL/Mesa API would be significant.


If Xgl used those commands and you didn't turn on fancy blending, etc. 
the performance should be fine.  If the hardware supported blending, 
that could be easily exposed too.  The rest of OpenGL would go through 
the usual software paths (slow, but better than nothing).


It might be an interesting project for someone.  After one driver was 
done subsequent ones should be fairly easy.




|... However, at the
| application level, GL is not a very friendly 2D application-level API.

The point of OpenGL is to expose what the vast majority of current
display hardware does well, and not a lot more.  So if a class of apps
isn't "happy" with the functionality that OpenGL provides, it won't be
happy with the functionality that any other low-level API provides.  The
problem lies with the hardware.



Not currently; the OpenGL we have today doesn't provide for
component-level compositing or off-screen drawable objects. The former
is possible in much modern hardware, and may be exposed in GL through
pixel shaders, while the latter spent far too long mired in the ARB and
is only now on the radar for implementation in our environment.

Off-screen drawing is the dominant application paradigm in the 2D world,
so we can't function without it while component-level compositing
provides superior text presentation on LCD screens, which is an
obviously increasing segment of the market.


Yeah, we really need to make some progress with off-screen rendering 
in our drivers (either Pbuffers or renderbuffers).  I've been working 
on renderbuffers but we really need that overdue memory manager.




Jon's right about this:  If you can accelerate a given simple function
(blending, say) for a 2D driver, you can accelerate that same function
in a Mesa driver for a comparable amount of effort, and deliver a
similar benefit to apps.  (More apps, in fact, since it helps
OpenGL-based apps as well as Cairo-based apps.)


Yes, you *can*, but the amount of code needed to perform simple
pixel-aligned upright blends is a tiny fraction of that needed to deal
with filtering textures and *then* blending. All of the compositing code
needed for the Render extension, including accelerated (MMX) is
implemented in 10K LOC. Optimizing a new case generally involves writing
about 50 lines of code or so.


If the blending is for screen-aligned rects, glDrawPixels would be a 
far easier path to optimize than texturing.  The number of state 
combinations related to texturing is pretty overwhelming.



Anyway, I think we're all in agreement about the desirability of 
having a single, unified driver in the future.


-Brian
-
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: KLive: Linux Kernel Live Usage Monitor

[Andrea Arcangeli]

On Wed, Aug 31, 2005 at 08:32:00PM +0200, Pavel Machek wrote:
> I'd say "ignore suspend". Machines using it are probably not connected
> to network, anyway, and it stresses system quite a lot.

Currently even if you're not connected to the network it's fine. As long
as you connect sometime. If a packet manages to get sent to the sever in
a window when you're connected your stats will be fine and the seconds
of uptime will be checked against the time it passed on the server.

> I'm afraid that if you compared completely idle system and system running
> one hour a day, suspended for the rest, the first system would likely reach 
> better
> uptime.

That shouldn't be the case. Anyway I can trivially detect the suspended
systems, so if you want I can add a tag like "suspended" on the right of
the table (in the future we can add filters in the main page so you can
filter out the archs you don't want, smp etc..).
-
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]reconfigure MSI registers after resume

[Nguyen, Tom L]

On Wednesday, August 31, 2005 2:44 PM Greg KH wrote:
>>On Thu, Aug 18, 2005 at 01:35:46PM +0800, Shaohua Li wrote:
>> Hi,
>> It appears pci_enable_msi doesn't reconfigure msi registers if it
>> successfully look up a msi for a device. It assumes the data and
address
>> registers unchanged after calling pci_disable_msi. But this isn't
always
>> true, such as in a suspend/resume circle. In my test system, the
>> registers unsurprised become zero after a S3 resume. This patch fixes
my
>> problem, please look at it. MSIX might have the same issue, but I
>> haven't taken a close look.

> Tom, any comments on this?

In the cases of suspend/resume, a device driver needs to restore its PCI
configuration space registers, which include the MSI/MSI-X capability
structures if a device uses MSI/MSI-X. I think reconfiguring MSI
data/address each time a driver calls pci_enable_msi may not be
necessary.

Thanks,
Tom
-
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: reboot vs poweroff

[Pierre Ossman]

Eric W. Biederman wrote:

>Hmm.  Looking at that bug report it specifies 2.6.11.  Does this
>problem really happen in 2.6.13?
>
>  
>

I first noticed it in 2.6.11. It was fixed sometime during 2.6.13-rc
only to be killed of again in 2.6.13-rc7. The bugzilla now has a patch
for 2.6.13 which fixes the problem again.

Rgds
Pierre

-
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] aacraid: 2.6.13 aacraid bad BUG_ON fix

[Mark Haverkamp]

This was noticed by Doug Bazamic and the fix found by Mark Salyzyn at
Adaptec.

There was an error in the BUG_ON() statement that validated the
calculated fib size which can cause the driver to panic.

Signed-off-by: Mark Haverkamp <[EMAIL PROTECTED]>

--- a/drivers/scsi/aacraid/aachba.c 2005-08-28 19:41:01.0 -0400
+++ b/drivers/scsi/aacraid/aachba.c 2005-09-01 08:05:29.118304656 -0400
@@ -968,7 +968,7 @@
fibsize = sizeof(struct aac_read64) + 
((le32_to_cpu(readcmd->sg.count) - 1) * 
 sizeof (struct sgentry64));
-   BUG_ON (fibsize > (sizeof(struct hw_fib) - 
+   BUG_ON (fibsize > (dev->max_fib_size - 
sizeof(struct aac_fibhdr)));
/*
 *  Now send the Fib to the adapter

-- 
Mark Haverkamp <[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: FW: [RFC] A more general timeout specification

[Roman Zippel]

Hi,

On Thu, 1 Sep 2005, Joe Korty wrote:

> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
> 
> > You still didn't explain what's the point in choosing
> > different clock sources for a _timeout_.
> 
> Well, if CLOCK_REALTIME is set forward by a minute,
> timers & timeout specified against that clock will expire
> a minute earlier than expected.

That just rather suggests that the pthread API is broken as usual.
(No other possible user was mentioned so far.)

>  That doesn't happen with
> CLOCK_MONOTONIC.  Applications should have the ability
> to select what they want to happen in this case (ie,
> whether the timeout/timer has to happen at a particular
> wall-clock time, say 2pm, or if the interval aspects of
> the timer/timeout are more important).  Applications
> get this if they have the ability to specify the clock
> their timer or timeout is specified against.

So setup a timer that goes off at that time and interrupts the operation. 
There is no need to overload the operation itself with an overly complex 
timeout specification.

> The purpose of CLOCK_MONOTONIC is to provide an even,
> unchanging progression of advancing time. That is, any two
> intervals on this time-line of the same measured length
> actually represent, as close as possible, the same length
> of time.
> 
> CLOCK_MONOTONIC should get adjustments only to bring its
> frequency back into line (but currently gets more than this
> in Linux).  CLOCK_REALTIME should and does get adjustments
> for frequency and then gets further, temporary speedups
> or slowdown to bring its absolute value back into line.

That would make a rather useless CLOCK_MONOTONIC. The basic problem is 
that it would be very hard to specify the time without exactly knowing 
it's frequency, the larger the time difference the larger the time skew 
would be compared to CLOCK_REALTIME and without an atomic clock in your 
computer you have no way of knowing which one is "real".
So in practice it's easier to advance CLOCK_MONOTONIC/CLOCK_REALTIME 
equally and only apply time jumps to CLOCK_REALTIME.

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

Re: KLive: Linux Kernel Live Usage Monitor

[Andrea Arcangeli]

On Wed, Aug 31, 2005 at 08:20:51PM +0200, Pavel Machek wrote:
> Well, you could remove everything that is not valid kernel text from 
> backtrace.

What if the corruption wrote the ssh key inside a the kernel text?

As suggested before, I suspect the only way would be to make it
optional.

> Oh and you probably want to somehow identify modified kernels.
> Otherwise if I do some development on 2.3.4-foo5, you'll get many oopsen
> caused by my development code... it is getting complex.

Agreed, however there's no way to do it reliably, since if you apply a
patch before compiling the kernel, there's no way to know it unless we
do a md5sum of the whole source at every compilation and that would be
too slow ;)

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

HELP: unable to use I-MATE SP3 as USB (HTC) gprs modem

[genoni]

Hi,

I've got am I-mate SP3, running wince.

It works very well with every linux 2.6 kernel I tried (actually  2.6.13,
using the ipaq driver and synce. The phone is accessed trought ttyUSB0.

dmesg shows:

ipaq 1-1:1.0: PocketPC PDA converter detected
usb 1-1: PocketPC PDA converter now attached to ttyUSB0


in /proc/bus/usb/devices I read:

T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 24 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  3
P:  Vendor=0bb4 ProdID=0a51 Rev= 0.00
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ipaq
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
C:  #Ifs= 1 Cfg#= 2 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
C:  #Ifs= 1 Cfg#= 3 Atr=c0 MxPwr=  2mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms


But I have a big problem.

I should use as an USB gprs modem.

Since it is possible to configure it to be a (HTC) modem, using it's menu,
when I enable it to act as a modem on the usb port the content of
/proc/bus/usb/devices who refers to the phone changes to: I


T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 37 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0bb4 ProdID=00cf Rev= 0.90
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=02(comm.) Sub=ff Prot=ff Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=80ms

The hotplug does not work anymore using the ipaq driver (as I exspected),
and the device is not attacched to ttyUSB0.

I read Cls=02(comm.). I suppose there should be a way to use something
like cdc-acm driver. Unfortunatelly this driver does not seem to like my
phone.
All I get is a sad:

usb 1-1: new full speed USB device using uhci_hcd and address 39


Is there a way to solve this problem and to use I-mate SP3 smartphone as
gprs modem for linux or should I surrender?

Thanx in advance

Luigi Genoni



-
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: GFS, what's remaining

[Lars Marowsky-Bree]

On 2005-09-01T16:28:30, Alan Cox <[EMAIL PROTECTED]> wrote:

> Competition will decide if OCFS or GFS is better, or indeed if someone
> comes along with another contender that is better still. And competition
> will probably get the answer right.

Competition will come up with the same situation like reiserfs and ext3
and XFS, namely that they'll all be maintained going forward because of,
uhm, political constraints ;-)

But then, as long as they _are_ maintained and play along nicely with
eachother (which, btw, is needed already so that at least data can be
migrated...), I don't really see a problem of having two or three.

> The only thing that is important is we don't end up with each cluster fs
> wanting different core VFS interfaces added.

Indeed.


Sincerely,
Lars Marowsky-Brée <[EMAIL PROTECTED]>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

-
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: reboot vs poweroff (was: Linux 2.6.13)

[Eric W. Biederman]

Nigel Cunningham <[EMAIL PROTECTED]> writes:

> On Thu, 2005-09-01 at 22:32, Pierre Ossman wrote:
>> Meelis Roos wrote:
>> > 
>> > It's OK then - I'm not using any suspend and I had a problem that my
>> > machine powered down instead of reboot. The patch that went into 2.6.13
>> > after rc7 fixed it for me. So the current tree is OK for me and if it's
>> > OK for you too after suspend2 changes then this case can probably be
>> > closed.
>> > 
>> 
>> I'm still having problems with this patch. Both swsusp and swsusp2 are
>> affected. Perhaps the fix Nigel did needs to be done to swsusp aswell?
>
> Yes, it does need modifying. I'll leave it to Pavel to do that though as
> he's more familiar with the intricacies of that code than I am.

Are suspend and suspend2 not calling kernel_power_off()?

I am not certain about that code path but I worked hard in the lead
up to 2.6.13 to get everyone on the same page so we did not have
strange reboot issues on one code path and not on another.

It is possible that the code path in suspend is so strange I did not
recognize it.  How do you initiate a S4 power off?

I can understand suspend2 having problems as it isn't merged but suspend
is merged isn't it?

Hmm.  Looking at that bug report it specifies 2.6.11.  Does this
problem really happen in 2.6.13?

Eric
-
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: FW: [RFC] A more general timeout specification

[Daniel Walker]

On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
> Hi,
> 
> On Thu, 1 Sep 2005, Joe Korty wrote:
> 
> > > When you convert a user time to kernel time you can
> > > automatically validate
> > 
> > Kernel time sucks.  It is just a single clock, it may not have
> > the attributes of the clock that the user really wished to use.
> 
> Wrong. The kernel time is simple and effective for almost all users.
> We are talking about _timeouts_ here, what fancy "attributes" does that 
> need that are just not overkill?


How do you feel about posix clocks ?

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: FW: [RFC] A more general timeout specification

[Daniel Walker]

On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
> Hi,
> 
> On Thu, 1 Sep 2005, Joe Korty wrote:
> 
> > > When you convert a user time to kernel time you can
> > > automatically validate
> > 
> > Kernel time sucks.  It is just a single clock, it may not have
> > the attributes of the clock that the user really wished to use.
> 
> Wrong. The kernel time is simple and effective for almost all users.
> We are talking about _timeouts_ here, what fancy "attributes" does that 
> need that are just not overkill?

Or rather, posix timers ?

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][RFC] vm: swap prefetch

[Thomas Schlichter]

Hi Con!

Am Donnerstag, 1. September 2005 15:46 schrieb Con Kolivas:
> Here is a working swap prefetching patch for 2.6.13. I have resuscitated
> and rewritten some early prefetch code Thomas Schlichter did in late 2.5 to
> create a configurable kernel thread that reads in swap from ram in reverse
> order it was written out. It does this once kswapd has been idle for a
> minute (implying no current vm stress). This patch attached below is a
> rollup of two patches the current versions of which are here:
>
> http://ck.kolivas.org/patches/swap-prefetch/
>
> These add an exclusive_timer function, and the patch that does the swap
> prefetching. I'm posting this rollup to lkml to see what the interest is in
> this feature, and for people to test it if they desire. I'm planning on
> including it in the next -ck but wanted to gauge general user opinion for
> mainline. Note that swapped in pages are kept on backing store (swap),
> meaning no further I/O is required if the page needs to swap back out.

I am (and some of my friends are) still interested in this functionality, so 
I'm definitly going to test your improved patch, of course. By the way, I'm 
quite happy that you came up with this new version of swap-prefetching, 
because I didn't and still don't have the time to develop or maintain it 
more...

So thanks for your good work, and keep on helping Linux-Desktop-Users! :-)

  Thomas
-
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: Swap areas lose their signatures after reboot

[Pavel Machek]

Hi!

> We have a machine with much RAM and 4 SCSI disks. We want to have 8 GB
> of Swap space. So I partitioned the hard disks with one swap partition
> of 2GB on every disk. But only the swap partition of the first disk can
> be used after a reboot; the other three swap partitions lose their swap
> signature.
> 
> When I call "swapon -a" manually, it says "Invalid argument" for these
> three partitions. After executing "mkswap" on them, "swapon -a" works
> fine. But I have to call "mkswap" after every reboot.
> 
> What happens with the swap signatures during reboot?

swsusp plays with them... Are you using swsusp?
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

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

Re: PREEMPT_RT with e1000

[Daniel Walker]

On Thu, 2005-09-01 at 07:43 -0700, Daniel Walker wrote:
> On Thu, 2005-09-01 at 09:10 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > 
> > > It looks like Gigabit Ethernet is still having some problems. This is 
> > > with the e1000 driver. If I remove all the qdisc_restart changes it 
> > > starts to work the warning below goes away, but it has 
> > > smp_processor_id warnings.
> > 
> > btw., what does "problems" mean, precisely - does it not work at all, or 
> > does it produce the lockup under certain loads?
> 
> It hangs when I un'tar a big archive over NFS, but otherwise it works
> slowly . The "possible softlockup" must mean it's doing some major
> looping in/around qdisc_restart() . 

Another note, the possible softlockup warning is disconnected from the
actual lockup . I get several possible softlockup warnings then nothing,
then a hang with no warning. 

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: KLive: Linux Kernel Live Usage Monitor

[Pavel Machek]

Hi!

> > [..] combined 
> > with an automatic oops/panic/bug-report this would be _very_ useful I think.
> 
> That would be nice addition IMHO. It'll be more complex since it'll
> involve netconsole dumping and passing the klive session to the kernel
> somehow (userland would be too unreliable to push the oops to the
> server). The worst part is that oops dumping might expose random kernel
> data (it could contain ssh keys as well), so I would either need to
> purify the stack/code/register lines making the oops quite useless, or
> not to show it at all (and only to show the count of the oopses
> publically). A parameter could be used to tell the kernel if the whole
> oops should be sent to the klive server or if only the notification an
> oops should be sent (without sending the payload with potentially
> sensitive data inside).

Well, you could remove everything that is not valid kernel text from backtrace.

That should make ssh keys non-issue and still provide usefull information.

Oh and you probably want to somehow identify modified kernels.
Otherwise if I do some development on 2.3.4-foo5, you'll get many oopsen
caused by my development code... it is getting complex.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
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: GFS, what's remaining

[Alan Cox]

> That's GFS.  The submission is about a GFS2 that's on-disk incompatible
> to GFS.

Just like say reiserfs3 and reiserfs4 or ext and ext2 or ext2 and ext3
then. I think the main point still stands - we have always taken
multiple file systems on board and we have benefitted enormously from
having the competition between them instead of a dictat from the kernel
kremlin that 'foofs is the one true way'

Competition will decide if OCFS or GFS is better, or indeed if someone
comes along with another contender that is better still. And competition
will probably get the answer right.

The only thing that is important is we don't end up with each cluster fs
wanting different core VFS interfaces added.

Alan

-
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: [git tree] DRM tree for 2.6.14 (fwd)

[Pavel Machek]

Hi!

> commit 282a16749ba63256bcdce2766817f46aaac4dc20
> Author: Dave Airlie <[EMAIL PROTECTED](none)>
> Date:   Sun Aug 7 15:43:54 2005 +1000
> 
> drm: add savage driver
> 
> Add driver for savage chipsets.
> 
> From: Felix Kuehling
> Signed-off-by: Dave Airlie <[EMAIL PROTECTED]>


Is it the one that breaks suspend in suse kernels? It tends to load
okay even on machines without savage hw, and then explodes on suspend...

Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
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: KLive: Linux Kernel Live Usage Monitor

[Pavel Machek]

Hi!

> > tiny C program or a shell script using netcat.
> > 
> > echo "Reporting boot: "
> > (echo "BOOT:"_(cat /etc/lum-serial)":"_(uname -a)"::") | nc -u -w 10
> > testhost.example.com 7658
> 
> Client completely stateless couldn't get right suspend to disk as far as
> I can tell.

I'd say "ignore suspend". Machines using it are probably not connected
to network, anyway, and it stresses system quite a lot.

I'm afraid that if you compared completely idle system and system running
one hour a day, suspended for the rest, the first system would likely reach 
better
uptime.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
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: Telecom Clock driver for MPCBL0010 ATCA compute blade.

[Pavel Machek]

Hi!

> The following is a driver I would like to see included in the base kernel.
> 
> It allows OS controll of a device that synchronizes signaling hardware across 
> a ATCA chassis.
> 
> The telecom clock hardware doesn't interact much with the operating system, 
> and is controlled 
> via registers in the FPGA on the hardware.  It is hardware that is unique to 
> this computer.

Now... it is probably not feasible, but: why does it need special interface to 
userland?
Could not it simply act as yet another timesource, and be controlled via 
get/settimeofday?

Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
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] mips: remove typedef from struct flock

[Yoichi Yuasa]

Hi,

This patch has fixed the following warning about MIPS.
Please apply.

Yoichi

  CC  arch/mips/kernel/offset.s
In file included from include/linux/fcntl.h:4,
 from include/linux/fs.h:689,
 from include/linux/mm.h:15,
 from arch/mips/kernel/offset.c:15:
include/asm/fcntl.h:53: warning: useless keyword or type name in empty 
declaration

Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>

diff -urN -X dontdiff mm1-orig/include/asm-mips/fcntl.h 
mm1/include/asm-mips/fcntl.h
--- mm1-orig/include/asm-mips/fcntl.h   2005-09-01 21:58:47.0 +0900
+++ mm1/include/asm-mips/fcntl.h2005-09-01 23:38:18.0 +0900
@@ -42,7 +42,7 @@
 
 #ifndef __mips64
 
-typedef struct flock {
+struct flock {
short   l_type;
short   l_whence;
__kernel_off_t l_start;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.13-mm1

[Adrian Bunk]

On Thu, Sep 01, 2005 at 07:22:53AM -0700, Martin J. Bligh wrote:
>...
> Lots of this:
> 
> In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
>  from fs/xfs/xfs.h:35,
>  from fs/xfs/xfs_rtalloc.c:37:
> fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
> In file included from fs/xfs/xfs_rtalloc.c:50:
> fs/xfs/xfs_bmap_btree.h:65:21: warning: "__LITTLE_ENDIAN" is not defined
>   CC  fs/xfs/xfs_acl.o
> In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
>  from fs/xfs/xfs.h:35,
>  from fs/xfs/xfs_acl.c:33:
> fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
> 
> Can't see anything obvious to cause that.
>...

They are there since we added -Wundef to the CFLAGS several -mm kernels 
ago.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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,RFC] Move Cell platform code to arch/powerpc

[Arnd Bergmann]

On Dunnersdag 01 September 2005 06:22, Murali N Iyer wrote:
> Architecture "cell" seems to be fine. What is your thought on supporting
> multiple different hardware configurations under cell. I think this patch
> has been tested only in CPBW hardware.  For example "+++

My general idea about future Cell based products is that we make the
changes to the platform code at the time we add new code. Of course,
a number of companies are working on designs that I have no insight in,
so I'll just wait what comes, but at least I've tried to make it
easy to add the stuff that I know about.

> linux-cg/arch/ppc64/kernel/bpa_nvram.c" assumes one particular hardware
> which may not be true for different hardware configurations.

Yes, this one is a bit odd. On the one hand, it is very generic and could
be used for any future open firmware or flat device tree based system
(even non-PowerPC). On the other hand, it works only on one particular
board design currently.

I don't really care about where this is put, ranging from:

arch/{ppc64,powerpc}/kernel/of_nvram.c, meaning that everyone using the
flat device tree can just add an "nvram" node that will work with
this driver.

arch/powerpc/platforms/cell/cellblade_nvram.c, to keep it specific to
the one design that we have, assuming that future Cell based
designs will use something else.

Arnd <><
-
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] MPC8xx PCMCIA driver

[Marcelo Tosatti]

Thu, Sep 01, 2005 at 10:53:19AM +0200, Dominik Brodowski wrote:
> Hi,
> 
> On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
> > Russell: The driver is using pccard_nonstatic_ops for card window
> > management, even though the driver its marked SS_STATIC_MAP (using
> > mem->static_map).
> 
> This is obviously broken. Where does it fail if pccard_static_ops is used?

IIRC pcmcia_request_io() fails to dynamically allocate IO windows for PCMCIA 
cards because find_io_region returns NULL. 

OTOH, as Magnus noted, the memory windows are static:

 * Because of the lacking offset register we must map the whole card.
 * We assign each memory window PCMCIA_MEM_WIN_SIZE address space.
 * Make sure there is (PCMCIA_MEM_WIN_SIZE * PCMCIA_MEM_WIN_NO
 * * PCMCIA_SOCKETS_NO) bytes at PCMCIA_MEM_WIN_BASE.
 * The i/o windows are dynamically allocated at PCMCIA_IO_WIN_BASE.
 * They are maximum 64KByte each...

socket[i].socket.features = SS_CAP_PCCARD | SS_CAP_MEM_ALIGN | 
SS_CAP_STATIC_MAP;
socket[i].socket.io_offset = 0;

> > +typedef struct  {
> > +   u_int regbit;
> > +   u_int eventbit;
> > +} event_table_t;
> 
> No typedefs, please.

OK, will fix.
-
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 01/14] GFS: headers

[David Teigland]

On Thu, Sep 01, 2005 at 04:19:34PM +0200, Arjan van de Ven wrote:

> > +/* Endian functions */
> 
> e again why?? 
> Why is this a compiletime hack?
> Either you care about either-endian on disk, at which point it has to be
> a runtime thing, or you make the on disk layout fixed endian, at which
> point you really shouldn't abstract be16_to_cpu etc any further!

Again, on-disk is fixed little endian, so we have for example:

#define gfs2_32_to_cpu le32_to_cpu
#define cpu_to_gfs2_32 cpu_to_le32

To _test_ and _verify_ the endian-handling of the code we can
#define GFS2_ENDIAN_BIG which switches the above to:

#define gfs2_32_to_cpu to be32_to_cpu
#define cpu_to_gfs2_32 to cpu_to_be32

We offered to removed this when I explained it before.  It sounds like it
would give you some comfort so I'll just go ahead and do it barring any
pleas otherwise.

Dave

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

Re: 2.6.13-mm1

[Alan Cox]

On Thu, Sep 01, 2005 at 07:22:53AM -0700, Martin J. Bligh wrote:
> -   if (count > (TTY_FLIPBUF_SIZE - tty->flip.count))
> -   count = TTY_FLIPBUF_SIZE - tty->flip.count;
> -
> +   count = tty_buffer_request_room(tty, N_INBUF);
> +   

Should be "int count = " yes

> /* If flip is full, just reschedule a later read */
> if (count == 0) {
> poll_mask |= HVC_POLL_READ;
> 
> shouldn't be deleting the declaration of count. 
> and possibly the "flip removal" was incomplete (line 636) ???

Yep. You can remove the tty->flip.count test or use count, but at that
point count is guaranteed to be > 0 I believe. Fixed both in my tree will
push a new diff to Andre soon.

Also if you are tidying up all the 'read 64 chars and take a break' stuff
should just go away. The kernel will buffer large chunks of data for you
now. In the ideal case if you know the total pending space you can do

int len = tty_buffer_request_room(tty, len)

and it'll look to kmalloc a big enough buffer for you if the buffer pool
isn't suitable. Even if that fails (its a hint) the tty layer will split the
data across multiple smaller buffers for you when you use tty_insert_flip_*

So you should be able to just ram data at it as it comes off the hvc.

Alan

-
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/1] Hot plug CPU to support physical add of newprocessors (i386)

[Protasevich, Natalie]

> Hi,
> On Wed, 2005-08-31 at 20:13 +0800, 
> [EMAIL PROTECTED] wrote:
> > Current IA32 CPU hotplug code doesn't allow bringing up processors 
> > that were not present in the boot configuration.
> > To make existing hot plug facility more practical for physical hot 
> > plug, possible processors should be encountered during boot for 
> > potentual hot add/replace/remove. On ES7000, ACPI marks all the 
> > sockets that are empty or not assigned to the partitionas as 
> > "disabled". The patch allows arrays/masks with APIC info 
> for disabled 
> > processors to be initialized. Then the OS can bring up a processor 
> > that was inserted in the socked and brought into 
> configuration during 
> > runtime.
> > To test the code, one can boot the system with maxcpu=1 and 
> then bring 
> > the rest of the processors up, which was not possible so far (only 
> > maxcpus number of nodes were created).
> > The patch also makes proc entry for interrupts dynamically 
> change to 
> > only show current onlined processors.
> Could we clean up the cpu_present_map a bit, like IA64 does? 
> Eg, if a new CPU is inserted, we allocated cpu id for it and 
> set cpu_present_map.
> Current alloc_cpu_id is just a workaround for suspend/resume 
> use, but isn't ok for physical cpu hotplug to me.
> 
> Thanks,
> Shaohua
> 
Sure, but this looks like independent task from the case I have with
ES7000. We don't have ACPI add/eject methods in AML to bring up new
processors so far (also thinking of implementing them). The IA64 code
also disregards the disabled processors, but ES7000 hot plug mechanism
only supports and relies on this deterministic method of topologically
pre-allocating APIC IDs by the platform.
Thanks,
--Natalie
-
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/1] Ptrace - i386: fix "syscall audit" interaction with singlestep

[Blaisorblade]

On Wednesday 31 August 2005 04:02, Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
> > From: Bodo Stroesser <[EMAIL PROTECTED]>, Paolo
> > 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> CC: Roland McGrath
> > <[EMAIL PROTECTED]>
> >
> > Avoid giving two traps for singlestep instead of one, when syscall
> > auditing is enabled.
> >
> > In fact no singlestep trap is sent on syscall entry, only on syscall
> > exit, as can be seen in entry.S:
> >
> > # Note that in this mask _TIF_SINGLESTEP is not tested !!! <<
> > testb
> > $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),TI_flags(%ebp) jnz
> > syscall_trace_entry
> > ...
> > syscall_trace_entry:
> > ...
> > call do_syscall_trace
> >
> > But auditing a SINGLESTEP'ed process causes do_syscall_trace to be
> > called, so the tracer will get one more trap on the syscall entry path,
> > which it shouldn't.
> >
> > This does not affect (to my knowledge) UML, nor is critical, so this
> > shouldn't IMHO go in 2.6.13.
> >
> > Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]>
> > ---
> >
> >  linux-2.6.git-paolo/arch/i386/kernel/ptrace.c |   15 +--
> >  1 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff -puN arch/i386/kernel/ptrace.c~sysaudit-singlestep-non-umlhost
> > arch/i386/kernel/ptrace.c ---
> > linux-2.6.git/arch/i386/kernel/ptrace.c~sysaudit-singlestep-non-umlhost 
> > 2
> >005-07-26 20:22:40.0 +0200 +++
> > linux-2.6.git-paolo/arch/i386/kernel/ptrace.c   2005-07-26
> > 20:23:44.0 +0200 @@ -683,8 +683,19 @@ void
> > do_syscall_trace(struct pt_regs *re
> > /* do the secure computing check first */
> > secure_computing(regs->orig_eax);
> >
> > -   if (unlikely(current->audit_context) && entryexit)
> > -   audit_syscall_exit(current, AUDITSC_RESULT(regs->eax), 
> > regs->eax);
> > +   if (unlikely(current->audit_context)) {
> > +   if (entryexit)
> > +   audit_syscall_exit(current, AUDITSC_RESULT(regs->eax), 
> > regs->eax);
> > +
> > +   /* Debug traps, when using PTRACE_SINGLESTEP, must be sent only
> > +* on the syscall exit path. Normally, when TIF_SYSCALL_AUDIT is
> > +* not used, entry.S will call us only on syscall exit, not
> > +* entry ; so when TIF_SYSCALL_AUDIT is used we must avoid
> > +* calling send_sigtrap() on syscall entry.
> > +*/
> > +   else if (is_singlestep)
> > +   goto out;
> > +   }

> This appears to be a UML patch,
No, absolutely.
> applied to x86, which has no 
> `is_singlestep'.

It is a x86 patch, is_singlestep just comes from later patches (in fact -mm 
has built because that var is created in later patches (about SYSEMU) from 
me).

I took this from one of your mail notices:

ptrace-i386-fix-syscall-audit-interaction-with-singlestep.patch
uml-support-ptrace-adds-the-host-sysemu-support-for-uml-and-general-usage.patch
uml-support-reorganize-ptrace_sysemu-support.patch
uml-support-add-ptrace_sysemu_singlestep-option-to-i386.patch
sysemu-fix-sysaudit--singlestep-interaction.patch

Note in particular the last 
(sysemu-fix-sysaudit--singlestep-interaction.patch) is the original version 
of the patch you're talking about (i.e. this fix was first made again the 
SYSEMU patch, even if it's of general interest).

Just use test_thread_flag(TIF_SINGLESTEP), but leave later patches as-is, they 
need the current 
   int is_singlestep = !is_sysemu && test_thread_flag(TIF_SINGLESTEP);
to be left there, and is_singlestpe to be used in that check.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade





___ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

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