Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Wed, 13 Dec 2006 05:39:43 +0100, Kasper Sandberg wrote:

> do you think it may be a bug in the kernel? the stuff with wine that
> gets thrown in the kernel messages?

Let's just say the behavior has changed.  It now returns
-EINVAL instead of -ENOTTY when the msdos IOCTLs fail.

> im 100% positive wine does NOT have
> access to any fat32, cause i entirely removed the only disk having such
> a filesystem, and it still likes to give this

That's when this happens: running certain programs that try
msdos-type IOCTLs on native Linux filesystems.

> however the last few
> times i havent observed the app going nuts

If there aren't any other problems you can just turn off the logging.

Did you change something else?

Anyway, here is a much simpler patch that restores the previous
behavior (but leaves the message.)  However if you aren't having
any problems now other than the messages maybe there's no real
problem after all?

--- 2.6.19.1-64smp.orig/fs/compat.c
+++ 2.6.19.1-64smp/fs/compat.c
@@ -444,7 +444,11 @@ asmlinkage long compat_sys_ioctl(unsigne
 
if (++count <= 50)
compat_ioctl_error(filp, fd, cmd, arg);
-   error = -EINVAL;
+
+   if (cmd == 0x82187201)
+   error = -ENOTTY;
+   else
+   error = -EINVAL;
}
 
goto out_fput;
-- 
MBTI: IXTP
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: IB: Add DMA mapping functions to allow device drivers to interpose

[Andrew Morton]

On Wed, 13 Dec 2006 03:59:45 GMT
Linux Kernel Mailing List  wrote:

> IB: Add DMA mapping functions to allow device drivers to interpose
> 
> The QLogic InfiniPath HCAs use programmed I/O instead of HW DMA.
> This patch allows a verbs device driver to interpose on DMA mapping
> function calls in order to avoid relying on bus_to_virt() and
> phys_to_virt() to undo the mappings created by dma_map_single(),
> dma_map_sg(), etc.
> 
> Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>

include/rdma/ib_verbs.h: In function 'ib_dma_alloc_coherent':
include/rdma/ib_verbs.h:1635: warning: passing argument 3 of 
'dma_alloc_coherent' from incompatible pointer type
In file included from drivers/infiniband/hw/mthca/mthca_provider.h:41,
 from drivers/infiniband/hw/mthca/mthca_dev.h:53,
 from drivers/infiniband/hw/mthca/mthca_main.c:44:
include/rdma/ib_verbs.h: In function 'ib_dma_alloc_coherent':
include/rdma/ib_verbs.h:1635: warning: passing argument 3 of 
'dma_alloc_coherent' from incompatible pointer type


That u64 needs to become a dma_addr_t.  That means that
ib_dma_mapping_ops.alloc_coherent() and ib_dma_mapping_ops.free_coherent() are
wrong as well.

> +struct ib_dma_mapping_ops {
> ...
> + void*(*alloc_coherent)(struct ib_device *dev,
> +size_t size,
> +u64 *dma_handle,
> +gfp_t flag);
> + void(*free_coherent)(struct ib_device *dev,
> +  size_t size, void *cpu_addr,
> +  u64 dma_handle);
> +};

I'd have picked this up if it had been in git-infiniband for even a couple
of days.  I'm assuming this all got slammed into mainline because of the
merge window thing.

I cannot find these patches on the kernel mailing list.  I cannot find the
pull request anywhere.

> +static inline u64 ib_dma_map_single(struct ib_device *dev,
> + void *cpu_addr, size_t size,
> + enum dma_data_direction direction)

no, dma_map_single() returns a dma_addr_t.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.18.4: flush_workqueue calls mutex_lock in interrupt environment

[xb]

Hi all,

Running some IO stress tests on a 8*ways IA64 platform, we got:
BUG: warning at kernel/mutex.c:132/__mutex_lock_common()  message
followed by:
Unable to handle kernel paging request at virtual address
00200200
oops corresponding to anon_vma_unlink() calling list_del() on a
poisonned list.

Having a look to the stack, we see that flush_workqueue() calls
mutex_lock() with softirqs disabled.
Can we suppose that the Oops that follows is due to the previous warning ?
Thanks in advance for your help.

Xavier

<4>BUG: warning at kernel/mutex.c:132/__mutex_lock_common()
<4>
<4>Call Trace:
<4> [] show_stack+0x80/0xa0
<4>sp=a0010070f960
bsp=a001007017c8
<4> [] dump_stack+0x30/0x60
<4>sp=a0010070fb30
bsp=a001007017b0
<4>r32 : a00100577b00 r33 : 0793 r34 :
0084
<4> [] __mutex_lock_slowpath+0x640/0x6c0
<4>sp=a0010070fb30
bsp=a00100701738
<4>r32 : a001007a1ae8 r33 : 4000 r34 :
e0010589
<4>r35 : a0010070 r36 : 0287 r37 :

<4>r38 : e0010589 r39 : 001008026018 r40 :
a00100065410
<4>r41 : 040d r42 : a00100af93f0 r43 :
0002
<4>r44 : a00100577ba0 r45 : 0205 r46 :
a00100065330
<4> [] mutex_lock+0x20/0x40
<4>sp=a0010070fb60
bsp=a00100701718
<4>r32 : a001007a1ae8 r33 : a001000a25b0 r34 :
0287
<4>r35 : 040c
<4> [] flush_workqueue+0xb0/0x1a0
<4>sp=a0010070fb60
bsp=a001007016f0
<4>r32 : e00107386780 r33 : a0010018c060 r34 :
a0010018c0c0
<4>r35 : 0309 r36 : e0275e781488
<4> [] __put_ioctx+0xc0/0x240
<4>sp=a0010070fb60
bsp=a001007016c0
<4>r32 : e0275e781380 r33 : e0275e781388 r34 :
0200
<4>r35 : a0010018d470 r36 : 050e r37 :
a0010018d410
<4> [] aio_complete+0x2f0/0x420
<4>sp=a0010070fb60
bsp=a00100701670
<4>r32 : 0001 r33 : 4000 r34 :
0001
<4>r35 : e0275e781380 r36 : 0001 r37 :
e0275e7813a8
<4>r38 : e02081f8fe28 r39 : a0010019cc80 r40 :
050d
<4>r41 : a00100149110
<4> [] finished_one_bio+0x200/0x2a0
<4>sp=a0010070fb60
bsp=a00100701620
<4>r32 : e0042f62a980 r33 : 4000 r34 :
e0042f62aca0
<4>r35 : e0042f62ac9c r36 : e0042f62acc8 r37 :
e0042f62a990
<4>r38 : e0042f62acb8 r39 : a0010019d1c0 r40 :
058c
<4>r41 : e00521d94300
<4> [] dio_bio_complete+0x1c0/0x200
<4>sp=a0010070fb60
bsp=a001007015c0
<4>r32 : e0042f62a980 r33 : e00521d94300 r34 :
000a
<4>r35 : 0030 r36 : e0042f62a990 r37 :
a00100083eb0
<4>r38 : e005b56cdfd0 r39 : 0001 r40 :
a0010019d260
<4>r41 : 0206 r42 : a00100af93f0
<4> [] dio_bio_end_aio+0x60/0x80
<4>sp=a0010070fb60
bsp=a001007015a0
<4>r32 : e00521d94300 r33 : a0010014acd0 r34 :
038b
<4>r35 : 4000
<4> [] bio_endio+0x110/0x1c0
<4>sp=a0010070fb60
bsp=a00100701568
<4>r32 : e00521d94300 r33 : 4000 r34 :

<4>r35 : e00521d94330 r36 : a001002770e0 r37 :
0997
<4>r38 : a00100af93f0
<4> [] __end_that_request_first+0x180/0xba0
<4>sp=a0010070fb60
bsp=a001007014d0
<4>r32 : e00109abbff8 r33 : 4000 r34 :
4000
<4>r35 : e02002038000 r36 : e006500b0c80 r37 :

<4>r38 :  r39 : e00521d94300 r40 :
00034000
<4>r41 : e00109abc050 r42 : e00109abc098 r43 :

<4>r44 :  r45 : e00109abc018 r46 :
a0010068fea0
<4>r47 : a00100277b90 r48 : 0309 r49 :
0183
<4>r50 : 10a282c802d59567
<4> [] end_that_request_chunk+0x30/0x60
<4>sp=a0010070fb60
bsp=a001007014a0
<4>r32 : e00109abbff8 r33 : 0001 r34 :
00038000
<4>r35 : a002073c0c70 r36 : 048c r37 :
e02002038000
<4> [] scsi_end_request+0x50/0x300 [scsi_mod]
<4>sp=a0010070fb60
bsp=a001007

[PATCH 2.6.19] e1000: replace kmalloc+memset with kcalloc and indent the way it is done in other parts of e1000

[Yan Burman]

Replace kmalloc+memset with kcalloc + remove now unused size variable

Signed-off-by: Yan Burman <[EMAIL PROTECTED]>

diff -rubp linux-2.6.19_orig/drivers/net/e1000/e1000_ethtool.c 
linux-2.6.19_tests/drivers/net/e1000/e1000_ethtool.c
--- linux-2.6.19_orig/drivers/net/e1000/e1000_ethtool.c 2006-11-30 
21:28:21.0 +0200
+++ linux-2.6.19_tests/drivers/net/e1000/e1000_ethtool.c2006-12-13 
09:31:25.0 +0200
@@ -1045,19 +1045,18 @@ e1000_setup_desc_rings(struct e1000_adap
struct e1000_rx_ring *rxdr = &adapter->test_rx_ring;
struct pci_dev *pdev = adapter->pdev;
uint32_t rctl;
-   int size, i, ret_val;
+   int i, ret_val;
 
/* Setup Tx descriptor ring and Tx buffers */
 
if (!txdr->count)
txdr->count = E1000_DEFAULT_TXD;
 
-   size = txdr->count * sizeof(struct e1000_buffer);
-   if (!(txdr->buffer_info = kmalloc(size, GFP_KERNEL))) {
+   if (!(txdr->buffer_info = kcalloc(txdr->count, sizeof(struct 
e1000_buffer),
+ GFP_KERNEL))) {
ret_val = 1;
goto err_nomem;
}
-   memset(txdr->buffer_info, 0, size);
 
txdr->size = txdr->count * sizeof(struct e1000_tx_desc);
E1000_ROUNDUP(txdr->size, 4096);
@@ -1108,12 +1107,11 @@ e1000_setup_desc_rings(struct e1000_adap
if (!rxdr->count)
rxdr->count = E1000_DEFAULT_RXD;
 
-   size = rxdr->count * sizeof(struct e1000_buffer);
-   if (!(rxdr->buffer_info = kmalloc(size, GFP_KERNEL))) {
+   if (!(rxdr->buffer_info = kcalloc(rxdr->count, sizeof(struct 
e1000_buffer),
+ GFP_KERNEL))) {
ret_val = 4;
goto err_nomem;
}
-   memset(rxdr->buffer_info, 0, size);
 
rxdr->size = rxdr->count * sizeof(struct e1000_rx_desc);
if (!(rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma))) 
{
diff -rubp linux-2.6.19_orig/drivers/net/e1000/e1000_main.c 
linux-2.6.19_tests/drivers/net/e1000/e1000_main.c
--- linux-2.6.19_orig/drivers/net/e1000/e1000_main.c2006-11-30 
21:28:21.0 +0200
+++ linux-2.6.19_tests/drivers/net/e1000/e1000_main.c   2006-12-13 
09:34:19.0 +0200
@@ -1225,31 +1225,26 @@ e1000_sw_init(struct e1000_adapter *adap
 static int __devinit
 e1000_alloc_queues(struct e1000_adapter *adapter)
 {
-   int size;
-
-   size = sizeof(struct e1000_tx_ring) * adapter->num_tx_queues;
-   adapter->tx_ring = kmalloc(size, GFP_KERNEL);
+   adapter->tx_ring = kcalloc(adapter->num_tx_queues, 
+  sizeof(struct e1000_tx_ring), GFP_KERNEL);
if (!adapter->tx_ring)
return -ENOMEM;
-   memset(adapter->tx_ring, 0, size);
 
-   size = sizeof(struct e1000_rx_ring) * adapter->num_rx_queues;
-   adapter->rx_ring = kmalloc(size, GFP_KERNEL);
+   adapter->rx_ring = kcalloc(adapter->num_rx_queues,
+  sizeof(struct e1000_rx_ring), GFP_KERNEL);
if (!adapter->rx_ring) {
kfree(adapter->tx_ring);
return -ENOMEM;
}
-   memset(adapter->rx_ring, 0, size);
 
 #ifdef CONFIG_E1000_NAPI
-   size = sizeof(struct net_device) * adapter->num_rx_queues;
-   adapter->polling_netdev = kmalloc(size, GFP_KERNEL);
+   adapter->polling_netdev = kcalloc(adapter->num_rx_queues,
+ sizeof(struct net_device), 
GFP_KERNEL);
if (!adapter->polling_netdev) {
kfree(adapter->tx_ring);
kfree(adapter->rx_ring);
return -ENOMEM;
}
-   memset(adapter->polling_netdev, 0, size);
 #endif
 
return E1000_SUCCESS;
@@ -1625,18 +1620,17 @@ e1000_setup_rx_resources(struct e1000_ad
}
memset(rxdr->buffer_info, 0, size);
 
-   size = sizeof(struct e1000_ps_page) * rxdr->count;
-   rxdr->ps_page = kmalloc(size, GFP_KERNEL);
+   rxdr->ps_page = kcalloc(rxdr->count, sizeof(struct e1000_ps_page),
+   GFP_KERNEL);
if (!rxdr->ps_page) {
vfree(rxdr->buffer_info);
DPRINTK(PROBE, ERR,
"Unable to allocate memory for the receive descriptor ring\n");
return -ENOMEM;
}
-   memset(rxdr->ps_page, 0, size);
 
-   size = sizeof(struct e1000_ps_page_dma) * rxdr->count;
-   rxdr->ps_page_dma = kmalloc(size, GFP_KERNEL);
+   rxdr->ps_page_dma = kcalloc(rxdr->count, sizeof(struct 
e1000_ps_page_dma),
+   GFP_KERNEL);
if (!rxdr->ps_page_dma) {
vfree(rxdr->buffer_info);
kfree(rxdr->ps_page);
@@ -1644,7 +1638,6 @@ e1000_setup_rx_resources(struct e1000_ad
"Unable to allocate memory for the receive descriptor ring\n");
return -ENOMEM;
}
-   memset(rxdr->ps_page_dma, 0, size);
 

[PATCH] binfmt_elf: core dump masking support

[Kawai, Hidehiro]

Hi,

This patch provides a feature which enables you to specify the memory
segment types you don't want to dump into a core file. You can specify
them per process via /proc//coremask file. This file represents
the bitmask of memory segment types which are not written out when the
 process is dumped. Currently, bit 0 is only available. This
means anonymous shared memory, which includes IPC shared memory and
some of mmap(2)'ed memory.

This patch can be applied against 2.6.19-rc6-mm2, and tested on i386,
x86_64, and ia64 platforms.

Here is the background. Some software programs share huge memory among
hundreds of processes. If a failure occurs on one of these processes,
they can be signaled by a monitoring process to generate core files
and restart the service. However, it can develop into a system-wide
failure such as system slow down for a long time and disk space
shortage because the total size of the core files is very huge!

To avoid the above situation we can limit the core file size by
setrlimit(2) or ulimit(1). But this method can lose important data
such as stack because core dumping is done from lower address to
higher address and terminated halfway.
So I suggest keeping shared memory segments from being dumped for
particular processes. Because the shared memory attached to processes
is common in them, we don't need to dump the shared memory every time.

If you don't want to dump all shared memory segments attached to
pid 1234, set the bit 0 of the process's coremask to 1:

  $ echo 1 > /proc/1234/coremask

Additionally, you can check its hexadecimal value by reading the file:

  $ cat /proc/1234/coremask
  0001

When a new process is created, the process inherits the coremask
setting from its parent. It is useful to set the coremask before
the program runs. For example:

  $ echo 1 > /proc/self/coremask
  $ ./some_program

Thanks,

Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory

Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
---
 Documentation/filesystems/proc.txt |   36 ++
 fs/binfmt_elf.c|   10 +-
 fs/proc/base.c |   96 +++
 include/linux/binfmts.h|3 
 include/linux/sched.h  |1 
 kernel/fork.c  |1 
 6 files changed, 144 insertions(+), 3 deletions(-)

Index: linux-2.6.19-rc6-mm2/fs/binfmt_elf.c
===
--- linux-2.6.19-rc6-mm2.orig/fs/binfmt_elf.c
+++ linux-2.6.19-rc6-mm2/fs/binfmt_elf.c
@@ -1189,9 +1189,13 @@
if (vma->vm_flags & (VM_IO | VM_RESERVED))
return 0;
 
-   /* Dump shared memory only if mapped from an anonymous file. */
-   if (vma->vm_flags & VM_SHARED)
-   return vma->vm_file->f_path.dentry->d_inode->i_nlink == 0;
+   /* Dump shared memory which mapped from an anonymous file and
+* not masked.  */
+   if (vma->vm_flags & VM_SHARED) {
+   if (vma->vm_file->f_dentry->d_inode->i_nlink)
+   return 0;
+   return (vma->vm_mm->core_mask & CORE_MASK_ANONSHM) == 0;
+   }
 
/* If it hasn't been written to, don't write it out */
if (!vma->anon_vma)
Index: linux-2.6.19-rc6-mm2/fs/proc/base.c
===
--- linux-2.6.19-rc6-mm2.orig/fs/proc/base.c
+++ linux-2.6.19-rc6-mm2/fs/proc/base.c
@@ -73,6 +73,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"
 
 /* NOTE:
@@ -912,6 +913,95 @@
 };
 #endif
 
+#if defined(USE_ELF_CORE_DUMP) && defined(CONFIG_ELF_CORE)
+static ssize_t proc_coremask_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+   struct task_struct *task = get_proc_task(file->f_dentry->d_inode);
+   struct mm_struct *mm;
+   char buffer[PROC_NUMBUF];
+   size_t len;
+   unsigned int coremask;
+   loff_t __ppos = *ppos;
+   int ret;
+
+   ret = -ESRCH;
+   if (!task)
+   goto out_no_task;
+
+   ret = 0;
+   mm = get_task_mm(task);
+   if (!mm)
+   goto out_no_mm;
+   coremask = mm->core_mask;
+
+   len = snprintf(buffer, sizeof(buffer), "%08x\n", coremask);
+   if (__ppos >= len)
+   goto out;
+   if (count > len - __ppos)
+   count = len - __ppos;
+
+   ret = -EFAULT;
+   if (copy_to_user(buf, buffer + __ppos, count))
+   goto out;
+
+   ret = count;
+   *ppos = __ppos + count;
+
+ out:
+   mmput(mm);
+ out_no_mm:
+   put_task_struct(task);
+ out_no_task:
+   return ret;
+}
+
+static ssize_t proc_coremask_write(struct file *file, const char __user *buf,
+  size_t count, loff_t *ppos)
+{
+   struct task_struct *task;
+   struct mm_struct *mm;
+   char buffer[PROC_NUMBUF], *end;
+   unsigned int coremask;
+   int ret;
+
+   ret

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

[Eric W. Biederman]

"Yinghai Lu" <[EMAIL PROTECTED]> writes:

> On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>
>> Your or I missed a bug fix/enhancement in there somewhere.
>>
>
> I found the problem. the __set_fixmap need to __va, so the entries
> will be referred from PAGE_OFFSET.
>
> solution will be
> 1. move enable_dbgp_console from setup_early_printk, and call it from
> setup_arch after init_memory_mapping.
> 2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
> addtion to _va.

3.  Make __va always work.  I had this in my tree and I guess it didn't get
   into my big rollup patch.

Eric


x86_64: Fix the memory mapping in the early page table

diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S
index 1e6f808..2f65469 100644
--- a/arch/x86_64/kernel/head.S
+++ b/arch/x86_64/kernel/head.S
@@ -328,9 +328,9 @@ ENTRY(wakeup_level4_pgt)
.align PAGE_SIZE
 ENTRY(boot_level4_pgt)
.quad   phys_level3_ident_pgt | 0x007
-   .fill   255,8,0
+   .fill   257,8,0
.quad   phys_level3_physmem_pgt | 0x007
-   .fill   254,8,0
+   .fill   252,8,0
/* (2^48-(2*1024*1024*1024))/(2^39) = 511 */
.quad   phys_level3_kernel_pgt | 0x007
 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] psmouse split

[Andres Salomon]

Dmitry Torokhov wrote:
> Hi Andres,
[...]
> 
> Unfortunately I do not think this is going to work well in in default case:
> 
> 1. PS/2 probing order is important. You need to probe for intellimouse
>explorer last otherwise you might miss that mouse supports extended
>protocol.
> 

Sorry, I'm not sure I understand; you're saying that the intellimouse
probe will match other mice?

I originally had kept the probing order, but dropped it here:

http://dev.laptop.org/git?p=users/dilinger/psmouse-split;a=commit;h=14f352333d057c3a7a05fdab484b339b9bac2959

I can readd it if necessary.


> 2. Synaptics hardware has to be probed even if synaptics protocol is not
>used, otherwise intellimouse probe will case trackpoint on passthrough
>port not working.
> 


I'm aware of that, and the synaptics_hardware variable remains in the
psmouse_extensions() function as a reminder.  I just need to figure out
a clean way to do the probing; I wanted feedback about whether people
liked the broken out modules idea, first.


> 3. Doing full reset after every protocol probe will cause long delays in
>mouse detection. 


I'm not convinced this will actually take that long, and it should only
happen during init.  With ordered detection and an additional field in
the psmouse_protocol struct, each protocol could specify whether it
should be reset or not.  However, if it's not necessary, I'd rather get
rid of it all (sounds like the detection ordering might be necessary,
though).

> 
> 4. Maxproto is still needed - psmouse base still contains several protocols
>and sometimes users need to force "standard" protocols (Intellimouse/
>Explorer), for example when using a KVM switch.
> 

Yes, I intended to split out the protocols into a separate module, as
mentioned in

http://dev.laptop.org/git?p=users/dilinger/psmouse-split;a=commit;h=2a19dbb884cb05b5e9469bde439ac60ed56bd48d

If a KVM requires a user to force a standard protocol, I would think
that forcing it via psmouse_attr_set_protocol would be a much nicer way
than dealing w/ max_proto.  Combine that w/ being able to rmmod specific
protocol modules (ie, rmmod psmouse-synaptics if it turns out that
detection is incorrectly seeing something synaptics-like).


> Also, splitting psmouse into several modules as opposed to having monolitic
> psmouse with an option to exclude some protocols via Kconfig does not really
> buy us anything - because protocol autoload is not possible (we do not know

It does; compiling a custom kernel for users is a pain.  However, using
a distribution kernel and being able to control specifically which
modules are loaded makes life a lot easier (users get security updates,
etc).


> what protocols port uses until we actually do the probe) distributions will
> have to compile and load everything anyway. Custom kernel users will just
> have to compile protocols they need into psmouse.
> 

Yes, distributions will have to compile and load everything anyways.
However, people who know what hardware they have can then force loading
of a specific module, rather than having a monolithic module or having
to recompile a custom kernel.


> And some comments for the patch itself:
> 
>> +   if (proto->detect(psmouse, set_properties) == 0) {
>> +   if (proto->type == PSMOUSE_SYNAPTICS)
>> +   synaptics_hardware = 1;
>> +   if (!set_properties) {
>> +   if (proto->init && proto->init(psmouse) != 0)
>> +   continue; 
> 
> I think you wanted if (set_properties)...
> 
>> +static void psmouse_rescan(struct serio *serio, void *data)
>> +{
>> +   if (serio->drv->driver.name == "psmouse")
>> +   serio_rescan(serio);
>> +}
> 
> This is going to crash if you encounter unconnected port
> (serio->drv == NULL).
>

Thanks!


>> +MODULE_AUTHOR("C. Scott Ananian <[EMAIL PROTECTED]>");
>> +MODULE_DESCRIPTION("Synaptics TouchPad PS/2 mouse driver");
>> +MODULE_LICENSE("GPL");
> 
> You need to be careful with code attribution - for example Synaptics driver
> was written by Peter Osterlund. He took some code from tpconfig utility,
> that's why there is C. Scott Ananian copyright notice but _module_ author
> is still Peter.
> 

Indeed, that was among the comments I was looking for.  The copyright
attribution in each protocol file wasn't clear.  Before actually
considering this done, we'd need to go through each module and make sure
that attribution is correct.



>> +   psmouse_protocol_register(&genius_proto, 0);
>> +   psmouse_protocol_register(&imps_proto), 0;
> 
> Hmm, does this compile?
> 

Oops, that was a mispaste between what I was testing and what I'd committed.

Thanks for the feedback!

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

Re: cfq performance gap

[Jens Axboe]

On Tue, Dec 12 2006, AVANTIKA R. MATHUR wrote:
> >That said, I might add some logic to detect when we can cheaply switch
> >queues instead of waiting for a new request from the same queue.
> >Averaging slice times over a period of time instead of 1:1 with that
> >logic, should help cases like this while still being fair.
> >  
> Thank you for looking at this issue.
> I've found an IBM/SUSE bugzilla bug for the same performance gap on 
> rawio. There was a fix for this bug included in SLES10-RC1, do you know 
> why it was not added in mainline?

Which bug do you mean? It was likely me doing the fixing on that bug,
and I'm certain that the patch is in mainline. If you included the bug
number, I could have expanded on that.

-- 
Jens Axboe

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

Re: [LinuxBIOS] [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.

[Yinghai Lu]

On 12/8/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:


Your or I missed a bug fix/enhancement in there somewhere.



I found the problem. the __set_fixmap need to __va, so the entries
will be referred from PAGE_OFFSET.

solution will be
1. move enable_dbgp_console from setup_early_printk, and call it from
setup_arch after init_memory_mapping.
2. or make __set_fixmap can use __pa or pa()+__START_KERNEL_map in
addtion to _va.

please check attached updated patch that is your patch plus 1.

YH
diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S
index edef508..c8b1ec9 100644
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -141,6 +141,12 @@ page_pde_offset = (__PAGE_OFFSET >> 20);
 	jb 10b
 	movl %edi,(init_pg_tables_end - __PAGE_OFFSET)
 
+	/* Do an early initialization of the fixmap area */
+	movl $(swapper_pg_dir - __PAGE_OFFSET), %edx
+	movl $(swapper_pg_pmd - __PAGE_OFFSET), %eax
+	addl $0x007, %eax			/* 0x007 = PRESENT+RW+USER */
+	movl %eax, 4092(%edx)
+
 #ifdef CONFIG_SMP
 	xorl %ebx,%ebx/* This is the boot CPU (BSP) */
 	jmp 3f
@@ -531,6 +537,8 @@ ENTRY(_stext)
 .section ".bss.page_aligned","w"
 ENTRY(swapper_pg_dir)
 	.fill 1024,4,0
+ENTRY(swapper_pg_pmd)
+	.fill 1024,4,0	
 ENTRY(empty_zero_page)
 	.fill 4096,1,0
 
diff --git a/arch/x86_64/kernel/early_printk.c b/arch/x86_64/kernel/early_printk.c
index 47b6d90..8b4c6f4 100644
--- a/arch/x86_64/kernel/early_printk.c
+++ b/arch/x86_64/kernel/early_printk.c
@@ -3,9 +3,19 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#define EARLY_PRINTK
+#include "../../../drivers/usb/host/ehci.h"
+
 
 /* Simple VGA output */
 
@@ -156,6 +166,562 @@ static struct console early_serial_console = {
 	.index =	-1,
 };
 
+
+static struct ehci_caps __iomem *ehci_caps;
+static struct ehci_regs __iomem *ehci_regs;
+static struct ehci_dbg_port __iomem *ehci_debug;
+static unsigned dbgp_endpoint_out;
+
+#define USB_DEBUG_DEVNUM 127
+
+#define DBGP_DATA_TOGGLE	0x8800
+#define DBGP_PID_UPDATE(x, tok) \
+	x) ^ DBGP_DATA_TOGGLE) & 0x00) | ((tok) & 0xff))
+
+#define DBGP_LEN_UPDATE(x, len) (((x) & ~0x0f) | ((len) & 0x0f))
+/*
+ * USB Packet IDs (PIDs)
+ */
+
+/* token */
+#define USB_PID_OUT		0xe1
+#define USB_PID_IN		0x69
+#define USB_PID_SOF		0xa5
+#define USB_PID_SETUP		0x2d
+/* handshake */
+#define USB_PID_ACK		0xd2
+#define USB_PID_NAK		0x5a
+#define USB_PID_STALL		0x1e
+#define USB_PID_NYET		0x96
+/* data */
+#define USB_PID_DATA0		0xc3
+#define USB_PID_DATA1		0x4b
+#define USB_PID_DATA2		0x87
+#define USB_PID_MDATA		0x0f
+/* Special */
+#define USB_PID_PREAMBLE	0x3c
+#define USB_PID_ERR		0x3c
+#define USB_PID_SPLIT		0x78
+#define USB_PID_PING		0xb4
+#define USB_PID_UNDEF_0		0xf0
+
+#define USB_PID_DATA_TOGGLE	0x88
+#define DBGP_CLAIM (DBGP_OWNER | DBGP_ENABLED | DBGP_INUSE)
+
+#define PCI_CAP_ID_EHCI_DEBUG	0xa
+
+#define HUB_ROOT_RESET_TIME	50	/* times are in msec */
+#define HUB_SHORT_RESET_TIME	10
+#define HUB_LONG_RESET_TIME	200
+#define HUB_RESET_TIMEOUT	500
+
+#define DBGP_MAX_PACKET		8
+
+static int dbgp_wait_until_complete(void)
+{
+	unsigned ctrl;
+	for (;;) {
+		ctrl = readl(&ehci_debug->control);
+		/* Stop when the transaction is finished */
+		if (ctrl & DBGP_DONE)
+			break;
+	}
+	/* Now that we have observed the completed transaction,
+	 * clear the done bit.
+	 */
+	writel(ctrl | DBGP_DONE, &ehci_debug->control);
+	return (ctrl & DBGP_ERROR) ? -DBGP_ERRCODE(ctrl) : DBGP_LEN(ctrl);
+}
+
+static void dbgp_mdelay(int ms)
+{
+	int i;
+	while (ms--) {
+		for (i = 0; i < 1000; i++)
+			outb(0x1, 0x80);
+	}
+}
+
+static void dbgp_breath(void)
+{
+	/* Sleep to give the debug port a chance to breathe */
+}
+
+static int dbgp_wait_until_done(unsigned ctrl)
+{
+	unsigned pids, lpid;
+	int ret;
+
+retry:
+	writel(ctrl | DBGP_GO, &ehci_debug->control);
+	ret = dbgp_wait_until_complete();
+	pids = readl(&ehci_debug->pids);
+	lpid = DBGP_PID_GET(pids);
+
+	if (ret < 0)
+		return ret;
+
+	/* If the port is getting full or it has dropped data
+	 * start pacing ourselves, not necessary but it's friendly.
+	 */
+	if ((lpid == USB_PID_NAK) || (lpid == USB_PID_NYET))
+		dbgp_breath();
+	
+	/* If I get a NACK reissue the transmission */
+	if (lpid == USB_PID_NAK)
+		goto retry;
+
+	return ret;
+}
+
+static void dbgp_set_data(const void *buf, int size)
+{
+	const unsigned char *bytes = buf;
+	unsigned lo, hi;
+	int i;
+	lo = hi = 0;
+	for (i = 0; i < 4 && i < size; i++)
+		lo |= bytes[i] << (8*i);
+	for (; i < 8 && i < size; i++)
+		hi |= bytes[i] << (8*(i - 4));
+	writel(lo, &ehci_debug->data03);
+	writel(hi, &ehci_debug->data47);
+}
+
+static void dbgp_get_data(void *buf, int size)
+{
+	unsigned char *bytes = buf;
+	unsigned lo, hi;
+	int i;
+	lo = readl(&ehci_debug->data03);
+	hi = readl(&ehci_debug->data47);
+	for (i = 0; i < 4 && i < size; i++)
+		bytes[i] = (lo >> (8*i)) & 0xff;
+	for (; i < 8 && i < size; i++)
+		bytes[i] = (hi >> (8*(i 

Re: 2.6.18.3 also 2.6.19 XFS xfs_force_shutdown (was: XFS internal error [...])

[David Chinner]

On Wed, Dec 13, 2006 at 02:12:23PM +0900, Shinichiro HIDA wrote:
> Hi,
> 
> I met same problem on my 2 machines, 2.6.19 (Debian unstable) also
> 2.6.18.3 (Debian stable),

The trace:

> ;; [1] lune: debian unstable with 2.6.19
> Dec 12 21:31:25 lune kernel:  [] xfs_da_do_buf+0x340/0xa10
> Dec 12 21:31:25 lune kernel:  [] xfs_da_read_buf+0x3c/0x40
> Dec 12 21:31:25 lune kernel:  [] 
> xfs_dir2_leafn_lookup_int+0x2e8/0x540
> Dec 12 21:31:25 lune kernel:  [] 
> xfs_dir2_leafn_lookup_int+0x2e8/0x540
> Dec 12 21:31:25 lune kernel:  [] xfs_dir2_data_log_unused+0x6d/0x90
> Dec 12 21:31:25 lune kernel:  [] xfs_da_read_buf+0x3c/0x40


Should have been preceeded with some other output explaining the
reason for the shutdown. Did these machines run 2.6.17.x where x<= 6?
i.e. is this problem:

http://oss.sgi.com/projects/xfs/faq.html#dir2

The one you are tripping over?

Cheers,

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

Re: Survey about the Kernel Community

[Timo Aaltonen]

Hi,

Sure, we will post the results to the mailing list after analyzing them.
Moreover, we post a link to the proceedings of the conference where the
results are published.

-- 
Timo


> Hi,
> 
> Well, I filled in the survey. Was wondering if you also post the results
> here at the mailing list. That would be nice.
> 
> Greetings,
> 
> Jim.
> 
>> Hi all,
>>
>> We would like to ask you few question about Linux Kernel Community. The
>> survey consists of 31 multiple choice questions and three text boxes.
>> The survey is conducted by Institute of Business Information Management
>> and Institute of Software Systems at Tampere University of Technology.
>>
>> We close the survey at 24th of December. The results of our study will
>> be published  in an international academic conference.
>>
>> Please devote a few minutes to help us in understanding OSS communities.
>> The survey is located at
>> .
>>
>> Thanks in advance.
>>
>> --
>> Timo Aaltonen and Maria Antikainen
>> [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/
>>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] psmouse split

[Dmitry Torokhov]

Hi Andres,

On Tuesday 12 December 2006 23:31, Andres Salomon wrote:
> Hi,
> 
> When Zephaniah Hull sent in a patch for the OLPC touchpad [0], it was
> suggested that the psmouse driver be split out into separate components.
>  What's currently there is way too fat, and people are not happy about
> adding even more code to the driver.
> 
> I've taken a stab at doing just that.  The attached patch splits the
> various protocol extensions into their own modules, defines a protocol
> registration layer, and allows modules to define their own psmouse
> protocols.  Psmouse-base now only registers a few extensions, and then
> scans the ps/2 ports.  Other modules (ie, psmouse-alps) register their
> extension, and force a rescan of all serio ports that the psmouse driver
> happens to be using.  The max_proto stuff has been removed, with the
> intention that people should be loading (or unloading) only the modules
> they need, rather than playing around w/ module arguments.  Rather than
> playing games w/ extension detection ordering, I opted to just reset the
> port before every scan.
> 

Unfortunately I do not think this is going to work well in in default case:

1. PS/2 probing order is important. You need to probe for intellimouse
   explorer last otherwise you might miss that mouse supports extended
   protocol.

2. Synaptics hardware has to be probed even if synaptics protocol is not
   used, otherwise intellimouse probe will case trackpoint on passthrough
   port not working.

3. Doing full reset after every protocol probe will cause long delays in
   mouse detection. 

4. Maxproto is still needed - psmouse base still contains several protocols
   and sometimes users need to force "standard" protocols (Intellimouse/
   Explorer), for example when using a KVM switch.

Also, splitting psmouse into several modules as opposed to having monolitic
psmouse with an option to exclude some protocols via Kconfig does not really
buy us anything - because protocol autoload is not possible (we do not know
what protocols port uses until we actually do the probe) distributions will
have to compile and load everything anyway. Custom kernel users will just
have to compile protocols they need into psmouse.

And some comments for the patch itself:

> +   if (proto->detect(psmouse, set_properties) == 0) {
> +   if (proto->type == PSMOUSE_SYNAPTICS)
> +   synaptics_hardware = 1;
> +   if (!set_properties) {
> +   if (proto->init && proto->init(psmouse) != 0)
> +   continue; 

I think you wanted if (set_properties)...

> +static void psmouse_rescan(struct serio *serio, void *data)
> +{
> +   if (serio->drv->driver.name == "psmouse")
> +   serio_rescan(serio);
> +}

This is going to crash if you encounter unconnected port
(serio->drv == NULL).

> +MODULE_AUTHOR("C. Scott Ananian <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("Synaptics TouchPad PS/2 mouse driver");
> +MODULE_LICENSE("GPL");

You need to be careful with code attribution - for example Synaptics driver
was written by Peter Osterlund. He took some code from tpconfig utility,
that's why there is C. Scott Ananian copyright notice but _module_ author
is still Peter.

> +   psmouse_protocol_register(&genius_proto, 0);
> +   psmouse_protocol_register(&imps_proto), 0;

Hmm, does this compile?

-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] connector: Some fixes for ia64 unaligned access errors

[Erik Jacobson]

Hi.  I didn't want to leave this hanging and it stayed in my head so I
thought I'd better just finish it and test it.

I tried out this patch and it got rid of all three unaligned acces errors
I was seeing with process connectors and the patch is indeed much smaller.

I ran our container daemon program in debug mode to be sure the forks
and exits still worked right when the patch was applied and all seemed
well.

I applied this patch to x86_64 as well as a sanity check and it seems
working fine.

Things look good to me.  I'm ok if you prefer this patch, or the one
already in -mm.

Signed-off-by: Erik Jacobson <[EMAIL PROTECTED]>
---

 cn_proc.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)
--- linux.orig/drivers/connector/cn_proc.c  2006-12-12 23:03:31.0 
-0600
+++ linux/drivers/connector/cn_proc.c   2006-12-12 23:06:34.243535000 -0600
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -60,7 +61,7 @@
ev = (struct proc_event*)msg->data;
get_seq(&msg->seq, &ev->cpu);
ktime_get_ts(&ts); /* get high res monotonic timestamp */
-   ev->timestamp_ns = timespec_to_ns(&ts);
+   put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);
ev->what = PROC_EVENT_FORK;
ev->event_data.fork.parent_pid = task->real_parent->pid;
ev->event_data.fork.parent_tgid = task->real_parent->tgid;
@@ -88,7 +89,7 @@
ev = (struct proc_event*)msg->data;
get_seq(&msg->seq, &ev->cpu);
ktime_get_ts(&ts); /* get high res monotonic timestamp */
-   ev->timestamp_ns = timespec_to_ns(&ts);
+   put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);
ev->what = PROC_EVENT_EXEC;
ev->event_data.exec.process_pid = task->pid;
ev->event_data.exec.process_tgid = task->tgid;
@@ -124,7 +125,7 @@
return;
get_seq(&msg->seq, &ev->cpu);
ktime_get_ts(&ts); /* get high res monotonic timestamp */
-   ev->timestamp_ns = timespec_to_ns(&ts);
+   put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);
 
memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
msg->ack = 0; /* not used */
@@ -146,7 +147,7 @@
ev = (struct proc_event*)msg->data;
get_seq(&msg->seq, &ev->cpu);
ktime_get_ts(&ts); /* get high res monotonic timestamp */
-   ev->timestamp_ns = timespec_to_ns(&ts);
+   put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);
ev->what = PROC_EVENT_EXIT;
ev->event_data.exit.process_pid = task->pid;
ev->event_data.exit.process_tgid = task->tgid;
@@ -181,7 +182,7 @@
ev = (struct proc_event*)msg->data;
msg->seq = rcvd_seq;
ktime_get_ts(&ts); /* get high res monotonic timestamp */
-   ev->timestamp_ns = timespec_to_ns(&ts);
+   put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);
ev->cpu = -1;
ev->what = PROC_EVENT_NONE;
ev->event_data.ack.err = err;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 000 of 14] knfsd: Assorted nfsd patches for 2.6.20 - prepare for IPv6 and more

[Jeff Garzik]

NeilBrown wrote:

Following are 14 patches for knfsd that are suitable for inclusion in 2.6.20.
First 13 are from Chuck Lever and make preparations for IPv6 support (I think 
we've
get them right this time).

Last is from Peter Staubach and fixes and issue with exclusive create
interacting badly with some ACLs.



Any word on this 2.6.19 oops?

http://lkml.org/lkml/2006/12/8/110

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/

Parse boot parameter error?

[Shaohua Li]

Say a boot parameter is "xxx", if you give a string "xxxy", then the
boot parameter's corresponding function is executed. Is this intended?
If not, below patch fixes it.

diff --git a/init/main.c b/init/main.c
index 036f97c..d56940c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -193,7 +193,8 @@ static int __init obsolete_checksetup(ch
p = __setup_start;
do {
int n = strlen(p->str);
-   if (!strncmp(line, p->str, n)) {
+   if (((!strncmp(line, p->str, n)) && (p->str[n-1] == '='))
+   || !strcmp(line, p->str)) {
if (p->early) {
/* Already done in parse_early_param?
 * (Needs exact match on param part).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: cfq performance gap

[Chen, Kenneth W]

AVANTIKA R. MATHUR wrote on Tuesday, December 12, 2006 5:33 PM
> >> rawio is actually performing sequential reads, but I don't believe it is
> >> purely sequential with the multiple processes.
> >> I am currently running the test with longer runtimes and will post
> >> results once it is complete.
> >> I've also attached the rawio source.
> >> 
> >
> > It's certainly the slice and idling hurting here. But at the same time,
> > I don't really think your test case is very interesting. The test area
> > is very small and you have 16 threads trying to read the same thing,
> > optimizing for that would be silly as I don't think it has much real
> > world relevance.
> 
> Could a database have similar workload to this test?


No.

Not what I have seen with db workloads exhibits such pattern.  There are
basically two types of db workloads: one does transaction processing, and
I/O pattern are truly random with large stride, both in the context of
process and overall I/O seen at device level.  A second one is decision
making type of db queries.  They does large sequential I/O within one
process context.

This rawio test plows through sequential I/O and modulo each small record
over number of threads.  So each thread appears to be non-contiguous within
its own process context, overall request hitting the device are sequential.
I can't see how any application does that kind of I/O pattern.

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

BUG# 6419, via-rhine II could be the problem

[Sergio Monteiro Basto]

My bug http://bugzilla.kernel.org/show_bug.cgi?id=6419

Today I found that my computer hang problem could be just a problem with
via-rhine II.

I got exactly the same problem describe on 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245398;msg=107

I had transfer by eth0 (via-rhine II), about 3500 files, about 15 Giga
bytes and when rsync over ssh stops transfer (eth0 has got problems), I
could press ctrl-c , abort rsync restart network , and continue the
rsync.
Or just restart network which remove via-rhine modules and reinsert it.
But if I left the computer with rsync stopped after some minutes
computer hangs.

netstat -i also give me some 2 or 3 TX-ERR s 
 
Any ideas to test this ?  

Thanks,
-- 
Sérgio M.B.


smime.p7s
Description: S/MIME cryptographic signature

SATA DMA problem (sata_uli)

[David Shirley]

Hi Chaps,

Basically I detected this problem because I added another drive to my
PCI SATA card, and now the system is running dog slow.

I tracked it down to one of the drives being forced into PIO4 mode
rather than UDMA mode; dmesg bits:

sata_nv :00:0b.0: version 2.0
ACPI: PCI Interrupt Link [LSID] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt :00:0b.0[A] -> Link [LSID] -> GSI 11 (level,
low) -> IRQ 11
PCI: Setting latency timer of device :00:0b.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xE800 irq 11
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xE808 irq 11
scsi0 : sata_nv
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi1 : sata_nv
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata2.00: ata2: dev 0 multi count 16
ata2.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA  ST3300831AS  3.06 PQ: 0 ANSI: 5
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 586072368 512-byte hdwr sectors (300069 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Direct-Access ATA  ST3300831AS  3.06 PQ: 0 ANSI: 5
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2
sd 1:0:0:0: Attached scsi disk sdb
sd 1:0:0:0: Attached scsi generic sg1 type 0
sata_uli :01:06.0: version 1.0
ACPI: PCI Interrupt :01:06.0[A] -> Link [LNK3] -> GSI 10 (level,
low) -> IRQ 10
ata3: SATA max UDMA/133 cmd 0x7000 ctl 0x7402 bmdma 0x8000 irq 10
ata4: SATA max UDMA/133 cmd 0x7800 ctl 0x7C02 bmdma 0x8008 irq 10
scsi2 : sata_uli
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: ATA-7, max UDMA/133, 625142448 sectors: LBA48 NCQ (depth 0/32)
ata3.00: ata3: dev 0 multi count 16
ata3.00: configured for UDMA/133
scsi3 : sata_uli
ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATA-7, max UDMA/133, 586072368 sectors: LBA48 NCQ (depth 0/32)
ata4.00: ata4: dev 0 multi count 16
ata4.00: simplex DMA is claimed by other device, disabling DMA
ata4.00: configured for PIO4
scsi 2:0:0:0: Direct-Access ATA  ST3320620AS  3.AA PQ: 0 ANSI: 5
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
SCSI device sdc: 625142448 512-byte hdwr sectors (320073 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: drive cache: write back
sdc: sdc1 sdc2
sd 2:0:0:0: Attached scsi disk sdc
sd 2:0:0:0: Attached scsi generic sg2 type 0
scsi 3:0:0:0: Direct-Access ATA  ST3300831AS  3.06 PQ: 0 ANSI: 5
SCSI device sdd: 586072368 512-byte hdwr sectors (300069 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
SCSI device sdd: 586072368 512-byte hdwr sectors (300069 MB)
sdd: Write Protect is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: drive cache: write back
sdd: sdd1 sdd2
sd 3:0:0:0: Attached scsi disk sdd
sd 3:0:0:0: Attached scsi generic sg3 type 0

Why is ata4 reporting "simplex DMA is claimed by another device" and
how can I get it to work correctly?

Please let me know if you need more information.

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

VM_RESERVED vs vm_normal_page()

[Benjamin Herrenschmidt]

Hi folks !

What is the logic regarding VM_RESERVED, and more specifically, why is
vm_normal_page() nor returning NULL for these ?

I have struct pages that are a bit special for things like SPE mappings
on Cell and I'd like to avoid a lot of the stuff the VM tries to do on
them, like rmap accounting, etc... In fact, for almost everything, the
semantics I want are vm_normal_page() to return NULL... I have struct
pages because for now I need do_no_page() to work, but I must absolutely
avoid things like getting swapped out etc...

Thus I looked at the logic in vm_normal_page() and it really sucks...
this is pretty much a "heuristic" to differenciate remap_page_range from
copy_on_write stuff ... gack.

What is VM_RESERVED for then ? Could I just use that ? I currently only
have VM_IO set on my SPE VMAs but I could add it. The current
implementation of vm_normal_page() doesn't test for it though, maybe it
should ?

I have still a problem though, in the case vm_normal_page() is made to
return NULL...

In that case, unmapping of pages will still cause them to be released
(tlb_* -> free_pages_and_swap_cache -> release_pages ->
put_page_testzero) but if you fork(), copy_one_pte() will not call an
additional get_page() when vm_normal_page() returns NULL... thus I fear
the page count will become bocus accross forks...

In the long run, I want to stop using struct page's for the SPU
registers and local store, once Nick's new stuff gets in, though I might
have a go at hacking something together before... but in the meantime,
I'd like to figure out what is the _safe_ way of having a VMA containing
PTEs mapping to struct pages that are _not_ normal memory and thus
aren't to be swapped out, freed, or anything like that.

Cheers,
Ben. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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: UML: remove MODE_TT?

[Jeff Dike]

On Wed, Dec 13, 2006 at 12:35:33AM +0100, Adrian Bunk wrote:
> MODE_TT is both marked as deprecated and marked as BROKEN.
> 
> Would a patch to remove MODE_TT, always enable MODE_SKAS, and doing all 
> possible cleanups after this be accepted?

Thanks, but not yet.

I've got that queued up in my tree now, waiting for SMP to work.  SMP is 
the one remaining justification for TT mode, so I'll get that in, then remove
MODE_TT and do the associated cleanups.

Jeff

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

Re: BUG? atleast >=2.6.19-rc5, x86 chroot on x86_64

[Kasper Sandberg]

On Mon, 2006-12-11 at 03:27 -0500, Chuck Ebbert wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
> 
> On Wed, 06 Dec 2006 13:58:00 +0100, Kasper Sandberg wrote:
> 
> > > Kasper, what problems (other that the annoying message) are you having?
> > if it had only been the messages i wouldnt have complained.
> > the thing is, when i get these messages, the app provoking them acts
> > very strange, and in some cases, my system simply hardlocks.
> 
> You can try the patch I sent you to see if it fixes the Wine app.
> (David thought I was proposing it for the mainline kernel but I just
> wanted to see whether it made a difference.)

do you think it may be a bug in the kernel? the stuff with wine that
gets thrown in the kernel messages? cause if it is, i ofcourse wish to
help by testing. one more thing, im 100% positive wine does NOT have
access to any fat32, cause i entirely removed the only disk having such
a filesystem, and it still likes to give this, however the last few
times i havent observed the app going nuts :)

> 
> As for the lockups, there are possibly other bugs lurking in 2.6.19.
yes, when the using-much-ram-perhaps-even-swap thing was mentioned i
came to think, cause i do happen to use alarmingly much swap. i noticed
a ~5 second lockup (where it actually returned to normal again) when i
reached ~50mb free ram, and this was outside the chroot.


> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] psmouse split

[Andres Salomon]

Hi,

When Zephaniah Hull sent in a patch for the OLPC touchpad [0], it was
suggested that the psmouse driver be split out into separate components.
 What's currently there is way too fat, and people are not happy about
adding even more code to the driver.

I've taken a stab at doing just that.  The attached patch splits the
various protocol extensions into their own modules, defines a protocol
registration layer, and allows modules to define their own psmouse
protocols.  Psmouse-base now only registers a few extensions, and then
scans the ps/2 ports.  Other modules (ie, psmouse-alps) register their
extension, and force a rescan of all serio ports that the psmouse driver
happens to be using.  The max_proto stuff has been removed, with the
intention that people should be loading (or unloading) only the modules
they need, rather than playing around w/ module arguments.  Rather than
playing games w/ extension detection ordering, I opted to just reset the
port before every scan.

The patch is attached, and I have a git repository here:

git://dev.laptop.org/users/dilinger/psmouse-split

There's also a gitweb interface:

http://dev.laptop.org/git?p=users/dilinger/psmouse-split;a=summary

Comments and feedback are welcome.  I intend to do a few further
cleanups (at the very least, there are now stale header files that need
to go away, and further testing is needed).

[0] http://thread.gmane.org/gmane.linux.kernel/441574/
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 35d998c..b160686 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -37,6 +37,66 @@ config MOUSE_PS2
 	  To compile this driver as a module, choose M here: the
 	  module will be called psmouse.
 
+config MOUSE_PS2_ALPS
+	tristate "ALPS PS/2 mouse protocol extension"
+	depends on MOUSE_PS2
+	---help---
+	  Say Y here if you have an ALPS PS/2 touchpad connected to
+	  your system.
+
+	  If unsure, say Y.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called psmouse-alps.
+
+config MOUSE_PS2_LOGIPS2PP
+	tristate "Logictech PS/2++ mouse protocol extension"
+	depends on MOUSE_PS2
+	---help---
+	  Say Y here if you have a Logictech PS/2++ mouse connected to
+	  your system.
+
+	  If unsure, say Y.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called psmouse-logips2pp.
+
+config MOUSE_PS2_SYNAPTICS
+	tristate "Synaptics PS/2 mouse protocol extension"
+	depends on MOUSE_PS2
+	---help---
+	  Say Y here if you have a Synaptics PS/2 TouchPad connected to
+	  your system.
+
+	  If unsure, say Y.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called psmouse-synaptics.
+
+config MOUSE_PS2_LIFEBOOK
+	tristate "Fujitsu Lifebook PS/2 mouse protocol extension"
+	depends on MOUSE_PS2
+	---help---
+	  Say Y here if you have a Fujitsu B-series Lifebook PS/2
+	  TouchScreen connected to your system.
+
+	  If unsure, say Y.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called psmouse-lifebook.
+
+config MOUSE_PS2_TRACKPOINT
+	tristate "IBM Trackpoint PS/2 mouse protocol extension"
+	depends on MOUSE_PS2
+	---help---
+	  Say Y here if you have an IBM Trackpoint PS/2 mouse connected
+	  to your system.
+
+	  If unsure, say Y.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called psmouse-trackpoint.
+
 config MOUSE_SERIAL
 	tristate "Serial mouse"
 	select SERIO
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 21a1de6..5a0767b 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -10,8 +10,18 @@ obj-$(CONFIG_MOUSE_INPORT)	+= inport.o
 obj-$(CONFIG_MOUSE_LOGIBM)	+= logibm.o
 obj-$(CONFIG_MOUSE_PC110PAD)	+= pc110pad.o
 obj-$(CONFIG_MOUSE_PS2)		+= psmouse.o
+obj-$(CONFIG_MOUSE_PS2_ALPS)	+= psmouse-alps.o
+obj-$(CONFIG_MOUSE_PS2_LOGIPS2PP)	+= psmouse-logips2pp.o
+obj-$(CONFIG_MOUSE_PS2_SYNAPTICS)	+= psmouse-synaptics.o
+obj-$(CONFIG_MOUSE_PS2_LIFEBOOK)	+= psmouse-lifebook.o
+obj-$(CONFIG_MOUSE_PS2_TRACKPOINT)	+= psmouse-trackpoint.o
 obj-$(CONFIG_MOUSE_SERIAL)	+= sermouse.o
 obj-$(CONFIG_MOUSE_HIL)		+= hil_ptr.o
 obj-$(CONFIG_MOUSE_VSXXXAA)	+= vsxxxaa.o
 
-psmouse-objs  := psmouse-base.o alps.o logips2pp.o synaptics.o lifebook.o trackpoint.o
+psmouse-alps-objs		:= alps.o
+psmouse-logips2pp-objs		:= logips2pp.o
+psmouse-synaptics-objs		:= synaptics.o
+psmouse-lifebook-objs		:= lifebook.o
+psmouse-trackpoint-objs		:= trackpoint.o
+psmouse-objs			:= psmouse-base.o
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 4e71a66..dc4f6b3 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -21,6 +21,10 @@ #include 
 #include "psmouse.h"
 #include "alps.h"
 
+MODULE_AUTHOR("Neil Brown <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("ALPS touchpad PS/2 mouse driver");
+MODULE_LICENSE("GPL");
+
 #undef DEBUG
 #ifdef DEBUG
 #define dbg(format, arg...) printk(KERN_INFO "alps.c:

Re: Status of buffered write path (deadlock fixes)

[Nick Piggin]

Trond Myklebust wrote:

On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:


Note that these pages should be *really* rare. Definitely even for normal
filesystems I think RMW would use too much bandwidth if it were required
for any significant number of writes.



If file "foo" exists on the server, and contains data, then something
like

fd = open("foo", O_WRONLY);
write(fd, "1", 1);

should never need to trigger a read. That's a fairly common workload
when you think about it (happens all the time in apps that do random
write).


Right. What I'm currently looking at doing in that case is two copies,
first into a temporary buffer. Unfortunate, but we'll see what the
performance looks like.


I don't want to mandate anything just yet, so I'm just going through our
options. The first two options (remove, and RMW) are probably trickier
than they need to be, given the 3rd option available (temp buffer). Given
your input, I'm increasingly thinking that the best course of action would
be to fix this with the temp buffer and look at improving that later if it
causes a noticable slowdown.



What is the generic problem you are trying to resolve? I saw something
fly by about a reader filling the !uptodate page while the writer is
updating it: how is that going to happen if the writer has the page
locked?


The problem is that you can't take a pagefault while holding the page
lock. You can deadlock against another page, the same page, or the
mmap_sem.


AFAIK the only thing that can modify the page if it is locked (aside
from the process that has locked it) is a process that has the page
mmapped(). However mmapped pages are always uptodate, right?


That's right (modulo the pagefault vs invalidate race bug).

But we need to unlock the destination page in order to be able to take
a pagefault to bring the source user memory uptodate. If the page is
not uptodate, then a read might see uninitialised data.

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


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

[PATCH] Alpha increase PERCPU_ENOUGH_ROOM

[Aneesh Kumar K.V]

Sending it again marking Jay Estabrook

-aneesh 

Module loading on Alpha was failing with error
"Could not allocate 8 bytes percpu data".

Looking at dmesg we have the below error
"No per-cpu room for modules."

Increase the PERCPU_ENOUGH_ROOM in a similar way as x86_64

Signed-off-by: Aneesh Kumar K.V <[EMAIL PROTECTED]>
---
 include/asm-alpha/percpu.h |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/include/asm-alpha/percpu.h b/include/asm-alpha/percpu.h
index 48348fe..651ebb1 100644
--- a/include/asm-alpha/percpu.h
+++ b/include/asm-alpha/percpu.h
@@ -1,6 +1,20 @@
 #ifndef __ALPHA_PERCPU_H
 #define __ALPHA_PERCPU_H
 
+/*
+ * Increase the per cpu area for Alpha so that
+ * modules using percpu area can load.
+ */
+#ifdef CONFIG_MODULES
+# define PERCPU_MODULE_RESERVE 8192
+#else
+# define PERCPU_MODULE_RESERVE 0
+#endif
+
+#define PERCPU_ENOUGH_ROOM \
+   (ALIGN(__per_cpu_end - __per_cpu_start, SMP_CACHE_BYTES) + \
+PERCPU_MODULE_RESERVE)
+
 #include 
 
 #endif /* __ALPHA_PERCPU_H */
-- 
1.4.4.2.gdb98-dirty

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] connector: Some fixes for ia64 unaligned access errors

[Erik Jacobson]

> But it's rather a lot of churn for such a thing.  Did you consider simply 
> using
> put_unaligned() against the specific offending field(s)?

Hi.  This was not considered.

I wanted to give you some quick feedback, so I tried your suggestion in the
fork path.  It seemed to fix the problem as well.

put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);

Is what I tried.

I'm on vacation tomorrow but on Thursday, if you like, I can whip up
a patch that does this and test it more thoroughly.  Is this the
direction you prefer?  What I did just now was really quick and dirty
to see if it has a shot or not but it looks like put_unaligned will
fix it too.

-- 
Erik Jacobson - Linux System Software - SGI - Eagan, Minnesota
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] incorrect error handling inside generic_file_direct_write

[Chen, Kenneth W]

Andrew Morton wrote on Tuesday, December 12, 2006 2:40 AM
> On Tue, 12 Dec 2006 16:18:32 +0300
> Dmitriy Monakhov <[EMAIL PROTECTED]> wrote:
> 
> > >> but according to filemaps locking rules: mm/filemap.c:77
> > >>  ..
> > >>  *  ->i_mutex(generic_file_buffered_write)
> > >>  *->mmap_sem (fault_in_pages_readable->do_page_fault)
> > >>  ..
> > >> I'm confused a litle bit, where is the truth? 
> > >
> > > xfs_write() calls generic_file_direct_write() without taking i_mutex for
> > > O_DIRECT writes.
> > Yes, but my quastion is about __generic_file_aio_write_nolock().
> > As i understand _nolock sufix means that i_mutex was already locked 
> > by caller, am i right ?
> 
> Nope.  It just means that __generic_file_aio_write_nolock() doesn't take
> the lock.  We don't assume or require that the caller took it.  For example
> the raw driver calls generic_file_aio_write_nolock() without taking
> i_mutex.  Raw isn't relevant to the problem (although ocfs2 might be).  But
> we cannot assume that all callers have taken i_mutex, I think.


I think we should also clean up generic_file_aio_write_nolock. This was
brought up a couple of weeks ago and I gave up too early.  Here is my
second attempt.

How about the following patch, I think we can kill generic_file_aio_write_nolock
and merge both *file_aio_write_nolock into one function, then

generic_file_aio_write
ocfs2_file_aio_write
blk_dev->aio_write

all points to a non-lock version of __generic_file_aio_write().  First
two already hold i_mutex, while the block device's aio_write method
doesn't require i_mutex to be held.


Signed-off-by: Ken Chen <[EMAIL PROTECTED]>

diff -Nurp linux-2.6.19/drivers/char/raw.c linux-2.6.19.ken/drivers/char/raw.c
--- linux-2.6.19/drivers/char/raw.c 2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19.ken/drivers/char/raw.c 2006-12-12 16:41:39.0 -0800
@@ -242,7 +242,7 @@ static const struct file_operations raw_
.read   =   do_sync_read,
.aio_read = generic_file_aio_read,
.write  =   do_sync_write,
-   .aio_write =generic_file_aio_write_nolock,
+   .aio_write =__generic_file_aio_write,
.open   =   raw_open,
.release=   raw_release,
.ioctl  =   raw_ioctl,
diff -Nurp linux-2.6.19/fs/block_dev.c linux-2.6.19.ken/fs/block_dev.c
--- linux-2.6.19/fs/block_dev.c 2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19.ken/fs/block_dev.c 2006-12-12 16:47:58.0 -0800
@@ -1198,7 +1198,7 @@ const struct file_operations def_blk_fop
.read   = do_sync_read,
.write  = do_sync_write,
.aio_read   = generic_file_aio_read,
-   .aio_write  = generic_file_aio_write_nolock,
+   .aio_write  = __generic_file_aio_write,
.mmap   = generic_file_mmap,
.fsync  = block_fsync,
.unlocked_ioctl = block_ioctl,
diff -Nurp linux-2.6.19/fs/ocfs2/file.c linux-2.6.19.ken/fs/ocfs2/file.c
--- linux-2.6.19/fs/ocfs2/file.c2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19.ken/fs/ocfs2/file.c2006-12-12 16:42:09.0 -0800
@@ -1107,7 +1107,7 @@ static ssize_t ocfs2_file_aio_write(stru
/* communicate with ocfs2_dio_end_io */
ocfs2_iocb_set_rw_locked(iocb);
 
-   ret = generic_file_aio_write_nolock(iocb, iov, nr_segs, iocb->ki_pos);
+   ret = __generic_file_aio_write(iocb, iov, nr_segs, iocb->ki_pos);
 
/* buffered aio wouldn't have proper lock coverage today */
BUG_ON(ret == -EIOCBQUEUED && !(filp->f_flags & O_DIRECT));
diff -Nurp linux-2.6.19/include/linux/fs.h linux-2.6.19.ken/include/linux/fs.h
--- linux-2.6.19/include/linux/fs.h 2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19.ken/include/linux/fs.h 2006-12-12 16:41:58.0 -0800
@@ -1742,7 +1742,7 @@ extern int file_send_actor(read_descript
 int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int 
isblk);
 extern ssize_t generic_file_aio_read(struct kiocb *, const struct iovec *, 
unsigned long, loff_t);
 extern ssize_t generic_file_aio_write(struct kiocb *, const struct iovec *, 
unsigned long, loff_t);
-extern ssize_t generic_file_aio_write_nolock(struct kiocb *, const struct 
iovec *,
+extern ssize_t __generic_file_aio_write(struct kiocb *, const struct iovec *,
unsigned long, loff_t);
 extern ssize_t generic_file_direct_write(struct kiocb *, const struct iovec *,
unsigned long *, loff_t, loff_t *, size_t, size_t);
diff -Nurp linux-2.6.19/mm/filemap.c linux-2.6.19.ken/mm/filemap.c
--- linux-2.6.19/mm/filemap.c   2006-11-29 13:57:37.0 -0800
+++ linux-2.6.19.ken/mm/filemap.c   2006-12-12 16:47:58.0 -0800
@@ -2219,9 +2219,9 @@ zero_length_segment:
 }
 EXPORT_SYMBOL(generic_file_buffered_write);
 
-static ssize_t
-__generic_file_aio_write_nolock(struct kiocb *iocb, const struct iovec *iov,
-   unsigned long nr_segs, loff_t *pp

Re: mapping PCI registers with write combining (and PAT on x86)...

[Kyle McMartin]

On Tue, Dec 12, 2006 at 02:05:32PM -0800, Roland Dreier wrote:
>   #if defined(__mc68000__)

>   #warning What do we have to do here??
>   #endif
>   if (io_remap_pfn_range(vma, vma->vm_start, off >> PAGE_SHIFT,
>vma->vm_end - vma->vm_start, 
> vma->vm_page_prot))
>   return -EAGAIN;
>   return 0;
> 

Wow, that should probably take the cake for the ugliest snippet
of code in the kernel.

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

Re: Weird code in scripts/kconfig/Makefile

[Jason Baron]

On Tue, 12 Dec 2006, Pete Zaitcev wrote:

> Hi, Roman & All:
> 
> In 2.6.19 (and Linus' curent tree), I found the following:
> 
>   libpath=$$dir/lib; lib=qt; osdir=""; \
>   $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \
> osdir=x$$($(HOSTCXX) -print-multi-os-directory); \
>   test -d $$libpath/$$osdir && libpath=$$libpath/$$osdir; \
> 
> What does the little 'x' do in front of $$(foo)? It looks suspiciously
> like a typo to me.
> 
> I think Jason caught it, but I didn't see a correction sent out.
> 

yes. looks like an error to me too...i left it out of an internal patch to 
this code. Since we are testing for the existence of the directory, it has 
probably gone unnoticed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] connector: Some fixes for ia64 unaligned access errors

[Andrew Morton]

On Tue, 12 Dec 2006 20:31:32 -0600
Erik Jacobson <[EMAIL PROTECTED]> wrote:

> > But it's rather a lot of churn for such a thing.  Did you consider simply 
> > using
> > put_unaligned() against the specific offending field(s)?
> 
> Hi.  This was not considered.
> 
> I wanted to give you some quick feedback, so I tried your suggestion in the
> fork path.  It seemed to fix the problem as well.

OK.

> put_unaligned(timespec_to_ns(&ts), (__u64 *) &ev->timestamp_ns);
> 
> Is what I tried.
> 
> I'm on vacation tomorrow but on Thursday, if you like, I can whip up
> a patch that does this and test it more thoroughly.  Is this the
> direction you prefer?  What I did just now was really quick and dirty
> to see if it has a shot or not but it looks like put_unaligned will
> fix it too.
> 

Well it's a one-liner and it makes it very clear what's going on.  So
unless there's some undiscovered downside, yes, I think it's a good way to
go.  It'll be an easier patch for the -stable guys to swallow too.

There's no particular hurry on 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/

Re: Status of buffered write path (deadlock fixes)

[Trond Myklebust]

On Wed, 2006-12-13 at 12:56 +1100, Nick Piggin wrote:
> Note that these pages should be *really* rare. Definitely even for normal
> filesystems I think RMW would use too much bandwidth if it were required
> for any significant number of writes.

If file "foo" exists on the server, and contains data, then something
like

fd = open("foo", O_WRONLY);
write(fd, "1", 1);

should never need to trigger a read. That's a fairly common workload
when you think about it (happens all the time in apps that do random
write).

> I don't want to mandate anything just yet, so I'm just going through our
> options. The first two options (remove, and RMW) are probably trickier
> than they need to be, given the 3rd option available (temp buffer). Given
> your input, I'm increasingly thinking that the best course of action would
> be to fix this with the temp buffer and look at improving that later if it
> causes a noticable slowdown.

What is the generic problem you are trying to resolve? I saw something
fly by about a reader filling the !uptodate page while the writer is
updating it: how is that going to happen if the writer has the page
locked?
AFAIK the only thing that can modify the page if it is locked (aside
from the process that has locked it) is a process that has the page
mmapped(). However mmapped pages are always uptodate, right?

Trond

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

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[Linus Torvalds]

On Wed, 13 Dec 2006, Nick Piggin wrote:
> 
> parisc seems to, but sparc uses its own open coded spinlock for bitops, and
> the array of regular spinlocks for atomic ops. OTOH, consolidating them
> might give more scalable code *and* a smaller cacheline footprint?

Yeah, I think you'd actually end up with better behaviour by just sharing 
the lock logic, so I don't think there are any downsides there.

> > Should we also just make the rule be that the architecture _must_ allow the
> > silly
> > 
> > (atomic_long_t *) -> (unsigned long *)
> > 
> > casting (so that we can make _one_ generic inline function that takes an
> > atomic_long_t and returns the same pointer as an "unsigned long *" to make
> > bitop functions happy), or would this have to be another arch-specific
> > function?
> > 
> > Comments? 
> 
> AFAIK no architecture does anything special, so maybe a generic converter
> would be best, until one comes along that does. (the only thing of note
> really is that half of the atomics use volatile types and half don't, is
> that a problem?).

No, the cast would cast away any such differences, and since anybody would 
have to use asm for the actual implementation, the code can't care about 
the absense or presense of "volatile" anyway.

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

Re: Status of buffered write path (deadlock fixes)

[Trond Myklebust]

On Wed, 2006-12-13 at 11:53 +1100, Nick Piggin wrote:

> Not silly -- I guess that is the main sticking point. Luckily *most*
> !uptodate pages will be ones that we have newly allocated so will
> not be in pagecache yet.
> 
> If it is in pagecache, we could do one of a number of things: either
> remove it or try to bring it uptodate ourselves. I'm not yet sure if
> either of these actions will cause other problems, though :P
> 
> If both of those are really going to cause problems, then we could
> solve this in a more brute force way (assuming that !uptodate, locked
> pages, in pagecache at this point are very rare -- AFAIKS these will
> only be caused by IO errors?). We could allocate another, temporary
> page and copy the contents into there first, then into the target
> page after the prepare_write.

We are NOT going to mandate read-modify-write behaviour on
prepare_write()/commit_write(). That would be a completely unnecessary
slowdown for write-only workloads on NFS.

Trond

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

Weird code in scripts/kconfig/Makefile

[Pete Zaitcev]

Hi, Roman & All:

In 2.6.19 (and Linus' curent tree), I found the following:

  libpath=$$dir/lib; lib=qt; osdir=""; \
  $(HOSTCXX) -print-multi-os-directory > /dev/null 2>&1 && \
osdir=x$$($(HOSTCXX) -print-multi-os-directory); \
  test -d $$libpath/$$osdir && libpath=$$libpath/$$osdir; \

What does the little 'x' do in front of $$(foo)? It looks suspiciously
like a typo to me.

I think Jason caught it, but I didn't see a correction sent out.

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

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[Nick Piggin]

Linus Torvalds wrote:


On Tue, 12 Dec 2006, Russell King wrote:


This seems to be a very silly question (and I'm bound to be utterly
wrong as proven in my last round) but why are we implementing a new
set of atomic primitives which effectively do the same thing as our
existing set?

Why can't we just use atomic_t for this?



Well, others have answered that ("wrong sizes"), but I'm wavering on using 
atomic_long_t. I have to admit that I'd rather not add a new accessor 
function, when it _should_ be easier to use the current ones.


I agree.

That does depend on every arch maintainer saying they're ok with mixing 
bitops and "atomic*_t"s. It would also require us to at least add some 
_minimal_ function to get at the actual value, and turn the pointer into a 
"unsigned long *" for the bitop functions.


I would _hope_ that people hopefully already use the same locking for 
atomic_t and for bitops, and that arch maintainers could just say "sure, 
that works for me". Obvously, anybody with LL/SC or otherwise just 
basically atomic bitops (which covers a fair part of the spectrum) should 
be ok, but sparc and the usual cast of suspects would have to say that 
it's ok.


parisc seems to, but sparc uses its own open coded spinlock for bitops, and
the array of regular spinlocks for atomic ops. OTOH, consolidating them
might give more scalable code *and* a smaller cacheline footprint?

Should we also just make the rule be that the architecture _must_ allow 
the silly


(atomic_long_t *) -> (unsigned long *)

casting (so that we can make _one_ generic inline function that takes an 
atomic_long_t and returns the same pointer as an "unsigned long *" to make 
bitop functions happy), or would this have to be another arch-specific 
function?


Comments? 


AFAIK no architecture does anything special, so maybe a generic converter
would be best, until one comes along that does. (the only thing of note
really is that half of the atomics use volatile types and half don't, is
that a problem?).

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


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

Re: Status of buffered write path (deadlock fixes)

[Nick Piggin]

Trond Myklebust wrote:

On Wed, 2006-12-13 at 11:53 +1100, Nick Piggin wrote:



Not silly -- I guess that is the main sticking point. Luckily *most*
!uptodate pages will be ones that we have newly allocated so will
not be in pagecache yet.

If it is in pagecache, we could do one of a number of things: either
remove it or try to bring it uptodate ourselves. I'm not yet sure if
either of these actions will cause other problems, though :P

If both of those are really going to cause problems, then we could
solve this in a more brute force way (assuming that !uptodate, locked
pages, in pagecache at this point are very rare -- AFAIKS these will
only be caused by IO errors?). We could allocate another, temporary
page and copy the contents into there first, then into the target
page after the prepare_write.



We are NOT going to mandate read-modify-write behaviour on
prepare_write()/commit_write(). That would be a completely unnecessary
slowdown for write-only workloads on NFS.


Note that these pages should be *really* rare. Definitely even for normal
filesystems I think RMW would use too much bandwidth if it were required
for any significant number of writes.

I don't want to mandate anything just yet, so I'm just going through our
options. The first two options (remove, and RMW) are probably trickier
than they need to be, given the 3rd option available (temp buffer). Given
your input, I'm increasingly thinking that the best course of action would
be to fix this with the temp buffer and look at improving that later if it
causes a noticable slowdown.

Thanks,
Nick

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 


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

Re: [Fastboot] [PATCH] free initrds boot option

[Horms]

On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > >Is there a kexec-tools patch too? How does second kernel know about
> > >the location of the first kernel's initrd to be reused?
> > >  
> > >
> > kexec-tools has to be modified to pass the first kernel initrd. On 
> > powerpc, initrd locations are exported using device-tree. At present, 
> > kexec-tool ignores the first kernel initrd property values and creates 
> > new initrd properties if the user passes '--initrd' option to the kexec 
> > command. So, will be an issue unless first kernel device-tree is passed 
> > as buffer.
> 
> We've been using the --devicetreeblob kexec-tools option available for
> POWERPC.  This enables you to setup the device tree (and hence, the
> initrd points) as you like.
> 
> I'm happy to put together a patch for kexec-tools. 

Please do. And please cc me on a copy that applies against kexec-tools-testing.

> Unfortunately this
> is arch specific.  A quick look through the x86, ia64, s390 and ppc64
> code shows the --initrd option for all these just reads the specified
> initrd file, pushes it out to memory and uses the base and size pointers
> to setup the next boot.  We'd obviously just skip to the last stage.
> 
> So what's the kexec-tools option called?  --initrd-location  ?

That sounds fine to me. I think its ok to make it arch specific for
starters and then move it out to generic code later. That said, if
you're feeling particularly entergetic, feel free to do the generic
stuff now and just add null stubs for the other architectures (does
that makes sense?).

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.19-mm1

[Andrew Morton]

On Wed, 13 Dec 2006 09:17:42 +0800
Conke Hu <[EMAIL PROTECTED]> wrote:

> Thank you for applying ATI SB600 SATA patch!
> But it seems the patch file name should be
> "ati"-sb600-sata-quirk.patch, not "via"-sb600-sata-quirk.patch, type
> error? :)

That's the sort of thing which happens when people send me patches titled
"Re: -mm merge plans for 2.6.20".  I guess, and I don't spend a lot of time
over it, either.


> BTW, the following line in ide/pci/atiixp.c had better be removed
> since there would be no legacy ide mode any more after this patch is
> applied.
> "{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_SATA, PCI_ANY_ID,
> PCI_ANY_ID, (PCI_CLASS_STORAGE_IDE<<8)|0x8a, 0x05, 1},"

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

Re: [2.6 patch] drivers/net/loopback.c: convert to module_init()

[David Miller]

From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 17:24:35 +0100

> This patch converts drivers/net/loopback.c to using module_init().
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

I'm not %100 sure of this one, let's look at the comment you
are deleting:

> -/*
> - *   The loopback device is global so it can be directly referenced
> - *   by the network code. Also, it must be first on device list.
> - */
> -extern int loopback_init(void);
> -

in particular notice the part that says "it must be first on the
device list".

I'm not sure whether that is important any longer.  It probably isn't,
but we should verify it before applying such a patch.

Since module_init() effectively == device_initcall() for statically
built objects, which loopback always is, the Makefile ordering does
not seem to indicate to me that there is anything guarenteeing
this "first on the list" invariant.  At least not via object
file ordering.

So this gives some support to the idea that loopback_dev's position
on the device list no longer matters.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[Linus Torvalds]

On Tue, 12 Dec 2006, Russell King wrote:
> 
> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
> 
> Why can't we just use atomic_t for this?

Well, others have answered that ("wrong sizes"), but I'm wavering on using 
atomic_long_t. I have to admit that I'd rather not add a new accessor 
function, when it _should_ be easier to use the current ones.

That does depend on every arch maintainer saying they're ok with mixing 
bitops and "atomic*_t"s. It would also require us to at least add some 
_minimal_ function to get at the actual value, and turn the pointer into a 
"unsigned long *" for the bitop functions.

I would _hope_ that people hopefully already use the same locking for 
atomic_t and for bitops, and that arch maintainers could just say "sure, 
that works for me". Obvously, anybody with LL/SC or otherwise just 
basically atomic bitops (which covers a fair part of the spectrum) should 
be ok, but sparc and the usual cast of suspects would have to say that 
it's ok.

Should we also just make the rule be that the architecture _must_ allow 
the silly

(atomic_long_t *) -> (unsigned long *)

casting (so that we can make _one_ generic inline function that takes an 
atomic_long_t and returns the same pointer as an "unsigned long *" to make 
bitop functions happy), or would this have to be another arch-specific 
function?

Comments? 

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

Re: [PATCH 010 of 14] knfsd: SUNRPC: add a "generic" function to see if the peer uses a secure port

[Andrew Morton]

On Wed, 13 Dec 2006 10:59:27 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:

> From: Chuck Lever <[EMAIL PROTECTED]>
> The only reason svcsock.c looks at a sockaddr's port is to check whether
> the remote peer is connecting from a privileged port.  Refactor this check
> to hide processing that is specific to address format.
> 
> Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
> Cc: Aurelien Charbon <[EMAIL PROTECTED]>
> Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
> 
> ### Diffstat output
>  ./net/sunrpc/svcsock.c |   20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
> --- .prev/net/sunrpc/svcsock.c2006-12-13 10:32:15.0 +1100
> +++ ./net/sunrpc/svcsock.c2006-12-13 10:32:17.0 +1100
> @@ -926,6 +926,20 @@ svc_tcp_data_ready(struct sock *sk, int 
>   wake_up_interruptible(sk->sk_sleep);
>  }
>  
> +static inline int svc_port_is_privileged(struct sockaddr *sin)
> +{
> + switch (sin->sa_family) {
> + case AF_INET:
> + return ntohs(((struct sockaddr_in *)sin)->sin_port) < 1024;
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> + case AF_INET6:
> + return ntohs(((struct sockaddr_in6 *)sin)->sin6_port) < 1024;
> +#endif
> + default:
> + return 0;
> + }
> +}

I'm a bit surprised to see this test implemented in sunrpc - it's the sort
of thing which core networking should implement?

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

Re: [patch 2.6.19-git] RTC Kconfig sorted by type

[David Brownell]

> > +if RTC_CLASS != n
> > +
> 
> 
> if RTC_CLASS
> 
> 
> because otherwise

Thanks for the clarification.  I think Alessandro was going to
redo this one soon, since the Kconfig changed so much the patch
would no longer apply.  I trust he'll remember your comments!

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

RFC: UML: remove MODE_TT?

[Adrian Bunk]

MODE_TT is both marked as deprecated and marked as BROKEN.

Would a patch to remove MODE_TT, always enable MODE_SKAS, and doing all 
possible cleanups after this be accepted?

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: cfq performance gap

[AVANTIKA R. MATHUR]

Jens Axboe wrote:

On Fri, Dec 08 2006, Avantika Mathur wrote:
  

On Fri, 2006-12-08 at 13:05 +0100, Jens Axboe wrote:


On Thu, Dec 07 2006, Avantika Mathur wrote:
  

Hi Jens,


(you probably noticed now, but the [EMAIL PROTECTED] email is no longer
valid)
  

I saw that, thanks!


I've noticed a performance gap between the cfq scheduler and other io
schedulers when running the rawio benchmark.

The benchmark workload is 16 processes running 4k random reads.

Is this performance gap a known issue?


CFQ could be a little slower at this benchmark, but your results are
much worse than I would expect. What is the queueing depth of sda? How
are you invoking rawio?
  

I am running rawio with the following options:
rawread -p 16 -m 1 -d 1 -x -z -t 0 -s 4096

The queue depth on sda is 4.


Your runtime is very low, how does it look if you allow the test to run
for much longer? 30MiB/sec random read bandwidth seems very high, I'm
wondering what exactly is being tested here.
  

rawio is actually performing sequential reads, but I don't believe it is
purely sequential with the multiple processes.
I am currently running the test with longer runtimes and will post
results once it is complete.
I've also attached the rawio source.



It's certainly the slice and idling hurting here. But at the same time,
I don't really think your test case is very interesting. The test area
is very small and you have 16 threads trying to read the same thing,
optimizing for that would be silly as I don't think it has much real
world relevance.

  

Could a database have similar workload to this test?

That said, I might add some logic to detect when we can cheaply switch
queues instead of waiting for a new request from the same queue.
Averaging slice times over a period of time instead of 1:1 with that
logic, should help cases like this while still being fair.
  

Thank you for looking at this issue.
I've found an IBM/SUSE bugzilla bug for the same performance gap on 
rawio. There was a fix for this bug included in SLES10-RC1, do you know 
why it was not added in mainline?


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

Re: xfslogd-spinlock bug?

[Haar János]

Hello, Justin,

This is a 64bit system.

But i cannot understand, what is the curious? :-)

I am not a kernel developer, and not a C programmer, but the long pointers
shows me, the 64 bit.
Or am i on the wrong clue? :-)

Anyway, this issue happens for me about daily, or max 2-3 day often.
But i have no idea what cause this exactly.
The 2.6.16.18 was stable for me a long time, and one day starts to tricking
me, and happens more and more often.
Thats why i thinking some bad part of the (14TB) FS on the disks.

(this fs have a lot of errors, what the xfs_repair cannot be corrected, but
anyway this is a productive system, and works well, except this issue.
Some months before i have replaced the parity disk in one of the RAID4
array, and the next day, during the resync process, another one disk died.
I almost lost everything, but thanks to the raid4, and mdadm, i have
successfully recovered a lot of data with the 1 day older parity-only drive.
This was really bad, and leave some scars on the fs. )

This issue looks like for me a race condition between the cpus. (2x Xeon HT)

Am i right? :-)

Thanks,

Janos




- Original Message - 
From: "Justin Piszcz" <[EMAIL PROTECTED]>
To: "Haar János" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; 
Sent: Tuesday, December 12, 2006 3:32 PM
Subject: Re: xfslogd-spinlock bug?


I'm not sure what is causing this problem but I was curious is this on a
32bit or 64bit platform?

Justin.

On Tue, 12 Dec 2006, Haar János wrote:

> Hello, list,
>
> I am the "big red button men" with the one big 14TB xfs, if somebody can
> remember me. :-)
>
> Now i found something in the 2.6.16.18, and try the 2.6.18.4, and the
> 2.6.19, but the bug still exists:
>
> Dec 11 22:47:21 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317
> Dec 11 22:47:21 dy-base general protection fault:  [1]
> Dec 11 22:47:21 dy-base SMP
> Dec 11 22:47:21 dy-base
> Dec 11 22:47:21 dy-base CPU 3
> Dec 11 22:47:21 dy-base
> Dec 11 22:47:21 dy-base Modules linked in:
> Dec 11 22:47:21 dy-base  nbd
> Dec 11 22:47:21 dy-base  rd
> Dec 11 22:47:21 dy-base  netconsole
> Dec 11 22:47:21 dy-base  e1000
> Dec 11 22:47:21 dy-base  video
> Dec 11 22:47:21 dy-base
> Dec 11 22:47:21 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1
> Dec 11 22:47:21 dy-base RIP: 0010:[]
> Dec 11 22:47:21 dy-base  [] spin_bug+0x69/0xdf
> Dec 11 22:47:21 dy-base RSP: 0018:81011fb89bc0  EFLAGS: 00010002
> Dec 11 22:47:21 dy-base RAX: 0033 RBX: 6b6b6b6b6b6b6b6b RCX:
> 
> Dec 11 22:47:21 dy-base RDX: 808137a0 RSI: 0082 RDI:
> 0001
> Dec 11 22:47:21 dy-base RBP: 81011fb89be0 R08: 00026a70 R09:
> 6b6b6b6b
> Dec 11 22:47:21 dy-base R10: 0082 R11: 81000584d380 R12:
> 8100db92ad80
> Dec 11 22:47:21 dy-base R13: 80642dc6 R14:  R15:
> 0003
> Dec 11 22:47:21 dy-base FS:  ()
> GS:81011fc76b90() knlGS:
> Dec 11 22:47:21 dy-base CS:  0010 DS: 0018 ES: 0018 CR0: 8005003b
> Dec 11 22:47:21 dy-base CR2: 2ba00770 CR3: 000108c05000 CR4:
> 06e0
> Dec 11 22:47:21 dy-base Process xfslogd/3 (pid: 317, threadinfo
> 81011fb88000, task 81011fa7f830)
> Dec 11 22:47:21 dy-base Stack:
> Dec 11 22:47:21 dy-base  81011fb89be0
> Dec 11 22:47:21 dy-base  8100db92ad80
> Dec 11 22:47:21 dy-base  
> Dec 11 22:47:21 dy-base  
> Dec 11 22:47:21 dy-base
> Dec 11 22:47:21 dy-base  81011fb89c10
> Dec 11 22:47:21 dy-base  803f3bdc
> Dec 11 22:47:21 dy-base  0282
> Dec 11 22:47:21 dy-base  
> Dec 11 22:47:21 dy-base
> Dec 11 22:47:21 dy-base  
> Dec 11 22:47:21 dy-base  
> Dec 11 22:47:21 dy-base  81011fb89c30
> Dec 11 22:47:21 dy-base  805e7f2b
> Dec 11 22:47:21 dy-base
> Dec 11 22:47:21 dy-base Call Trace:
> Dec 11 22:47:21 dy-base  [] _raw_spin_lock+0x23/0xf1
> Dec 11 22:47:21 dy-base  [] _spin_lock_irqsave+0x11/0x18
> Dec 11 22:47:21 dy-base  [] __wake_up+0x22/0x50
> Dec 11 22:47:21 dy-base  [] xfs_buf_unpin+0x21/0x23
> Dec 11 22:47:21 dy-base  [] xfs_buf_item_unpin+0x2e/0xa6
> Dec 11 22:47:21 dy-base  []
> xfs_trans_chunk_committed+0xc3/0xf7
> Dec 11 22:47:21 dy-base  []
xfs_trans_committed+0x49/0xde
> Dec 11 22:47:21 dy-base  []
> xlog_state_do_callback+0x185/0x33f
> Dec 11 22:47:21 dy-base  [] xlog_iodone+0x104/0x131
> Dec 11 22:47:22 dy-base  []
xfs_buf_iodone_work+0x1a/0x3e
> Dec 11 22:47:22 dy-base  [] worker_thread+0x0/0x134
> Dec 11 22:47:22 dy-base  [] run_workqueue+0xa8/0xf8
> Dec 11 22:47:22 dy-base  [] xfs_buf_iodone_work+0x0/0x3e
> Dec 11 22:47:22 dy-base  [] worker_thread+0x0/0x134
> Dec 11 22:47:22 dy-base  [] worker_thread+0xfb/0x134
> Dec 11 22:47:22 dy-base  []
default_wake_function+0x0/0xf
> Dec 11 22:47:22 dy-base  [] worker_thread+0x0/0x134
> Dec 11 22:47:22 dy-base  [] kthread+0xd8/0x10b
> Dec 11 22:47:22 

Re: [patch] lockdep: fix seqlock_init()

[Ingo Molnar]

* Andrew Morton <[EMAIL PROTECTED]> wrote:

> > > > +#define seqlock_init(x)\
> > > > +   do {\
> > > > +   (x)->sequence = 0;  \
> > > > +   spin_lock_init(&(x)->lock); \
> > > > +   } while (0)
> > > 
> > > This does not have to be a macro, does it?
> > 
> > Maybe it could be an __always_inline inline function (it has to be 
> > inlined to get the callsite based lock class key right)
> 
> the compiler darn better inline it, else we'll have an out-of-line 
> copy of everything in everywhere.

the compiler will do the uninlining happily if it sees a size advantage 
(when a single .c module calls the function several times), and creates 
a private per-object-file uninlined function. So an __always_inline 
would definitely be needed.

> > - but i'm not 
> > sure about the include file dependencies. Will probably work out fine as 
> > seqlock.h is supposed to be a late one in the order of inclusion - but i 
> > didnt want to make a blind bet.
> 
> seqlock.h already includes spinlock.h.

yes ... i just preserved the status quo.

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: -mm merge plans for 2.6.20

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Tue, 12 Dec 2006 12:49:09 -0500, Dave Jones wrote:

> EFLAGS: 00010246   (2.6.18-1.2849.fc6 #1) 

> That was from a 2.6.18.3 kernel iirc.

Here's an idea from Michael Tokarev <[EMAIL PROTECTED]>:
since .version always contains 1 when you build an RPM,
you can modify it and put your base kernel version there
during the build. Then you would see:

EFLAGS: 00010246   (2.6.18-1.2849.fc6 #2.6.18.3)

-- 
MBTI: IXTP

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] net, 8139too.c: fix netpoll deadlock

[Ingo Molnar]

* Francois Romieu <[EMAIL PROTECTED]> wrote:

> > (I'll queue it, if Linus doesn't pick it up; please CC me in the 
> > future)
> 
> I have lived with the "NAPI ->poll() handler runs in BH irq enabled 
> context" rule for years. Is it definitely false/dead ?
> 
> If so at least 8139cp needs the same fix.

hm, this isnt really about NAPI polling, but about the 
netconsole/netpoll/netdump poll_controller() handler.

with netconsole, printk can be called from IRQ context (and is 
frequently from IRQ context during bootup or module initialization), so 
a BH rule isnt enough for them.

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: [PATCH 2/5] Paravirt cpu batching.patch

[Zachary Amsden]

Chuck Ebbert wrote:

In-Reply-To: <[EMAIL PROTECTED]>

On Tue, 12 Dec 2006 14:54:30 -0800, Chros Wright wrote:

  

--- a/arch/i386/kernel/process.cTue Dec 12 13:50:50 2006 -0800
+++ b/arch/i386/kernel/process.cTue Dec 12 13:50:53 2006 -0800
@@ -665,6 +665,37 @@ struct task_struct fastcall * __switch_t
load_TLS(next, cpu);
 
/*

+* Restore IOPL if needed.
+*/
+   if (unlikely(prev->iopl != next->iopl))
+   set_iopl_mask(next->iopl);
  

Small sidenote that this bit undoes a recent change from Chuck Ebbert, which
killed iopl_mask update via hypervisor.



This whole thing needs a proper fix IMO.  I posted something a while back
but Andi didn't like it, I guess.
  


We can handle this one with an #ifdef CONFIG_PARAVIRT, though.

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

Re: [PATCH 2.6.19-rc1] Toshiba TC86C001 IDE driver

[Bartlomiej Zolnierkiewicz]

On 12/13/06, Alan <[EMAIL PROTECTED]> wrote:


> +static int tc86c001_busproc(ide_drive_t *drive, int state)
> +{

Waste of space having a busproc routine. The maintainer removed all the
usable hotplug support from old IDE so this might as well be dropped.


I took over IDE when hotplug was already broken (late 2.5), moreover IDE
hotplug support has been always a quick hack according to its original author...
I remember your great efforts to fix it but unfortunately they
depended on executing
ioctls on non-existing devices which made them depend on layering
violation in 2.6,
also IDE device model fixes has some conflicts with them.  I take the
blame for not
applying them (for the reasons given above) and for taking much too
long in reviewing/testing them (due to lack of time not bad intention)
but accusing me of
intentional feature removal is going a bit too far...  You can hate me
all you want
for the way I did my entirely volunteer and unpaid job (but hey there
were and still is shortage of ATA hackers and there weren't anybody to
step up and takeover IDE)
but I actually have always taken responsibility/blame for all my
patches and patches
I accepted so if you really think I intentionally removed some usable
hotplug support
please point me to specific patch and describe the regression after
applying this
specific patch and I will do my best to have this regression fixed...

Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] connector: Some fixes for ia64 unaligned access errors

[Andrew Morton]

On Tue, 12 Dec 2006 11:54:11 -0600
Erik Jacobson <[EMAIL PROTECTED]> wrote:

> Hi Andrew.
> 
> There was some discussion on this patch but I believe we've agreed
> on the first version I sent.  This was ACKed by Matt Helsley.
> 
> Would you consider taking this in to -mm?
> 
> I've included my original patch email at the bottom.
> 

I'm a bit late to the party.

>  cn_proc.c |   94 
> +++---

But it's rather a lot of churn for such a thing.  Did you consider simply using
put_unaligned() against the specific offending field(s)?

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

Re: Status of buffered write path (deadlock fixes)

[Nick Piggin]

Mark Fasheh wrote:

On Tue, Dec 12, 2006 at 02:52:26AM +1100, Nick Piggin wrote:


Nick Piggin wrote:

Hmm, doesn't look like we can do this either because at least GFS2
uses BH_New for its own special things.

Also, I don't know if the trick of only walking over BH_New buffers
will work anyway, since we may still need to release resources on
other buffers as well.



Oh, my idea was that only the range passed to ->commit() would be walked,
but any BH_New buffers (regardless of where they are in the page) would be
passed to the journal as well. So the logic would be:

for all the buffers in the page:
  If the buffer is new, or it is within the range passed to commit, pass to
  the journal.

Is there anything I'm still missing here?


If the buffer is not new, outside the commit range (and inside the prepare),
then it does not get passed to the journal. I'm not familiar with jbd, but
this seems that it could cause a problem eg. in data journalling mode?


As you say, filesystems are simply not set up to expect this, which is a
problem.

Maybe it isn't realistic to change the API this way, no matter how
bad it is presently.



We definitely agree. It's not intuitive that the range should change
between ->prepare_write() and ->commit_write() and IMHO, all the issues
we've found are good evidence that this particular approach will be
problematic.


Yes.


What if we tackle the problem a different way?

1. In the case of no page in the pagecache (or an otherwise
!uptodate page), if the operation is a full-page write then we
first copy all the user data *then* lock the page *then* insert it
into pagecache and go on to call into the filesystem.



Silly question - what's preventing a reader from filling the !uptodate page 
with disk
data while the writer is copying the user buffer into it?


Not silly -- I guess that is the main sticking point. Luckily *most*
!uptodate pages will be ones that we have newly allocated so will
not be in pagecache yet.

If it is in pagecache, we could do one of a number of things: either
remove it or try to bring it uptodate ourselves. I'm not yet sure if
either of these actions will cause other problems, though :P

If both of those are really going to cause problems, then we could
solve this in a more brute force way (assuming that !uptodate, locked
pages, in pagecache at this point are very rare -- AFAIKS these will
only be caused by IO errors?). We could allocate another, temporary
page and copy the contents into there first, then into the target
page after the prepare_write.


2. In the case of a !uptodate page and a partial-page write, then
we can first bring the page uptodate, then continue (goto 3).

3. In the case of an uptodate page, we could perform a full-length
commit_write so long as we didn't expand i_size further than was
copied, and were sure to trim off blocks allocated past that
point.

This scheme IMO is not as "nice" as the partial commit patches,
but in practical terms it may be much more realistic.



It seems more realistic in that it makes sure the write is properly setup
before calling into the file system. What do you think is not as nice about
it?


The corner cases. However I guess the current scheme was building up
corner cases as well, so you might be right.

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


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

Re: 2.6.19-mm1 (md/raid1 randomly drops partitions - possible sata_uli problem)

[Neil Brown]

On Tuesday December 12, [EMAIL PROTECTED] wrote:
> > 
> > So when md writes to write out the superblock, to gets EIO... Odd that
> > you aren't getting errors for normal writes.
> > 
> > What devices are the md/raid1 built on?
> 
> Sata drives, on sata_uli.
> 
> > > 
> > > I'll try to reproduce it tomorrow and collect some more information.
> > 
> > Thanks.  More information is definitely better than less, so send over
> > anything you can find.
> 
> Okay, seems to be readily reproducible, dmesg output from the failing kernel
> attached.

Weird.  You are getting silent write errors...

Can you write to these drives are all? e.g.

  dd if=/dev/sdb3 of=/tmp/tmp count=1
  dd if=/tmp/tmp of=/dev/sdb3 oflag=direct

(hopefully 'direct' will cause write errors to be passed up).

I really think this looks like a sata problem, not an md problem.

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

Re: BUG: unable to handle kernel paging request in 2.6.19-git

[Randy Dunlap]

On Tue, 12 Dec 2006 07:48:51 +0100 (CET) Ben Castricum wrote:

> 
> This bug started to show up after the release of 2.6.19 (iirc plain 2.6.19
> was still working fine).
> 
> The full dmesg is at
> http://www.bencastricum.nl/lk/bootmessages-2.6.19-g9202f325.log,
> and the .config http://www.bencastricum.nl/lk/config-g9202f325.log
> 
> I haven't tried disabling CONFIG_PCI_MULTITHREAD_PROBE. But if this
> might help in someway I'll give it a shot.

Yes, it appears to be that config option.  Please disable it
and retest and re-report.


> Thanks,
> Ben
> 
> e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
> e100: Copyright(c) 1999-2006 Intel Corporation
> BUG: unable to handle kernel paging request at virtual address d880a000
>  printing eip:
> d880a000
> *pde = 01382067
> *pte = 
> Oops:  [#1]
> Modules linked in: e100 mii ext2 unix
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010282   (2.6.19-g9202f325 #15)
> EIP is at 0xd880a000
> eax: c13c9000   ebx: d8876fe0   ecx: d8876470   edx: d8876470
> esi: d8876fe0   edi: ffed   ebp: d8877014   esp: d7a15f7c
> ds: 007b   es: 007b   ss: 0068
> Process probe-:00:0 (pid: 72, ti=d7a14000 task=d7828560
> task.ti=d7a14000)
> Stack: c01b009a c13c9000 c01b00ec d8876fe0 c13c9000  c01b0126
> c13c9048
>d7821560 c0205b27 d7821560 1fcc 6ab5e081 4ada d7acded0
> d7821560
>c0205aa0 fffc c0128186 0001   c01280d0
> 
> Call Trace:
>  [] pci_call_probe+0xa/0x10
>  [] __pci_device_probe+0x4c/0x60
>  [] pci_device_probe+0x26/0x50
>  [] really_probe+0x87/0x100
>  [] really_probe+0x0/0x100
>  [] kthread+0xb6/0xc0
>  [] kthread+0x0/0xc0
>  [] kernel_thread_helper+0x7/0x14
>  ===
> Code:  Bad EIP value.
> EIP: [] 0xd880a000 SS:ESP 0068:d7a15f7c

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

Re: [patch 2.6.19-git] rtc, remove syslog spam on registration

[Alessandro Zummo]

On Tue, 12 Dec 2006 11:23:55 -0800
David Brownell <[EMAIL PROTECTED]> wrote:

> This removes some syslog spam as RTC drivers register; debug messages 
> shouldn't come out at "info" level.
> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>

 Thanks David,

   please also cc [EMAIL PROTECTED] on future patches.


 Acked-by: Alessandro Zummo <[EMAIL PROTECTED]>
-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.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/

Re: [patch 2.6.19-git] rtc framework: rtc_wkalrm.enabled reporting updates

[Alessandro Zummo]

On Tue, 12 Dec 2006 11:49:13 -0800
David Brownell <[EMAIL PROTECTED]> wrote:

> Fix a glitch in the procfs dumping of whether the alarm IRQ is enabled:
> use the traditional name (from drivers/char/rtc.c and many other places)
> of "alarm_IRQ", not "alrm_wakeup" (which didn't even match the efirtc
> code, which originated that reporting API).
> 
> Also, update a few of the RTC drivers to stop providing that duplicate
> status, and/or to expose it properly when reporting the alarm state.
> We really don't want every RTC driver doing their own thing here...
> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>

 Acked-by: Alessandro Zummo <[EMAIL PROTECTED]>

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.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/

Re: [PATCH 2/5] Paravirt cpu batching.patch

[Jeremy Fitzhardinge]

Chuck Ebbert wrote:
> This whole thing needs a proper fix IMO.  I posted something a while back
> but Andi didn't like it, I guess.
>   

What's a quick summary of the issue again?

J

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

Re: Support 2.4 modules features in 2.6

[Robert Hancock]

Jaswinder Singh wrote:

you only need include/* for this in 2.6

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

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


Really!!

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

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

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


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

now make it.


Of course you can't, there are no kernel header files left.



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


Those are userspace header files, not for building modules. They may 
have worked in certain setups for doing this in the past but this was 
never recommended. Current distributions no longer include any 
kernel-internal headers in /usr/include anymore.


You do need at least a partial kernel source tree to build modules against.

--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

Re: Revised [PATCH 1/2]: define inline for test of channel error state

[Greg KH]

On Tue, Dec 12, 2006 at 04:55:59PM -0600, Linas Vepstas wrote:
> Greg,
> 
> Per discussion, a revised patch. Silly me, the value was already
> initialized in drivers/pci/probe.c and I'd been dragging along
> a prehistoric version of the if checks.
> 
> --linas
> 
> [PATCH 1/2]: define inline for test of pci channel error state

care to resend 2/2 also?  It's best to resend entire series, otherwise I
have to go dig for it, and it will take me a while to remember to do
that...

thanks,

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

Re: [PATCH 2.6.19-rc1] Toshiba TC86C001 IDE driver

[Alan]

On Wed, 13 Dec 2006 01:48:34 +0300
Sergei Shtylyov <[EMAIL PROTECTED]> wrote:

> Behold!  This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
> completely reworked from the original brain-damaged Toshiba's 2.4 version.

Actually un-nack the PCI quirk. While it is true the native mode is
relevant because of the way the BAR values work we know legacy bar values
are never "& 8" so the test is sufficient [but should be commented about
the assumption]

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: mapping PCI registers with write combining (and PAT on x86)...

[Eric W. Biederman]

Roland Dreier <[EMAIL PROTECTED]> writes:

>  > So I think we may simplify this but there is pci_mmap_page_range.  That
>  > already handles this for the architectures that currently support it.
>  > So it is probably the case the fbdev should be changed to use that.
>
> Thanks... I was not aware of pci_mmap_page_range(), but that doesn't
> seem to be quite the right interface.  It uses vma->vm_pgoff to say
> what to remap.  A typical use for what I have in mind would be for a
> userspace process to open a magic file and do mmap() at some
> well-known offset (like 0), and have the kernel driver map the right
> PCI registers into userspace, without userspace having to know what
> offset to ask for.
>
> This is especially important when the kernel has to handle picking a
> "context" or "port" to avoid multiple userspace processes stepping on
> each other.

Agreed.  But I think it is a healthier starting point then the fbdev
location.  A little refactoring and we should be able to handle
the generic case.

> And of course arch/i386/pci/i386.c has the following in its
> pci_mmap_page_range() anyway:
>
>   /* Write-combine setting is ignored, it is changed via the mtrr
>* interfaces on this platform.
>*/
>
> so the write_combine parameter is ignored...

Yes.  Although my earlier patch fixed that :)

It is also worth nothing that the pci prefetchable attribute 
says that write-combining is safe through that bar.

>  > No one had any serious objections to my patches as they were.  The actual
>  > problem was that the patches were incomplete.  In particular if you
>  > mismatch page protections it is possible to get silent data corruption
>  > or processor crashes.  So we need checks to ensure all mappings of
>  > a given page are using the same protections.
>  > 
>  > To a certain extent I think adding those checks really is a strawman
>  > and should not stop the merge effort, because we have this feature and
>  > those possible bugs on other architectures right now and we don't have
>  > those checks.  But I also think in the long term we need them, it just
>  > requires several days of going through the mm so we don't leave any
>  > path uncovered.
>
> It does seem somewhat hard to make sure there aren't multiple mappings
> of the same thing, and I'm not sure it's worth trying to avoid it.  If
> a device driver lets me mmap PCI memory with write-combining on, and
> then (as root) I mmap raw PCI resources to get the same memory, whose
> fault is it if things break?
>
> I'm kind of an mm dummy but I don't even see a good way to avoid
> multiple mappings like that.

It is possible.  It is just a matter of looking for other mappings of the
same thing, and seeing if one exists seeing if it has the mapping
attributes you are asking for.  We have reverse mappings and
the basic infrastructure.

The justification for pursuing reverse mappings really is that it is
less work than taking weeks tracing down the one bug caused by
allowing this and then silently corrupting data.

The obvious problem comes when one mapping is write combined and
the other mapping is write back.

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: Support 2.4 modules features in 2.6

[Matthias Schniedermeyer]

Jaswinder Singh wrote:
> Hello,
> 
> I want to support old 2.4 modules features in 2.6 kernel modules:-
> 1. no kernel source tree is required to build modules.

I don't think that is possible.

There are a few "questions" that are quite fundamental when you want to
build a module that can be loaded by a given kernel.

About the most important fundamental "questions" i can think of ATM:
- UP/SMP
- Preempt yes/no
- RegParm yes/no
(x86)- High Memory off/4g/64G(IOW PAE yes/no)
And maybe a few more "not so fundamental" points.

AFAIK there is no way to build a module that would work in all of the
8/16 possible "kernel-types" you get with these 3/4 fundamental options
alone.





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 008 of 14] knfsd: SUNRPC: Make rq_daddr field address-version independent

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
The rq_daddr field must support larger addresses.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./include/linux/sunrpc/svc.h |   15 +++
 ./net/sunrpc/svcsock.c   |4 ++--
 2 files changed, 13 insertions(+), 6 deletions(-)

diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2006-12-13 10:31:37.0 +1100
+++ ./include/linux/sunrpc/svc.h2006-12-13 10:32:10.0 +1100
@@ -11,6 +11,7 @@
 #define SUNRPC_SVC_H
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -188,7 +189,13 @@ static inline void svc_putu32(struct kve
iov->iov_len += sizeof(__be32);
 }
 
-   
+union svc_addr_u {
+struct in_addr addr;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+struct in6_addraddr6;
+#endif
+};
+
 /*
  * The context of a single thread, including the request currently being
  * processed.
@@ -224,8 +231,8 @@ struct svc_rqst {
unsigned short
rq_secure  : 1; /* secure port */
 
-
-   __be32  rq_daddr;   /* dest addr of request - reply 
from here */
+   union svc_addr_urq_daddr;   /* dest addr of request -
+* reply from here */
 
void *  rq_argp;/* decoded arguments */
void *  rq_resp;/* xdr'd results */
@@ -305,7 +312,7 @@ struct svc_deferred_req {
struct sockaddr_storage addr;
int addrlen;
struct svc_sock *svsk;  /* where reply must go */
-   __be32  daddr;  /* where reply must come from */
+   union svc_addr_udaddr;  /* where reply must come from */
struct cache_deferred_req handle;
int argslen;
__be32  args[0];

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:31:37.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:31:39.0 +1100
@@ -476,7 +476,7 @@ svc_sendto(struct svc_rqst *rqstp, struc
cmh->cmsg_level = SOL_IP;
cmh->cmsg_type = IP_PKTINFO;
pki->ipi_ifindex = 0;
-   pki->ipi_spec_dst.s_addr = rqstp->rq_daddr;
+   pki->ipi_spec_dst.s_addr = rqstp->rq_daddr.addr.s_addr;
 
if (sock_sendmsg(sock, &msg, 0) < 0)
goto out;
@@ -747,7 +747,7 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
sin->sin_family = AF_INET;
sin->sin_port = skb->h.uh->source;
sin->sin_addr.s_addr = skb->nh.iph->saddr;
-   rqstp->rq_daddr = skb->nh.iph->daddr;
+   rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
 
if (skb_is_nonlinear(skb)) {
/* we have to copy */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 007 of 14] knfsd: SUNRPC: Provide room in svc_rqst for larger addresses

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Expand the rq_addr field to allow it to contain larger addresses.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/lockd/host.c|2 +-
 ./fs/lockd/svc4proc.c|6 --
 ./fs/lockd/svcproc.c |6 --
 ./fs/nfs/callback.c  |2 +-
 ./fs/nfs/callback_xdr.c  |4 ++--
 ./fs/nfsd/nfs4state.c|   18 +-
 ./fs/nfsd/nfscache.c |2 +-
 ./include/linux/sunrpc/svc.h |   15 ++-
 ./net/sunrpc/svcauth_unix.c  |3 ++-
 ./net/sunrpc/svcsock.c   |   16 +---
 10 files changed, 47 insertions(+), 27 deletions(-)

diff .prev/fs/lockd/host.c ./fs/lockd/host.c
--- .prev/fs/lockd/host.c   2006-12-13 10:28:51.0 +1100
+++ ./fs/lockd/host.c   2006-12-13 10:31:37.0 +1100
@@ -192,7 +192,7 @@ struct nlm_host *
 nlmsvc_lookup_host(struct svc_rqst *rqstp,
const char *hostname, int hostname_len)
 {
-   return nlm_lookup_host(1, &rqstp->rq_addr,
+   return nlm_lookup_host(1, svc_addr_in(rqstp),
   rqstp->rq_prot, rqstp->rq_vers,
   hostname, hostname_len);
 }

diff .prev/fs/lockd/svc4proc.c ./fs/lockd/svc4proc.c
--- .prev/fs/lockd/svc4proc.c   2006-12-13 10:29:44.0 +1100
+++ ./fs/lockd/svc4proc.c   2006-12-13 10:31:37.0 +1100
@@ -224,7 +224,7 @@ nlm4svc_proc_granted(struct svc_rqst *rq
resp->cookie = argp->cookie;
 
dprintk("lockd: GRANTED   called\n");
-   resp->status = nlmclnt_grant(&rqstp->rq_addr, &argp->lock);
+   resp->status = nlmclnt_grant(svc_addr_in(rqstp), &argp->lock);
dprintk("lockd: GRANTED   status %d\n", ntohl(resp->status));
return rpc_success;
 }
@@ -421,7 +421,9 @@ static __be32
 nlm4svc_proc_sm_notify(struct svc_rqst *rqstp, struct nlm_reboot *argp,
  void  *resp)
 {
-   struct sockaddr_in  saddr = rqstp->rq_addr;
+   struct sockaddr_in  saddr;
+
+   memcpy(&saddr, svc_addr_in(rqstp), sizeof(saddr));
 
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)

diff .prev/fs/lockd/svcproc.c ./fs/lockd/svcproc.c
--- .prev/fs/lockd/svcproc.c2006-12-13 10:29:21.0 +1100
+++ ./fs/lockd/svcproc.c2006-12-13 10:31:37.0 +1100
@@ -253,7 +253,7 @@ nlmsvc_proc_granted(struct svc_rqst *rqs
resp->cookie = argp->cookie;
 
dprintk("lockd: GRANTED   called\n");
-   resp->status = nlmclnt_grant(&rqstp->rq_addr, &argp->lock);
+   resp->status = nlmclnt_grant(svc_addr_in(rqstp), &argp->lock);
dprintk("lockd: GRANTED   status %d\n", ntohl(resp->status));
return rpc_success;
 }
@@ -452,7 +452,9 @@ static __be32
 nlmsvc_proc_sm_notify(struct svc_rqst *rqstp, struct nlm_reboot *argp,
  void  *resp)
 {
-   struct sockaddr_in  saddr = rqstp->rq_addr;
+   struct sockaddr_in  saddr;
+
+   memcpy(&saddr, svc_addr_in(rqstp), sizeof(saddr));
 
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)

diff .prev/fs/nfs/callback.c ./fs/nfs/callback.c
--- .prev/fs/nfs/callback.c 2006-12-13 10:29:21.0 +1100
+++ ./fs/nfs/callback.c 2006-12-13 10:31:37.0 +1100
@@ -166,7 +166,7 @@ void nfs_callback_down(void)
 
 static int nfs_callback_authenticate(struct svc_rqst *rqstp)
 {
-   struct sockaddr_in *addr = &rqstp->rq_addr;
+   struct sockaddr_in *addr = svc_addr_in(rqstp);
struct nfs_client *clp;
char buf[RPC_MAX_ADDRBUFLEN];
 

diff .prev/fs/nfs/callback_xdr.c ./fs/nfs/callback_xdr.c
--- .prev/fs/nfs/callback_xdr.c 2006-12-13 10:28:51.0 +1100
+++ ./fs/nfs/callback_xdr.c 2006-12-13 10:31:37.0 +1100
@@ -176,7 +176,7 @@ static __be32 decode_getattr_args(struct
status = decode_fh(xdr, &args->fh);
if (unlikely(status != 0))
goto out;
-   args->addr = &rqstp->rq_addr;
+   args->addr = svc_addr_in(rqstp);
status = decode_bitmap(xdr, args->bitmap);
 out:
dprintk("%s: exit with status = %d\n", __FUNCTION__, status);
@@ -188,7 +188,7 @@ static __be32 decode_recall_args(struct 
__be32 *p;
__be32 status;
 
-   args->addr = &rqstp->rq_addr;
+   args->addr = svc_addr_in(rqstp);
status = decode_stateid(xdr, &args->stateid);
if (unlikely(status != 0))
goto out;

diff .prev/fs/nfsd/nfs4state.c ./fs/nfsd/nfs4state.c
--- .prev/fs/nfsd/nfs4state.c   2006-12-13 10:28:51.0 +1100
+++ ./fs/nfsd/nfs4state.c   2006-12-13 10:31:37.0 +1100
@@ -714,7 +714,7 @@ __be32
 nfsd4_setclientid(struct svc_rqst *rqstp, struct nfsd4_compoun

[PATCH] sata_nv: add suspend/resume support v3

[Robert Hancock]

This patch is against 2.6.19-rc6-mm2 and should apply to what is in 
Linus' and Jeff's git trees currently. This includes a later fix to the 
kfree ordering in the nv_remove_one function. Both the original patch 
and the later fix are already in the -mm tree.


---

This patch adds the necessary callbacks to support suspend/resume 
properly in sata_nv. Most of the controllers don't need any specific 
handling but CK804/MCP04 controllers, whether ADMA is enabled or not, 
need some additional setup on resume.


As well as the additional storage of the controller type needed for 
proper resume handling, this also removes the inline helper functions 
for getting ADMA register locations by storing the pointers so we don't 
have to keep calculating them all the time.


This also includes a fix to a bug in the original version of this patch
where the hpriv structure was freed while it could potentially still be
used.

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

--- linux-2.6.19-rc6-mm2/drivers/ata/sata_nv.c  2006-12-12 17:49:02.0 
-0600
+++ linux-2.6.19-rc6-mm2admafix/drivers/ata/sata_nv.c   2006-12-11 
22:15:58.0 -0600
@@ -49,7 +49,7 @@
#include 

#define DRV_NAME"sata_nv"
-#define DRV_VERSION"3.2"
+#define DRV_VERSION"3.3"

#define NV_ADMA_DMA_BOUNDARY0xUL

@@ -213,12 +213,21 @@ struct nv_adma_port_priv {
dma_addr_t  cpb_dma;
struct nv_adma_prd  *aprd;
dma_addr_t  aprd_dma;
+   void __iomem *  ctl_block;
+   void __iomem *  gen_block;
+   void __iomem *  notifier_clear_block;
u8  flags;
};

+struct nv_host_priv {
+   unsigned long   type;
+};
+
#define NV_ADMA_CHECK_INTR(GCTL, PORT) ((GCTL) & ( 1 << (19 + (12 * (PORT)

static int nv_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
+static void nv_remove_one (struct pci_dev *pdev);
+static int nv_pci_device_resume(struct pci_dev *pdev);
static void nv_ck804_host_stop(struct ata_host *host);
static irqreturn_t nv_generic_interrupt(int irq, void *dev_instance);
static irqreturn_t nv_nf2_interrupt(int irq, void *dev_instance);
@@ -239,6 +248,8 @@ static irqreturn_t nv_adma_interrupt(int
static void nv_adma_irq_clear(struct ata_port *ap);
static int nv_adma_port_start(struct ata_port *ap);
static void nv_adma_port_stop(struct ata_port *ap);
+static int nv_adma_port_suspend(struct ata_port *ap, pm_message_t mesg);
+static int nv_adma_port_resume(struct ata_port *ap);
static void nv_adma_error_handler(struct ata_port *ap);
static void nv_adma_host_stop(struct ata_host *host);
static void nv_adma_bmdma_setup(struct ata_queued_cmd *qc);
@@ -292,7 +303,9 @@ static struct pci_driver nv_pci_driver =
.name   = DRV_NAME,
.id_table   = nv_pci_tbl,
.probe  = nv_init_one,
-   .remove = ata_pci_remove_one,
+   .suspend= ata_pci_device_suspend,
+   .resume = nv_pci_device_resume,
+   .remove = nv_remove_one,
};

static struct scsi_host_template nv_sht = {
@@ -311,6 +324,8 @@ static struct scsi_host_template nv_sht 
	.slave_configure	= ata_scsi_slave_config,

.slave_destroy  = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+   .suspend= ata_scsi_device_suspend,
+   .resume = ata_scsi_device_resume,
};

static struct scsi_host_template nv_adma_sht = {
@@ -330,6 +345,8 @@ static struct scsi_host_template nv_adma
.slave_configure= nv_adma_slave_config,
.slave_destroy  = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+   .suspend= ata_scsi_device_suspend,
+   .resume = ata_scsi_device_resume,
};

static const struct ata_port_operations nv_generic_ops = {
@@ -438,6 +455,8 @@ static const struct ata_port_operations 
	.scr_write		= nv_scr_write,

.port_start = nv_adma_port_start,
.port_stop  = nv_adma_port_stop,
+   .port_suspend   = nv_adma_port_suspend,
+   .port_resume= nv_adma_port_resume,
.host_stop  = nv_adma_host_stop,
};

@@ -476,6 +495,7 @@ static struct ata_port_info nv_port_info
{
.sht= &nv_adma_sht,
.flags  = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
+  ATA_FLAG_HRST_TO_RESUME | 
  ATA_FLAG_MMIO | ATA_FLAG_NCQ,

.pio_mask   = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
@@ -492,32 +512,10 @@ MODULE_VERSION(DRV_VERSION);

static int adma_enabled = 1;

-static inline void __iomem *__nv_adma_ctl_block(void __iomem *mmio,
-   unsigned int port_no)
-{
-   mmio += NV_

2.6.19-rc6-mm2 oops and udev misbehavior

[Robert Hancock]

Seeing this oops on 2.6.19-rc6-mm2 intermittently on bootup. Also, when 
this doesn't happen it seems like udev goes crazy adding and removing 
/dev/md0 over and over using up a ton of CPU. Is this a known problem? 
This also happened with -mm1.


Linux version 2.6.19-rc6-mm2admafix ([EMAIL PROTECTED]) 
(gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Mon Dec 11 
22:38:59 CST 2006

Command line: ro root=/dev/VolGroup00/LogVol00
BIOS-provided physical RAM map:
BIOS-e820:  - 0009f400 (usable)
BIOS-e820: 0009f400 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 7fff (usable)
BIOS-e820: 7fff - 7fff3000 (ACPI NVS)
BIOS-e820: 7fff3000 - 8000 (ACPI data)
BIOS-e820: e000 - f000 (reserved)
BIOS-e820: fec0 - 0001 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 12800 used
Entering add_active_range(0, 256, 524272) 1 entries of 12800 used
end_pfn_map = 1048576
DMI 2.3 present.
ACPI: RSDP (v000 Nvidia) @ 
0x000f7c80
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fff3040
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fff30c0
ACPI: SSDT (v001 PTLTD  POWERNOW 0x0001  LTP 0x0001) @ 
0x7fff9900
ACPI: SRAT (v001 AMDHAMMER   0x0001 AMD  0x0001) @ 
0x7fff9b40
ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fff9c40
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x7fff9840
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 
0x

SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: Node 0 PXM 0 0-a
Entering add_active_range(0, 0, 159) 0 entries of 12800 used
SRAT: Node 0 PXM 0 0-8000
Entering add_active_range(0, 0, 159) 1 entries of 12800 used
Entering add_active_range(0, 256, 524272) 1 entries of 12800 used
Bootmem setup node 0 -8000
Node 0 memmap at 0x8196a000 size 33554432 first pfn 
0x8196a000

sizeof(struct page) = 64
Zone PFN ranges:
 DMA 0 -> 4096
 DMA324096 ->  1048576
 Normal1048576 ->  1048576
early_node_map[2] active PFN ranges
   0:0 ->  159
   0:  256 ->   524272
On node 0 totalpages: 524175
 DMA zone: 64 pages used for memmap
 DMA zone: 1907 pages reserved
 DMA zone: 2028 pages, LIFO batch:0
 DMA32 zone: 8127 pages used for memmap
 DMA32 zone: 512049 pages, LIFO batch:31
 Normal zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Nosave address range: 0009f000 - 000a
Nosave address range: 000a - 000f
Nosave address range: 000f - 0010
Allocating PCI resources starting at 8800 (gap: 8000:6000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 67968 bytes of per cpu data
Built 1 zonelists.  Total pages: 514077
Kernel command line: ro root=/dev/VolGroup00/LogVol00
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
CPU 0: aperture @ 63000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 2050348k/2097088k available (2275k kernel code, 46352k reserved, 
1601k data, 624k init)
Calibrating delay using timer specific routine.. 4425.40 BogoMIPS 
(lpj=8850801)

Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processo

[PATCH 2/2]: Use newly defined PCI channel offline routine

[Linas Vepstas]

Use newly minted routine to access the PCI channel state.

Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>


 drivers/net/e1000/e1000_main.c |2 +-
 drivers/net/ixgb/ixgb_main.c   |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.19-git7/drivers/net/e1000/e1000_main.c
===
--- linux-2.6.19-git7.orig/drivers/net/e1000/e1000_main.c   2006-12-12 
16:38:34.0 -0600
+++ linux-2.6.19-git7/drivers/net/e1000/e1000_main.c2006-12-12 
16:40:51.0 -0600
@@ -3449,7 +3449,7 @@ e1000_update_stats(struct e1000_adapter 
 */
if (adapter->link_speed == 0)
return;
-   if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+   if (pci_channel_offline(pdev))
return;
 
spin_lock_irqsave(&adapter->stats_lock, flags);
Index: linux-2.6.19-git7/drivers/net/ixgb/ixgb_main.c
===
--- linux-2.6.19-git7.orig/drivers/net/ixgb/ixgb_main.c 2006-12-12 
16:38:34.0 -0600
+++ linux-2.6.19-git7/drivers/net/ixgb/ixgb_main.c  2006-12-12 
16:41:00.0 -0600
@@ -1564,7 +1564,7 @@ ixgb_update_stats(struct ixgb_adapter *a
struct pci_dev *pdev = adapter->pdev;
 
/* Prevent stats update while adapter is being reset */
-   if (pdev->error_state && pdev->error_state != pci_channel_io_normal)
+   if (pci_channel_offline(pdev))
return;
 
if((netdev->flags & IFF_PROMISC) || (netdev->flags & IFF_ALLMULTI) ||
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 006 of 14] knfsd: SUNRPC: Add a function to format the address in an svc_rqst for printing

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
There are loads of places where the RPC server assumes that the rq_addr
fields contains an IPv4 address.  Top among these are error and debugging
messages that display the server's IP address.

Let's refactor the address printing into a separate function that's smart
enough to figure out the difference between IPv4 and IPv6 addresses.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/lockd/svc.c |6 +--
 ./fs/lockd/svc4proc.c|7 +--
 ./fs/lockd/svcproc.c |7 +--
 ./fs/nfs/callback.c  |   12 +-
 ./fs/nfsd/nfsfh.c|7 ++-
 ./fs/nfsd/nfsproc.c  |7 ++-
 ./include/linux/sunrpc/svc.h |3 +
 ./net/sunrpc/svcsock.c   |   76 +++
 8 files changed, 85 insertions(+), 40 deletions(-)

diff .prev/fs/lockd/svc4proc.c ./fs/lockd/svc4proc.c
--- .prev/fs/lockd/svc4proc.c   2006-12-13 10:28:51.0 +1100
+++ ./fs/lockd/svc4proc.c   2006-12-13 10:29:44.0 +1100
@@ -426,10 +426,9 @@ nlm4svc_proc_sm_notify(struct svc_rqst *
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
 || ntohs(saddr.sin_port) >= 1024) {
-   printk(KERN_WARNING
-   "lockd: rejected NSM callback from %08x:%d\n",
-   ntohl(rqstp->rq_addr.sin_addr.s_addr),
-   ntohs(rqstp->rq_addr.sin_port));
+   char buf[RPC_MAX_ADDRBUFLEN];
+   printk(KERN_WARNING "lockd: rejected NSM callback from %s\n",
+   svc_print_addr(rqstp, buf, sizeof(buf)));
return rpc_system_err;
}
 

diff .prev/fs/lockd/svc.c ./fs/lockd/svc.c
--- .prev/fs/lockd/svc.c2006-12-13 10:29:09.0 +1100
+++ ./fs/lockd/svc.c2006-12-13 10:30:01.0 +1100
@@ -141,6 +141,7 @@ lockd(struct svc_rqst *rqstp)
 */
while ((nlmsvc_users || !signalled()) && nlmsvc_pid == current->pid) {
long timeout = MAX_SCHEDULE_TIMEOUT;
+   char buf[RPC_MAX_ADDRBUFLEN];
 
if (signalled()) {
flush_signals(current);
@@ -175,11 +176,10 @@ lockd(struct svc_rqst *rqstp)
break;
}
 
-   dprintk("lockd: request from %08x\n",
-   (unsigned)ntohl(rqstp->rq_addr.sin_addr.s_addr));
+   dprintk("lockd: request from %s\n",
+   svc_print_addr(rqstp, buf, sizeof(buf)));
 
svc_process(rqstp);
-
}
 
flush_signals(current);

diff .prev/fs/lockd/svcproc.c ./fs/lockd/svcproc.c
--- .prev/fs/lockd/svcproc.c2006-12-13 10:28:51.0 +1100
+++ ./fs/lockd/svcproc.c2006-12-13 10:29:21.0 +1100
@@ -457,10 +457,9 @@ nlmsvc_proc_sm_notify(struct svc_rqst *r
dprintk("lockd: SM_NOTIFY called\n");
if (saddr.sin_addr.s_addr != htonl(INADDR_LOOPBACK)
 || ntohs(saddr.sin_port) >= 1024) {
-   printk(KERN_WARNING
-   "lockd: rejected NSM callback from %08x:%d\n",
-   ntohl(rqstp->rq_addr.sin_addr.s_addr),
-   ntohs(rqstp->rq_addr.sin_port));
+   char buf[RPC_MAX_ADDRBUFLEN];
+   printk(KERN_WARNING "lockd: rejected NSM callback from %s\n",
+   svc_print_addr(rqstp, buf, sizeof(buf)));
return rpc_system_err;
}
 

diff .prev/fs/nfs/callback.c ./fs/nfs/callback.c
--- .prev/fs/nfs/callback.c 2006-12-13 10:29:09.0 +1100
+++ ./fs/nfs/callback.c 2006-12-13 10:29:21.0 +1100
@@ -71,6 +71,8 @@ static void nfs_callback_svc(struct svc_
complete(&nfs_callback_info.started);
 
for(;;) {
+   char buf[RPC_MAX_ADDRBUFLEN];
+
if (signalled()) {
if (nfs_callback_info.users == 0)
break;
@@ -88,8 +90,8 @@ static void nfs_callback_svc(struct svc_
__FUNCTION__, -err);
break;
}
-   dprintk("%s: request from %u.%u.%u.%u\n", __FUNCTION__,
-   NIPQUAD(rqstp->rq_addr.sin_addr.s_addr));
+   dprintk("%s: request from %s\n", __FUNCTION__,
+   svc_print_addr(rqstp, buf, sizeof(buf)));
svc_process(rqstp);
}
 
@@ -166,13 +168,17 @@ static int nfs_callback_authenticate(str
 {
struct sockaddr_in *addr = &rqstp->rq_addr;
struct nfs_client *clp;
+   char buf[RPC_MAX_ADDRBUFLEN];
 
/* Don't talk to strangers */
clp = nfs_find_client(addr, 4);
if (clp == NULL)
return SVC_DROP;
-   dprintk("%s: %u.%u.%u.%u NF

[PATCH 000 of 14] knfsd: Assorted nfsd patches for 2.6.20 - prepare for IPv6 and more

[NeilBrown]

Following are 14 patches for knfsd that are suitable for inclusion in 2.6.20.
First 13 are from Chuck Lever and make preparations for IPv6 support (I think 
we've
get them right this time).

Last is from Peter Staubach and fixes and issue with exclusive create
interacting badly with some ACLs.

Thanks,
NeilBrown


 [PATCH 001 of 14] knfsd: SUNRPC: update internal API: separate pmap register 
and temp sockets
 [PATCH 002 of 14] knfsd: SUNRPC: allow creating an RPC service without 
registering with portmapper
 [PATCH 003 of 14] knfsd: SUNRPC: Cache remote peer's address in svc_sock.
 [PATCH 004 of 14] knfsd: SUNRPC: Don't set msg_name and msg_namelen when 
calling sock_recvmsg
 [PATCH 005 of 14] knfsd: SUNRPC: Use sockaddr_storage to store address in 
svc_deferred_req
 [PATCH 006 of 14] knfsd: SUNRPC: Add a function to format the address in an 
svc_rqst for printing
 [PATCH 007 of 14] knfsd: SUNRPC: Provide room in svc_rqst for larger addresses
 [PATCH 008 of 14] knfsd: SUNRPC: Make rq_daddr field address-version 
independent
 [PATCH 009 of 14] knfsd: SUNRPC: teach svc_sendto() to deal with IPv6 addresses
 [PATCH 010 of 14] knfsd: SUNRPC: add a "generic" function to see if the peer 
uses a secure port
 [PATCH 011 of 14] knfsd: SUNRPC: Support IPv6 addresses in svc_tcp_accept
 [PATCH 012 of 14] knfsd: SUNRPC: support IPv6 addresses in RPC server's UDP 
receive path
 [PATCH 013 of 14] knfsd: SUNRPC: fix up svc_create_socket() to take a sockaddr 
struct + length
 [PATCH 014 of 14] knfsd: Don't mess with the 'mode' when storing a 
exclusive-create cookie.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Add the ability to layer another driver over the serial driver

[Tilman Schmidt]

Am 11.12.2006 18:07 schrieb Corey Minyard:
> Tilman Schmidt wrote:
>> I was under the impression that line disciplines need a user space
>> process to open the serial device and push them onto it. Is there
>> a way for a driver to attach to a serial port through the line
>> discipline interface from kernel space, eg. from an initialization,
>> module load, or probe function?
>>   
> Module initialization functions run in a task context, so that's
> generally not a problem.  The probe function depends on the driver,
> I guess, but most I have seen are in task context.

Could you be a bit more specific? If I write a module implementing a
line discipline, how would I go about having that line discipline
push itself onto a given serial port (specified for example through a
module parameter) immediately, during its own module initialization?
I can't seem to find an in-kernel interface for that.

Also, if I understand correctly, this would only work if the driver
is compiled as a module, but such a limitation seems to be frowned
upon within the kernel community. Any way around that?

Thanks
Tilman

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Add the ability to layer another driver over the serial driver

[Tilman Schmidt]

Am 11.12.2006 18:40 schrieb Alan:
> On Mon, 11 Dec 2006 17:58:29 +0100
> Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> 
>> On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
>>> This looks wrong. You already have a kernel interface to serial drivers.
>>> It is called a line discipline. We use it for ppp, we use it for slip, we
>>> use it for a few other things such as attaching sync drivers to some
>>> devices.
>> I was under the impression that line disciplines need a user space
>> process to open the serial device and push them onto it. 
> 
> Yes that is correct. You need a way for the user to tell you which port
> to use and to the permission and usage management for it anyway (as well
> as load the module and configure settings), so this seems quite
> reasonable.

I'm afraid I'm not familiar with Linux' SLIP implementation.
So there's a line discipline called "slip" which, when pushed
onto a serial port, registers as a network device, right? How
does it get - and stay - pushed? Is there a daemon process which
opens the serial port, pushes the line discipline onto it, and
then just sleeps, keeping the serial port open so that the line
discipline stays put? Can you point me to the source for such a
daemon for reference?

What I am actually looking for is a way to port an existing driver
which directly programs an i8250 serial port, to cooperate more
cleanly with the existing serial port drivers of Linux (and, at
the same time, shed the dependency on the specific serial port
hardware.) If that requires a permanently running (or sleeping)
userspace daemon, then so be it. (Although I admit I'd rather do
without.)

Thanks
Tilman

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

[PATCH 002 of 14] knfsd: SUNRPC: allow creating an RPC service without registering with portmapper

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Sometimes we need to create an RPC service but not register it with the
local portmapper.  NFSv4 delegation callback, for example.

Change the svc_makesock() API to allow optionally creating temporary or
permanent sockets, optionally registering with the local portmapper, and
make it return the ephemeral port of the new socket.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/lockd/svc.c |   26 --
 ./fs/nfs/callback.c  |   20 +---
 ./fs/nfsd/nfssvc.c   |6 --
 ./include/linux/sunrpc/svcsock.h |2 +-
 ./net/sunrpc/svcsock.c   |6 --
 5 files changed, 34 insertions(+), 26 deletions(-)

diff .prev/fs/lockd/svc.c ./fs/lockd/svc.c
--- .prev/fs/lockd/svc.c2006-12-13 10:28:52.0 +1100
+++ ./fs/lockd/svc.c2006-12-13 10:29:09.0 +1100
@@ -223,23 +223,29 @@ static int find_socket(struct svc_serv *
return found;
 }
 
+/*
+ * Make any sockets that are needed but not present.
+ * If nlm_udpport or nlm_tcpport were set as module
+ * options, make those sockets unconditionally
+ */
 static int make_socks(struct svc_serv *serv, int proto)
 {
-   /* Make any sockets that are needed but not present.
-* If nlm_udpport or nlm_tcpport were set as module
-* options, make those sockets unconditionally
-*/
-   static int  warned;
+   static int warned;
int err = 0;
+
if (proto == IPPROTO_UDP || nlm_udpport)
if (!find_socket(serv, IPPROTO_UDP))
-   err = svc_makesock(serv, IPPROTO_UDP, nlm_udpport);
-   if (err == 0 && (proto == IPPROTO_TCP || nlm_tcpport))
+   err = svc_makesock(serv, IPPROTO_UDP, nlm_udpport,
+   SVC_SOCK_DEFAULTS);
+   if (err >= 0 && (proto == IPPROTO_TCP || nlm_tcpport))
if (!find_socket(serv, IPPROTO_TCP))
-   err= svc_makesock(serv, IPPROTO_TCP, nlm_tcpport);
-   if (!err)
+   err = svc_makesock(serv, IPPROTO_TCP, nlm_tcpport,
+   SVC_SOCK_DEFAULTS);
+
+   if (err >= 0) {
warned = 0;
-   else if (warned++ == 0)
+   err = 0;
+   } else if (warned++ == 0)
printk(KERN_WARNING
   "lockd_up: makesock failed, error=%d\n", err);
return err;

diff .prev/fs/nfs/callback.c ./fs/nfs/callback.c
--- .prev/fs/nfs/callback.c 2006-12-13 10:28:52.0 +1100
+++ ./fs/nfs/callback.c 2006-12-13 10:29:09.0 +1100
@@ -106,7 +106,6 @@ static void nfs_callback_svc(struct svc_
 int nfs_callback_up(void)
 {
struct svc_serv *serv;
-   struct svc_sock *svsk;
int ret = 0;
 
lock_kernel();
@@ -119,17 +118,14 @@ int nfs_callback_up(void)
ret = -ENOMEM;
if (!serv)
goto out_err;
-   /* FIXME: We don't want to register this socket with the portmapper */
-   ret = svc_makesock(serv, IPPROTO_TCP, nfs_callback_set_tcpport);
-   if (ret < 0)
+
+   ret = svc_makesock(serv, IPPROTO_TCP, nfs_callback_set_tcpport,
+   SVC_SOCK_ANONYMOUS);
+   if (ret <= 0)
goto out_destroy;
-   if (!list_empty(&serv->sv_permsocks)) {
-   svsk = list_entry(serv->sv_permsocks.next,
-   struct svc_sock, sk_list);
-   nfs_callback_tcpport = ntohs(inet_sk(svsk->sk_sk)->sport);
-   dprintk ("Callback port = 0x%x\n", nfs_callback_tcpport);
-   } else
-   BUG();
+   nfs_callback_tcpport = ret;
+   dprintk("Callback port = 0x%x\n", nfs_callback_tcpport);
+
ret = svc_create_thread(nfs_callback_svc, serv);
if (ret < 0)
goto out_destroy;
@@ -140,6 +136,8 @@ out:
unlock_kernel();
return ret;
 out_destroy:
+   dprintk("Couldn't create callback socket or server thread; err = %d\n",
+   ret);
svc_destroy(serv);
 out_err:
nfs_callback_info.users--;

diff .prev/fs/nfsd/nfssvc.c ./fs/nfsd/nfssvc.c
--- .prev/fs/nfsd/nfssvc.c  2006-12-13 10:28:52.0 +1100
+++ ./fs/nfsd/nfssvc.c  2006-12-13 10:29:09.0 +1100
@@ -235,7 +235,8 @@ static int nfsd_init_socks(int port)
 
error = lockd_up(IPPROTO_UDP);
if (error >= 0) {
-   error = svc_makesock(nfsd_serv, IPPROTO_UDP, port);
+   error = svc_makesock(nfsd_serv, IPPROTO_UDP, port,
+   SVC_SOCK_DEFAULTS);
if (error < 0)
lockd_down();
}
@@ -245,7 +246,8 @@ static int nfsd_init_socks(int port)
 #ifdef CONFIG_NFSD_TCP
error = lockd_u

[PATCH 012 of 14] knfsd: SUNRPC: support IPv6 addresses in RPC server's UDP receive path

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Add support for IPv6 addresses in the RPC server's UDP receive path.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./include/linux/sunrpc/svc.h |5 
 ./net/sunrpc/svcsock.c   |   49 +++
 2 files changed, 46 insertions(+), 8 deletions(-)

diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2006-12-13 10:32:10.0 +1100
+++ ./include/linux/sunrpc/svc.h2006-12-13 10:32:20.0 +1100
@@ -267,6 +267,11 @@ static inline struct sockaddr_in *svc_ad
return (struct sockaddr_in *) &rqst->rq_addr;
 }
 
+static inline struct sockaddr_in6 *svc_addr_in6(struct svc_rqst *rqst)
+{
+   return (struct sockaddr_in6 *) &rqst->rq_addr;
+}
+
 static inline struct sockaddr *svc_addr(struct svc_rqst *rqst)
 {
return (struct sockaddr *) &rqst->rq_addr;

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:32:19.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:32:20.0 +1100
@@ -717,13 +717,51 @@ svc_write_space(struct sock *sk)
}
 }
 
+static void svc_udp_get_sender_address(struct svc_rqst *rqstp,
+   struct sk_buff *skb)
+{
+   switch (rqstp->rq_sock->sk_sk->sk_family) {
+   case AF_INET:
+   /* this seems to come from net/ipv4/udp.c:udp_recvmsg */
+   do {
+   struct sockaddr_in *sin = svc_addr_in(rqstp);
+
+   sin->sin_family = AF_INET;
+   sin->sin_port = skb->h.uh->source;
+   sin->sin_addr.s_addr = skb->nh.iph->saddr;
+   rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
+   } while (0);
+   break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+   case AF_INET6:
+   /* this is derived from net/ipv6/udp.c:udpv6_recvmesg */
+   do {
+   struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp);
+
+   sin6->sin6_family = AF_INET6;
+   sin6->sin6_port = skb->h.uh->source;
+   sin6->sin6_flowinfo = 0;
+   sin6->sin6_scope_id = 0;
+   if (ipv6_addr_type(&sin6->sin6_addr) &
+   IPV6_ADDR_LINKLOCAL)
+   sin6->sin6_scope_id = IP6CB(skb)->iif;
+   ipv6_addr_copy(&sin6->sin6_addr,
+   &skb->nh.ipv6h->saddr);
+   ipv6_addr_copy(&rqstp->rq_daddr.addr6,
+   &skb->nh.ipv6h->saddr);
+   } while (0);
+   break;
+#endif
+   }
+   return;
+}
+
 /*
  * Receive a datagram from a UDP socket.
  */
 static int
 svc_udp_recvfrom(struct svc_rqst *rqstp)
 {
-   struct sockaddr_in *sin = svc_addr_in(rqstp);
struct svc_sock *svsk = rqstp->rq_sock;
struct svc_serv *serv = svsk->sk_server;
struct sk_buff  *skb;
@@ -775,14 +813,9 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
 
len  = skb->len - sizeof(struct udphdr);
rqstp->rq_arg.len = len;
+   rqstp->rq_prot = IPPROTO_UDP;
 
-   rqstp->rq_prot= IPPROTO_UDP;
-
-   /* Get sender address */
-   sin->sin_family = AF_INET;
-   sin->sin_port = skb->h.uh->source;
-   sin->sin_addr.s_addr = skb->nh.iph->saddr;
-   rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
+   svc_udp_get_sender_address(rqstp, skb);
 
if (skb_is_nonlinear(skb)) {
/* we have to copy */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 004 of 14] knfsd: SUNRPC: Don't set msg_name and msg_namelen when calling sock_recvmsg

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Clean-up: msg_name and msg_namelen are not used by sock_recvmsg, so
don't bother to set them in svc_recvfrom.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./net/sunrpc/svcsock.c |   23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:29:13.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:29:15.0 +1100
@@ -560,21 +560,14 @@ svc_recv_available(struct svc_sock *svsk
 static int
 svc_recvfrom(struct svc_rqst *rqstp, struct kvec *iov, int nr, int buflen)
 {
-   struct msghdr   msg;
-   struct socket   *sock;
-   int len, alen;
-
-   rqstp->rq_addrlen = sizeof(rqstp->rq_addr);
-   sock = rqstp->rq_sock->sk_sock;
-
-   msg.msg_name= &rqstp->rq_addr;
-   msg.msg_namelen = sizeof(rqstp->rq_addr);
-   msg.msg_control = NULL;
-   msg.msg_controllen = 0;
-
-   msg.msg_flags   = MSG_DONTWAIT;
+   struct svc_sock *svsk = rqstp->rq_sock;
+   struct msghdr msg = {
+   .msg_flags  = MSG_DONTWAIT,
+   };
+   int len;
 
-   len = kernel_recvmsg(sock, &msg, iov, nr, buflen, MSG_DONTWAIT);
+   len = kernel_recvmsg(svsk->sk_sock, &msg, iov, nr, buflen,
+   msg.msg_flags);
 
/* sock_recvmsg doesn't fill in the name/namelen, so we must..
 */
@@ -582,7 +575,7 @@ svc_recvfrom(struct svc_rqst *rqstp, str
rqstp->rq_addrlen = svsk->sk_remotelen;
 
dprintk("svc: socket %p recvfrom(%p, %Zu) = %d\n",
-   rqstp->rq_sock, iov[0].iov_base, iov[0].iov_len, len);
+   svsk, iov[0].iov_base, iov[0].iov_len, len);
 
return 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/

[PATCH 013 of 14] knfsd: SUNRPC: fix up svc_create_socket() to take a sockaddr struct + length

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Replace existing svc_create_socket() API to allow callers to pass addresses
larger than a sockaddr_in.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./net/sunrpc/svcsock.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:32:20.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:32:50.0 +1100
@@ -1677,7 +1677,7 @@ EXPORT_SYMBOL_GPL(svc_addsock);
  * Create socket for RPC service.
  */
 static int svc_create_socket(struct svc_serv *serv, int protocol,
-   struct sockaddr_in *sin, int flags)
+   struct sockaddr *sin, int len, int flags)
 {
struct svc_sock *svsk;
struct socket   *sock;
@@ -1687,8 +1687,7 @@ static int svc_create_socket(struct svc_
 
dprintk("svc: svc_create_socket(%s, %d, %s)\n",
serv->sv_program->pg_name, protocol,
-   __svc_print_addr((struct sockaddr *) sin, buf,
-   sizeof(buf)));
+   __svc_print_addr(sin, buf, sizeof(buf)));
 
if (protocol != IPPROTO_UDP && protocol != IPPROTO_TCP) {
printk(KERN_WARNING "svc: only UDP and TCP "
@@ -1697,15 +1696,15 @@ static int svc_create_socket(struct svc_
}
type = (protocol == IPPROTO_UDP)? SOCK_DGRAM : SOCK_STREAM;
 
-   if ((error = sock_create_kern(PF_INET, type, protocol, &sock)) < 0)
+   error = sock_create_kern(sin->sa_family, type, protocol, &sock);
+   if (error < 0)
return error;
 
svc_reclassify_socket(sock);
 
if (type == SOCK_STREAM)
-   sock->sk->sk_reuse = 1; /* allow address reuse */
-   error = kernel_bind(sock, (struct sockaddr *) sin,
-   sizeof(*sin));
+   sock->sk->sk_reuse = 1; /* allow address reuse */
+   error = kernel_bind(sock, sin, len);
if (error < 0)
goto bummer;
 
@@ -1783,7 +1782,8 @@ int svc_makesock(struct svc_serv *serv, 
};
 
dprintk("svc: creating socket proto = %d\n", protocol);
-   return svc_create_socket(serv, protocol, &sin, flags);
+   return svc_create_socket(serv, protocol, (struct sockaddr *) &sin,
+   sizeof(sin), flags);
 }
 
 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 009 of 14] knfsd: SUNRPC: teach svc_sendto() to deal with IPv6 addresses

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
CMSG_DATA comes in different sizes, depending on address family.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./net/sunrpc/svcsock.c |   69 -
 1 file changed, 52 insertions(+), 17 deletions(-)

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:31:39.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:32:15.0 +1100
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -438,6 +439,47 @@ svc_wake_up(struct svc_serv *serv)
}
 }
 
+union svc_pktinfo_u {
+   struct in_pktinfo pkti;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+   struct in6_pktinfo pkti6;
+#endif
+};
+
+static void svc_set_cmsg_data(struct svc_rqst *rqstp, struct cmsghdr *cmh)
+{
+   switch (rqstp->rq_sock->sk_sk->sk_family) {
+   case AF_INET:
+   do {
+   struct in_pktinfo *pki =
+   (struct in_pktinfo *) CMSG_DATA(cmh);
+
+   cmh->cmsg_level = SOL_IP;
+   cmh->cmsg_type = IP_PKTINFO;
+   pki->ipi_ifindex = 0;
+   pki->ipi_spec_dst.s_addr = rqstp->rq_daddr.addr.s_addr;
+   cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
+   } while (0);
+   break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+   case AF_INET6:
+   do {
+   struct in6_pktinfo *pki =
+   (struct in6_pktinfo *) CMSG_DATA(cmh);
+
+   cmh->cmsg_level = SOL_IPV6;
+   cmh->cmsg_type = IPV6_PKTINFO;
+   pki->ipi6_ifindex = 0;
+   ipv6_addr_copy(&pki->ipi6_addr,
+   &rqstp->rq_daddr.addr6);
+   cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
+   } while (0);
+   break;
+#endif
+   }
+   return;
+}
+
 /*
  * Generic sendto routine
  */
@@ -447,9 +489,8 @@ svc_sendto(struct svc_rqst *rqstp, struc
struct svc_sock *svsk = rqstp->rq_sock;
struct socket   *sock = svsk->sk_sock;
int slen;
-   charbuffer[CMSG_SPACE(sizeof(struct in_pktinfo))];
+   charbuffer[CMSG_SPACE(sizeof(union svc_pktinfo_u))];
struct cmsghdr *cmh = (struct cmsghdr *)buffer;
-   struct in_pktinfo *pki = (struct in_pktinfo *)CMSG_DATA(cmh);
int len = 0;
int result;
int size;
@@ -462,21 +503,15 @@ svc_sendto(struct svc_rqst *rqstp, struc
slen = xdr->len;
 
if (rqstp->rq_prot == IPPROTO_UDP) {
-   /* set the source and destination */
-   struct msghdr   msg;
-   msg.msg_name= &rqstp->rq_addr;
-   msg.msg_namelen = rqstp->rq_addrlen;
-   msg.msg_iov = NULL;
-   msg.msg_iovlen  = 0;
-   msg.msg_flags   = MSG_MORE;
-
-   msg.msg_control = cmh;
-   msg.msg_controllen = sizeof(buffer);
-   cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
-   cmh->cmsg_level = SOL_IP;
-   cmh->cmsg_type = IP_PKTINFO;
-   pki->ipi_ifindex = 0;
-   pki->ipi_spec_dst.s_addr = rqstp->rq_daddr.addr.s_addr;
+   struct msghdr msg = {
+   .msg_name   = &rqstp->rq_addr,
+   .msg_namelen= rqstp->rq_addrlen,
+   .msg_control= cmh,
+   .msg_controllen = sizeof(buffer),
+   .msg_flags  = MSG_MORE,
+   };
+
+   svc_set_cmsg_data(rqstp, cmh);
 
if (sock_sendmsg(sock, &msg, 0) < 0)
goto out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 011 of 14] knfsd: SUNRPC: Support IPv6 addresses in svc_tcp_accept

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Modify svc_tcp_accept to support connecting on IPv6 sockets.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./net/sunrpc/svcsock.c |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:32:17.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:32:19.0 +1100
@@ -946,7 +946,8 @@ static inline int svc_port_is_privileged
 static void
 svc_tcp_accept(struct svc_sock *svsk)
 {
-   struct sockaddr_in sin;
+   struct sockaddr_storage addr;
+   struct sockaddr *sin = (struct sockaddr *) &addr;
struct svc_serv *serv = svsk->sk_server;
struct socket   *sock = svsk->sk_sock;
struct socket   *newsock;
@@ -973,8 +974,7 @@ svc_tcp_accept(struct svc_sock *svsk)
set_bit(SK_CONN, &svsk->sk_flags);
svc_sock_enqueue(svsk);
 
-   slen = sizeof(sin);
-   err = kernel_getpeername(newsock, (struct sockaddr *) &sin, &slen);
+   err = kernel_getpeername(newsock, sin, &slen);
if (err < 0) {
if (net_ratelimit())
printk(KERN_WARNING "%s: peername failed (err %d)!\n",
@@ -986,12 +986,11 @@ svc_tcp_accept(struct svc_sock *svsk)
 * hosts here, but when we get encryption, the IP of the host won't
 * tell us anything.  For now just warn about unpriv connections.
 */
-   if (!svc_port_is_privileged((struct sockaddr *) &sin)) {
+   if (!svc_port_is_privileged(sin)) {
dprintk(KERN_WARNING
"%s: connect from unprivileged port: %s\n",
serv->sv_name,
-   __svc_print_addr((struct sockaddr *) &sin, buf,
-   sizeof(buf)));
+   __svc_print_addr(sin, buf, sizeof(buf)));
}
dprintk("%s: connect from %s\n", serv->sv_name, buf);
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 001 of 14] knfsd: SUNRPC: update internal API: separate pmap register and temp sockets

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Currently in the RPC server, registering with the local portmapper and
creating "permanent" sockets are tied together.  Expand the internal APIs
to allow these two socket characteristics to be separately specified.

This will be externalized in the next patch.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./include/linux/sunrpc/svcsock.h |7 +
 ./net/sunrpc/svcsock.c   |   47 ++-
 2 files changed, 34 insertions(+), 20 deletions(-)

diff .prev/include/linux/sunrpc/svcsock.h ./include/linux/sunrpc/svcsock.h
--- .prev/include/linux/sunrpc/svcsock.h2006-12-13 10:28:53.0 
+1100
+++ ./include/linux/sunrpc/svcsock.h2006-12-13 10:28:59.0 +1100
@@ -74,4 +74,11 @@ int  svc_addsock(struct svc_serv *serv,
char *name_return,
int *proto);
 
+/*
+ * svc_makesock socket characteristics
+ */
+#define SVC_SOCK_DEFAULTS  (0U)
+#define SVC_SOCK_ANONYMOUS (1U << 0)   /* don't register with pmap */
+#define SVC_SOCK_TEMPORARY (1U << 1)   /* flag socket as temporary */
+
 #endif /* SUNRPC_SVCSOCK_H */

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:28:53.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:28:59.0 +1100
@@ -69,7 +69,7 @@
 
 
 static struct svc_sock *svc_setup_socket(struct svc_serv *, struct socket *,
-int *errp, int pmap_reg);
+int *, int);
 static voidsvc_udp_data_ready(struct sock *, int);
 static int svc_udp_recvfrom(struct svc_rqst *);
 static int svc_udp_sendto(struct svc_rqst *);
@@ -922,7 +922,8 @@ svc_tcp_accept(struct svc_sock *svsk)
 */
newsock->sk->sk_sndtimeo = HZ*30;
 
-   if (!(newsvsk = svc_setup_socket(serv, newsock, &err, 0)))
+   if (!(newsvsk = svc_setup_socket(serv, newsock, &err,
+(SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
 
 
@@ -1456,12 +1457,14 @@ svc_age_temp_sockets(unsigned long closu
  * Initialize socket for RPC use and create svc_sock struct
  * XXX: May want to setsockopt SO_SNDBUF and SO_RCVBUF.
  */
-static struct svc_sock *
-svc_setup_socket(struct svc_serv *serv, struct socket *sock,
-   int *errp, int pmap_register)
+static struct svc_sock *svc_setup_socket(struct svc_serv *serv,
+   struct socket *sock,
+   int *errp, int flags)
 {
struct svc_sock *svsk;
struct sock *inet;
+   int pmap_register = !(flags & SVC_SOCK_ANONYMOUS);
+   int is_temporary = flags & SVC_SOCK_TEMPORARY;
 
dprintk("svc: svc_setup_socket %p\n", sock);
if (!(svsk = kzalloc(sizeof(*svsk), GFP_KERNEL))) {
@@ -1503,7 +1506,7 @@ svc_setup_socket(struct svc_serv *serv, 
svc_tcp_init(svsk);
 
spin_lock_bh(&serv->sv_lock);
-   if (!pmap_register) {
+   if (is_temporary) {
set_bit(SK_TEMP, &svsk->sk_flags);
list_add(&svsk->sk_list, &serv->sv_tempsocks);
serv->sv_tmpcnt++;
@@ -1547,7 +1550,7 @@ int svc_addsock(struct svc_serv *serv,
else if (so->state > SS_UNCONNECTED)
err = -EISCONN;
else {
-   svsk = svc_setup_socket(serv, so, &err, 1);
+   svsk = svc_setup_socket(serv, so, &err, SVC_SOCK_DEFAULTS);
if (svsk)
err = 0;
}
@@ -1563,8 +1566,8 @@ EXPORT_SYMBOL_GPL(svc_addsock);
 /*
  * Create socket for RPC service.
  */
-static int
-svc_create_socket(struct svc_serv *serv, int protocol, struct sockaddr_in *sin)
+static int svc_create_socket(struct svc_serv *serv, int protocol,
+   struct sockaddr_in *sin, int flags)
 {
struct svc_sock *svsk;
struct socket   *sock;
@@ -1600,8 +1603,8 @@ svc_create_socket(struct svc_serv *serv,
goto bummer;
}
 
-   if ((svsk = svc_setup_socket(serv, sock, &error, 1)) != NULL)
-   return 0;
+   if ((svsk = svc_setup_socket(serv, sock, &error, flags)) != NULL)
+   return ntohs(inet_sk(svsk->sk_sk)->sport);
 
 bummer:
dprintk("svc: svc_create_socket error = %d\n", -error);
@@ -1651,19 +1654,23 @@ svc_delete_socket(struct svc_sock *svsk)
svc_sock_put(svsk);
 }
 
-/*
- * Make a socket for nfsd and lockd
+/**
+ * svc_makesock - Make a socket for nfsd and lockd
+ * @serv: RPC server structure
+ * @protocol: transport protocol to use
+ * @port: port to use
+ *
  */
-int
-svc_makesock(struct svc_serv *serv, int protocol, unsig

[PATCH 005 of 14] knfsd: SUNRPC: Use sockaddr_storage to store address in svc_deferred_req

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
Sockaddr_storage will allow us to store arbitrary socket addresses in
the svc_deferred_req struct.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./include/linux/sunrpc/svc.h |3 ++-
 ./net/sunrpc/svcsock.c   |6 --
 2 files changed, 6 insertions(+), 3 deletions(-)

diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2006-12-13 10:28:52.0 +1100
+++ ./include/linux/sunrpc/svc.h2006-12-13 10:29:18.0 +1100
@@ -289,7 +289,8 @@ static inline void svc_free_res_pages(st
 
 struct svc_deferred_req {
u32 prot;   /* protocol (UDP or TCP) */
-   struct sockaddr_in  addr;
+   struct sockaddr_storage addr;
+   int addrlen;
struct svc_sock *svsk;  /* where reply must go */
__be32  daddr;  /* where reply must come from */
struct cache_deferred_req handle;

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:29:15.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:29:18.0 +1100
@@ -1713,7 +1713,8 @@ svc_defer(struct cache_req *req)
 
dr->handle.owner = rqstp->rq_server;
dr->prot = rqstp->rq_prot;
-   dr->addr = rqstp->rq_addr;
+   memcpy(&dr->addr, &rqstp->rq_addr, rqstp->rq_addrlen);
+   dr->addrlen = rqstp->rq_addrlen;
dr->daddr = rqstp->rq_daddr;
dr->argslen = rqstp->rq_arg.len >> 2;
memcpy(dr->args, rqstp->rq_arg.head[0].iov_base-skip, 
dr->argslen<<2);
@@ -1737,7 +1738,8 @@ static int svc_deferred_recv(struct svc_
rqstp->rq_arg.page_len = 0;
rqstp->rq_arg.len = dr->argslen<<2;
rqstp->rq_prot= dr->prot;
-   rqstp->rq_addr= dr->addr;
+   memcpy(&rqstp->rq_addr, &dr->addr, dr->addrlen);
+   rqstp->rq_addrlen = dr->addrlen;
rqstp->rq_daddr   = dr->daddr;
rqstp->rq_respages= rqstp->rq_pages;
return dr->argslen<<2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 003 of 14] knfsd: SUNRPC: Cache remote peer's address in svc_sock.

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
The remote peer's address won't change after the socket has been
accepted.  We don't need to call ->getname on every incoming request.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./include/linux/sunrpc/svcsock.h |3 +++
 ./net/sunrpc/svcsock.c   |   11 +--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff .prev/include/linux/sunrpc/svcsock.h ./include/linux/sunrpc/svcsock.h
--- .prev/include/linux/sunrpc/svcsock.h2006-12-13 10:29:09.0 
+1100
+++ ./include/linux/sunrpc/svcsock.h2006-12-13 10:29:13.0 +1100
@@ -57,6 +57,9 @@ struct svc_sock {
 
/* cache of various info for TCP sockets */
void*sk_info_authunix;
+
+   struct sockaddr_storage sk_remote;  /* remote peer's address */
+   int sk_remotelen;   /* length of address */
 };
 
 /*

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:29:09.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:29:13.0 +1100
@@ -577,11 +577,9 @@ svc_recvfrom(struct svc_rqst *rqstp, str
len = kernel_recvmsg(sock, &msg, iov, nr, buflen, MSG_DONTWAIT);
 
/* sock_recvmsg doesn't fill in the name/namelen, so we must..
-* possibly we should cache this in the svc_sock structure
-* at accept time. FIXME
 */
-   alen = sizeof(rqstp->rq_addr);
-   kernel_getpeername(sock, (struct sockaddr *)&rqstp->rq_addr, &alen);
+   memcpy(&rqstp->rq_addr, &svsk->sk_remote, svsk->sk_remotelen);
+   rqstp->rq_addrlen = svsk->sk_remotelen;
 
dprintk("svc: socket %p recvfrom(%p, %Zu) = %d\n",
rqstp->rq_sock, iov[0].iov_base, iov[0].iov_len, len);
@@ -873,7 +871,7 @@ svc_tcp_accept(struct svc_sock *svsk)
struct socket   *sock = svsk->sk_sock;
struct socket   *newsock;
struct svc_sock *newsvsk;
-   int err, slen;
+   int err, slen = 0;
 
dprintk("svc: tcp_accept %p sock %p\n", svsk, sock);
if (!sock)
@@ -925,7 +923,8 @@ svc_tcp_accept(struct svc_sock *svsk)
if (!(newsvsk = svc_setup_socket(serv, newsock, &err,
 (SVC_SOCK_ANONYMOUS | SVC_SOCK_TEMPORARY
goto failed;
-
+   memcpy(&newsvsk->sk_remote, &sin, slen);
+   newsvsk->sk_remotelen = slen;
 
/* make sure that we don't have too many active connections.
 * If we have, something must be dropped.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 010 of 14] knfsd: SUNRPC: add a "generic" function to see if the peer uses a secure port

[NeilBrown]

From: Chuck Lever <[EMAIL PROTECTED]>
The only reason svcsock.c looks at a sockaddr's port is to check whether
the remote peer is connecting from a privileged port.  Refactor this check
to hide processing that is specific to address format.

Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./net/sunrpc/svcsock.c |   20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c  2006-12-13 10:32:15.0 +1100
+++ ./net/sunrpc/svcsock.c  2006-12-13 10:32:17.0 +1100
@@ -926,6 +926,20 @@ svc_tcp_data_ready(struct sock *sk, int 
wake_up_interruptible(sk->sk_sleep);
 }
 
+static inline int svc_port_is_privileged(struct sockaddr *sin)
+{
+   switch (sin->sa_family) {
+   case AF_INET:
+   return ntohs(((struct sockaddr_in *)sin)->sin_port) < 1024;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+   case AF_INET6:
+   return ntohs(((struct sockaddr_in6 *)sin)->sin6_port) < 1024;
+#endif
+   default:
+   return 0;
+   }
+}
+
 /*
  * Accept a TCP connection
  */
@@ -972,7 +986,7 @@ svc_tcp_accept(struct svc_sock *svsk)
 * hosts here, but when we get encryption, the IP of the host won't
 * tell us anything.  For now just warn about unpriv connections.
 */
-   if (ntohs(sin.sin_port) >= 1024) {
+   if (!svc_port_is_privileged((struct sockaddr *) &sin)) {
dprintk(KERN_WARNING
"%s: connect from unprivileged port: %s\n",
serv->sv_name,
@@ -1313,7 +1327,6 @@ int
 svc_recv(struct svc_rqst *rqstp, long timeout)
 {
struct svc_sock *svsk = NULL;
-   struct sockaddr_in  *sin = svc_addr_in(rqstp);
struct svc_serv *serv = rqstp->rq_server;
struct svc_pool *pool = rqstp->rq_pool;
int len, i;
@@ -1408,7 +1421,8 @@ svc_recv(struct svc_rqst *rqstp, long ti
svsk->sk_lastrecv = get_seconds();
clear_bit(SK_OLD, &svsk->sk_flags);
 
-   rqstp->rq_secure = ntohs(sin->sin_port) < 1024;
+   rqstp->rq_secure =
+   svc_port_is_privileged(svc_addr(rqstp));
rqstp->rq_chandle.defer = svc_defer;
 
if (serv->sv_stats)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 014 of 14] knfsd: Don't mess with the 'mode' when storing a exclusive-create cookie.

[NeilBrown]

From: Peter Staubach <[EMAIL PROTECTED]>

NFS V3 (and V4) support exclusive create by passing a 'cookie' which
can get stored with the file.  If the file exists but has exactly the
right cookie stored, then we assume this is a retransmit and the
exclusive create was successful.

The cookie is 64bits and is traditionally stored in the mtime and
atime fields.  This causes a problem with Solaris7 as negative mtime
or atime confuse it.  So we moved two bits into the mode word instead.

But inherited ACLs sometimes overwrite the mode word on create, so
this is a problem.

So we give up and just store 62 of the 64 bits and assume that is
close enough.

Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./fs/nfsd/vfs.c |   21 +
 1 file changed, 5 insertions(+), 16 deletions(-)

diff .prev/fs/nfsd/vfs.c ./fs/nfsd/vfs.c
--- .prev/fs/nfsd/vfs.c 2006-12-08 12:08:37.0 +1100
+++ ./fs/nfsd/vfs.c 2006-12-13 10:44:55.0 +1100
@@ -1248,7 +1248,6 @@ nfsd_create_v3(struct svc_rqst *rqstp, s
__be32  err;
int host_err;
__u32   v_mtime=0, v_atime=0;
-   int v_mode=0;
 
err = nfserr_perm;
if (!flen)
@@ -1285,16 +1284,11 @@ nfsd_create_v3(struct svc_rqst *rqstp, s
goto out;
 
if (createmode == NFS3_CREATE_EXCLUSIVE) {
-   /* while the verifier would fit in mtime+atime,
-* solaris7 gets confused (bugid 4218508) if these have
-* the high bit set, so we use the mode as well
+   /* solaris7 gets confused (bugid 4218508) if these have
+* the high bit set, so just clear the high bits.
 */
v_mtime = verifier[0]&0x7fff;
v_atime = verifier[1]&0x7fff;
-   v_mode  = S_IFREG
-   | ((verifier[0]&0x8000) >> (32-7)) /* u+x */
-   | ((verifier[1]&0x8000) >> (32-9)) /* u+r */
-   ;
}

if (dchild->d_inode) {
@@ -1322,7 +1316,6 @@ nfsd_create_v3(struct svc_rqst *rqstp, s
case NFS3_CREATE_EXCLUSIVE:
if (   dchild->d_inode->i_mtime.tv_sec == v_mtime
&& dchild->d_inode->i_atime.tv_sec == v_atime
-   && dchild->d_inode->i_mode  == v_mode
&& dchild->d_inode->i_size  == 0 )
break;
 /* fallthru */
@@ -1344,26 +1337,22 @@ nfsd_create_v3(struct svc_rqst *rqstp, s
}
 
if (createmode == NFS3_CREATE_EXCLUSIVE) {
-   /* Cram the verifier into atime/mtime/mode */
+   /* Cram the verifier into atime/mtime */
iap->ia_valid = ATTR_MTIME|ATTR_ATIME
-   | ATTR_MTIME_SET|ATTR_ATIME_SET
-   | ATTR_MODE;
+   | ATTR_MTIME_SET|ATTR_ATIME_SET;
/* XXX someone who knows this better please fix it for nsec */ 
iap->ia_mtime.tv_sec = v_mtime;
iap->ia_atime.tv_sec = v_atime;
iap->ia_mtime.tv_nsec = 0;
iap->ia_atime.tv_nsec = 0;
-   iap->ia_mode  = v_mode;
}
 
/* Set file attributes.
-* Mode has already been set but we might need to reset it
-* for CREATE_EXCLUSIVE
 * Irix appears to send along the gid when it tries to
 * implement setgid directories via NFS. Clear out all that cruft.
 */
  set_attr:
-   if ((iap->ia_valid &= ~(ATTR_UID|ATTR_GID)) != 0) {
+   if ((iap->ia_valid &= ~(ATTR_UID|ATTR_GID|ATTR_MODE)) != 0) {
__be32 err2 = nfsd_setattr(rqstp, resfhp, iap, 0, (time_t)0);
if (err2)
err = err2;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mapping PCI registers with write combining (and PAT on x86)...

[Roland Dreier]

 > So I think we may simplify this but there is pci_mmap_page_range.  That
 > already handles this for the architectures that currently support it.
 > So it is probably the case the fbdev should be changed to use that.

Thanks... I was not aware of pci_mmap_page_range(), but that doesn't
seem to be quite the right interface.  It uses vma->vm_pgoff to say
what to remap.  A typical use for what I have in mind would be for a
userspace process to open a magic file and do mmap() at some
well-known offset (like 0), and have the kernel driver map the right
PCI registers into userspace, without userspace having to know what
offset to ask for.

This is especially important when the kernel has to handle picking a
"context" or "port" to avoid multiple userspace processes stepping on
each other.

And of course arch/i386/pci/i386.c has the following in its
pci_mmap_page_range() anyway:

/* Write-combine setting is ignored, it is changed via the mtrr
 * interfaces on this platform.
 */

so the write_combine parameter is ignored...

 > No one had any serious objections to my patches as they were.  The actual
 > problem was that the patches were incomplete.  In particular if you
 > mismatch page protections it is possible to get silent data corruption
 > or processor crashes.  So we need checks to ensure all mappings of
 > a given page are using the same protections.
 > 
 > To a certain extent I think adding those checks really is a strawman
 > and should not stop the merge effort, because we have this feature and
 > those possible bugs on other architectures right now and we don't have
 > those checks.  But I also think in the long term we need them, it just
 > requires several days of going through the mm so we don't leave any
 > path uncovered.

It does seem somewhat hard to make sure there aren't multiple mappings
of the same thing, and I'm not sure it's worth trying to avoid it.  If
a device driver lets me mmap PCI memory with write-combining on, and
then (as root) I mmap raw PCI resources to get the same memory, whose
fault is it if things break?

I'm kind of an mm dummy but I don't even see a good way to avoid
multiple mappings like that.

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

Re: [PATCH 2.6.19-rc1] Toshiba TC86C001 IDE driver

[Alan]

> + * We work around this by initiating dummy, zero-length DMA transfer on
> + * a DMA timeout expiration. I found no better way to do this with the 
> current

Novel workaround and probably better than resetting the chip as the
winbong does.

> +static int tc86c001_busproc(ide_drive_t *drive, int state)
> +{

Waste of space having a busproc routine. The maintainer removed all the
usable hotplug support from old IDE so this might as well be dropped.

> @@ -1407,6 +1407,24 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x260a, quirk_intel_pcie_pm);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x260b, quirk_intel_pcie_pm);
>  
> +/*
> + * Toshiba TC86C001 IDE controller reports the standard 8-byte BAR0 size
> + * but PIO transfer won't work if BAR0 falls at the odd 8 bytes.
> + * Re-allocate the region if needed.
> + */

NAK. I think this fixup should be testing if the device port 0 is in
native mode before doing the fixup. In comaptibility mode bar 0 is
ignored and the correct compatibility values set up in the resource tree
by the PCI layer as of 2.6.18-mm-mumble. They are also of course on a xx0
boundary.

"Close but no cookie": please fix the PCI quirk to match the current -mm
behaviour with the ATA resource tree. Otherwise - nice driver.

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: [2.6 patch] remove the broken SCSI_SEAGATE driver

[Adrian Bunk]

On Tue, Dec 12, 2006 at 05:31:14PM -0600, James Bottomley wrote:
> On Tue, 2006-12-12 at 17:22 +0100, Adrian Bunk wrote:
> > The SCSI_SEAGATE driver has:
> > - already been marked as BROKEN in 2.6.0 three years ago and
> > - is still marked as BROKEN.
> > 
> > Drivers that had been marked as BROKEN for such a long time seem to be
> > unlikely to be revived in the forseeable future.
> > 
> > But if anyone wants to ever revive this driver, the code is still
> > present in the older kernel releases.
> 
> Would you care to explain the rationale for this, please.  If the driver
> had been riddled with errors and compilation problems, I might have
> acquiesced, but now I come to look it over, it seems structurally
> reasonably OK (we certainly have non-BROKEN worse ones) plus it compiles
> fine.  So I'm wondering why it's marked broken in the first place.
> 
> Since it was your original patch:
> 
> Author: Adrian Bunk <[EMAIL PROTECTED]>
> Date:   Mon Sep 1 19:22:52 2003 -0700
> 
> [PATCH] Mark more drivers BROKEN{,ON_SMP}
> 
> - let more drivers that don't compile depend on BROKEN
> - MTD_BLKMTD is fixed, remove the dependency on BROKEN
> - let all drivers that don't compile on SMP (due to cli/sti usage)
>   depend on a BROKEN_ON_SMP that is only defined if !SMP || BROKEN
> - #include interrupt.h for dummy cli/sti/... in two files to fix the
>   UP compilation of these files
> 
> I marked only drivers that are broken for a long time and where I don't
> know about existing fixes with BROKEN or BROKEN_ON_SMP.
> 
> I'd like to know why it was marked BROKEN in the first place.


There must have been a compile error that has since been fixed, but I 
don't remember the details of this specific driver and I don't have 
such old compile logs anymore.


> Thanks,
> 
> James

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 2/3] acpi: Add a docked sysfs file to the dock driver.

[Stefan Schmidt]

Hello.

On Tue, 2006-12-12 at 15:00, Kristen Carlson Accardi wrote:
> 
> I did have different dock/undock events a few months ago - but
> after some discussion we scrapped them because Kay wants to avoid driver
> specific events.  The "change" event is the only thing that makes sense,
> given the set of uevents available right now, and userspace should be 
> able to handle checking a file to get driver specific details (i.e. dock 
> and undock status).  If you have a specific reason why this won't work,
> let me know.

It's fine with me. I just find two different events more handy.
Checking the file after the event in userspace should not be aproblem.

regards
Stefan Schmidt


signature.asc
Description: Digital signature

Re: Make OLPC camera driver depend on x86.

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Tue, 12 Dec 2006 10:39:56 -0500, Dave Jones wrote:

> [gads, an ia64 olpc, what a thought...]

Teacher in front of a classroom full of students, all madly
pedaling away on stationary bicycles: "Okay, class, just another
hour of this and we can use the computers for a few minutes."

-- 
MBTI: IXTP

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

Re: [PATCH 2/5] Paravirt cpu batching.patch

[Chuck Ebbert]

In-Reply-To: <[EMAIL PROTECTED]>

On Tue, 12 Dec 2006 14:54:30 -0800, Chros Wright wrote:

> > --- a/arch/i386/kernel/process.cTue Dec 12 13:50:50 2006 -0800
> > +++ b/arch/i386/kernel/process.cTue Dec 12 13:50:53 2006 -0800
> > @@ -665,6 +665,37 @@ struct task_struct fastcall * __switch_t
> > load_TLS(next, cpu);
> >  
> > /*
> > +* Restore IOPL if needed.
> > +*/
> > +   if (unlikely(prev->iopl != next->iopl))
> > +   set_iopl_mask(next->iopl);
>
> Small sidenote that this bit undoes a recent change from Chuck Ebbert, which
> killed iopl_mask update via hypervisor.

This whole thing needs a proper fix IMO.  I posted something a while back
but Andi didn't like it, I guess.

-- 
MBTI: IXTP

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

Postgrey experiment at VGER

[Matti Aarnio]

Hello,

  I am running an experiment with Postgrey to delay (for 300 seconds
minimum) incoming emails.   If the clients don't retry after this
delay, then the messages don't usually get in.

The "postgrey" in question is the very same thing that exists for
the Postfix MTA with various automatic whitelistings of repeatedly
successfull senders, etc.

I do already see spammers smart enough to retry addresses from
the zombie machine, but that share is now below 10% of all emails.
My prediction for next 200 days is that most spammers get the clue,
but it gives us perhaps 3 months of less leaked junk.

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

please pull from the trivial tree

[Adrian Bunk]

Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial.git


This tree contains the following:

Alistair John Strachan (1):
  include/linux/compiler.h: reject gcc 3 < gcc 3.2

Cal Peake (1):
  Fix inotify maintainers entry

Dave Jones (2):
  Jon needs a new shift key.
  Fix typo in new debug options.

Jan Engelhardt (1):
  EXT{2,3,4}_FS: remove outdated part of the help text

Jesper Juhl (1):
  Kconfig: fix spelling error in config KALLSYMS help text

Peter Zijlstra (1):
  fix typo in net/ipv4/ip_fragment.c

Robert P. J. Day (3):
  kconfig: Standardize "depends" -> "depends on" in Kconfig files
  configfs.h: Remove dead macro definitions.
  fs: Convert kmalloc() + memset() to kzalloc() in fs/.

Rolf Eike Beer (1):
  Remove duplicate "have to" in comment

Samuel Tardieu (1):
  Use consistent casing in help message

Thomas Hisch (1):
  Fix small typo in drivers/serial/icom.c

Yan Burman (2):
  um: replace kmalloc+memset with kzalloc
  e100: replace kmalloc with kcalloc


 Documentation/kbuild/kconfig-language.txt  |8 +++---
 MAINTAINERS|6 +++-
 Makefile   |4 +--
 arch/arm/mach-pxa/Kconfig  |   16 ++--
 arch/arm/plat-omap/Kconfig |2 -
 arch/powerpc/platforms/4xx/Kconfig |2 -
 arch/powerpc/platforms/embedded6xx/Kconfig |2 -
 arch/ppc/Kconfig   |4 +--
 arch/ppc/platforms/4xx/Kconfig |2 -
 arch/um/drivers/net_kern.c |3 --
 arch/v850/Kconfig  |   28 ++---
 drivers/char/Kconfig   |2 -
 drivers/ide/Kconfig|2 -
 drivers/leds/Kconfig   |   22 
 drivers/media/video/ov7670.c   |2 -
 drivers/net/e100.c |3 --
 drivers/serial/Kconfig |4 +--
 drivers/serial/icom.c  |2 -
 fs/Kconfig |   14 +++---
 fs/binfmt_elf_fdpic.c  |3 --
 include/linux/compiler.h   |2 -
 include/linux/configfs.h   |   25 --
 include/linux/sysctl.h |2 -
 init/Kconfig   |2 -
 lib/Kconfig.debug  |2 -
 net/ipv4/ip_fragment.c |2 -
 sound/aoa/fabrics/Kconfig  |2 -
 27 files changed, 68 insertions(+), 100 deletions(-)


diff --git a/Documentation/kbuild/kconfig-language.txt 
b/Documentation/kbuild/kconfig-language.txt
index 125093c..536d5bf 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -29,7 +29,7 @@ them. A single configuration option is defined like this:
 
 config MODVERSIONS
bool "Set version information on all module symbols"
-   depends MODULES
+   depends on MODULES
help
  Usually, modules have to be recompiled whenever you switch to a new
  kernel.  ...
@@ -163,7 +163,7 @@ The position of a menu entry in the tree is determined in 
two ways. First
 it can be specified explicitly:
 
 menu "Network device support"
-   depends NET
+   depends on NET
 
 config NETDEVICES
...
@@ -188,10 +188,10 @@ config MODULES
 
 config MODVERSIONS
bool "Set version information on all module symbols"
-   depends MODULES
+   depends on MODULES
 
 comment "module support disabled"
-   depends !MODULES
+   depends on !MODULES
 
 MODVERSIONS directly depends on MODULES, this means it's only visible if
 MODULES is different from 'n'. The comment on the other hand is always
diff --git a/MAINTAINERS b/MAINTAINERS
index b202493..9649ed9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1504,8 +1504,10 @@ T:   git 
kernel.org:/pub/scm/linux/kernel/git/dtor/input.git
 S: Maintained
 
 INOTIFY
-P: John McCutchan and Robert Love
-M: [EMAIL PROTECTED] and [EMAIL PROTECTED]
+P: John McCutchan
+M: [EMAIL PROTECTED]
+P: Robert Love
+M: [EMAIL PROTECTED]
 L: linux-kernel@vger.kernel.org
 S: Maintained
 
diff --git a/Makefile b/Makefile
index 73e825b..4eabaa8 100644
--- a/Makefile
+++ b/Makefile
@@ -1100,9 +1100,9 @@ boards := $(notdir $(boards))
 
 help:
@echo  'Cleaning targets:'
-   @echo  '  clean   - remove most generated files but keep the 
config and'
+   @echo  '  clean   - Remove most generated files but keep the 
config and'
@echo  'enough build support to build external 
modules'
-   @echo  '  mrproper- remove all generated files + config + 
various backup files'
+   @echo  '  mrproper- Remove all generated files + config + 
various backup files'
@echo  '  distclean   - mrp

Re: [2.6 patch] remove the broken SCSI_SEAGATE driver

[James Bottomley]

On Tue, 2006-12-12 at 17:22 +0100, Adrian Bunk wrote:
> The SCSI_SEAGATE driver has:
> - already been marked as BROKEN in 2.6.0 three years ago and
> - is still marked as BROKEN.
> 
> Drivers that had been marked as BROKEN for such a long time seem to be
> unlikely to be revived in the forseeable future.
> 
> But if anyone wants to ever revive this driver, the code is still
> present in the older kernel releases.

Would you care to explain the rationale for this, please.  If the driver
had been riddled with errors and compilation problems, I might have
acquiesced, but now I come to look it over, it seems structurally
reasonably OK (we certainly have non-BROKEN worse ones) plus it compiles
fine.  So I'm wondering why it's marked broken in the first place.

Since it was your original patch:

Author: Adrian Bunk <[EMAIL PROTECTED]>
Date:   Mon Sep 1 19:22:52 2003 -0700

[PATCH] Mark more drivers BROKEN{,ON_SMP}

- let more drivers that don't compile depend on BROKEN
- MTD_BLKMTD is fixed, remove the dependency on BROKEN
- let all drivers that don't compile on SMP (due to cli/sti usage)
  depend on a BROKEN_ON_SMP that is only defined if !SMP || BROKEN
- #include interrupt.h for dummy cli/sti/... in two files to fix the
  UP compilation of these files

I marked only drivers that are broken for a long time and where I don't
know about existing fixes with BROKEN or BROKEN_ON_SMP.

I'd like to know why it was marked BROKEN in the first place.

Thanks,

James


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

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[David Howells]

Russell King <[EMAIL PROTECTED]> wrote:

> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
> 
> Why can't we just use atomic_t for this?

atomic_t is the wrong thing as it's basically an int, not an unsigned long.

atomic64_t/atomic_long_t is also probably the wrong thing to use as it's a
signed long (and the long is also volatile on some platforms - x86_64 for
example).  Bitops operate on unsigned long.

But the most important point is that assign_bits() has to take the same pointer
type as test_bit(), set_bit(), test_and_set_bit(), etc., and none of those
operate on an atomic*_t.

We could change that, of course, but I don't fancy tackling the task just at
the moment.  It oughtn't to be a difficult change, but there are a lot of flags
words in the kernel.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] kthread API conversion for dvb_frontend and av7110

[Herbert Poetzl]

On Tue, Dec 12, 2006 at 03:58:16PM -0700, Eric W. Biederman wrote:
> Andrew de Quincey <[EMAIL PROTECTED]> writes:
> 
> > [snip]
> >
> >> correct, will fix that up in the next round
> >>
> >> thanks for the feedback,
> >> Herbert
> >
> > Hi - the conversion looks good to me.. I can't really offer any more 
> > constructive suggestions beyond what Cedric has already said. 
> >
> > Theres another thread in dvb_ca_en50221.c that could be converted as well 
> > though, hint hint ;)
> >
> > Apologies for the delay in this reply - I've been hibernating for a bit.
> 
> Guys where are we at on this conversion?

I can take a look at it in the next few days, but
I have no hardware to test that, so it would be
good to get in contact with somebody who does

best,
Herbert

> 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: [PATCH 2.6.19-rc1] Toshiba TC86C001 IDE driver

[Randy Dunlap]

Sergei Shtylyov wrote:

Hello.

Randy Dunlap wrote:

Behold!  This is the driver for the Toshiba TC86C001 GOKU-S IDE 
controller,
completely reworked from the original brain-damaged Toshiba's 2.4 
version.


This single channel UltraDMA/66 controller is very simple in 
programming, yet
Toshiba managed to plant many interesting bugs in it.  The 
particularly nasty
"limitation 5" (as they call the errata) caused me to abuse the IDE 
core in a
possibly most interesting way so far.  However, this is still better 
than the
#ifdef mess in drivers/ide/ide-io.c that the original version 
included (well,

it had much more mess)...



Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>


drivers/ide/Kconfig|5 drivers/ide/pci/Makefile   |1 
drivers/ide/pci/tc86c001.c |  304 
+

drivers/pci/quirks.c   |   18 ++
include/linux/pci_ids.h|1 5 files changed, 329 insertions(+)

Index: linux-2.6/drivers/ide/Kconfig
===
--- linux-2.6.orig/drivers/ide/Kconfig
+++ linux-2.6/drivers/ide/Kconfig
@@ -742,6 +742,11 @@ config BLK_DEV_VIA82CXXX
  This allows the kernel to change PIO, DMA and UDMA speeds and to
  configure the chip to optimum performance.

+config BLK_DEV_TC86C001
+tristate "Toshiba TC86C001 support"



Needs something here like lots of other IDE PCI drivers have:
depends on PCI && BLK_DEV_IDEPCI



or at least:  depends on PCI


   No, it's already under if BLK_DEV_IDEPCI. And if you really look into 
Kconfig you'll see hwo it's done there...



+help
+This driver adds support for Toshiba TC86C001 GOKU-S chip.
+
endif


   Here's that endif.


Ack.  Thanks.

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

Re: [patch 2/3] acpi: Add a docked sysfs file to the dock driver.

[Kristen Carlson Accardi]

On Tue, 12 Dec 2006 14:31:10 -0800
Jesse Barnes <[EMAIL PROTECTED]> wrote:

> On Tuesday, December 12, 2006 2:15 pm, Stefan Schmidt wrote:
> > Hello.
> >
> > On Mon, 2006-12-11 at 12:05, Kristen Carlson Accardi wrote:
> > > On Sat, 9 Dec 2006 12:59:58 +0100
> > >
> > > Holger Macht <[EMAIL PROTECTED]> wrote:
> > > > Well, I like to have them ;-)
> > >
> > > Ok - how is this?
> > >
> > > Send a uevent to indicate a device change whenever we dock or
> > > undock, so that userspace may now check the dock status via
> > > sysfs.
> >
> > I would like to have two different events for dock and undock.
> >
> > This way the userspace listener don't need to check the status file
> > in sysfs to know if there was a dock or undock after getting the
> > event.
> >
> > Anyway the status file is still usefull for programs don't react on
> > the events, but like to know if the laptop is docked before starting
> > for example.
> 
> FWIW, Kay and Neil recently went back and forth regarding what sorts of 
> events to generate for MD online/offline events.  In concept md 
> online/offline and dock/undock seem similar enough that the 'change' 
> events Kay requested for md probably make sense in the dock/undock 
> context as well, but I've Cc'd him just in case.
> 
> Jesse
> 

I did have different dock/undock events a few months ago - but
after some discussion we scrapped them because Kay wants to avoid driver
specific events.  The "change" event is the only thing that makes sense,
given the set of uevents available right now, and userspace should be 
able to handle checking a file to get driver specific details (i.e. dock 
and undock status).  If you have a specific reason why this won't work,
let me know.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.19-rc1] Toshiba TC86C001 IDE driver

[Sergei Shtylyov]

Hello.

Randy Dunlap wrote:


Behold!  This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
completely reworked from the original brain-damaged Toshiba's 2.4 version.

This single channel UltraDMA/66 controller is very simple in programming, yet
Toshiba managed to plant many interesting bugs in it.  The particularly nasty
"limitation 5" (as they call the errata) caused me to abuse the IDE core in a
possibly most interesting way so far.  However, this is still better than the
#ifdef mess in drivers/ide/ide-io.c that the original version included (well,
it had much more mess)...



Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>


drivers/ide/Kconfig|5 
drivers/ide/pci/Makefile   |1 
drivers/ide/pci/tc86c001.c |  304 +

drivers/pci/quirks.c   |   18 ++
include/linux/pci_ids.h|1 
5 files changed, 329 insertions(+)


Index: linux-2.6/drivers/ide/Kconfig
===
--- linux-2.6.orig/drivers/ide/Kconfig
+++ linux-2.6/drivers/ide/Kconfig
@@ -742,6 +742,11 @@ config BLK_DEV_VIA82CXXX
  This allows the kernel to change PIO, DMA and UDMA speeds and to
  configure the chip to optimum performance.

+config BLK_DEV_TC86C001
+   tristate "Toshiba TC86C001 support"



Needs something here like lots of other IDE PCI drivers have:
depends on PCI && BLK_DEV_IDEPCI



or at least:  depends on PCI


   No, it's already under if BLK_DEV_IDEPCI. And if you really look into 
Kconfig you'll see hwo it's done there...



+   help
+   This driver adds support for Toshiba TC86C001 GOKU-S chip.
+
endif


   Here's that endif.

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

Re: [patch 2.6.19-git] RTC Kconfig sorted by type

[Adrian Bunk]

On Wed, Dec 06, 2006 at 04:52:44PM -0800, David Brownell wrote:
> This reorders the RTC driver menu into separate sections, splitting out
> the SOC, I2C, and SPI support to help make the menu easier to navigate.
> (We got some feedback a while ago that it was "a mess" and hard to make
> sense of...)
> 
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> 
> ---
> Assumes the rtc-omap patch has been merged, and no other RTC drivers
> have been added to this Kconfig menu.
> 
> Index: at91/drivers/rtc/Kconfig
> ===
> --- at91.orig/drivers/rtc/Kconfig 2006-12-05 03:25:20.0 -0800
> +++ at91/drivers/rtc/Kconfig  2006-12-05 03:46:53.0 -0800
> @@ -1,4 +1,4 @@
> -\#
> +#
>  # RTC class/drivers configuration
>  #
>  
> @@ -20,6 +20,8 @@ config RTC_CLASS
> This driver can also be built as a module. If so, the module
> will be called rtc-class.
>  
> +if RTC_CLASS != n
> +


if RTC_CLASS


because otherwise


>  config RTC_HCTOSYS
>   bool "Set system time from RTC on startup"
>   depends on RTC_CLASS = y
> @@ -45,11 +47,10 @@ config RTC_DEBUG
> and individual RTC drivers.
>  
>  comment "RTC interfaces"
> - depends on RTC_CLASS
>  
>  config RTC_INTF_SYSFS
>   tristate "sysfs"
> - depends on RTC_CLASS && SYSFS
> + depends on SYSFS
>...


RTC_CLASS=m, RTC_INTF_SYSFS=y would be an allowed configuration.


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 2/2] cciss: remove calls to pci_disable_device

[Alan]

On Tue, 12 Dec 2006 13:54:58 -0600
"Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote:

> PATCH 2/2
> 
> This patch removes calls to pci_disable_device except in fail_all_cmds. The 
> pci_disable_device function does something nasty to Smart Array controllers 
> that pci_enable_device does not undo. So if the driver is unloaded it cannot 
> be reloaded.

Acked-by: Alan Cox <[EMAIL PROTECTED]>

Various devices do this. Please however update the patch or add a patch
which includes comments as to why or someone will helpfully put them back
one day.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[WATCHDOG] fixes for v2.6.19+

[Wim Van Sebroeck]

Hi Linus,

Please pull from 'master' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git
or if master.kernel.org hasn't synced up yet:
master.kernel.org:/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog.git

This will update the following files:

 drivers/char/watchdog/at91rm9200_wdt.c |6 ++--
 drivers/char/watchdog/mpcore_wdt.c |2 -
 drivers/char/watchdog/omap_wdt.c   |2 -
 drivers/char/watchdog/pcwd_usb.c   |5 ---
 drivers/char/watchdog/rm9k_wdt.c   |   44 -
 5 files changed, 28 insertions(+), 31 deletions(-)

with these Changes:

Author: Wim Van Sebroeck <[EMAIL PROTECTED]>
Date:   Tue Dec 12 23:46:47 2006 +0100

[WATCHDOG] pcwd_usb.c generic HID include file

Now that the generic HID layer created include/linux/hid.h
we can use the HID_REQ_SET_REPORT and HID_DT_REPORT defines
directly from that include file.

Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Andrew Victor <[EMAIL PROTECTED]>
Date:   Mon Dec 4 15:56:18 2006 +0200

[WATCHDOG] watchdog miscdevice patch

It looks like the recent changes to 'struct miscdevice' have impacted
some of the Watchdog drivers.

at91rm9200_wdt.c:205: error: 'struct miscdevice' has no member named 'dev'

For the AT91RM9200 driver I just replaced "miscdevice.dev" with
"miscdevice.parent".

The mpcore_wdt.c and omap_wdt.c seem similarly affected.

Signed-off-by: Andrew Victor <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Thomas Koeller <[EMAIL PROTECTED]>
Date:   Wed Dec 6 01:45:39 2006 +0100

[WATCHDOG] rm9k_wdt: fix interrupt handler arguments

Removed 'struct pt_regs *' from interrupt handler arguments.

Signed-off-by: Thomas Koeller <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

Author: Thomas Koeller <[EMAIL PROTECTED]>
Date:   Wed Dec 6 01:45:26 2006 +0100

[WATCHDOG] rm9k_wdt: fix compilation

Driver did not compile any more. Someone moved the definition
of 'struct miscdevice miscdev' to a place near the end of the
file, after some code that was refering to this variable.

Signed-off-by: Thomas Koeller <[EMAIL PROTECTED]>
Signed-off-by: Wim Van Sebroeck <[EMAIL PROTECTED]>

The Changes can also be looked at on:

http://www.kernel.org/git/?p=linux/kernel/git/wim/linux-2.6-watchdog.git;a=summary

For completeness, I added the overal diff below.

Greetings,
Wim.


diff --git a/drivers/char/watchdog/at91rm9200_wdt.c 
b/drivers/char/watchdog/at91rm9200_wdt.c
index cb86967..38bd373 100644
--- a/drivers/char/watchdog/at91rm9200_wdt.c
+++ b/drivers/char/watchdog/at91rm9200_wdt.c
@@ -203,9 +203,9 @@ static int __init at91wdt_probe(struct p
 {
int res;
 
-   if (at91wdt_miscdev.dev)
+   if (at91wdt_miscdev.parent)
return -EBUSY;
-   at91wdt_miscdev.dev = &pdev->dev;
+   at91wdt_miscdev.parent = &pdev->dev;
 
res = misc_register(&at91wdt_miscdev);
if (res)
@@ -221,7 +221,7 @@ static int __exit at91wdt_remove(struct 
 
res = misc_deregister(&at91wdt_miscdev);
if (!res)
-   at91wdt_miscdev.dev = NULL;
+   at91wdt_miscdev.parent = NULL;
 
return res;
 }
diff --git a/drivers/char/watchdog/mpcore_wdt.c 
b/drivers/char/watchdog/mpcore_wdt.c
index 3404a9c..e88947f 100644
--- a/drivers/char/watchdog/mpcore_wdt.c
+++ b/drivers/char/watchdog/mpcore_wdt.c
@@ -347,7 +347,7 @@ static int __devinit mpcore_wdt_probe(st
goto err_free;
}
 
-   mpcore_wdt_miscdev.dev = &dev->dev;
+   mpcore_wdt_miscdev.parent = &dev->dev;
ret = misc_register(&mpcore_wdt_miscdev);
if (ret) {
dev_printk(KERN_ERR, _dev, "cannot register miscdev on minor=%d 
(err=%d)\n",
diff --git a/drivers/char/watchdog/omap_wdt.c b/drivers/char/watchdog/omap_wdt.c
index 5dbd7dc..6c6f973 100644
--- a/drivers/char/watchdog/omap_wdt.c
+++ b/drivers/char/watchdog/omap_wdt.c
@@ -290,7 +290,7 @@ static int __init omap_wdt_probe(struct 
omap_wdt_disable();
omap_wdt_adjust_timeout(timer_margin);
 
-   omap_wdt_miscdev.dev = &pdev->dev;
+   omap_wdt_miscdev.parent = &pdev->dev;
ret = misc_register(&omap_wdt_miscdev);
if (ret)
goto fail;
diff --git a/drivers/char/watchdog/pcwd_usb.c b/drivers/char/watchdog/pcwd_usb.c
index 6113872..2da5ac9 100644
--- a/drivers/char/watchdog/pcwd_usb.c
+++ b/drivers/char/watchdog/pcwd_usb.c
@@ -42,6 +42,7 @@ #include 
 #include 
 #include 
 #include 
+#include  /* For HID_REQ_SET_REPORT & HID_DT_REPORT */
 
 
 #ifdef CONFIG_USB_DEBUG
@@ -109,10 +110,6 @@ #define CMD_WRITE_WATCHDOG_TIMEOUT 0x19
 #define CMD_ENABLE_WATCHDOG0x30/* Enable / Disable Watchd

Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

[Paul Mackerras]

Russell King writes:

> Why can't we just use atomic_t for this?

On 64-bit platforms, atomic_t tends to be 4 bytes, whereas bitops work
on arrays of unsigned long, i.e. multiples of 8 bytes.  We could
use atomic_long_t for this, however.

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

Re: [PATCH 2.6.19-rc1] Toshiba TC86C001 IDE driver

[Randy Dunlap]

On Wed, 13 Dec 2006 01:48:34 +0300 Sergei Shtylyov wrote:

> Behold!  This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
> completely reworked from the original brain-damaged Toshiba's 2.4 version.
> 
> This single channel UltraDMA/66 controller is very simple in programming, yet
> Toshiba managed to plant many interesting bugs in it.  The particularly nasty
> "limitation 5" (as they call the errata) caused me to abuse the IDE core in a
> possibly most interesting way so far.  However, this is still better than the
> #ifdef mess in drivers/ide/ide-io.c that the original version included (well,
> it had much more mess)...
> 
> Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
> 
>  drivers/ide/Kconfig|5 
>  drivers/ide/pci/Makefile   |1 
>  drivers/ide/pci/tc86c001.c |  304 
> +
>  drivers/pci/quirks.c   |   18 ++
>  include/linux/pci_ids.h|1 
>  5 files changed, 329 insertions(+)
> 
> Index: linux-2.6/drivers/ide/Kconfig
> ===
> --- linux-2.6.orig/drivers/ide/Kconfig
> +++ linux-2.6/drivers/ide/Kconfig
> @@ -742,6 +742,11 @@ config BLK_DEV_VIA82CXXX
> This allows the kernel to change PIO, DMA and UDMA speeds and to
> configure the chip to optimum performance.
>  
> +config BLK_DEV_TC86C001
> + tristate "Toshiba TC86C001 support"

Needs something here like lots of other IDE PCI drivers have:
depends on PCI && BLK_DEV_IDEPCI

or at least:  depends on PCI


> + help
> + This driver adds support for Toshiba TC86C001 GOKU-S chip.
> +
>  endif

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