Re: [RFC] Limit the size of the pagecache

[Peter Zijlstra]

On Tue, 2007-01-23 at 16:49 -0800, Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is IMHO 
> the right way. Feel free to improve on it. I have gotten repeatedly 
> requests to be able to limit the pagecache. With the revised VM statistics 
> this is now actually possile. I'd like to know more about possible uses of 
> such a feature.
> 
> 
> 
> 
> It may be useful to limit the size of the page cache for various reasons
> such as
> 
> 1. Insure that anonymous pages that may contain performance
>critical data is never subject to swap.

This is what we have mlock for, no?

> 2. Insure rapid turnaround of pages in the cache.

This sounds like we either need more fadvise hints and/or understand why
the VM doesn't behave properly.

> 3. Reserve memory for other uses? (Aubrey?)

He wants to make a nommu system act like a mmu system; this will just
never ever work. Memory fragmentation is a real issue not some gimmick
thought up by the hardware folks to sell these mmu chips.

> We add a new variable "pagecache_ratio" to /proc/sys/vm/ that
> defaults to 100 (all memory usable for the pagecache).
> 
> The size of the pagecache is the number of file backed
> pages in a zone which is available through NR_FILE_PAGES.
> 
> We skip zones that contain too many page cache pages in
> the page allocator which may cause us to enter reclaim.
> 
> If we enter reclaim and the number of page cache pages
> is too high then we switch off swapping during reclaim
> to avoid touching anonymous pages.
> 
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

Code looks nice, however earlier responses have raised good points. Esp.
the one pointing out you'd need to defeat swappiness too.

That said, I'm not much in favour of a limit pagecache knob.

Esp. the "my customers are scared of the 99.9% memory used scenario" is
a clear case of educate them. We don't go fix psychological problems
with code.

The only maybe valid point would be 2, and I'd like to see if we can't
solve that differently - a better use-once logic comes to mind.

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

[Andrew Morton]

On Tue, 23 Jan 2007 23:45:07 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:

> setup-bus.o is linked only on x86

oops, that's untrue.  But it will break ppc32, I think.

I suppose we can deprive the ppc32 guys of eight bytes of RAM.  But putting
cardbus things in pci.c seems wrong..


diff -puN 
drivers/pci/pci.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix 
drivers/pci/pci.c
--- 
a/drivers/pci/pci.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix
+++ a/drivers/pci/pci.c
@@ -21,6 +21,12 @@
 
 unsigned int pci_pm_d3_delay = 10;
 
+#define DEFAULT_CARDBUS_IO_SIZE(256)
+#define DEFAULT_CARDBUS_MEM_SIZE   (64*1024*1024)
+/* pci=cbmemsize=nnM,cbiosize=nn can override this */
+unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
+unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
+
 /**
  * pci_bus_max_busnr - returns maximum PCI bus number of given bus' children
  * @bus: pointer to PCI bus structure to search
@@ -1213,11 +1219,9 @@ static int __devinit pci_setup(char *str
if (!strcmp(str, "nomsi")) {
pci_no_msi();
} else if (!strncmp(str, "cbiosize=", 9)) {
-   pci_cardbus_io_size =
-   memparse(str + 9, );
+   pci_cardbus_io_size = memparse(str + 9, );
} else if (!strncmp(str, "cbmemsize=", 10)) {
-   pci_cardbus_mem_size =
-   memparse(str + 10, );
+   pci_cardbus_mem_size = memparse(str + 10, );
} else {
printk(KERN_ERR "PCI: Unknown option `%s'\n",
str);
diff -puN 
drivers/pci/setup-bus.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix
 drivers/pci/setup-bus.c
--- 
a/drivers/pci/setup-bus.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix
+++ a/drivers/pci/setup-bus.c
@@ -36,16 +36,6 @@
 
 #define ROUND_UP(x, a) (((x) + (a) - 1) & ~((a) - 1))
 
-/*
- * FIXME: IO should be max 256 bytes.  However, since we may
- * have a P2P bridge below a cardbus bridge, we need 4K.
- */
-#define DEFAULT_CARDBUS_IO_SIZE(256)
-#define DEFAULT_CARDBUS_MEM_SIZE   (64*1024*1024)
-/* pci=cbmemsize=nnM,cbiosize=nn can override this */
-unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
-unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;
-
 static void __devinit
 pbus_assign_resources_sorted(struct pci_bus *bus)
 {
_

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

[Andrew Morton]

On Tue, 23 Jan 2007 10:30:27 +0900 (JST)
Atsushi Nemoto <[EMAIL PROTECTED]> wrote:

> Subject: [PATCH] Make CARDBUS_MEM_SIZE and CARDBUS_IO_SIZE customizable
> 
> CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size
> might result in allocation failure for the reserving itself on some
> platforms (for example typical 32bit MIPS).  Make it (and
> CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms.
> 
> ...
>
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1168,6 +1168,12 @@ static int __devinit pci_setup(char *str
>   if (*str && (str = pcibios_setup(str)) && *str) {
>   if (!strcmp(str, "nomsi")) {
>   pci_no_msi();
> + } else if (!strncmp(str, "cbiosize=", 9)) {
> + pci_cardbus_io_size =
> + memparse(str + 9, );
> + } else if (!strncmp(str, "cbmemsize=", 10)) {
> + pci_cardbus_mem_size =
> + memparse(str + 10, );
>   } else {
>   printk(KERN_ERR "PCI: Unknown option `%s'\n",
>   str);
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 89f3036..1dfc288 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -40,8 +40,11 @@ #define ROUND_UP(x, a) (((x) + (a) - 1)
>   * FIXME: IO should be max 256 bytes.  However, since we may
>   * have a P2P bridge below a cardbus bridge, we need 4K.
>   */
> -#define CARDBUS_IO_SIZE  (256)
> -#define CARDBUS_MEM_SIZE (64*1024*1024)
> +#define DEFAULT_CARDBUS_IO_SIZE  (256)
> +#define DEFAULT_CARDBUS_MEM_SIZE (64*1024*1024)
> +/* pci=cbmemsize=nnM,cbiosize=nn can override this */
> +unsigned long pci_cardbus_io_size = DEFAULT_CARDBUS_IO_SIZE;
> +unsigned long pci_cardbus_mem_size = DEFAULT_CARDBUS_MEM_SIZE;

setup-bus.o is linked only on x86, so your patch will cause all other
pci-using architectures to not link.

An easy fix is to move the definitions of pci_cardbus_io_size and
pci_cardbus_mem_size into pci.c.  An ugly, fragile but more efficient fix
is, reluctantly:

diff -puN 
drivers/pci/pci.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix 
drivers/pci/pci.c
--- 
a/drivers/pci/pci.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix
+++ a/drivers/pci/pci.c
@@ -1212,13 +1212,15 @@ static int __devinit pci_setup(char *str
if (*str && (str = pcibios_setup(str)) && *str) {
if (!strcmp(str, "nomsi")) {
pci_no_msi();
-   } else if (!strncmp(str, "cbiosize=", 9)) {
-   pci_cardbus_io_size =
-   memparse(str + 9, );
+   }
+#ifdef CONFIG_X86
+   else if (!strncmp(str, "cbiosize=", 9)) {
+   pci_cardbus_io_size = memparse(str + 9, );
} else if (!strncmp(str, "cbmemsize=", 10)) {
-   pci_cardbus_mem_size =
-   memparse(str + 10, );
-   } else {
+   pci_cardbus_mem_size = memparse(str + 10, );
+   }
+#endif
+   else {
printk(KERN_ERR "PCI: Unknown option `%s'\n",
str);
}
diff -puN 
drivers/pci/setup-bus.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix
 drivers/pci/setup-bus.c
--- 
a/drivers/pci/setup-bus.c~make-cardbus_mem_size-and-cardbus_io_size-boot-options-fix
+++ a/drivers/pci/setup-bus.c
@@ -36,10 +36,6 @@
 
 #define ROUND_UP(x, a) (((x) + (a) - 1) & ~((a) - 1))
 
-/*
- * FIXME: IO should be max 256 bytes.  However, since we may
- * have a P2P bridge below a cardbus bridge, we need 4K.
- */
 #define DEFAULT_CARDBUS_IO_SIZE(256)
 #define DEFAULT_CARDBUS_MEM_SIZE   (64*1024*1024)
 /* pci=cbmemsize=nnM,cbiosize=nn can override this */
_


Perhaps we should move the cbiosize= and cbmemsize= handlers over into
setup-bus.c.  The implementation would be cleaner, but then we wouldn't be
able to use the pci= namespace.

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

Re: sigaction's ucontext_t with incorrect stack reference when SA_SIGINFO is being used ?

[Xavier Roche]

Nicholas Miell wrote:
> so if uc_stack doesn't point to the stack in use immediately prior to
> signal generation, this is a bug.

Looking at arch/i386/kernel/signal.c (and others) inside
setup_rt_frame(), the problem is pretty obvious:

err |= __put_user(current->sas_ss_sp, _user->uc.uc_stack.ss_sp);
err |= __put_user(sas_ss_flags(regs->esp),
>uc.uc_stack.ss_flags);
err |= __put_user(current->sas_ss_size, _user->uc.uc_stack.ss_size);

And of course, the ss_sp is NULL when no alternative stack is used.
Seems definitively a bug.

However, my reading of include/linux/sched.h and thread_info.h did not
enlighten me on the way to get the original thread's stack base and size.

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

[newbie] Re: Is it possible to directly call do_path_lookup() in kernel?

[Oleg Verych]

On 2007-01-24, Xin Zhao wrote:
> Archived-At: 

Hallo.

> I just successfully called do_path_lookup() in my kernel module. I
> just removed the "fastcall" from the declaration of do_path_lookup(),
> then the problem disappeared. I don't quite understand "fastcall"
> though.

In linkage.h header near you.

> Can someone explain it?

Please use appropriate mailing list:

Kernelnewbies: Help each other learn about the Linux kernel.
Archive:   http://mail.nl.linux.org/kernelnewbies/
FAQ:   http://kernelnewbies.org/faq/

> Thanks,
> -x
>


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

Re: XFS or Kernel Problem / Bug

[Stefan Priebe - FH]

Hi!

I do everything you like :-) if we can find the bug.

So here are the files (2.6.18.6):
http://server055.de-nserver.de/filemap.o
http://server055.de-nserver.de/filemap.s

Stefan


Chuck Ebbert schrieb:

Stefan Priebe - FH wrote:


I've 3 Servers which works wonderful with 2.6.16.X (also testet the
latest 2.6.16.37)

but with 2.6.18.6 i get these errors:

"general protection fault:  [#1]"
"Modules linked in:"
"CPU:0"
"EIP:0060:[]Not tainted VLI"
"EFLAGS: 00010246   (2.6.18.6 #1) "
"EIP is at xfs_bmap_add_extent_hole_delay+0x58d/0x59b"
"eax:    ebx: fffe0007   ecx: 0071a4cd   edx: "
"esi:    edi:    ebp: 0015   esp: ce35f8f0"
"ds:    es: 007b   ss: 0068"
"Process mysqld (pid: 1836, ti=ce35e000 task=ee618550 task.ti=ce35e000)"
"Stack: 0232  0233    000c
 "
"   0007  eca90250 eca90278 0001 eca90200 
03c3 "
"    010003c3 ffc0 ce35fa58 ce35fa58 0001 
 "
"Call Trace:"
" [] xfs_trans_dqresv+0x3f9/0x405"
" [] xfs_bmap_add_extent+0x163/0x377"
" [] xfs_bmapi+0xa4e/0x1109"
" [] xfs_iomap_write_delay+0x233/0x2fa"
" [] xfs_imap_to_bmap+0x29/0x1d6"
" [] xfs_iomap+0x23c/0x3e1"
" [] xfs_iomap+0x2e0/0x3e1"
" [] xfs_bmap+0x1a/0x1e"
" [] __xfs_get_blocks+0x5d/0x195"


Without the "Code:" line it's hard to tell what happened...



and sometimes this one:

"BUG: unable to handle kernel NULL pointer dereference at virtual
address 0288"
" printing eip:"
"c0142ff7"
"*pde = "
"Oops:  [#1]"
"SMP "
"Modules linked in: iptable_filter ip_tables x_tables"
"CPU:0"
"EIP:0060:[]Not tainted VLI"
"EFLAGS: 00010246   (2.6.18.6 #1) "
"EIP is at generic_file_buffered_write+0x390/0x6cf"
"eax:    ebx: 01ec   ecx: ea029a40   edx: 8002"
"esi:    edi: e3b28c9c   ebp: 01ec   esp: dd04bd18"
"ds: 007b   es: 007b   ss: 0068"
"Process proftpd (pid: 3615, ti=dd04a000 task=eba88a70 task.ti=dd04a000)"
"Stack: e3b28d44 0001 0010 01fc c036d793 01fc c14765c0
0010 "
"   080d404c 01ec e3b28c9c c03e78c0 e3b28d44 ea029a40 01fc
 "
"    01ec dd04beac 00d420b1   dd04bd80
45b1fa67 "
"Call Trace:"
" [] sock_def_readable+0x7f/0x81"
" [] file_update_time+0xad/0xcb"
" [] xfs_iunlock+0x55/0x9f"
" [] xfs_write+0xa74/0xc61"
" [] sock_aio_read+0x95/0x99"
" [] xfs_file_aio_write+0x8f/0xa0"
" [] do_sync_write+0xc9/0x10f"
" [] autoremove_wake_function+0x0/0x57"
" [] generic_file_llseek+0x95/0xbc"
" [] do_sync_write+0x0/0x10f"
" [] vfs_write+0xa6/0x179"
" [] sys_write+0x51/0x80"
" [] syscall_call+0x7/0xb"

"Code: 04 89 10 8b 44 24 40 85 c0 0f 85 db 00 00 00 8b 5c 24 24 85 db 0f
88 c3 00 00 00 8b 4c 24 34 8b 51 18 f6 c6 10 75 73 8b 7c 24 28 <8b> 85
9c 00 00 00 f6 40 30 10 75 63 f6 87 48 01 00 00 01 75 5a "

"EIP: [] generic_file_buffered_write+0x390/0x6cf SS:ESP
0068:dd04bd18"



Well that's strange. It's here in mm/filemap.c line 2201:

/*
 * For now, when the user asks for O_SYNC, we'll actually give
O_DSYNC
 */
if (likely(status >= 0)) {
if (unlikely((file->f_flags & O_SYNC) ||
IS_SYNC(inode))) { <===
if (!a_ops->writepage || !is_sync_kiocb(iocb))
status = generic_osync_inode(inode, mapping,
OSYNC_METADATA|OSYNC_DATA);
}
}

ebp holds the value of 'inode' and it's obviously wrong (it's also the same
as 'written', which is in ebx.) So when it tries to read inode->i_sb, it
dies.

If you can, post the file mm/filemap.o from your build directory to some
website.
And do 'make mm/filemap.s' and post that file too.



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

Re: Is it possible to directly call do_path_lookup() in kernel?

[Xin Zhao]

I just successfully called do_path_lookup() in my kernel module. I
just removed the "fastcall" from the declaration of do_path_lookup(),
then the problem disappeared. I don't quite understand "fastcall"
though.

Can someone explain it?

Thanks,
-x

On 1/23/07, Xin Zhao <[EMAIL PROTECTED]> wrote:

Hi,

I tried to call the following code in a kernel module:

error = do_path_lookup(AT_FDCWD, "/etc/profile.d/glib2.csh",
LOOKUP_PARENT, );

I exported the function do_path_lookup() using
"EXPORT_SYMBOL_GPL(do_path_lookup);"

But do_path_lookup() caused the "general protection fault:  [#1]"
kernel error.

I thought it could be the problem of protection error, so I used the
following codes to enclose the code that calls do_path_lookup(), but
still got the same error.

fs = get_fs ();   /* 
save previous value */
set_fs (KERNEL_DS);   /* 
use kernel limit */
..
set_fs(fs);

Any idea on this?

Thanks a lot!

-x


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

What's in netdev-2.6.git

[Jeff Garzik]

This is the stuff queued for 2.6.21 in netdev-2.6.git#upstream.

Nothing earthshakingly notable.  A couple new drivers, a couple removed
drivers, a bunch of driver updates.

Adrian Bunk (4):
  remove the broken SKMC driver
  make hdlc_setup() static again
  remove the broken OAKNET driver
  bonding.h: "extern inline" -> "static inline"

Akinobu Mita (1):
  net: use bitrev8

Arjan van de Ven (1):
  remove NETIF_F_TSO ifdefery

Auke Kok (3):
  e1000: clean up debug output defines
  e1000: display flow control of link status at link up
  e1000: update version to 7.3.20-k2

Ayaz Abdulla (12):
  forcedeth: dma access
  forcedeth: ring access
  forcedeth: tx locking
  forcedeth: rx skb recycle
  forcedeth: optimized routines
  forcedeth: tx limiting
  forcedeth: tx data path optimization
  forcedeth: rx data path optimization
  forcedeth: irq data path optimization
  forcedeth: tx max work
  forcedeth: statistics supported
  forcedeth: statistics optimization

Bruce Allan (1):
  e1000: clear ip csum info from context descriptor

Cesar Eduardo Barros (1):
  driver for Silan SC92031 netdev

Daniel Drake (6):
  zd1211rw: Generic HMAC initialization
  zd1211rw: 2 new ZD1211B device ID's
  zd1211rw: Consistency for address space constants
  zd1211rw: Remove addressing abstraction
  zd1211rw: Add ID for Linksys WUSBF54G
  zd1211rw: Add ID for ZyXEL ZyAIR G-220 v2

Divy Le Ray (1):
  Add support for the latest 1G/10G Chelsio adapter, T3.

Francois Romieu (7):
  chelsio: move return, break and continue statements on their own line
  chelsio: the return statement is not a function
  chelsio: spaces, tabs and friends
  chelsio: useless curly braces
  chelsio: useless test in cxgb2::remove_one
  chelsio: misc cleanups in sge
  chelsio: tabulate the update of the statistic counters

Jay Vosburgh (4):
  bonding: fix device name allocation error
  bonding: fix error check in sysfs creation
  bonding: modify sysfs support to permit multiple loads
  bonding: update version

Jeff Garzik (3):
  Merge branch 'upstream-fixes' into upstream
  Merge branch 'master-e1000' of 
git://lost.foo-projects.org/~ahkok/git/netdev-2.6 into upstream
  Merge branch 'upstream-fixes' into upstream

Jesse Brandeburg (4):
  e1000: simplify case handling gigabit at half duplex
  e1000: Fix MSI only interrupt handler routine
  e1000: fix NAPI performance on 4-port adapters
  e1000: tune our dynamic itr transmit packet accounting

John W. Linville (1):
  softmac: avoid assert in ieee80211softmac_wx_get_rate

Kai Engert (1):
  prism54: add ethtool -i interface

Larry Finger (1):
  bcm43xx: Interrogate hardware-enable switch and update LEDs

Linas Vepstas (13):
  Spidernet DMA coalescing
  Spidernet add net_ratelimit to suppress long output
  Spidernet remove rxramfull tasklet
  Spidernet cleanup un-needed API
  Spidernet RX skb mem leak
  Spidernet another skb mem leak
  Spidernet Cleanup return codes
  Spidernet RX Refill
  Spidernet Remove unused variable
  Spidernet RX Chain tail
  Spidernet Memory barrier
  Spidernet Avoid possible RX chain corruption
  Spidernet RX Debugging printout

Michael Buesch (1):
  Update Prism54 MAINTAINERS entry

Ron Mercer (1):
  qla3xxx: Add support for Qlogic 4032 chip.

Stephen Hemminger (3):
  sky2: better power state management
  chelsio: NAPI speed improvement
  chelsio: more rx speedup

Zhu Yi (1):
  ipw2200: add iwconfig rts/frag auto support

 MAINTAINERS   |2 
 drivers/net/Kconfig   |   56 
 drivers/net/Makefile  |5 
 drivers/net/Space.c   |4 
 drivers/net/bmac.c|   20 
 drivers/net/bnx2.c|   12 
 drivers/net/bonding/bond_main.c   |   23 
 drivers/net/bonding/bond_sysfs.c  |   15 
 drivers/net/bonding/bonding.h |9 
 drivers/net/chelsio/common.h  |2 
 drivers/net/chelsio/cpl5_cmd.h|   18 
 drivers/net/chelsio/cxgb2.c   |  149 -
 drivers/net/chelsio/elmer0.h  |   40 
 drivers/net/chelsio/espi.c|   44 
 drivers/net/chelsio/fpga_defs.h   |6 
 drivers/net/chelsio/gmac.h|   11 
 drivers/net/chelsio/ixf1010.c |  100 
 drivers/net/chelsio/mv88e1xxx.c   |   27 
 drivers/net/chelsio/my3126.c  |   16 
 drivers/net/chelsio/pm3393.c  |   91 
 drivers/net/chelsio/sge.c |  328 +-
 drivers/net/chelsio/subr.c|   89 
 drivers/net/chelsio/tp.c  |   62 
 drivers/net/chelsio/vsc7326.c |  

Re: [PATCH 002 of 4] md: Make 'repair' actually work for raid1.

[Neil Brown]

On Tuesday January 23, [EMAIL PROTECTED] wrote:
> On Tue, 23 Jan 2007 11:26:52 +1100
> NeilBrown <[EMAIL PROTECTED]> wrote:
> 
> > +   for (j = 0; j < vcnt ; j++)
> > +   
> > memcpy(page_address(sbio->bi_io_vec[j].bv_page),
> > +  
> > page_address(pbio->bi_io_vec[j].bv_page),
> > +  PAGE_SIZE);
> 
> I trust these BIOs are known to only contain suitably-allocated, MD-private
> pages?  Because if these pages can be user pages then this change is
> spectacularly buggy ;)

Your trust is well placed.
This is in the 'resync' path, were all buffers are allocated in lowmem
and are full pages and so-forth, so this is perfectly safe.

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/

What's in libata-dev.git

[Jeff Garzik]

This is a summary and diffstat of all the changes pending in branch
libata-dev.git#upstream for kernel 2.6.21.  Items of note:

* major sata_promise improvements, including PATA and ATAPI support
* new drivers sata_inic162x, pata_it8213, MPC52xx
* sata_via PATA port support
* other minor improvements

Patchsets ACK'd and about to be merged:

* Tejun's devres stuff
* Cell ATA driver
* sata_sis PATA port support


Adrian Bunk (1):
  drivers/ata/: make 4 functions static

Alan (5):
  pata_it8213: Add new driver for the IT8213 card
  sata_via: PATA support
  libata-sff: Don't try and activate channels which are not in use
  ahci: Remove jmicron fixup
  libata: PIIX3 support

Alan Cox (1):
  pci: Move PCI_VDEVICE from libata to core

Andrew Morton (1):
  libata piix3 support warning fix

Arjan van de Ven (1):
  user of the jiffies rounding patch: ATA subsystem

Conke Hu (1):
  Add pci class code for SATA & AHCI, and replace some magic numbers.

Dan Wolstenholme (1):
  [libata] sata_vsc: support PCI MSI

J J (1):
  ata_piix: add ICH7 on Acer 3682WLMi to laptop list

Jakub W. Jozwicki J (1):
  pata_sis: implement laptop list and add ASUS A6K/A6U

Jeff Garzik (2):
  [libata] trim trailing whitespace
  [libata] sata_vsc: build fix after PCI MSI feature addition

Mikael Pettersson (5):
  sata_promise: TX2plus PATA support
  sata_promise: ATAPI support
  sata_promise: ATAPI cleanup
  sata_promise: issue ATAPI commands as normal packets
  sata_promise: handle ATAPI_NODATA ourselves

Robert Hancock (1):
  sata_nv: add suspend/resume support v3 (Resubmit)

Sylvain Munaut (1):
  libata: Add support for the MPC52xx ATA controller

Tejun Heo (6):
  libata: straighten out ATA_ID_* constants
  libata: use ata_id_c_string()
  libata: handle pci_enable_device() failure while resuming
  libata: kill qc->nsect and cursect
  sata_inic162x: finally, driver for initio 162x SATA controllers, take #2
  sata_promise: kill qc->nsect

Uwe Koziolek (1):
  sata_sis: support SiS966/966L

 drivers/ata/Kconfig |   26 +
 drivers/ata/Makefile|3 
 drivers/ata/ahci.c  |   20 
 drivers/ata/ata_piix.c  |   23 -
 drivers/ata/libata-core.c   |   81 +---
 drivers/ata/libata-eh.c |7 
 drivers/ata/libata-scsi.c   |   52 +-
 drivers/ata/libata-sff.c|   22 +
 drivers/ata/pata_ali.c  |8 
 drivers/ata/pata_cs5520.c   |2 
 drivers/ata/pata_cs5530.c   |8 
 drivers/ata/pata_hpt366.c   |   20 
 drivers/ata/pata_hpt37x.c   |   23 -
 drivers/ata/pata_hpt3x3.c   |2 
 drivers/ata/pata_it8213.c   |  354 +
 drivers/ata/pata_it821x.c   |   20 
 drivers/ata/pata_jmicron.c  |2 
 drivers/ata/pata_marvell.c  |4 
 drivers/ata/pata_mpc52xx.c  |  563 +++
 drivers/ata/pata_pdc202xx_old.c |5 
 drivers/ata/pata_serverworks.c  |   19 
 drivers/ata/pata_sil680.c   |2 
 drivers/ata/pata_sis.c  |   34 +
 drivers/ata/pata_via.c  |   10 
 drivers/ata/pata_winbond.c  |   16 
 drivers/ata/sata_inic162x.c |  809 
 drivers/ata/sata_nv.c   |  239 ---
 drivers/ata/sata_promise.c  |  226 ++-
 drivers/ata/sata_qstor.c|2 
 drivers/ata/sata_sil.c  |   10 
 drivers/ata/sata_sil24.c|5 
 drivers/ata/sata_sis.c  |   79 ++-
 drivers/ata/sata_via.c  |  110 +
 drivers/ata/sata_vsc.c  |   44 ++
 drivers/pci/quirks.c|2 
 include/linux/ata.h |   11 
 include/linux/libata.h  |   14 
 include/linux/pci_ids.h |3 
 38 files changed, 2554 insertions(+), 326 deletions(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git patch] net driver fix

[Jeff Garzik]

As the patch indicates, the Al Viro patch had already been merged into
my history (and another branch depending on it, making rebasing
difficult if not impossible), but since it was merged by Linus, the
actual patch isn't shown here by 'git diff'.

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
upstream-linus

to receive the following updates:

 drivers/net/mv643xx_eth.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

Al Viro (1):
  s2io bogus memset

Dale Farnsworth (1):
  mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs

diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index c41ae42..b3bf864 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -314,6 +314,13 @@ int mv643xx_eth_free_tx_descs(struct net_device *dev, int 
force)
 
while (mp->tx_desc_count > 0) {
spin_lock_irqsave(>lock, flags);
+
+   /* tx_desc_count might have changed before acquiring the lock */
+   if (mp->tx_desc_count <= 0) {
+   spin_unlock_irqrestore(>lock, flags);
+   return released;
+   }
+
tx_index = mp->tx_used_desc_q;
desc = >p_tx_desc_area[tx_index];
cmd_sts = desc->cmd_sts;
@@ -332,13 +339,13 @@ int mv643xx_eth_free_tx_descs(struct net_device *dev, int 
force)
if (skb)
mp->tx_skb[tx_index] = NULL;
 
-   spin_unlock_irqrestore(>lock, flags);
-
if (cmd_sts & ETH_ERROR_SUMMARY) {
printk("%s: Error in TX\n", dev->name);
mp->stats.tx_errors++;
}
 
+   spin_unlock_irqrestore(>lock, flags);
+
if (cmd_sts & ETH_TX_FIRST_DESC)
dma_unmap_single(NULL, addr, count, DMA_TO_DEVICE);
else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git patches] libata fixes

[Jeff Garzik]

All fixes for ugly bugs and/or regressions.

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git 
upstream-linus

to receive the following updates:

 drivers/ata/ahci.c|   39 +++
 drivers/ata/libata-scsi.c |2 +-
 drivers/ata/sata_nv.c |   14 ++
 include/linux/libata.h|2 ++
 4 files changed, 20 insertions(+), 37 deletions(-)

Brian King (2):
  libata: Fixup n_elem initialization
  libata: Initialize qc->pad_len

Robert Hancock (1):
  sata_nv: don't rely on NV_INT_DEV indication with ADMA

Tejun Heo (2):
  ahci: make ULi M5288 ignore interface fatal error bit
  ahci: don't enter slumber on power down

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index b517d24..e3c7b31 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -361,7 +361,7 @@ static const struct pci_device_id ahci_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, 0x27c1), board_ahci }, /* ICH7 */
{ PCI_VDEVICE(INTEL, 0x27c5), board_ahci }, /* ICH7M */
{ PCI_VDEVICE(INTEL, 0x27c3), board_ahci }, /* ICH7R */
-   { PCI_VDEVICE(AL, 0x5288), board_ahci }, /* ULi M5288 */
+   { PCI_VDEVICE(AL, 0x5288), board_ahci_ign_iferr }, /* ULi M5288 */
{ PCI_VDEVICE(INTEL, 0x2681), board_ahci }, /* ESB2 */
{ PCI_VDEVICE(INTEL, 0x2682), board_ahci }, /* ESB2 */
{ PCI_VDEVICE(INTEL, 0x2683), board_ahci }, /* ESB2 */
@@ -586,35 +586,18 @@ static void ahci_power_down(void __iomem *port_mmio, u32 
cap)
 {
u32 cmd, scontrol;
 
-   cmd = readl(port_mmio + PORT_CMD) & ~PORT_CMD_ICC_MASK;
-
-   if (cap & HOST_CAP_SSC) {
-   /* enable transitions to slumber mode */
-   scontrol = readl(port_mmio + PORT_SCR_CTL);
-   if ((scontrol & 0x0f00) > 0x100) {
-   scontrol &= ~0xf00;
-   writel(scontrol, port_mmio + PORT_SCR_CTL);
-   }
-
-   /* put device into slumber mode */
-   writel(cmd | PORT_CMD_ICC_SLUMBER, port_mmio + PORT_CMD);
-
-   /* wait for the transition to complete */
-   ata_wait_register(port_mmio + PORT_CMD, PORT_CMD_ICC_SLUMBER,
- PORT_CMD_ICC_SLUMBER, 1, 50);
-   }
+   if (!(cap & HOST_CAP_SSS))
+   return;
 
-   /* put device into listen mode */
-   if (cap & HOST_CAP_SSS) {
-   /* first set PxSCTL.DET to 0 */
-   scontrol = readl(port_mmio + PORT_SCR_CTL);
-   scontrol &= ~0xf;
-   writel(scontrol, port_mmio + PORT_SCR_CTL);
+   /* put device into listen mode, first set PxSCTL.DET to 0 */
+   scontrol = readl(port_mmio + PORT_SCR_CTL);
+   scontrol &= ~0xf;
+   writel(scontrol, port_mmio + PORT_SCR_CTL);
 
-   /* then set PxCMD.SUD to 0 */
-   cmd &= ~PORT_CMD_SPIN_UP;
-   writel(cmd, port_mmio + PORT_CMD);
-   }
+   /* then set PxCMD.SUD to 0 */
+   cmd = readl(port_mmio + PORT_CMD) & ~PORT_CMD_ICC_MASK;
+   cmd &= ~PORT_CMD_SPIN_UP;
+   writel(cmd, port_mmio + PORT_CMD);
 }
 
 static void ahci_init_port(void __iomem *port_mmio, u32 cap,
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 836947d..7cc5a4a 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -372,7 +372,7 @@ struct ata_queued_cmd *ata_scsi_qc_new(struct ata_device 
*dev,
if (cmd->use_sg) {
qc->__sg = (struct scatterlist *) cmd->request_buffer;
qc->n_elem = cmd->use_sg;
-   } else {
+   } else if (cmd->request_bufflen) {
qc->__sg = >sgent;
qc->n_elem = 1;
}
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index f6d498e..f7a963e 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -700,7 +700,6 @@ static void nv_adma_check_cpb(struct ata_port *ap, int 
cpb_num, int force_err)
 static int nv_host_intr(struct ata_port *ap, u8 irq_stat)
 {
struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
-   int handled;
 
/* freeze if hotplugged */
if (unlikely(irq_stat & (NV_INT_ADDED | NV_INT_REMOVED))) {
@@ -719,13 +718,7 @@ static int nv_host_intr(struct ata_port *ap, u8 irq_stat)
}
 
/* handle interrupt */
-   handled = ata_host_intr(ap, qc);
-   if (unlikely(!handled)) {
-   /* spurious, clear it */
-   ata_check_status(ap);
-   }
-
-   return 1;
+   return ata_host_intr(ap, qc);
 }
 
 static irqreturn_t nv_adma_interrupt(int irq, void *dev_instance)
@@ -752,6 +745,11 @@ static irqreturn_t nv_adma_interrupt(int irq, void 
*dev_instance)
if (pp->flags & NV_ADMA_PORT_REGISTER_MODE) {
u8 irq_stat = 

Re: [PATCH] seq_file conversion: APM on arm

[Paul Mundt]

On Tue, Jan 23, 2007 at 04:45:41PM -0800, Andrew Morton wrote:
> There is an ongoing desultory effort from Ralf to unify the ARM and MIPS
> APM implementations.  Independently converting them both to use seqfile
> at this stage might muck that up.   Ralf, talk to me?

What happened with this anyways? As soon as I got the conversion for SH
ready it was silently dropped from -mm. Is there anything that this is
still waiting on?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/46] High resolution timer / dynamic tick update

[Ingo Molnar]

* Daniel Walker <[EMAIL PROTECTED]> wrote:

> To lessen Andrews burden it would be wise to integrate the two trees 
> prior to anything going into -mm .. [...]

i disagree. Thomas' tree has been tested in -rt for some time already, 
and he's the author of this code so as far as i'm concerned he calls the 
shots of what to do and in what order to do. He did the overwhelming 
majority of regression fixes of dynticks/hrt stuff both in -mm and in 
-rt. So why should i not take his queue over yours? Last i checked your 
queue didnt really do anything substantial to the code - other than 
shuffling around wast amounts of code around. Even this latest iteration 
from Thomas that is now in -rt is working well on the target platform we 
are aiming for currently (i686). (and it's working on x86_64 as well in 
-rt)

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

Re: [RFC] Limit the size of the pagecache

[Vaidyanathan Srinivasan]

Christoph Lameter wrote:
> This is a patch using some of Aubrey's work plugging it in what is IMHO
> the right way. Feel free to improve on it. I have gotten repeatedly
> requests to be able to limit the pagecache. With the revised VM statistics
> this is now actually possile. I'd like to know more about possible uses of
> such a feature.
> 
> 
> 
> 
> It may be useful to limit the size of the page cache for various reasons
> such as
> 
> 1. Insure that anonymous pages that may contain performance
>critical data is never subject to swap.
> 
> 2. Insure rapid turnaround of pages in the cache.
> 
> 3. Reserve memory for other uses? (Aubrey?)
> 
> We add a new variable "pagecache_ratio" to /proc/sys/vm/ that
> defaults to 100 (all memory usable for the pagecache).
> 
> The size of the pagecache is the number of file backed
> pages in a zone which is available through NR_FILE_PAGES.
> 
> We skip zones that contain too many page cache pages in
> the page allocator which may cause us to enter reclaim.

Skipping the zone may not be a good idea.  We can have a threshold
for reclaim to avoid running the reclaim code too often

> If we enter reclaim and the number of page cache pages
> is too high then we switch off swapping during reclaim
> to avoid touching anonymous pages.

This is a good idea, however there could be the following problems:

1. We may not find much of unmapped pages in the given number of
pages to scan.  We will have to iterate too much in shrink_zone and
artificially increase memory pressure in order to scan more pages
and find sufficient pagecache pages to free and bring it under limit

2. NR_FILE_PAGES include mapped pagecache pages count, if we turn
off may_swap, then reclaim_mapped will also be off and we will not
remove mapped pagecache.  This is correct because these pages are
'in use' relative to unmapped pagecache pages.

But the problem is in the limit comparison, we need to subtract
mapped pages before checking for overlimit

3. We may want to write out dirty and referenced pagecache pages and
free them.  Current shrink_zone looks for easily freeable pagecache
pages only, but if we set a 200MB limit and write out a 1GB file,
then all of the pages will be dirty, active and referenced and still
we will have to force the reclaimer to remove those pages.

Adding more scan control flags in reclaim can give us better
control.  Please review http://lkml.org/lkml/2007/01/17/96 which
used new scan control flags.


> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> 
> Index: linux-2.6.20-rc5/include/linux/gfp.h
> ===
> --- linux-2.6.20-rc5.orig/include/linux/gfp.h 2007-01-12 12:54:26.0 
> -0600
> +++ linux-2.6.20-rc5/include/linux/gfp.h  2007-01-23 17:54:51.750696888 
> -0600
> @@ -46,6 +46,7 @@ struct vm_area_struct;
>  #define __GFP_NOMEMALLOC ((__force gfp_t)0x1u) /* Don't use emergency 
> reserves */
>  #define __GFP_HARDWALL   ((__force gfp_t)0x2u) /* Enforce hardwall 
> cpuset memory allocs */
>  #define __GFP_THISNODE   ((__force gfp_t)0x4u)/* No fallback, no 
> policies */
> +#define __GFP_PAGECACHE  ((__force gfp_t)0x8u) /* Page cache 
> allocation */
> 
>  #define __GFP_BITS_SHIFT 20  /* Room for 20 __GFP_FOO bits */
>  #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
> Index: linux-2.6.20-rc5/include/linux/pagemap.h
> ===
> --- linux-2.6.20-rc5.orig/include/linux/pagemap.h 2007-01-12 
> 12:54:26.0 -0600
> +++ linux-2.6.20-rc5/include/linux/pagemap.h  2007-01-23 18:13:14.310062155 
> -0600
> @@ -62,12 +62,13 @@ static inline struct page *__page_cache_
> 
>  static inline struct page *page_cache_alloc(struct address_space *x)
>  {
> - return __page_cache_alloc(mapping_gfp_mask(x));
> + return __page_cache_alloc(mapping_gfp_mask(x)| __GFP_PAGECACHE);
>  }
> 
>  static inline struct page *page_cache_alloc_cold(struct address_space *x)
>  {
> - return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD);
> + return __page_cache_alloc(mapping_gfp_mask(x) |
> +  __GFP_COLD | __GFP_PAGECACHE);
>  }
> 
>  typedef int filler_t(void *, struct page *);
> Index: linux-2.6.20-rc5/include/linux/sysctl.h
> ===
> --- linux-2.6.20-rc5.orig/include/linux/sysctl.h  2007-01-12 
> 12:54:26.0 -0600
> +++ linux-2.6.20-rc5/include/linux/sysctl.h   2007-01-23 18:17:09.285324555 
> -0600
> @@ -202,6 +202,7 @@ enum
>   VM_PANIC_ON_OOM=33, /* panic at out-of-memory */
>   VM_VDSO_ENABLED=34, /* map VDSO into new processes? */
>   VM_MIN_SLAB=35,  /* Percent pages ignored by zone reclaim */
> + VM_PAGECACHE_RATIO=36,  /* percent of RAM to use as page cache */
>  };
> 
> 
> @@ -956,7 +957,6 @@ extern ctl_handler sysctl_intvec;
>  extern ctl_handler sysctl_jiffies;
>  

Re: [PATCH 002 of 4] md: Make 'repair' actually work for raid1.

[Andrew Morton]

On Tue, 23 Jan 2007 11:26:52 +1100
NeilBrown <[EMAIL PROTECTED]> wrote:

> + for (j = 0; j < vcnt ; j++)
> + 
> memcpy(page_address(sbio->bi_io_vec[j].bv_page),
> +
> page_address(pbio->bi_io_vec[j].bv_page),
> +PAGE_SIZE);

I trust these BIOs are known to only contain suitably-allocated, MD-private
pages?  Because if these pages can be user pages then this change is
spectacularly buggy ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc5] Gigaset ISDN driver error handling fixes

[Andrew Morton]

On Wed, 17 Jan 2007 18:42:13 +0100 (CET)
Tilman Schmidt <[EMAIL PROTECTED]> wrote:

> + mutex_init(>mutex);
> + mutex_lock(>mutex);

I have vague memories of making rude comments about this a few months ago.

It is very weird to lock a mutex just after intialising it.  I mean, if any 
other
thread can lock this mutex then there's a race.  If no other thread can
lock it, then this thread doesn't need to either.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MMC: au1xmmc R6 response support

[Manuel Lauss]

On Wed, Jan 24, 2007 at 06:52:02AM +0100, Manuel Lauss wrote:
> On Tue, Jan 23, 2007 at 07:56:51PM +0100, Pierre Ossman wrote:
> > > here's a trivial patch which adds R6 reponse support to the au1xmmc
> > > driver. Fixes SD card detection / operation.
> > > 
> > NAK. MMC_RSP_R1 and MMC_RSP_R6 have the same value so this will break
> > the switch.
> 
> not in my version of 2.6.20-rc5 (and 2.6.19):
> 
> #define MMC_RSP_R1(MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
> #define MMC_RSP_R6(MMC_RSP_PRESENT|MMC_RSP_CRC)
> 
> Without the patch, SD card detection stops with CMD7 returning error.

Correction: it fails at SD_SEND_RELATIVE_ADDR (it's the only command
which request R6 response)

-- 
 ml.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -mm 5/5][AIO] - Add listio syscall support

[Andrew Morton]

On Wed, 17 Jan 2007 10:55:54 +0100
Sébastien Dugué <[EMAIL PROTECTED]> wrote:

> +void lio_check(struct lio_event *lio)
> +{
> + int ret;
> +
> + ret = atomic_dec_and_test(>lio_users);
> +
> + if (unlikely(ret) && lio->lio_notify.notify != SIGEV_NONE) {
> + /* last one -> notify process */
> + if (aio_send_signal(>lio_notify))
> + sigqueue_free(lio->lio_notify.sigq);
> + kfree(lio);
> + }
> +}

That's a scary function.  It may (or may not) free the memory at lio,
returning no indication to the caller whether or not that memory is still
allocated.  This is most peculiar - are you really sure there's no
potential for a use-after-free here?

The function is poorly named: I'd expect something called "foo_check" to
not have any side-effects.  This one has gross side-effects.  Want to think
up a better name, please?

And given that this function has global scope, perhaps a little explanatory
comment is in order?

> +struct lio_event *lio_create(struct sigevent __user *user_event,
> + int mode)

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

Re: [2.6 patch] process include/linux/if_{addr,link}.h with unifdef

[David Miller]

From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 21 Jan 2007 20:13:19 +0100

> After commit d3dcc077bf88806201093f86325ec656e4dbfbce, 
> include/linux/if_{addr,link}.h should be processed with unifdef.
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Applied, thanks Adrian.

I believe at least the 2.6.19 -stable branch will need
this too, right?  Please submit to -stable as needed,
and feel free to add my sign-off:

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

Re: [PATCH] select: fix sys_select to not leak ERESTARTNOHAND to userspace

[David Miller]

From: Neil Horman <[EMAIL PROTECTED]>
Date: Tue, 16 Jan 2007 15:13:32 -0500

> As it is currently written, sys_select checks its return code to convert
> ERESTARTNOHAND to EINTR.  However, the check is within an if (tvp) clause, and
> so if select is called from userspace with a NULL timeval, then it is possible
> for the ERESTARTNOHAND errno to leak into userspace, which is incorrect.  This
> patch moves that check outside of the conditional, and prevents the errno 
> leak.
> 
> Signed-Off-By: Neil Horman <[EMAIL PROTECTED]>

As has been probably mentioned, this change is bogus.

core_sys_select() returns -ERESTARTNOHAND in exactly the
case where that return value is legal, when a signal is
pending, so that the signal dispatch code (on return from
the system call) will "fixup" the -ERESTARTNOHAND return
value so that userspace does not see it.

What could be happening is that, somehow, we see the signal
pending in core_sys_select(), but for some reason by the time
the signal dispatch code would run, the signal is cleared.

I always found this scheme a little fishy, relying on signal
pending state to guarentee the fixup of the syscall restart
error return values.

For example, I see nothing that prevents another thread sharing
this signal state from clearing the signal between the syscall
checking in the other thread and the signal dispatch check running
in that other thread.

cpu 1   cpu 2
check sigpending
clear signal
syscall return
no signal panding
get -ERESTARTNOHAND

Perhaps something makes this no happen, but I don't see 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 -mm 4/5][AIO] - AIO completion signal notification

[Andrew Morton]

On Wed, 17 Jan 2007 10:50:18 +0100
Sébastien Dugué <[EMAIL PROTECTED]> wrote:

> +static long aio_setup_sigevent(struct aio_notify *notify,
> +struct sigevent __user *user_event)
> +{
> + sigevent_t event;
> + struct task_struct *target;
> +
> + if (copy_from_user(, user_event, sizeof (event)))
> + return -EFAULT;
> +
> + if (event.sigev_notify == SIGEV_NONE)
> + return 0;
> +
> + notify->notify = event.sigev_notify;
> + notify->signo = event.sigev_signo;
> + notify->value = event.sigev_value;
> +
> + read_lock(_lock);
> + target = good_sigevent();
> +
> + if (unlikely(!target || (target->flags & PF_EXITING)))
> + goto out_unlock;
> +
> + /*
> +  * At this point, we know that notify is either SIGEV_SIGNAL or
> +  * SIGEV_THREAD_ID and the target task is valid. So get a reference
> +  * on the task, it will be dropped in really_put_req() when
> +  * we're done with the request.
> +  */
> + get_task_struct(target);
> + notify->target = target;
> + read_unlock(_lock);
> +
> + /*
> +  * NOTE: we cannot free the sigqueue in the completion path as
> +  * the signal may not have been delivered to the target task.
> +  * Therefore it has to be freed in __sigqueue_free() when the
> +  * signal is collected if si_code is SI_ASYNCIO.
> +  */
> + notify->sigq = sigqueue_alloc();
> +
> + if (unlikely(!notify->sigq))
> + return -EAGAIN;

Did this just leak a ref on the task_struct?

> +
> + return 0;
> +
> +out_unlock:
> + read_unlock(_lock);
> + return -EINVAL;
> +}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache

[Aubrey Li]

On 1/24/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:



Aubrey Li wrote:
> On 1/19/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
>> Hi Aubrey,
>>
>> I used your patch on my PPC64 box and I do not get expected
>> behavior.  As you had requested, I am attaching zoneinfo and meminfo
>> dumps:
>>
>> Please let me know if you need any further data to help me out with
>> the test/experiment.
>>
>
> Although I have no PPC64 box in hand, I think the logic should be the same.
> get_page_from_freelist() is called 5 times in __alloc_pages().
>
> 1) alloc_flags = ALLOC_WMARK_LOW | ALLOC_PAGECACHE;
> 2) alloc_flags = ALLOC_WMARK_MIN | ALLOC_PAGECACHE;
> We should have the same result on the first two times 
get_page_from_freelist().
>
> 3) if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
>   && !in_interrupt())
>alloc_flags = ALLOC_NO_WATERMARKS
> The case on my platform will never enter this branch. If the branch
> occurs on your side,
> The limit will be omitted. Because NO watermark, zone_watermark_ok()
> will not be checked. memory will be allocated directly.
>
> 4)if (likely(did_some_progress)) {
>alloc_flags should include ALLOC_PAGECACHE.
> So we should have the same result on this call.
>
> 5)} else if ((gfp_mask & __GFP_FS) && !(gfp_mask & __GFP_NORETRY)) {
>alloc_flags = ALLOC_WMARK_HIGH, without ALLOC_PAGECACHE
>
> This branch will not hit on my case. You may need to check it.
>
> If 3) or 5) occurs on your platform, I think you can easily fix it.
> Please confirm it and let me know the result.


None of the above condition was the problem in my PPC64 box.  I
added __GFP_PAGECACHE flag in pagecache_alloc_cold() and
grab_cache_page_nowait() routines and the reclaim seemed to work.

--- linux-2.6.20-rc5.orig/include/linux/pagemap.h
+++ linux-2.6.20-rc5/include/linux/pagemap.h
@@ -62,12 +62,12 @@ static inline struct page *__page_cache_

 static inline struct page *page_cache_alloc(struct address_space *x)
 {
-   return __page_cache_alloc(mapping_gfp_mask(x));
+   return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_PAGECACHE);
 }

 static inline struct page *page_cache_alloc_cold(struct
address_space *x)
 {
-   return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD);
+   return
__page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD|__GFP_PAGECACHE);
 }

 typedef int filler_t(void *, struct page *);

[snip]

--- linux-2.6.20-rc5.orig/mm/filemap.c
+++ linux-2.6.20-rc5/mm/filemap.c
@@ -823,7 +823,7 @@ grab_cache_page_nowait(struct address_sp
page_cache_release(page);
return NULL;
}
-   page = __page_cache_alloc(mapping_gfp_mask(mapping) & ~__GFP_FS);
+   page = __page_cache_alloc(mapping_gfp_mask(mapping) & ~__GFP_FS |
__GFP_PAGECACHE);
if (page && add_to_page_cache_lru(page, mapping, index, GFP_KERNEL)) {
page_cache_release(page);
page = NULL;


pagecache_alloc_cold() is used in the read-ahead path which was
being called in my case of large file operations.

--Vaidy


Thanks to point it out. There is another patch on the LKML which I
think is better.
Checking the zone->max_pagecache  in the get_page_from_freelist() is
better than checking the watermark in zone_watermark_ok(). Let me know
if it works for you.

Thanks,
-Aubrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -mm 5/5][AIO] - Add listio syscall support

[Andrew Morton]

On Wed, 17 Jan 2007 10:55:54 +0100
Sébastien Dugué <[EMAIL PROTECTED]> wrote:

> +struct lio_event *lio_create(struct sigevent __user *user_event,
> + int mode)
> +{
> + int ret = 0;
> + struct lio_event *lio = NULL;
> +
> + if (unlikely((mode == LIO_NOWAIT) && !user_event))
> + return lio;
> +
> + lio = kzalloc(sizeof(*lio), GFP_KERNEL);
> +
> + if (!lio)
> + return ERR_PTR(-EAGAIN);
> +

Why EAGAIN and not ENOMEM?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -mm 5/5][AIO] - Add listio syscall support

[Andrew Morton]

On Wed, 17 Jan 2007 10:55:54 +0100
Sébastien Dugué <[EMAIL PROTECTED]> wrote:

> +asmlinkage long
> +compat_sys_lio_submit(aio_context_t ctx_id, int mode, int nr, u32 __user 
> *iocb,
> + struct compat_sigevent __user *sig_user)
> +{
> + struct kioctx *ctx;
> + struct lio_event *lio = NULL;
> + struct sigevent __user *event = NULL;
> + long ret = 0;
> +
> + if (unlikely(nr < 0))
> + return -EINVAL;
> +
> + if (unlikely(!access_ok(VERIFY_READ, iocb, (nr * sizeof(u32)
> + return -EFAULT;
> +
> + ctx = lookup_ioctx(ctx_id);
> + if (unlikely(!ctx))
> + return -EINVAL;
> +
> + if (sig_user) {
> + struct sigevent kevent;
> + event = compat_alloc_user_space(sizeof(struct sigevent));
> + if (get_compat_sigevent(, sig_user) ||
> + copy_to_user(event, , sizeof(struct sigevent)))
> + return -EFAULT;

I think we just leaked a ref against the ioctx.

That's two.  Please re-review the whole patchset for leaks like this.

Please also do not do returns from the middle of functions like this.  It's just
asking for resource leaks, either now or in the future.


> + }
> +
> + lio = lio_create(event, mode);
> +
> + ret = PTR_ERR(lio);
> + if (IS_ERR(lio))
> + goto out_put_ctx;
> +
> + ret = compat_io_submit_group(ctx, nr, iocb, lio);
> +
> + /* If we failed to submit even one request just return */
> + if (ret < 0) {
> + if (lio)
> + kfree(lio);
> + goto out_put_ctx;
> + }
> +
> + /*
> +  * Drop extra ref on the lio now that we're done submitting requests.
> +  */
> + if (lio)
> + lio_check(lio);
> +
> +
> + if (mode == LIO_WAIT) {
> + wait_event(ctx->wait, atomic_read(>lio_users) == 0);
> + kfree(lio);
> + }
> +out_put_ctx:
>   put_ioctx(ctx);
> - return i ? i: ret;
> + return ret;
>  }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MMC: au1xmmc R6 response support

[Manuel Lauss]

On Tue, Jan 23, 2007 at 07:56:51PM +0100, Pierre Ossman wrote:
> > here's a trivial patch which adds R6 reponse support to the au1xmmc
> > driver. Fixes SD card detection / operation.
> > 
> NAK. MMC_RSP_R1 and MMC_RSP_R6 have the same value so this will break
> the switch.

not in my version of 2.6.20-rc5 (and 2.6.19):

#define MMC_RSP_R1  (MMC_RSP_PRESENT|MMC_RSP_CRC|MMC_RSP_OPCODE)
#define MMC_RSP_R6  (MMC_RSP_PRESENT|MMC_RSP_CRC)

Without the patch, SD card detection stops with CMD7 returning error.

Thanks,

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

[Aubrey Li]

Christoph's patch is better than mine. The only thing I think is that
zone->max_pagecache_pages should be checked never less than
zone->pages_low.

The good part of the patch is using the existing reclaimer. But the
problem in my opinion of the idea is the existing reclaimer too. Think
of  when vfs cache limit is
hit, reclaimer doesn't reclaim all of the reclaimable pages, it just
give few out. So next time vfs pagecache request, it is quite possible
reclaimer is triggered again. That means after limit is hit, reclaim
will be implemented every time fs ops allocating memory. That's the
point in my mind impacting the performance of the applications.

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

[Alexey Dobriyan]

On Tue, Jan 23, 2007 at 04:53:33PM -0800, Andrew Morton wrote:
> On Tue, 16 Jan 2007 00:53:05 +0300
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> 
> > Compile-tested.
> 
> You can runtime-test this interface without ever having mounted a CODA fs.
> 
> Please.   compile-tested-only patches are always a worry.

OK, I've built coda. Patch doesn't change output of
/proc/fs/coda/{cache_inv_stats,vfs_stats}. Though I haven't mounted
filesystems.

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

Re: [RPC][PATCH 2.6.20-rc5] limit total vfs page cache

[Vaidyanathan Srinivasan]

Aubrey Li wrote:
> On 1/19/07, Vaidyanathan Srinivasan <[EMAIL PROTECTED]> wrote:
>> Hi Aubrey,
>>
>> I used your patch on my PPC64 box and I do not get expected
>> behavior.  As you had requested, I am attaching zoneinfo and meminfo
>> dumps:
>>
>> Please let me know if you need any further data to help me out with
>> the test/experiment.
>>
> 
> Although I have no PPC64 box in hand, I think the logic should be the same.
> get_page_from_freelist() is called 5 times in __alloc_pages().
> 
> 1) alloc_flags = ALLOC_WMARK_LOW | ALLOC_PAGECACHE;
> 2) alloc_flags = ALLOC_WMARK_MIN | ALLOC_PAGECACHE;
> We should have the same result on the first two times 
> get_page_from_freelist().
> 
> 3) if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
>   && !in_interrupt())
>alloc_flags = ALLOC_NO_WATERMARKS
> The case on my platform will never enter this branch. If the branch
> occurs on your side,
> The limit will be omitted. Because NO watermark, zone_watermark_ok()
> will not be checked. memory will be allocated directly.
> 
> 4)if (likely(did_some_progress)) {
>alloc_flags should include ALLOC_PAGECACHE.
> So we should have the same result on this call.
> 
> 5)} else if ((gfp_mask & __GFP_FS) && !(gfp_mask & __GFP_NORETRY)) {
>alloc_flags = ALLOC_WMARK_HIGH, without ALLOC_PAGECACHE
> 
> This branch will not hit on my case. You may need to check it.
> 
> If 3) or 5) occurs on your platform, I think you can easily fix it.
> Please confirm it and let me know the result.


None of the above condition was the problem in my PPC64 box.  I
added __GFP_PAGECACHE flag in pagecache_alloc_cold() and
grab_cache_page_nowait() routines and the reclaim seemed to work.

--- linux-2.6.20-rc5.orig/include/linux/pagemap.h
+++ linux-2.6.20-rc5/include/linux/pagemap.h
@@ -62,12 +62,12 @@ static inline struct page *__page_cache_

 static inline struct page *page_cache_alloc(struct address_space *x)
 {
-   return __page_cache_alloc(mapping_gfp_mask(x));
+   return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_PAGECACHE);
 }

 static inline struct page *page_cache_alloc_cold(struct
address_space *x)
 {
-   return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD);
+   return
__page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD|__GFP_PAGECACHE);
 }

 typedef int filler_t(void *, struct page *);

[snip]

--- linux-2.6.20-rc5.orig/mm/filemap.c
+++ linux-2.6.20-rc5/mm/filemap.c
@@ -823,7 +823,7 @@ grab_cache_page_nowait(struct address_sp
page_cache_release(page);
return NULL;
}
-   page = __page_cache_alloc(mapping_gfp_mask(mapping) & ~__GFP_FS);
+   page = __page_cache_alloc(mapping_gfp_mask(mapping) & ~__GFP_FS |
__GFP_PAGECACHE);
if (page && add_to_page_cache_lru(page, mapping, index, GFP_KERNEL)) {
page_cache_release(page);
page = NULL;


pagecache_alloc_cold() is used in the read-ahead path which was
being called in my case of large file operations.

--Vaidy

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

[KAMEZAWA Hiroyuki]

On Tue, 23 Jan 2007 20:30:16 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> On Wed, 24 Jan 2007, KAMEZAWA Hiroyuki wrote:
> 
> > I don't prefer to cause zone fallback by this.
> > This may use ZONE_DMA before exhausing ZONE_NORMAL (ia64),
> 
> Hmmm... We could use node_page_state instead of zone_page_state.
> 
> > Very rapid page allocation can eats some amount of lower zone.
> 
> One queston: For what purpose would you be using the page cache size 
> limitation?
> 
This is my experience in support-desk for RHEL4. 
(therefore, this may not be suitable for talking about the current kernel)

- One for stability
  When a customer constructs their detabase(Oracle), the system often goes to 
oom.
  This is because that the system cannot allocate DMA_ZOME memory for 32bit 
device.
  (USB or e100)
  Not allowing to use almost all pages as page cache (for temporal use) will be 
some help.
  (Note: construction DB on ext3so all writes are serialized and the system 
couldn't
   free page cache.)

- One for tuing.
  Sometimes our cutomer requests us to limit size of page-cache.
  
  Many cutomers's memory usage reaches 99.x%. (this is very common situation.)
  If almost all memories are used by page-cache, and we can think we can free 
it.
  But the customer cannot estimate what amount of page-cache can be freed 
(without 
  perfromance regression).
  
  When a cutomer wants to add a new application, he tunes the system.
  But memory usage is always 99%.
  page-cache limitation is useful when the customer tunes his system and find
  sets of data and page-cache. 
  (Of course, we can use some other complicated resource management system for 
this.)
  This will allow the users to decide that they need extra memory or not.

  And...some customers want to keep memory Free as much as possible.
  99% memory usage makes insecure them ;)

-Kame



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/irda/vlsi_ir.{h,c}: remove kernel 2.4 code

[David Miller]

From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Sun, 21 Jan 2007 23:36:58 +0200

> On Thu, Jan 18, 2007 at 10:56:13PM +0100, Adrian Bunk wrote:
> > This patch removes kernel 2.4 compatibility code.
> Looks correct to me, thanks.
> 
> 
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Acked-by: Samuel Ortiz <[EMAIL PROTECTED]>

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

Re: 2.6.18-stable release plans?

[Daniel Barkalow]

On Tue, 23 Jan 2007, Jesper Juhl wrote:

> Now that 2.6.19 is out, most likely not.  -stable releases are made
> for the latest stable 2.6.x kernel, once 2.6.x+1 is out that's the one
> -stable patches are made for (2.6.16 is an exception)..

There's generally a bit of overlap. 2.6.17.14 was about the same time as 
2.6.18.1, and 2.6.18.6 was after 2.6.19.1. But 2.6.18.x must be over now, 
because the -stable team didn't release a 2.6.18.7 to match 2.6.19.2, and 
all of 2.6.x except for 2.6.19.2 has that weird file corruption bug 
(although rarely triggered).

-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 0/3] i_ino uniqueness: alternate approach -- hash the inodes

[Andrew Morton]

On Tue, 16 Jan 2007 13:57:38 -0500
Jeff Layton <[EMAIL PROTECTED]> wrote:

> The questions are:
> 
> 1) how much would this slow down lookups for these filesystems?
> 2) is it enough to justify adding more infrastructure to avoid it?
> 
> What might be best is to start with this approach and then only move to using
> IDR or some other scheme if these extra inodes in the hashtable prove to be
> problematic.
> 
> I've done some cursory testing with this patch and the overhead of hashing
> and unhashing the inodes with pipefs is pretty low -- just a few seconds of
> system time added on to the creation and destruction of 10 million pipes (very
> similar to the overhead that the IDR approach would add).

What is the additional overhead, expressed in relative terms?  ie: as a 
percentage?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Limit the size of the pagecache

[Christoph Lameter]

On Wed, 24 Jan 2007, KAMEZAWA Hiroyuki wrote:

> I don't prefer to cause zone fallback by this.
> This may use ZONE_DMA before exhausing ZONE_NORMAL (ia64),

Hmmm... We could use node_page_state instead of zone_page_state.

> Very rapid page allocation can eats some amount of lower zone.

One queston: For what purpose would you be using the page cache size 
limitation?

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

[Andrew Morton]

On Tue, 16 Jan 2007 12:56:31 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:

> Here is a patch to lockdep.c so it behaves correctly when a kprobe breakpoint 
> is
> put on a marker within hardirq tracing functions as long as the marker is 
> within
> the lockdep_recursion incremented boundaries. It should apply on 
> 2.6.20-rc4-git3.
> 
> Mathieu
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> 
> 
> @@ -1841,33 +1843,36 @@ void trace_hardirqs_on(void)

You lost the patch headers.

>   struct task_struct *curr = current;
>   unsigned long ip;
>  
>   if (unlikely(!debug_locks || current->lockdep_recursion))
>   return;
>  
> + current->lockdep_recursion++;
> + barrier();

Why can't we use lockdep_off() here?

>   if (DEBUG_LOCKS_WARN_ON(unlikely(!early_boot_irqs_enabled)))
> - return;
> + goto end;
>  
>   if (unlikely(curr->hardirqs_enabled)) {
>   debug_atomic_inc(_hardirqs_on);
> - return;
> + goto end;
>   }
>   /* we'll do an OFF -> ON transition: */
>   curr->hardirqs_enabled = 1;
>   ip = (unsigned long) __builtin_return_address(0);
>  
>   if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> - return;
> + goto end;
>   if (DEBUG_LOCKS_WARN_ON(current->hardirq_context))
> - return;
> + goto end;
>   /*
>* We are going to turn hardirqs on, so set the
>* usage bit for all held locks:
>*/
>   if (!mark_held_locks(curr, 1, ip))
> - return;
> + goto end;
>   /*
>* If we have softirqs enabled, then set the usage
>* bit for all held locks. (disabled hardirqs prevented
> @@ -1875,11 +1880,14 @@ void trace_hardirqs_on(void)
>*/
>   if (curr->softirqs_enabled)
>   if (!mark_held_locks(curr, 0, ip))
> - return;
> + goto end;
>  
>   curr->hardirq_enable_ip = ip;
>   curr->hardirq_enable_event = ++curr->irq_events;
>   debug_atomic_inc(_on_events);
> +end:
> + barrier();
> + current->lockdep_recursion--;

lockdep_on()?

>  }
>  
>  EXPORT_SYMBOL(trace_hardirqs_on);
> @@ -1888,14 +1896,17 @@ void trace_hardirqs_off(void)
>  {
>   struct task_struct *curr = current;
>  
>   if (unlikely(!debug_locks || current->lockdep_recursion))
>   return;
>  
> + current->lockdep_recursion++;
> + barrier();

lockdep_off()?

>   if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
> - return;
> + goto end;
>  
>   if (curr->hardirqs_enabled) {
>   /*
> @@ -1910,6 +1921,9 @@ void trace_hardirqs_off(void)
>   debug_atomic_inc(_off_events);
>   } else
>   debug_atomic_inc(_hardirqs_off);
> +end:
> + barrier();
> + current->lockdep_recursion--;

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

Re: [PATCH 1/2] lockdep missing barrier()

[Andrew Morton]

On Tue, 16 Jan 2007 12:56:24 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:

> This patch adds a barrier() to lockdep.c lockdep_recursion updates. This
> variable behaves like the preemption count and should therefore use similar
> memory barriers.
> 
> This patch applies on 2.6.20-rc4-git3.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> 
> --- a/kernel/lockdep.c
> +++ b/kernel/lockdep.c
> @@ -166,12 +166,14 @@ static struct list_head chainhash_table[CHAINHASH_SIZE];
>  void lockdep_off(void)
>  {
>   current->lockdep_recursion++;
> + barrier();
>  }
>  
>  EXPORT_SYMBOL(lockdep_off);
>  
>  void lockdep_on(void)
>  {
> + barrier();
>   current->lockdep_recursion--;
>  }

I am allergic to undocumented barriers.  It is often unobvious what the
barrier is supposed to protect against, yielding mystifying code.  This is
one such case.

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

Re: fix typo in geode_configre()@cyrix.c

[Andrew Morton]

On Wed, 17 Jan 2007 02:12:42 +0900 (JST)
takada <[EMAIL PROTECTED]> wrote:

> From: [EMAIL PROTECTED] (Lennart Sorensen)
> Subject: Re: fix typo in geode_configre()@cyrix.c
> Date: Tue, 16 Jan 2007 11:50:07 -0500
> 
> > On Wed, Jan 17, 2007 at 01:38:35AM +0900, takada wrote:
> > > You are right. I agree to your comment. These variables are needless.
> > > I made a patch again.
> > 
> > Of course there are also lots of "magic numbers" around, but I must
> > admit I don't personally really feel like going through the data sheet
> > and naming all of them.
> 
> Me too.
> 
> > 
> > > diff -Narup linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c 
> > > linux-2.6.19/arch/i386/kernel/cpu/cyrix.c
> > > --- linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c2006-11-30 
> > > 06:57:37.0 +0900
> > > +++ linux-2.6.19/arch/i386/kernel/cpu/cyrix.c 2007-01-16 
> > > 19:55:05.0 +0900
> > > @@ -161,19 +161,15 @@ static void __cpuinit set_cx86_inc(void)
> > >  static void __cpuinit geode_configure(void)
> > >  {
> > >   unsigned long flags;
> > > - u8 ccr3, ccr4;
> > >   local_irq_save(flags);
> > >  
> > >   /* Suspend on halt power saving and enable #SUSP pin */
> > >   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
> > >  
> > > - ccr3 = getCx86(CX86_CCR3);
> > > - setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* Enable */
> > > + setCx86(CX86_CCR3, (getCx86(CX86_CCR3) & 0x0f) | 0x10); /* Enable */
> > >   
> > > - ccr4 = getCx86(CX86_CCR4);
> > > - ccr4 |= 0x38;   /* FPU fast, DTE cache, Mem bypass */
> > > - 
> > > - setCx86(CX86_CCR3, ccr3);
> > > + /* FPU fast, DTE cache, Mem bypass */
> > > + setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x30);
> > 
> > Why did that change from 0x38 to 0x30?
> 
> ah... I made mistake. My eye is tired.
> Correctry, 0x38.
> 

I'm lost.  Could someone please prepare a complete new patch against the
latest -linus tree?

Thanks.

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

Re: [RFC] Limit the size of the pagecache

[Nick Piggin]

Aubrey Li wrote:

On 1/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:


On Wed, 24 Jan 2007, Nick Piggin wrote:

> > 1. Insure that anonymous pages that may contain performance
> >critical data is never subject to swap.
> >
> > 2. Insure rapid turnaround of pages in the cache.
>
> So if these two aren't working properly at 100%, then I want to know 
the
> reason why. Or at least see what the workload and the numbers look 
like.


The reason for the anonymous page may be because data is rarely touched
but for some reason the pages must stay in memory. Rapid turnaround is
just one of the reason that I vaguely recall but I never really
understood what the purpose was.

> > 3. Reserve memory for other uses? (Aubrey?)
>
> Maybe. This is still a bad hack, and I don't like to legitimise such 
use
> though. I hope Aubrey isn't relying on this alone for his device to 
work
> because his customers might end up hitting fragmentation problems 
sooner

> or later.

I surely wish that Aubrey would give us some more clarity on
how this should work. Maybe the others who want this feature could also
speak up? I am not that clear on its purpose.


Sorry for the delay. Somehow this thread was put into the spam folder
of my gmail box. :(
The patch I posted several days ago works properly on my side. I'm
working on blackfin-uclinux platform. So I'm not sure it works 100% on
the other arch platform. From O_DIRECT threads, I know different
people suffer from VFS pagecache issue for different reason. So I
really hope the patch can be improved.


So we need to work out what those issues are and fix them.


On my side, When VFS pagecache eat up all of the available memory,
applications who want to allocate the largeish block(order =4 ?) will
fail. So the logic is as follows:


Yeah, it will be failing at order=4, because the allocator won't try
very hard reclaim pagecache pages at that cutoff point. This needs to
be fixed in the allocator.


I hope Aubrey isn't relying on this alone for his device to work
because his customers might end up hitting fragmentation problems sooner
or later.



That's true. I wrote a replacement of buddy system, it's here:
http://lkml.org/lkml/2006/12/30/36.

That can improve the fragmentation problems on our platform.


That might be a good idea, but while the buddy system may not seem as
efficient and wastes space, it is actually really good for fragmentation.

Anyway, point being that you can't eliminate fragmentation, so you need
to cope with allocation failures or implement reserve pools if you want a
robust system.

--
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: [RFC] Limit the size of the pagecache

[Aubrey Li]

On 1/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:

On Wed, 24 Jan 2007, Nick Piggin wrote:

> > 1. Insure that anonymous pages that may contain performance
> >critical data is never subject to swap.
> >
> > 2. Insure rapid turnaround of pages in the cache.
>
> So if these two aren't working properly at 100%, then I want to know the
> reason why. Or at least see what the workload and the numbers look like.

The reason for the anonymous page may be because data is rarely touched
but for some reason the pages must stay in memory. Rapid turnaround is
just one of the reason that I vaguely recall but I never really
understood what the purpose was.

> > 3. Reserve memory for other uses? (Aubrey?)
>
> Maybe. This is still a bad hack, and I don't like to legitimise such use
> though. I hope Aubrey isn't relying on this alone for his device to work
> because his customers might end up hitting fragmentation problems sooner
> or later.

I surely wish that Aubrey would give us some more clarity on
how this should work. Maybe the others who want this feature could also
speak up? I am not that clear on its purpose.


Sorry for the delay. Somehow this thread was put into the spam folder
of my gmail box. :(
The patch I posted several days ago works properly on my side. I'm
working on blackfin-uclinux platform. So I'm not sure it works 100% on
the other arch platform. From O_DIRECT threads, I know different
people suffer from VFS pagecache issue for different reason. So I
really hope the patch can be improved.

On my side, When VFS pagecache eat up all of the available memory,
applications who want to allocate the largeish block(order =4 ?) will
fail. So the logic is as follows:

if request pagecache
 watermark =  min + reserved_pagecache.
else
 watermark =  min.

Here, assume min=123 pages, reserved_pagecache = 200 pages. That means
when VFS pagecache eat up its all of available memory, there are still
200 pages available for the allocation of the application. Does that
make sense?


I hope Aubrey isn't relying on this alone for his device to work
because his customers might end up hitting fragmentation problems sooner
or later.


That's true. I wrote a replacement of buddy system, it's here:
http://lkml.org/lkml/2006/12/30/36.

That can improve the fragmentation problems on our platform.

Christoph - I can't find your original patch, Can you send me again?
it would be great if you merged all of the  enhancement.

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

In-tree version of new FireWire drivers available

[Kristian Høgsberg]

Hi,

I've moved the new FireWire stack to an in-tree git repository and
moved over the missing patches from my out-of-tree version.  The tree
is available over here:

 git://people.freedesktop.org/~krh/linux-2.6

with gitweb avialable here:

 http://gitweb.freedesktop.org/?p=users/krh/linux-2.6.git;a=summary

There's only one branch there which is branched of off Stefan Richters
master from the linux1394 repo, and has the most recent work from my
out-of -tree repo.  Hosting this on freedesktop.org should be fine,
though kernel.org may be more appropriate :)

Changes since the merge into the linux1394 tree include:

- gap count optimization
- full bus management
- loopback for async requests to the local node
- a bug fix for a problem exposed by VIA 6306 controllers
- a typo fix from the bitfield -> mask+shift conversion.

Plus I've merged Stefans recent fixes and resolved the few conflicts
from that.  Stefan, I'm still not sure what the work flow should be
here, do you want to just pull these changes or should I send the 13
patches to linux1394-devel?

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

Re: [patch 00/46] High resolution timer / dynamic tick update

[Daniel Walker]

On Tue, 2007-01-23 at 18:23 -0800, Andrew Morton wrote:

> > There appears to be some fairly clear duplication between my clocksource
> > tree and this release of high resolution timers. Not to mention that we
> > both submitted our tree's to Andrew within days . 
> > 
> > To lessen Andrews burden it would be wise to integrate the two trees
> > prior to anything going into -mm .. It makes sense to eliminate this
> > kind of duplication since it just results in wasted effort. With the
> > benefit that the merge would likely result in a stronger patch set over
> > all.
> > 
> 
> There's also the question of testing status.  We know that the dynticks
> patches in -mm mostly work.  Now that they appear to have been largely respun,
> we don't know that any more.  Then if we go adding more stuff on top, problem
> identification becomes harder.

My code is fairly stable and reviewed, for a couple months .. It also
goes on -mm without this new high res/dynamic tick patches.. So you
could accept that set while HRT stabilizes, and gets merged with my
stuff. I wouldn't be pushing for my changes to go into 2.6.20 , but I
think they could.

There is more collision from parts of my patch set which haven't been
submitted to you. It's the clocksource->flags introduction in this new
high res/dynamic tick patch set. I'd NAK those just because I'm not
convinced they're well thought out, and since they make changes to
several arch clocksources reverting them later wouldn't be to fun.

> I thought that dynticks/hrtimers was a done thing: in fact $certain_people 
> wanted
> them in 2.6.20.  The late-breaking rip-up-and-rewrite was rather unwelcome.  
> But
> I haven't got onto reading the patchset yet.

I haven't review it all either, but I was rather surprised to see such
extensive changes this late. The -mm version was getting pretty mature
too..

Daniel

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

Re: [RFC] Limit the size of the pagecache

[KAMEZAWA Hiroyuki]

one more thing...

On Tue, 23 Jan 2007 16:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> @@ -1168,6 +1170,11 @@ zonelist_scan:
>   !cpuset_zone_allowed_softwall(zone, gfp_mask))
>   goto try_next_zone;
>  
> + if ((gfp_mask & __GFP_PAGECACHE) &&
> + zone_page_state(zone, NR_FILE_PAGES) >
> + zone->max_pagecache_pages)
> + goto try_next_zone;
> +

I don't prefer to cause zone fallback by this.
This may use ZONE_DMA before exhausing ZONE_NORMAL (ia64),
ZONE_NORMAL before ZONE_HIGHMEM (x86).
Very rapid page allocation can eats some amount of lower zone.

Regards,
-Kame

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

[Christoph Lameter]

On Wed, 24 Jan 2007, Nick Piggin wrote:

> > 1. Insure that anonymous pages that may contain performance
> >critical data is never subject to swap.
> > 
> > 2. Insure rapid turnaround of pages in the cache.
> 
> So if these two aren't working properly at 100%, then I want to know the
> reason why. Or at least see what the workload and the numbers look like.

The reason for the anonymous page may be because data is rarely touched 
but for some reason the pages must stay in memory. Rapid turnaround is 
just one of the reason that I vaguely recall but I never really 
understood what the purpose was.

> > 3. Reserve memory for other uses? (Aubrey?)
> 
> Maybe. This is still a bad hack, and I don't like to legitimise such use
> though. I hope Aubrey isn't relying on this alone for his device to work
> because his customers might end up hitting fragmentation problems sooner
> or later.

I surely wish that Aubrey would give us some more clarity on 
how this should work. Maybe the others who want this feature could also 
speak up? I am not that clear on its purpose.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Page Table cleanup patch

[Nick Piggin]

Paul Davies wrote:

This patch is a proposed cleanup of the current page table organisation.
Such a cleanup would be a logical first step towards introducing at least
a partial clean page table interface, geared towards providing enhanced 
virtualization oportunities for x86.  It is also a common sense cleanup 
in its own right.


 * Creates mlpt.c to hold the page table implementation currently held 
   in memory.c.
 * Adjust Makefile 
 * Move implementation dependent page table code out of 
   include/linux/mm.h into include/linux/mlpt-mm.h
 * Move implementation dependent page table code out of 
   include/asm-generic/pgtable.h to include/asm-generic/pgtable-mlpt.h


mlpt stands from multi level page table.


Hi Paul,

I'm not sure that I see the point of this patch alone, as there is still
all the mlpt implementation details in all the page table walkers. Or
did you have a scheme to change implementations somehow just using the
p*d_addr_next?


-#ifndef __PAGETABLE_PUD_FOLDED
-/*
- * Allocate page upper directory.
- * We've already handled the fast-path in-line.
- */
-int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address)
-{
-   pud_t *new = pud_alloc_one(mm, address);
-   if (!new)
-   return -ENOMEM;
-
-   spin_lock(>page_table_lock);
-   if (pgd_present(*pgd))  /* Another has populated it */
-   pud_free(new);
-   else
-   pgd_populate(mm, pgd, new);
-   spin_unlock(>page_table_lock);
-   return 0;
-}
-#else
-/* Workaround for gcc 2.96 */
-int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address)
-{
-   return 0;
-}
-#endif /* __PAGETABLE_PUD_FOLDED */


...


-/* Workaround for gcc 2.96 */
-int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
-{
-   return 0;
-}
-#endif /* __PAGETABLE_PMD_FOLDED */


Hmm, we're gcc-3.2 minimum now -- let's get rid of that crud?

--
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: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)

[Florin Iucha]

On Mon, Jan 15, 2007 at 10:58:29AM -0500, Alan Stern wrote:
> On Sun, 14 Jan 2007, Florin Iucha wrote:
> 
> > Jiri and Trond,
> > 
> > On Mon, Jan 15, 2007 at 01:14:09AM +0100, Jiri Kosina wrote:
> > > On Sun, 14 Jan 2007, Florin Iucha wrote:
> > > 
> > > > All the testing was done via a ssh into the workstation.  The console 
> > > > was left as booted into, with the gdm running.  The remote nfs4 
> > > > directory was mounted on "/mnt". After copying the 60+ GB and testing 
> > > > that the keyboard was still functioning, I did not reboot but stayed in 
> > > > the same kernel and pulled the latest git then started bisecting.  
> > > 
> > > Hi Florin,
> > > 
> > > thanks a lot for the testing. Just to verify - what kernel is 'the same 
> > > kernel' mentioned above? (just to isolate whether the problem is really 
> > > somewhere between 2.6.19 and 2.6.20-rc2, as you stated in previous posts, 
> > > or the situation has changed).
> > 
> > This happened with 2.6.19.  It worked last time, but I wanted to test
> > again, to make sure.  This time, it bombed, but half an hour after the 
> > transfer finished.
> > 
> > > > After recompiling, I moved over to the workstation to reboot it, but 
> > > > the 
> > > > keyboard was not functioning ;(
> > > 
> > > So this time the hang occured when the system was idle, not during the 
> > > transfers, right?
> > 
> > Yes it was idle.  Immediately after the transfer finished, the keyboard was
> > still functioning.  It "hang" minutes later, after the first bisected kernel
> > was compiled and installed.
> > 
> > > > I ran "lsusb" and it displayed all the devices. "dmesg" did not show
> > > > any oops, anything for that matter.  I have unplugged the keyboard and
> > > > run "lsusb" again, but it hang.  I ran "ls /mnt" and it hang as well.
> > > > Stracing "lsusb" showed it hang (entered the kernel) at opening the 
> > > > device
> > > > that used to be the keyboard.  Stracing "ls /mnt" showed that it
> > > > hang at "stat(/mnt)".  Both processes were in "D" state.  "ls /root"
> > > > worked without problem, so it appears that crossing mountpoints causes
> > > > some hang in the kernel.
> > > 
> > > Could you please do alt-sysrq-t (or "echo t > /proc/sysrq-trigger" via 
> > > ssh, when your keyboard is dead) to see the calltraces of the processes 
> > > which are stuck inside kernel?
> > > 
> > > You will probably get a lot of output after the sysrq, so please either 
> > > put it somewhere on the web if possible, or just extract the interesting 
> > > processes out of it (mainly the ones which are stuck).
> > 
> > Will do.
> 
> It would be nice to learn exactly why the keyboard stopped working.  Try
> using the usbmon facility (instructions in Documentation/usb/usbmon.txt)
> to see what happens when you type on the dead keyboard.  Be sure to turn
> on CONFIG_USB_DEBUG as well.  And also check /proc/interrupts; each time
> you hit a key the USB controller should get an interrupt.

Attached is the output from usbmon, unfortunately this kernel did not
have CONFIG_USB_DEBUG set.  This is kernel 2.6.20-rc5.

So, the bus sees some traffic when the keyboard is used, but gdm does
not receive any keystrokes.

florin

-- 
Bruce Schneier expects the Spanish Inquisition.
  http://geekz.co.uk/schneierfacts/fact/163
81007fe91308 707039742 C Ii:003:01 0 8 = 2800 
81007fe91308 707039783 S Ii:003:01 -115 8 <
81007fe91308 707103733 C Ii:003:01 0 8 =  
81007fe91308 707103749 S Ii:003:01 -115 8 <
81007fe91308 707207728 C Ii:003:01 0 8 = 2800 
81007fe91308 707207744 S Ii:003:01 -115 8 <
81007fe91308 707271726 C Ii:003:01 0 8 =  
81007fe91308 707271741 S Ii:003:01 -115 8 <
81007fe91308 707375721 C Ii:003:01 0 8 = 2800 
81007fe91308 707375736 S Ii:003:01 -115 8 <
81007fe91308 707447718 C Ii:003:01 0 8 =  
81007fe91308 707447732 S Ii:003:01 -115 8 <
81007fe91308 707655708 C Ii:003:01 0 8 = 0f00 
81007fe91308 707655725 S Ii:003:01 -115 8 <
81007fe91308 707663708 C Ii:003:01 0 8 = 0f33 
81007fe91308 707663724 S Ii:003:01 -115 8 <
81007fe91308 707679708 C Ii:003:01 0 8 = 0f33 0e00
81007fe91308 707679724 S Ii:003:01 -115 8 <
81007fe91308 707719706 C Ii:003:01 0 8 = 0f33 0e0d
81007fe91308 707719721 S Ii:003:01 -115 8 <
81007fe91308 707727706 C Ii:003:01 0 8 = 0f0e 0d00
81007fe91308 707727721 S Ii:003:01 -115 8 <
81007fe91308 707743704 C Ii:003:01 0 8 = 0e0d 
81007fe91308 707743719 S Ii:003:01 -115 8 <
81007fe91308 707791703 C Ii:003:01 0 8 = 0d00 
81007fe91308 707791717 S Ii:003:01 -115 8 <
81007fe91308 707831702 C Ii:003:01 0 8 =  
81007fe91308 707831717 S Ii:003:01 -115 8 <
81007fe91308 707847701 C Ii:003:01 0 8 = 0900 
81007fe91308 707847716 S Ii:003:01 -115 8 <
81007fe91308 707879698 C 

Re: [RFC] Limit the size of the pagecache

[Christoph Lameter]

On Wed, 24 Jan 2007, KAMEZAWA Hiroyuki wrote:

> if (sc->may_swap &&
> zone_page_state(zone, NR_FILE_PAGES) &&
> !(curreht->flags & PF_MEMALLOC))
>   sc->may_swap = 0;

That is probably better than what we have so far.

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

[Nick Piggin]

Christoph Lameter wrote:
This is a patch using some of Aubrey's work plugging it in what is IMHO 
the right way. Feel free to improve on it. I have gotten repeatedly 
requests to be able to limit the pagecache. With the revised VM statistics 
this is now actually possile. I'd like to know more about possible uses of 
such a feature.





It may be useful to limit the size of the page cache for various reasons
such as

1. Insure that anonymous pages that may contain performance
   critical data is never subject to swap.

2. Insure rapid turnaround of pages in the cache.


So if these two aren't working properly at 100%, then I want to know the
reason why. Or at least see what the workload and the numbers look like.



3. Reserve memory for other uses? (Aubrey?)


Maybe. This is still a bad hack, and I don't like to legitimise such use
though. I hope Aubrey isn't relying on this alone for his device to work
because his customers might end up hitting fragmentation problems sooner
or later.

--
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: [RFC] Limit the size of the pagecache

[KAMEZAWA Hiroyuki]

On Tue, 23 Jan 2007 16:49:55 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:

> If we enter reclaim and the number of page cache pages
> is too high then we switch off swapping during reclaim
> to avoid touching anonymous pages.

In general, I like this (kind of) feature.

> + /*
> +  * If the page cache is too big then focus on page cache
> +  * and ignore anonymous pages
> +  */
> + if (sc->may_swap && zone_page_state(zone, NR_FILE_PAGES)
> + > zone->max_pagecache_pages)
> + sc->may_swap = 0;
> +


How about adding this (kind of) check ?

if (sc->may_swap &&
zone_page_state(zone, NR_FILE_PAGES) &&
!(curreht->flags & PF_MEMALLOC))
sc->may_swap = 0;

-Kame

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/1] V4L/DVB fix

[Mauro Carvalho Chehab]

Linus,

Please pull 'master' from:
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git 
master. 

The patch fixes an important bug on V4L core. By doing some ioctls on an 
unexpected order, it is possible to hang the machine without needing to be 
root, causing a DoS.

   - Buf_qbuf: fix: videobuf_queue->stream corruption and lockup

This patch should also be applied also at -stable releases.

Cheers,
Mauro.

V4L/DVB development is hosted at http://linuxtv.org
---

 drivers/media/video/video-buf.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

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

[PATCH 1/1] V4L/DVB (5123): Buf_qbuf: fix: videobuf_queue->stream corruption and lockup

[Mauro Carvalho Chehab]

From: Oleg Nesterov <[EMAIL PROTECTED]>

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
---

 drivers/media/video/video-buf.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/video-buf.c b/drivers/media/video/video-buf.c
index 635d102..6504a58 100644
--- a/drivers/media/video/video-buf.c
+++ b/drivers/media/video/video-buf.c
@@ -700,6 +700,7 @@ videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
if (buf->state == STATE_QUEUED ||
+   buf->state == STATE_PREPARED ||
buf->state == STATE_ACTIVE) {
dprintk(1,"qbuf: buffer is already queued or active.\n");
goto done;

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

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Alessandro Di Marco]

Pavel Machek <[EMAIL PROTECTED]> writes:

   Imagine for a moment that we solve time-warp somehow. Any other
   problems? 

Well, a user-level daemon have to process a lot of data just to detect user
interaction. Considering that the trackpad bandwidth is nearly 5KB/sec,
probably would be better to leave my panel alone... :-/

   I'd really like to get "is user idle" solved, but it really should not be in
   kernel unless it _has_ to. And time-warp probably causes problems not only
   for your daemon.

IMHO signal the user-space is a kernel duty and no user-space daemon will ever
make it better. There are plenty of PM daemons out there, but Linux still lacks
of a decent power management. Thanks to SIN, acpid and a silly bash script I'm
able to save a lot of battery and furthermore, when my friends see the dimming
panel they break out: WOW, how do you succeed in running MacOS on your Vaio!?!
:-(

Best,

-- 
Gratitude is not only the greatest of virtues, but the parent of all the
others. - Cicero
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] md: bitmap read_page error

[Neil Brown]

On Tuesday January 23, [EMAIL PROTECTED] wrote:
> I think your patch is not enough to slove the read_page error
> completely. I think in the bitmap_init_from_disk we also need to check
> the 'count' never exceeds the size of file before calling the
> read_page function. How do your think about it.
> Thanks your reply.

bitmap_init_from_disk already has a test:

if (file && i_size_read(file->f_mapping->host) < bytes + 
sizeof(bitmap_super_t)) {
printk(KERN_INFO "%s: bitmap file too short %lu < %lu\n",
bmname(bitmap),
(unsigned long) i_size_read(file->f_mapping->host),
bytes + sizeof(bitmap_super_t));
goto out;
}

so 'bytes' of the bitmap must fit entirely within the file, and count
is set:
if (index == num_pages-1)
count = bytes + sizeof(bitmap_super_t)
- index * PAGE_SIZE;
else
count = PAGE_SIZE;
which ensures that it will not go beyond the end of the file.

So I don't think count can ever exceed the size of the file in this
case. 

Can you still see a problem?

Thanks,
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: 2.6.19.2 sky2/acpi crashes

[Len Brown]

> > > Apple Macbook 2GHz (x86, not amd64)

> > > > > Please try to remove processor module.
> > > >
> > > > Ok, that's done. Same problem.
> > >
> > > any difference with "idle=poll"?
> > > if yes, how about "idle=halt"?
> >
> > idle=poll seems to fix the problem (cpu fan is running almost at full
> > speed). Maybe I should run a longer test... For now it consists to run
> > about 15 torrents and watching HDTV through ethernet device.
> >
> > idle=halt does not :
> 
> It sounds like issues relative to Processor C state.
> Please enter a bug in ACPI category on bugzilla.kernel.org

Actually, the test above with the processor module removed proved
that it isn't ACPI C-states -- as they will not be available.
You should be able to observe that /proc/acpi/processor/*/power
does not indicate any C-state use when processor is unloaded.

My guess was that some deep C-state with long exit latency
was interfering with the device.  booting w/o the processor
module should have left you running the native mwait idle.
booting with idle=halt should have left you running the HLT idle.
booting with idle=poll is a busy spin loop that never enters
any hardware power saving state.

I'm quite puzzled that idle=halt was not sufficient to solve the issue,
because that should be the lowest exit latency idle loop.
So maybe I'm wrong about the cause -- though I can't then
explain why idle=poll helps...

All of the idle selection options cause the kernel to print
a line with the word "idle" in it.  Perhaps you could search
your dmesg for "idle" to verify that it is running what we
think it is?

-Len


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

Re: [patch 00/46] High resolution timer / dynamic tick update

[Andrew Morton]

On Tue, 23 Jan 2007 18:16:31 -0800
Daniel Walker <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-01-23 at 22:00 +, Thomas Gleixner wrote:
> >  - Provide a generic way to verify clocksources. TSC needs
> >verification due to broken hardware and BIOS implementations. The
> >previous attempt to allow TSC usage for high resolution and/or
> >dynamic ticks only in combination with the PM-Timer made hardwired
> >assumptions, which are ugly to maintain. The new verification code
> >solves this by chosing the best available clocksource for
> >verification and handles the usability check for highres / dynamic
> >ticks. This makes TSC code agnostic of other hardware available in
> >the system.
> 
> 
> There appears to be some fairly clear duplication between my clocksource
> tree and this release of high resolution timers. Not to mention that we
> both submitted our tree's to Andrew within days . 
> 
> To lessen Andrews burden it would be wise to integrate the two trees
> prior to anything going into -mm .. It makes sense to eliminate this
> kind of duplication since it just results in wasted effort. With the
> benefit that the merge would likely result in a stronger patch set over
> all.
> 

There's also the question of testing status.  We know that the dynticks
patches in -mm mostly work.  Now that they appear to have been largely respun,
we don't know that any more.  Then if we go adding more stuff on top, problem
identification becomes harder.

I thought that dynticks/hrtimers was a done thing: in fact $certain_people 
wanted
them in 2.6.20.  The late-breaking rip-up-and-rewrite was rather unwelcome.  But
I haven't got onto reading the patchset yet.

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

Re: [patch 00/46] High resolution timer / dynamic tick update

[Daniel Walker]

On Tue, 2007-01-23 at 22:00 +, Thomas Gleixner wrote:
>  - Provide a generic way to verify clocksources. TSC needs
>verification due to broken hardware and BIOS implementations. The
>previous attempt to allow TSC usage for high resolution and/or
>dynamic ticks only in combination with the PM-Timer made hardwired
>assumptions, which are ugly to maintain. The new verification code
>solves this by chosing the best available clocksource for
>verification and handles the usability check for highres / dynamic
>ticks. This makes TSC code agnostic of other hardware available in
>the system.


There appears to be some fairly clear duplication between my clocksource
tree and this release of high resolution timers. Not to mention that we
both submitted our tree's to Andrew within days . 

To lessen Andrews burden it would be wise to integrate the two trees
prior to anything going into -mm .. It makes sense to eliminate this
kind of duplication since it just results in wasted effort. With the
benefit that the merge would likely result in a stronger patch set over
all.

Daniel

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

[PATCH 2.6.20] sata_nv: don't rely on NV_INT_DEV indication with ADMA

[Robert Hancock]

OK, here it is in full signed-off glory. Hopefully we can get this in 
for 2.6.20.


---

Several people reported issues with certain drive commands timing out on 
sata_nv controllers running in ADMA mode. The commands in question were 
non-DMA-mapped commands, usually FLUSH CACHE or FLUSH CACHE EXT.


From experimentation it appears that the NV_INT_DEV indication isn't 
always set when a legitimate command completion interrupt is received on 
a legacy-mode command, at least not on these controllers in ADMA mode. 
When a command is pending on the port, force the flag on always in the 
irq_stat value before calling nv_host_intr so that the drive busy state 
is always checked by ata_host_intr.


This also fixes some questionable code in nv_host_intr which called 
ata_check_status when a command was pending and ata_host_intr returned 
"unhandled". If the device interrupted at just the wrong time this could 
cause interrupts to be lost.


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

--- linux-2.6.20-rc5/drivers/ata/sata_nv.c  2007-01-19 19:18:53.0 
-0600
+++ linux-2.6.20-rc5debug/drivers/ata/sata_nv.c 2007-01-22 22:33:43.0 
-0600
@@ -700,7 +700,6 @@ static void nv_adma_check_cpb(struct ata
 static int nv_host_intr(struct ata_port *ap, u8 irq_stat)
 {
struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
-   int handled;
 
/* freeze if hotplugged */
if (unlikely(irq_stat & (NV_INT_ADDED | NV_INT_REMOVED))) {
@@ -719,13 +718,7 @@ static int nv_host_intr(struct ata_port 
}
 
/* handle interrupt */
-   handled = ata_host_intr(ap, qc);
-   if (unlikely(!handled)) {
-   /* spurious, clear it */
-   ata_check_status(ap);
-   }
-
-   return 1;
+   return ata_host_intr(ap, qc);
 }
 
 static irqreturn_t nv_adma_interrupt(int irq, void *dev_instance)
@@ -752,6 +745,11 @@ static irqreturn_t nv_adma_interrupt(int
if (pp->flags & NV_ADMA_PORT_REGISTER_MODE) {
u8 irq_stat = readb(host->mmio_base + 
NV_INT_STATUS_CK804)
>> (NV_INT_PORT_SHIFT * i);
+   if(ata_tag_valid(ap->active_tag))
+   /** NV_INT_DEV indication seems 
unreliable at times
+   at least in ADMA mode. Force it on 
always when a
+   command is active, to prevent 
losing interrupts. */
+   irq_stat |= NV_INT_DEV;
handled += nv_host_intr(ap, irq_stat);
continue;
}

Re: SATA hotplug from the user side ?

[Tejun Heo]

Henrique de Moraes Holschuh wrote:
> On Tue, 23 Jan 2007, Tejun Heo wrote:
>> Henrique de Moraes Holschuh wrote:
>>> Does SATA electrical conector keying let the disk firmware unload
>>> heads before the user manages to pull it out enough to sever power?
>> I don't think so.
> 
> Heh, thought as much. (Good) SCSI hotswap bays notice you pulled the disk
> release lever and issue an START_STOP_UNIT by themselves to the disk well
> before you have time to start pulling the disk out.  I wonder if the SATA
> ones do (I kind of doubt that, SATA seems to attract the el-cheapo, el-crapo
> crowd of manufacturers).

ahci controller spec has places for such thing but I've never seen it
actually implemented.  I'm thinking about a CLI tool to list & control
libata devices including hotplugging, NCQ and other stuff.  Eventually,
it would be really nice to give the user/admin easy gui/web/whatever
tool to watch and control ATA devices.

>>> If it does not, the drive will do an emergency head unload, which is
>>> not good and will likely reduce the drive's lifetime.
>> Probably.
> 
> So, that means it should be explained in the docs that you are to stop the
> disk first, if you can.

Yeap, agreed.

> Even if hald does this automatically, it would still be a very good idea to
> document the proper sequence, IMO...

Agreed.

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

Re: [PATCH 2.6.20-rc5] SPI: alternative fix for spi_busnum_to_master

[David Brownell]

On Tuesday 23 January 2007 8:07 am, Atsushi Nemoto wrote:
> On Tue, 23 Jan 2007 07:42:15 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> > > Indeed the check can be omitted.  Should I send a new patch just
> > > moving class_device_get() into "if (master->bus_num == bus_num)"
> > > block?
> > 
> > Yes, please.
> 
> OK, here is.  This patch uses spi_master_get() instead of
> class_device_get().

Much better.  This should be merged for 2.6.20 ...

> 
> 
> Subject: SPI: alternative fix for spi_busnum_to_master
> 
> If a SPI master device exists, udev (udevtrigger) causes kernel crash,
> due to wrong kobj pointer in kobject_uevent_env().  This problem was
> not in 2.6.19.
> 
> The backtrace (on MIPS) was:
> [<8024db6c>] kobject_uevent_env+0x54c/0x5e8
> [<802a8264>] store_uevent+0x1c/0x3c  (in drivers/class.c)
> [<801cb14c>] subsys_attr_store+0x2c/0x50
> [<801cb80c>] flush_write_buffer+0x38/0x5c
> [<801cb900>] sysfs_write_file+0xd0/0x190
> [<80181444>] vfs_write+0xc4/0x1a0
> [<80181cdc>] sys_write+0x54/0xa0
> [<8010dae4>] stack_done+0x20/0x3c
> 
> flush_write_buffer() passes kobject of spi_master_class.subsys to
> subsys_addr_store(), then subsys_addr_store() passes a pointer to a
> struct subsystem to store_uevent() which expects a pointer to a struct
> class_device.  The problem seems subsys_attr_store() called instead of
> class_device_attr_store().
> 
> This mismatch was caused by commit
> 3bd0f6943520e459659d10f3282285e43d3990f1, which overrides kset of
> master class.  This made spi_master_class.subsys.kset.ktype NULL so
> subsys_sysfs_ops is used instead of class_dev_sysfs_ops.
> 
> The commit was to fix spi_busnum_to_master().  Here is a patch fixes
> this function in other way, just searching children list of
> class_device.
> 
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 270e621..6307428 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -366,7 +366,6 @@ spi_alloc_master(struct device *dev, uns
>  
>   class_device_initialize(>cdev);
>   master->cdev.class = _master_class;
> - kobj_set_kset_s(>cdev, spi_master_class.subsys);
>   master->cdev.dev = get_device(dev);
>   spi_master_set_devdata(master, [1]);
>  
> @@ -466,14 +465,20 @@ EXPORT_SYMBOL_GPL(spi_unregister_master)
>   */
>  struct spi_master *spi_busnum_to_master(u16 bus_num)
>  {
> - charname[9];
> - struct kobject  *bus;
> -
> - snprintf(name, sizeof name, "spi%u", bus_num);
> - bus = kset_find_obj(_master_class.subsys.kset, name);
> - if (bus)
> - return container_of(bus, struct spi_master, cdev.kobj);
> - return NULL;
> + struct class_device *cdev;
> + struct spi_master   *master = NULL;
> + struct spi_master   *m;
> +
> + down(_master_class.sem);
> + list_for_each_entry(cdev, _master_class.children, node) {
> + m = container_of(cdev, struct spi_master, cdev);
> + if (m->bus_num == bus_num) {
> + master = spi_master_get(m);
> + break;
> + }
> + }
> + up(_master_class.sem);
> + return master;
>  }
>  EXPORT_SYMBOL_GPL(spi_busnum_to_master);
>  
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Alessandro Di Marco]

"Scott Preece" <[EMAIL PROTECTED]> writes:

   My own hot button is making sure that the definition of what
   constitutes user activity is managed in exactly one place, whether in
   the kernel or not. My naive model would be to put the response at user
   level, but to provide a single point of definition in the kernel (say,
   /dev/useractivity or the equivalent) that the user-level daemon could
   listen to.

Unfortunately the term "user activity" seems a bit too vague for this. IMHO
different users (but also applications) present different needs that you cannot
fit with a single device node.

Example. The user expects that the keyboard light is turned off after 10
minutes of keyboard inactivity, disregarding the mouse movements. This makes
sense since the glare at the bottom disturb the Quake sessions. :-) However when
the screen is blanked, the user expects that either keyboard or mouse events
can unblank it...

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

Re: identifying CONFIG variable typoes in the source tree

[Robert P. J. Day]

On Tue, 23 Jan 2007, Oleg Verych wrote:

> On 2007-01-23, Robert P. J. Day wrote:
> []
> >   what it does is scan the entire tree for lines of the form
> >
> > ...if... CONFIG_whatever...
> >
> > collects all of those CONFIG variables and, one at a time, checks to
> > see if that variable even exists in any Kconfig file in the tree so
> > that it could possibly ever be set.  (i'm not guaranteeing that the
> > script is perfect, but it does generate some interesting results.)
> >
> >   the first few lines of output:
> >
> > 53C700_BE_BUS
> > 64_BIT
> > 68328_SERIAL_UART2
> > ...
> >
> []
> >   the script turns up 284 examples of this.
>
> Next, this script must to learn how to search whom to send this info.
> And if there's nobody, just to make list of known orphans ;).

  i'm pretty sure that's not going to happen this evening, but i
tweaked the script just a bit so you can run it (from the top-level
directory) against any subdirectory to see what CONFIG symbols appear
to be (for lack of a better word) "orphaned."

  let's test it against, say, fs/xfs:

$ ../config_vars.sh fs/xfs
FS_POSIX_CAP
FS_POSIX_MAC
XFS_DEBUG
XFS_DMAPI
XFS_TRACE

$ grep -r FS_POSIX_CAP .
fs/xfs/xfs_cap.h:#ifdef CONFIG_FS_POSIX_CAP

$ grep -r FS_POSIX_MAC .
./fs/xfs/xfs_mac.h:#ifdef CONFIG_FS_POSIX_MAC

$ grep -r XFS_DEBUG .
./fs/xfs/xfs.h:#ifdef CONFIG_XFS_DEBUG
./fs/xfs/Makefile-linux-2.6:ifeq ($(CONFIG_XFS_DEBUG),y)

and so on.  of course, there may be good reasons for some of these
variables to be there with no corresponding Kconfig entry -- i'm just
printing them out.

rday

p.s. new script is attached.

config_vars.sh
Description: Bourne shell script

Re: [PATCH query] arm: i.MX/MX1 clock event source

[Pavel Pisa]

On Tuesday 23 January 2007 03:52, Pavel Pisa wrote:
> > i've added your patch to -rt, but note that there's a new, slightly
> > incompatible clockevents code in -rt now so you'll need to do some more
> > (hopefully trivial) fixups for this to build and work.
> >
> > Ingo
>
> Hello Ingo,
>
> Unfortunately, even with these corrections boot stuck at
>
> Memory: 18972KB available (2488K code, 358K data, 92K init)
>
> I have not time now to start JTAG debugging session, so I look at that
> tomorrow or on Friday.
>
> It seems, that the interrupts are not coming from device.
>
> Best wishes
>
> Pavel
>

Hello Ingo,

I have found some time and tried to debugg problem with
help of JTAG debugger. But I have found, that IRQs
are processed right. The plain rc5 runs flawlessly.
The rt8 doesnot start. The problem is, that handler
stays NULL after clock event registration. Interrupts
runs, but my code doesnot call any function. The notification
chain and clock events list seems to be filled correctly.
I have added 

clockevent_imx.cpumask = cpumask_of_cpu(0);

to ensure that clock are not used for affinity
mask reasons. I have tried even exchange clock 
event forcibly at the end of clockevent_imx initialization.
But it only resulted in asking timer to switch off
into unused mode.

I have added next hack into IRQ
write_seqlock(_lock);
timer_tick();
write_sequnlock(_lock);
which stays enabled until imx_set_mode() is called first time,
The system boots after this modification, but imx_set_mode()
is never called and there is no switch to high resolution mode.

CONFIG_ARM=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
??? CONFIG_TICK_ONESHOT=y ???
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT_RT=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_SOFTIRQS=y
CONFIG_PREEMPT_HARDIRQS=y
CONFIG_PREEMPT_BKL=y

Could I preset some handler directly during timer initialization?
Can I declare somehow, that I want to use that clock event device
as source of tick from beginning? Should I try to rebuild with CONFIG_NO_HZ=n?
I would like to keep up with changes, because I have tested
RTs for ARM already over more "stable" releases and over many rc-s.
And high resolution timers support has worked well over for me last
three months (up to 2.6.20-rc4). So I want to learn what is required
to be compatible with latest code.

Thanks for any hints to the problem

 Pavel


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

Re: Strange

[Alistair John Strachan]

On Wednesday 24 January 2007 00:01, Christoph Anton Mitterer wrote:
> Alan wrote:
> >> kernel:   Error: Illegal request -- (Sense key=0x05)
> >> kernel:   Read of scrambled sector without authentication -- (asc=0x6f,
> >> ascq=0x03)
> >
> > The disc is using digital rights management. If you are in a country that
> > permits it you can use a dvd reader library with decss support, if not
> > you'll have to either watch your disks on a system approved by the movie
> > industry enforcers or commit a crime to read the disc.
>
> I knew of course about libdvdcss but I've never noticed before that the
> kernel issues these error messages to the syslog.

If you've replaced the drive, the decss keys might have changed for inserted 
media (this is especially true if your old drive had a different region 
setting).

First set the DVD region on the drive to where you are (probably 2), 
using "regionset". Then rm -rf ~/.dvdcss and restart your video playing 
application. It should rescan the dvd, figure out the keys, no error 
messages.

> So you say this is normal?! But the problem with ejecting isn't probably
> normal.

Yeah, like Alan says it's just the DRM nonsense built into your drive trying 
to "protect" the media. You can find firmware modifications which remove this 
logic from the drive, but I'm not sure of their legality.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA problems

[Tejun Heo]

Pablo Sebastian Greco wrote:
> Well, it took me a few days,  but I think I'm ready to report back. One
> of the drives was failing, and it stopped after rewiring power supply so
> the last problem seems to be corrected.
> OTOH, your blacklist seems to be needed too, now I'm running FC6
> distribution kernel 2.6.19-1.2895.fc6 (2.6.19.2 + some patches by
> fedora) and setting
> echo 1 >/sys/block/sdX/device/queue_depth
> on all the SAMSUNG drives (sdb, sdc and sdd)
> The second I type
> echo 31 >/sys/block/sdX/device/queue_depth
> on any of the drives I get these messages
> 
> Jan 23 12:36:30 squid kernel: BUG: warning: (ap->ops->error_handler &&
> ata_tag_valid(ap->active_tag)) at
> drivers/ata/libata-core.c:4602/ata_qc_issue() (Not ta
> inted)

This is kernel bug that needs fixing.  I'll investigate.

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

Re: [PATCH] seq_file conversion: APM on arm

[Ralf Baechle]

On Tue, Jan 23, 2007 at 04:45:41PM -0800, Andrew Morton wrote:

> There is an ongoing desultory effort from Ralf to unify the ARM and MIPS
> APM implementations.  Independently converting them both to use seqfile
> at this stage might muck that up.   Ralf, talk to me?

I was planning to get back to this next week but since soembody noticed
this patch was still pending, why not now ;-)

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

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Theodore Tso]

On Wed, Jan 24, 2007 at 04:41:39AM +0530, Sunil Naidu wrote:
> >You have to remember that the Kernel Summit is invite only.  Holding
> >the summit at a location doesn't really mean it's open to anyone
> >there.
> 
> Defnitely this could be held on invite only. Many Top forums happen in
> India in this fashion. This initiatives itself would be like a booster
> in a Rocket which gives *huge* impact.

Presumably the way to do this would be to have a large conference
(such as OLS) after the kernel summit.  Hopefully most kernel summit
attendees would stick around for 2-3 days afterwards for the technical
conference.

The problem is that the value of the kernel summit is that we get the
> 90% of the key, "right" people there so we can have face-to-face
conversations.  There reason why I started organizing it years ago was
that I hoped that if key developers had a chance to meet with each
other at least once a year, it would help them more productively
communicate with each other via e-mail the rest of the year.  I think
it has succeeded in that goal quite well.  The problem though is that
most people can't afford to fly to India or Australia, and their
employers' travel budgets won't allow that either --- and the value of
the K-S is based on getting as many of the key kernel developers in
one place as possible.

Two years ago, maddog tried to convince me that Brazil would be a
perfect place to hold a kernel summit, and that the Brazillian
government was 100% behind linux, and could provide a wonderful
location, yadda, yadda, yadda.  What I told him was that the only way
I could imagine it working would be if the Brazillian government was
willing to pay travel costs for all 80+ kernel summit attendees to fly
from whatever their home airport to Brazil.  That way, we don't have
to deal with the pushback from corporate travel budget keepers for
having to pay $$$ for travel to places around the world.  When I told
maddog that, presumably he went back to his Brazillian contacts and we
never heard back from him about moving the kernel summit to Brazil again.  :-)

I would suspect it would be a similar issue with India.  I'd love to
have the opportunity to visit Bangalore (or should I say Bengaluru? :-).  
I also know that it's extremely unlikely that my employer would agree
to pay for me to fly there, not to mention all of the other folks that
would need to go to the K-S.  But hey, if you think that there are
organizations in India who would be willing to pay travel for _all_ of
the K-S attendees (preferably business class travel :-), let's
talk

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.2 sky2/acpi crashes

[Luming Yu]

On 1/24/07, Lionel Landwerlin <[EMAIL PROTECTED]> wrote:

Le mardi 23 janvier 2007 à 16:30 -0500, Len Brown a écrit :
> On Tuesday 23 January 2007 07:27, Lionel Landwerlin wrote:
> > Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
> > > Please try to remove processor module.
> >
> > Ok, that's done. Same problem.
>
> any difference with "idle=poll"?
> if yes, how about "idle=halt"?

idle=poll seems to fix the problem (cpu fan is running almost at full
speed). Maybe I should run a longer test... For now it consists to run
about 15 torrents and watching HDTV through ethernet device.

idle=halt does not :


It sounds like issues relative to Processor C state.
Please enter a bug in ACPI category on bugzilla.kernel.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [KBUILD] I don't want initramfs in 2.6.19.1 but usr/ is still processed

[Oleg Verych]

On 2007-01-03, DervishD wrote:
>
> Hi all :)

Hallo!

> I've noticed that, even if I say NO to initramfs (and even ramdisk
> support), the make process wants to GEN usr/initramfs_data.cpio.gz by
> running the scripts/gen_initramfs_list.sh script.
>
> Why is that script run no matter the initramfs support? Looks like
> it only depends on the contents of CONFIG_INITRAMFS_SOURCE :?

I think reading Documentation/filesystems/ramfs-rootfs-initramfs.txt
will answer your question.

> Thanks in advance :)
>
> RaЗl NЗЯez de Arenas Coronado
>
> -- 
> Linux Registered User 88736 | http://www.dervishd.net
> It's my PC and I'll cry if I want to... RAmen!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scsi: use lock per host instead of per device for shared queue tag host

[Ed Lin]

The block layer uses lock to protect request queue. Every scsi device
has a unique request queue, and queue lock is the default lock in struct
request_queue. This is good for normal cases. But for a  host with
shared queue tag (e.g. stex controllers), a queue lock per device means
the shared queue tag is not protected when multiple devices are accessed
at a same time.  This patch is a simple fix for this situation by introducing
a host queue lock to protect shared queue tag. Without this patch we will
see various kernel panics (including the BUG() and kernel errors in
blk_queue_start_tag and blk_queue_end_tag of ll_rw_blk.c) when accessing
different devices simultaneously (e.g. copying big file from one device to
another in smp kernels).

This is against kernel 2.6.20-rc5.

Signed-off-by: Ed Lin <[EMAIL PROTECTED]>
---
 drivers/scsi/scsi_lib.c  |2 +-
 drivers/scsi/stex.c  |2 ++
 include/scsi/scsi_host.h |3 +++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff -purN a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c   2007-01-23 14:40:28.0 -0800
+++ b/drivers/scsi/scsi_lib.c   2007-01-23 14:46:43.0 -0800
@@ -1574,7 +1574,7 @@ struct request_queue *__scsi_alloc_queue
 {
struct request_queue *q;
 
-   q = blk_init_queue(request_fn, NULL);
+   q = blk_init_queue(request_fn, shost->req_q_lock);
if (!q)
return NULL;
 
diff -purN a/drivers/scsi/stex.c b/drivers/scsi/stex.c
--- a/drivers/scsi/stex.c   2007-01-23 14:40:28.0 -0800
+++ b/drivers/scsi/stex.c   2007-01-23 14:48:59.0 -0800
@@ -1254,6 +1254,8 @@ stex_probe(struct pci_dev *pdev, const s
if (err)
goto out_free_irq;
 
+   spin_lock_init(>__req_q_lock);
+   host->req_q_lock = >__req_q_lock;
err = scsi_init_shared_tag_map(host, host->can_queue);
if (err) {
printk(KERN_ERR DRV_NAME "(%s): init shared queue failed\n",
diff -purN a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
--- a/include/scsi/scsi_host.h  2007-01-23 14:40:29.0 -0800
+++ b/include/scsi/scsi_host.h  2007-01-23 14:57:04.0 -0800
@@ -508,6 +508,9 @@ struct Scsi_Host {
spinlock_t  default_lock;
spinlock_t  *host_lock;
 
+   spinlock_t  __req_q_lock;
+   spinlock_t  *req_q_lock;/* protect shared block queue tag */
+
struct mutexscan_mutex;/* serialize scanning activity */
 
struct list_headeh_cmd_q;



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

Re: Strange

[Alan]

> I knew of course about libdvdcss but I've never noticed before that the
> kernel issues these error messages to the syslog.

Various bits of random desktop junk poll drives to see what has appeared
and stick icons on desktops. Some of them do stuff that produces messages
like this because they aren't careful how they probe and what they do.

> So you say this is normal?! But the problem with ejecting isn't probably
> normal.

Eject is application controllable. Most movie players re-enable the
button.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: select() setting ERESTARTNOHAND (514).

[Sean Reifschneider]

On Thu, Jan 11, 2007 at 11:22:46PM +0100, bert hubert wrote:
>Anything else relevant? Do you know which signal interrupted select? Is this
>a single or multithreaded application? And where did the signal come from?

It is, AFAIK, a multi-threaded application.  I don't have any information
on which signal interrupted the process.  I'll ask the person who reported
it to me, Doug, to respond with additional information.

>I tried to reproduce your problem in various ways on 2.6.20-rc4, but it
>didn't appear.

Thanks.

Sean
-- 
 [...] Premature optimization is the root of all evil.
 -- Donald Knuth
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

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

[Andrew Morton]

On Tue, 16 Jan 2007 00:53:05 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:

> Compile-tested.

You can runtime-test this interface without ever having mounted a CODA fs.

Please.   compile-tested-only patches are always a worry.

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

[Christoph Lameter]

This is a patch using some of Aubrey's work plugging it in what is IMHO 
the right way. Feel free to improve on it. I have gotten repeatedly 
requests to be able to limit the pagecache. With the revised VM statistics 
this is now actually possile. I'd like to know more about possible uses of 
such a feature.




It may be useful to limit the size of the page cache for various reasons
such as

1. Insure that anonymous pages that may contain performance
   critical data is never subject to swap.

2. Insure rapid turnaround of pages in the cache.

3. Reserve memory for other uses? (Aubrey?)

We add a new variable "pagecache_ratio" to /proc/sys/vm/ that
defaults to 100 (all memory usable for the pagecache).

The size of the pagecache is the number of file backed
pages in a zone which is available through NR_FILE_PAGES.

We skip zones that contain too many page cache pages in
the page allocator which may cause us to enter reclaim.

If we enter reclaim and the number of page cache pages
is too high then we switch off swapping during reclaim
to avoid touching anonymous pages.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

Index: linux-2.6.20-rc5/include/linux/gfp.h
===
--- linux-2.6.20-rc5.orig/include/linux/gfp.h   2007-01-12 12:54:26.0 
-0600
+++ linux-2.6.20-rc5/include/linux/gfp.h2007-01-23 17:54:51.750696888 
-0600
@@ -46,6 +46,7 @@ struct vm_area_struct;
 #define __GFP_NOMEMALLOC ((__force gfp_t)0x1u) /* Don't use emergency 
reserves */
 #define __GFP_HARDWALL   ((__force gfp_t)0x2u) /* Enforce hardwall cpuset 
memory allocs */
 #define __GFP_THISNODE ((__force gfp_t)0x4u)/* No fallback, no policies */
+#define __GFP_PAGECACHE((__force gfp_t)0x8u) /* Page cache 
allocation */
 
 #define __GFP_BITS_SHIFT 20/* Room for 20 __GFP_FOO bits */
 #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
Index: linux-2.6.20-rc5/include/linux/pagemap.h
===
--- linux-2.6.20-rc5.orig/include/linux/pagemap.h   2007-01-12 
12:54:26.0 -0600
+++ linux-2.6.20-rc5/include/linux/pagemap.h2007-01-23 18:13:14.310062155 
-0600
@@ -62,12 +62,13 @@ static inline struct page *__page_cache_
 
 static inline struct page *page_cache_alloc(struct address_space *x)
 {
-   return __page_cache_alloc(mapping_gfp_mask(x));
+   return __page_cache_alloc(mapping_gfp_mask(x)| __GFP_PAGECACHE);
 }
 
 static inline struct page *page_cache_alloc_cold(struct address_space *x)
 {
-   return __page_cache_alloc(mapping_gfp_mask(x)|__GFP_COLD);
+   return __page_cache_alloc(mapping_gfp_mask(x) |
+__GFP_COLD | __GFP_PAGECACHE);
 }
 
 typedef int filler_t(void *, struct page *);
Index: linux-2.6.20-rc5/include/linux/sysctl.h
===
--- linux-2.6.20-rc5.orig/include/linux/sysctl.h2007-01-12 
12:54:26.0 -0600
+++ linux-2.6.20-rc5/include/linux/sysctl.h 2007-01-23 18:17:09.285324555 
-0600
@@ -202,6 +202,7 @@ enum
VM_PANIC_ON_OOM=33, /* panic at out-of-memory */
VM_VDSO_ENABLED=34, /* map VDSO into new processes? */
VM_MIN_SLAB=35,  /* Percent pages ignored by zone reclaim */
+   VM_PAGECACHE_RATIO=36,  /* percent of RAM to use as page cache */
 };
 
 
@@ -956,7 +957,6 @@ extern ctl_handler sysctl_intvec;
 extern ctl_handler sysctl_jiffies;
 extern ctl_handler sysctl_ms_jiffies;
 
-
 /*
  * Register a set of sysctl names by calling register_sysctl_table
  * with an initialised array of ctl_table's.  An entry with zero
Index: linux-2.6.20-rc5/kernel/sysctl.c
===
--- linux-2.6.20-rc5.orig/kernel/sysctl.c   2007-01-12 12:54:26.0 
-0600
+++ linux-2.6.20-rc5/kernel/sysctl.c2007-01-23 18:24:04.763443772 -0600
@@ -1023,6 +1023,17 @@ static ctl_table vm_table[] = {
.extra2 = _hundred,
},
 #endif
+   {
+   .ctl_name   = VM_PAGECACHE_RATIO,
+   .procname   = "pagecache_ratio",
+   .data   = _pagecache_ratio,
+   .maxlen = sizeof(sysctl_pagecache_ratio),
+   .mode   = 0644,
+   .proc_handler   = _pagecache_ratio_sysctl_handler,
+   .strategy   = _intvec,
+   .extra1 = ,
+   .extra2 = _hundred,
+   },
 #ifdef CONFIG_X86_32
{
.ctl_name   = VM_VDSO_ENABLED,
Index: linux-2.6.20-rc5/mm/page_alloc.c
===
--- linux-2.6.20-rc5.orig/mm/page_alloc.c   2007-01-16 23:26:28.0 
-0600
+++ linux-2.6.20-rc5/mm/page_alloc.c2007-01-23 18:11:40.484617205 -0600
@@ -59,6 +59,8 @@ unsigned long totalreserve_pages __read_
 long nr_swap_pages;
 

Re: [RFC] pci_bus conversion to struct device

[Benjamin Herrenschmidt]

On Tue, 2007-01-23 at 16:22 -0800, Tim Pepper wrote:
> On 1/18/07, Greg KH <[EMAIL PROTECTED]> wrote:
> 
> > Hm, only ia64 enables that option.  Matthew, do you care about those
> > files?
> 
> Given the ia64 nature, unless benh was truly wanting to do something
> or ppc64, IBM's big NUMA boxes are pretty unlikely to care.

I'd still like to do something at one point for ppc and ppc64... or
others. It's a generic problem with non-x86 machines.

In addition, there is the problem of legacy VGA arbitration

Part of the problem with legacy VGA accesses is also that it needs some
level of arbitration which we currently don't do in the kernel at all. X
does some stuff, but it doesn't necessarily arbitrate well with other
things for obvious reasons :-)

I wrote some code for that a little while ago but never quite finished,
and X would have had to be ported over. I might give it a go again one
of these days though. Now that X is slowly moving over some sane PCI
access library, there is a good opportunity to slap in support for a
nice kernel based VGA access arbitration interface.

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: [PATCH] seq_file conversion: APM on arm

[Andrew Morton]

On Mon, 15 Jan 2007 23:59:35 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:

> Compile-tested.
> 
> Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> ---
> 
>  arch/arm/kernel/apm.c |   28 +++-
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> --- a/arch/arm/kernel/apm.c
> +++ b/arch/arm/kernel/apm.c

There is an ongoing desultory effort from Ralf to unify the ARM and MIPS
APM implementations.  Independently converting them both to use seqfile
at this stage might muck that up.   Ralf, talk to me?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] sed s/gawk/awk/ scripts/gen_init_ramfs.sh

[Andrew Morton]

On Mon, 15 Jan 2007 23:11:46 +0100
Sam Ravnborg <[EMAIL PROTECTED]> wrote:

> On Mon, Jan 15, 2007 at 04:24:17PM -0500, Rob Landley wrote:
> > Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
> Acked-by: Sam Ravnborg <[EMAIL PROTECTED]>
> 
> > Use "awk" instead of "gawk".
> > 
> > -- 
> > 
> > There's a symlink from awk to gawk if you're using the gnu tools, but no
> > symlink from gawk to awk if you're using BusyBox or some such.  (There's a
> > reason for the existence of standard names.  Can we use them please?)

If the kernel is being compiled on a non-Linux system (eg: legacy Unix)
then it is, I guess, possible for `awk' and `gawk' to offer different
features.  If the kernel's use of gawk uses GNU extensions then this patch
might break things on such a system.

I guess we'll find 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/

Re: 2.6.19.2 sky2/acpi crashes

[Lionel Landwerlin]

Le mardi 23 janvier 2007 à 16:30 -0500, Len Brown a écrit : 
> On Tuesday 23 January 2007 07:27, Lionel Landwerlin wrote:
> > Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
> > > Please try to remove processor module.
> > 
> > Ok, that's done. Same problem.
> 
> any difference with "idle=poll"?
> if yes, how about "idle=halt"?

idle=poll seems to fix the problem (cpu fan is running almost at full
speed). Maybe I should run a longer test... For now it consists to run
about 15 torrents and watching HDTV through ethernet device.

idle=halt does not : 

Jan 24 01:37:02 cocoduo kernel: [ 1562.672639] NETDEV WATCHDOG: eth0: transmit 
timed out
Jan 24 01:37:02 cocoduo kernel: [ 1562.672648] sky2 eth0: tx timeout
Jan 24 01:37:02 cocoduo kernel: [ 1562.672656] sky2 eth0: transmit ring 243 .. 
222 report=244 done=244
Jan 24 01:37:02 cocoduo kernel: [ 1562.672660] sky2 status report lost?
Jan 24 01:37:11 cocoduo kernel: [ 1571.787958] BUG: soft lockup detected on 
CPU#0!
Jan 24 01:37:11 cocoduo kernel: [ 1571.787989]  [softlockup_tick+155/208] 
softlockup_tick+0x9b/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788007]  [update_process_times+49/128] 
update_process_times+0x31/0x80
Jan 24 01:37:11 cocoduo kernel: [ 1571.788020]  
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788032]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Jan 24 01:37:11 cocoduo kernel: [ 1571.788048]  [_spin_lock_bh+15/32] 
_spin_lock_bh+0xf/0x20
Jan 24 01:37:11 cocoduo kernel: [ 1571.788061]  [pg0+946730645/1068803072] 
sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 24 01:37:11 cocoduo kernel: [ 1571.788083]  [dev_watchdog+0/208] 
dev_watchdog+0x0/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788090]  [dev_watchdog+192/208] 
dev_watchdog+0xc0/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788099]  [run_timer_softirq+273/400] 
run_timer_softirq+0x111/0x190
Jan 24 01:37:11 cocoduo kernel: [ 1571.788114]  [__do_softirq+116/240] 
__do_softirq+0x74/0xf0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788125]  [do_softirq+59/80] 
do_softirq+0x3b/0x50
Jan 24 01:37:11 cocoduo kernel: [ 1571.788134]  
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788143]  [apic_timer_interrupt+31/36] 
apic_timer_interrupt+0x1f/0x24
Jan 24 01:37:11 cocoduo kernel: [ 1571.788153]  [default_idle+0/112] 
default_idle+0x0/0x70
Jan 24 01:37:11 cocoduo kernel: [ 1571.788166]  [default_idle+54/112] 
default_idle+0x36/0x70
Jan 24 01:37:11 cocoduo kernel: [ 1571.788175]  [cpu_idle+116/208] 
cpu_idle+0x74/0xd0
Jan 24 01:37:11 cocoduo kernel: [ 1571.788184]  [start_kernel+872/1072] 
start_kernel+0x368/0x430
Jan 24 01:37:11 cocoduo kernel: [ 1571.788194]  [unknown_bootoption+0/624] 
unknown_bootoption+0x0/0x270
Jan 24 01:37:11 cocoduo kernel: [ 1571.788208]  ===

-- 
Lionel Landwerlin <[EMAIL PROTECTED]>

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

[patch] kbuild: create KBUILD_OUTPUT

[Oleg Verych]

kbuild: create KBUILD_OUTPUT

 When requesting build to another directory, try to create it first.

Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Oleg Verych <[EMAIL PROTECTED]>
---

,-*- bash -*-
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$ make O=/tmp/build
|cd: 1: can't cd to /tmp/build
|Makefile:116: *** output directory "/tmp/build" does not exist.  Stop.
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$ patch -p1 
<../../va-patch/
|kbuild-create-output-dir.patch
|patching file Makefile
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$ make O=/tmp/build
|HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc make[3]: ***
|[scripts/basic/docproc] Interrupt make[2]: *** [scripts_basic] Interrupt
|make: *** [_all] Interrupt
|
|[EMAIL PROTECTED]:~/kernel.org/_work/src/linux-2.6.20-rc5$
`-*-

--- linux-2.6.20-rc5/Makefile~orig  2007-01-12 19:54:26.0 +0100
+++ linux-2.6.20-rc5/Makefile   2007-01-24 00:59:55.926951750 +0100
@@ -113,5 +113,5 @@
 # check that the output directory actually exists
 saved-output := $(KBUILD_OUTPUT)
-KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
+KBUILD_OUTPUT := $(shell d=$(KBUILD_OUTPUT) ; mkdir -p $$d && cd $$d && pwd)
 $(if $(KBUILD_OUTPUT),, \
  $(error output directory "$(saved-output)" does not exist))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 PATCH 4/6] RCU: preemptible RCU

[Andrew Morton]

On Tue, 16 Jan 2007 00:58:58 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:

> +/*
> + * Wait for CPUs to acknowledge the flip.
> + */
> +static int rcu_try_flip_waitack(int flipctr)
> +{
> + int cpu;
> +
> + for_each_possible_cpu(cpu)
> + if (per_cpu(rcu_flip_flag, cpu) != RCU_FLIP_SEEN) 
> + return 1;
> +
> + /*
> +  * Make sure our checks above don't bleed into subsequent
> +  * waiting for the sum of the counters to reach zero.
> +  */
> + smp_mb();
> + return 0;
> +}

Confused.  If some of the possible cpus aren't online, doesn't the 
state machine get stuck??
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA exceptions with 2.6.20-rc5

[Björn Steinbrink]

On 2007.01.23 17:18:43 -0600, Robert Hancock wrote:
> Larry Walton wrote:
> >The last patch (sata_nv-force-int-dev-in-interrupt.patch) 
> >seems to have fix the problem.  Much appreciated, 
> >thank you. I'd consider it a must have in 2.6.20.
> 
> Can any of the rest of you that have been seeing this problem also 
> confirm that this fixes it?

Seems to work for me, uptime is about an hour now and no exception yet.
Had the stress test running for only about 10 minutes, but I usually got
an exception within an hour even during plain irssi usage, so I'm quite
confident that the patch fixes it.

Thanks,
Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 PATCH 4/6] RCU: preemptible RCU

[Andrew Morton]

On Tue, 16 Jan 2007 00:58:58 +0530
Dipankar Sarma <[EMAIL PROTECTED]> wrote:

> This patch implements a new version of RCU which allows its read-side
> critical sections to be preempted.

Why is it selectable if CONFIG_PREEMPT=n?

> It uses a set of counter pairs
> to keep track of the read-side critical sections and flips them
> when all tasks exit read-side critical section. The details
> of this implementation can be found in this paper -
> 
> http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf
> 
> This patch was developed as a part of the -rt kernel
> development and meant to provide better latencies when
> read-side critical sections of RCU don't disable preemption.

Does it succeed in that attempt?  Thus far you've given no reason for
merging this code..

This is a pile of tricky new core kernel code for us to test, maintain,
understand, debug, etc.  It needs to provide a substantial benefit.  Does
it?

> As a consequence of keeping track of RCU readers, the readers
> have a slight overhead (optimizations in the paper).
> This implementation co-exists with the "classic" RCU
> implementations and can be switched to at compiler.

That's yet another question we need to ask people when their kernel dies,
and yet another deviation between the kernels which we all test, causing
more dilution of testing efforts.  It would be much better if we could
remove classic RCU.  You say this would incur extra cost, but the magnitude
of that cost is not clear.  Please help us make that decision.


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

via irq quirk breakage

[Nick Piggin]

Recently updated an old box to a new kernel, and the USB mouse stops working.
Well it sort of works, but stutters and is very unresponsive. This happens
now and again when the IRQ routing for my board gets broken.

Attached a dmesg from a bad 2.6.20-rc5, and a quick hack that gets everything
working again, and a diff between good and bad dmesg, and lspci.

I can test patches or send any other info needed.

--
SUSE Labs, Novell Inc.
Linux version 2.6.20-rc5 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061020 
(prerelease) (Debian 4.1.1-17)) #27 SMP PREEMPT Tue Jan 23 17:13:01 EST 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:  size: 0009fc00 end: 
0009fc00 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0009fc00 size: 0400 end: 
000a type: 2
copy_e820_map() start: 000f size: 0001 end: 
0010 type: 2
copy_e820_map() start: 0010 size: 0fef end: 
0fff type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0fff size: 8000 end: 
0fff8000 type: 3
copy_e820_map() start: 0fff8000 size: 8000 end: 
1000 type: 4
copy_e820_map() start: fec0 size: 1000 end: 
fec01000 type: 2
copy_e820_map() start: fee0 size: 1000 end: 
fee01000 type: 2
copy_e820_map() start:  size: 0001 end: 
0001 type: 2
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0fff (usable)
 BIOS-e820: 0fff - 0fff8000 (ACPI data)
 BIOS-e820: 0fff8000 - 1000 (ACPI NVS)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820:  - 0001 (reserved)
255MB LOWMEM available.
found SMP MP-table at 000fb110
Entering add_active_range(0, 0, 65520) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->65520
early_node_map[1] active PFN ranges
0:0 ->65520
On node 0 totalpages: 65520
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 479 pages used for memmap
  Normal zone: 60945 pages, LIFO batch:15
DMI 2.3 present.
ACPI: RSDP (v000 AMI   ) @ 0x000fc590
ACPI: RSDT (v001 AMIINT  0x0010 MSFT 0x0099) @ 0x0fff
ACPI: FADT (v001 AMIINT  0x0011 MSFT 0x0099) @ 0x0fff0030
ACPI: MADT (v001 AMIINT  0x0009 MSFT 0x0099) @ 0x0fff00b0
ACPI: DSDT (v001VIA APOLLO-P 0x1000 MSFT 0x010b) @ 0x
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 2000 (gap: 1000:eec0)
Detected 996.609 MHz processor.
Built 1 zonelists.  Total pages: 65009
Kernel command line: BOOT_IMAGE=linuxtest2 ro root=305 nmi_watchdog=1
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c041 soft=c040e000
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour VGA+ 132x60
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255836k/262080k available (2206k kernel code, 5696k reserved, 678k 
data, 200k init, 0k highmem)
virtual kernel memory layout:
fixmap  : 0xfffb7000 - 0xf000   ( 288 kB)
vmalloc : 0xd080 - 0xfffb5000   ( 759 MB)
lowmem  : 0xc000 - 0xcfff   ( 255 MB)
  .init : 0xc03d7000 - 0xc0409000   ( 200 kB)
  .data : 0xc0327a4f - 0xc03d128c   ( 678 kB)
  .text : 0xc010 - 0xc0327a4f   (2206 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1994.39 BogoMIPS (lpj=997195)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff     
 
CPU: L1 I cache: 

Re: [RFC] pci_bus conversion to struct device

[Tim Pepper]

On 1/18/07, Greg KH <[EMAIL PROTECTED]> wrote:


Hm, only ia64 enables that option.  Matthew, do you care about those
files?


Given the ia64 nature, unless benh was truly wanting to do something
or ppc64, IBM's big NUMA boxes are pretty unlikely to care.


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

Re: problems with latest smbfs changes on 2.4.34 and security backports

[dann frazier]

On Wed, Jan 24, 2007 at 10:46:24AM +1100, Grant Coady wrote:
> On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier <[EMAIL PROTECTED]> wrote:
> 
> >Users have reported a symlink issue with my recent smbfs backport.
> >Turns out my backport overlooked a second 2.6 patch w/ the fix:
> > http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
> >
> >This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
> >issue, and also cleans up an unnecessary double assignment. As his
> >commit message notes, you will need the userspace patches from Samba
> >Bug #999 in order to use the permission/ownership assigned by the
> >server.
> 
> Server-side:
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.6.19.2a
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 8
> drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
> -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
> lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test
> 
> Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
> for comparison:
> 
> [EMAIL PROTECTED]:/home/other$ uname -r
> 2.4.33.3
> [EMAIL PROTECTED]:/home/other$ ls -l
> total 4096
> drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
> lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
> -rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
> lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
> -rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
> lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test
> 
> [EMAIL PROTECTED]:~$ uname -r
> 2.6.19.2a
> [EMAIL PROTECTED]:~$ ls -l /home/other/
> total 10
> drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
> lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
> -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
> lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*
> 
> [EMAIL PROTECTED]:~$ uname -r
> 2.4.34c
> [EMAIL PROTECTED]:~$ ls -l /home/other/
> total 4096
> drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
> lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
> -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
> -rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
> lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

Great, that's what I'd expect. If you patch your userspace, you can
avoid the executable bits.


-- 
dann frazier

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

Re: Strange

[Christoph Anton Mitterer]

Alan wrote:
>> kernel:   Error: Illegal request -- (Sense key=0x05)
>> kernel:   Read of scrambled sector without authentication -- (asc=0x6f,
>> ascq=0x03)
>> 
>
> The disc is using digital rights management. If you are in a country that
> permits it you can use a dvd reader library with decss support, if not
> you'll have to either watch your disks on a system approved by the movie
> industry enforcers or commit a crime to read the disc.
>   
I knew of course about libdvdcss but I've never noticed before that the
kernel issues these error messages to the syslog.

So you say this is normal?! But the problem with ejecting isn't probably
normal.

Best wishes,
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Strange

[Alan]

> kernel:   Error: Illegal request -- (Sense key=0x05)
> kernel:   Read of scrambled sector without authentication -- (asc=0x6f,
> ascq=0x03)

The disc is using digital rights management. If you are in a country that
permits it you can use a dvd reader library with decss support, if not
you'll have to either watch your disks on a system approved by the movie
industry enforcers or commit a crime to read the disc.

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: problems with latest smbfs changes on 2.4.34 and security backports

[Grant Coady]

On Tue, 23 Jan 2007 14:12:57 -0700, dann frazier <[EMAIL PROTECTED]> wrote:

>Users have reported a symlink issue with my recent smbfs backport.
>Turns out my backport overlooked a second 2.6 patch w/ the fix:
> http://linux.bkbits.net:8080/linux-2.6/?PAGE=cset=419e7b76CdrmRG_NZ8LKj9DUUBGu1w
>
>This is a backport of Haroldo Gamal's 2.6 patch that fixes the symlink
>issue, and also cleans up an unnecessary double assignment. As his
>commit message notes, you will need the userspace patches from Samba
>Bug #999 in order to use the permission/ownership assigned by the
>server.

Server-side:
[EMAIL PROTECTED]:/home/other$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:/home/other$ ls -l
total 8
drwxr-xr-x 2 root  root  96 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test

Client-side, 2.4.34c is with this new patch, 2.4.33.3 and 2.6.19.2 
for comparison:

[EMAIL PROTECTED]:/home/other$ uname -r
2.4.33.3
[EMAIL PROTECTED]:/home/other$ ls -l
total 4096
drwxr-xr-x 1 root  root   0 2007-01-21 11:44 dir/
lrwxrwxrwx 1 root  root   3 2007-01-21 11:43 dirlink -> dir/
-rw-r--r-- 1 root  root  15 2007-01-21 11:43 file
lrwxrwxrwx 1 root  root   4 2007-01-21 11:44 filelink -> file
-rw-r--r-- 1 grant wheel 20 2007-01-24 10:24 test
lrwxrwxrwx 1 grant wheel  4 2007-01-24 10:23 testlink -> test

[EMAIL PROTECTED]:~$ uname -r
2.6.19.2a
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 10
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

[EMAIL PROTECTED]:~$ uname -r
2.4.34c
[EMAIL PROTECTED]:~$ ls -l /home/other/
total 4096
drwxr-xr-x 1 grant wheel  0 2007-01-21 11:44 dir/
lrwxr-xr-x 1 grant wheel  3 2007-01-21 11:43 dirlink -> dir/
-rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
lrwxr-xr-x 1 grant wheel  4 2007-01-21 11:44 filelink -> file*
-rwxr-xr-x 1 grant wheel 20 2007-01-24 10:24 test*
lrwxr-xr-x 1 grant wheel  4 2007-01-24 10:23 testlink -> test*

Grant.

>
>Signed-off-by: dann frazier <[EMAIL PROTECTED]>
>
>diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c
>index be975fe..7fd9b51 100644
>--- a/fs/smbfs/inode.c
>+++ b/fs/smbfs/inode.c
>@@ -513,10 +513,10 @@ smb_read_super(struct super_block *sb, void *raw_data, 
>int silent)
>   mnt->flags = (oldmnt->file_mode >> 9) | SMB_MOUNT_UID |
>   SMB_MOUNT_GID | SMB_MOUNT_FMODE | SMB_MOUNT_DMODE;
>   } else {
>-  mnt->file_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFREG;
>-  mnt->dir_mode = mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>-  S_IROTH | S_IXOTH | S_IFDIR;
>+  mnt->file_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFREG;
>+  mnt->dir_mode = S_IRWXU | S_IRGRP | S_IXGRP |
>+  S_IROTH | S_IXOTH | S_IFDIR;
>   if (parse_options(mnt, raw_data))
>   goto out_bad_option;
>   }
>diff --git a/fs/smbfs/proc.c b/fs/smbfs/proc.c
>index 7f0794c..5570007 100644
>--- a/fs/smbfs/proc.c
>+++ b/fs/smbfs/proc.c
>@@ -1994,10 +1994,11 @@ void smb_decode_unix_basic(struct smb_fattr *fattr, 
>struct smb_sb_info *server,
> 
>   if ( (server->mnt->flags & SMB_MOUNT_DMODE) &&
>(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->dir_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFDIR;
>+  fattr->f_mode = (server->mnt->dir_mode & S_IRWXUGO) | S_IFDIR;
>   else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> !(S_ISDIR(fattr->f_mode)) )
>-  fattr->f_mode = (server->mnt->file_mode & (S_IRWXU | S_IRWXG | 
>S_IRWXO)) | S_IFREG;
>+  fattr->f_mode = (server->mnt->file_mode & S_IRWXUGO) |
>+  (fattr->f_mode & S_IFMT);
> 
> }
> 

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

Strange

[Christoph Anton Mitterer]

Hi.

I'm using a kernel 2.6.18.1 with a Plextor PX-769A CD/DVD drive (using
the old IDE drivers)... The drive itself is brand-new. The firmware
version is 1.06 (which is the most recent).

There are to issues I experience.

1) On some (but not all) DVD-Videos I get the following messages:

kernel: hdb: command error: status=0x51 { DriveReady SeekComplete Error }
kernel: hdb: command error: error=0x54 { AbortedCommand
LastFailedSense=0x05 }
kernel: ide: failed opcode was: unknown
kernel: ATAPI device hdb:
kernel:   Error: Illegal request -- (Sense key=0x05)
kernel:   Read of scrambled sector without authentication -- (asc=0x6f,
ascq=0x03)
kernel:   The failed "Read 10" packet command was:
kernel:   "28 00 00 00 01 38 00 00 01 00 00 00 00 00 00 00 "
kernel: end_request: I/O error, dev hdb, sector 1248

What do they mean? Does it indicate a damage in the drive? Or a firmware
error? Anyway I can read the contents of the media (and watch the movies
on it)

The error appears after mounting the discs (but as I've said, not with
every disc).

Any ideas?



2) As far as I can remember, when a disc was mounted, the eject button
was disabled. But now, when I press the eject button, the disc is
ejected (and it seems that it is unmounted, at least mount doesn't show
it any longer).

Is this the correct behaviour? I'd doubt that.




Thanks in advance,
Chris.
begin:vcard
fn:Mitterer, Christoph Anton
n:Mitterer;Christoph Anton
email;internet:[EMAIL PROTECTED]
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: identifying CONFIG variable typoes in the source tree

[Oleg Verych]

On 2007-01-23, Robert P. J. Day wrote:
[]
>   what it does is scan the entire tree for lines of the form
>
> ...if... CONFIG_whatever...
>
> collects all of those CONFIG variables and, one at a time, checks to
> see if that variable even exists in any Kconfig file in the tree so
> that it could possibly ever be set.  (i'm not guaranteeing that the
> script is perfect, but it does generate some interesting results.)
>
>   the first few lines of output:
>
> 53C700_BE_BUS
> 64_BIT
> 68328_SERIAL_UART2
> ...
>
[]
>   the script turns up 284 examples of this.

Next, this script must to learn how to search whom to send this info.
And if there's nobody, just to make list of known orphans ;).

> rday



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] serial driver PMC MSP71xx, kernel linux-mips.git mast er

[Alan]

On Tue, 23 Jan 2007 14:37:23 -0800
Marc St-Jean <[EMAIL PROTECTED]> wrote:
> > This I would hope you can hide in the platform specific
> > serial_in/serial_out functions. If you write the UART_LCR save it in
> > serial_out(), if you read IER etc.
> 
> I couldn't find hooks for platform specific serial_in/out functions.
> Do you mean using the up->port.iotype's in serial_in/out from 8250.c?

If you can have other uarts as well then yes. Basically I want all the
ugliness to belong to you not to the 8250 driver (and ditto for any other
half baked uart or demented piece of broken glue logic). If we don't do
that then 8250.c will end up unmanagable. So long as you crap in your own
pond everyone else is fine ;)

> A serial_in(up, UART_IIR) calls occur in more places that just the interrupt
> handler (i.e. autoconfig*, serial8250_start_tx, etc). We will need to check
> if we are in an interrupt on each IIR read, hopefully that won't be too much
> overhead!

Or if need be we make that hint generally available as we can do that bit
cleanly.

> > 
> > And we might want to add a void * for board specific insanity to the 8250
> > structures if we really have to so you can hang your brain damage
> > privately off that ?
> 
> Sounds good to me, it would give us a location to store the address of the
> UART_STATUS_REG required by this UART variant.

and for anything harder people can hang a struct off it.

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: SATA exceptions with 2.6.20-rc5

[Robert Hancock]

Larry Walton wrote:
The last patch (sata_nv-force-int-dev-in-interrupt.patch) 
seems to have fix the problem.  Much appreciated, 
thank you. I'd consider it a must have in 2.6.20.


Can any of the rest of you that have been seeing this problem also 
confirm that this fixes it?


--
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: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit

[Samium Gromoff]

At Tue, 23 Jan 2007 16:16:12 -0500,
Jakub Jelinek wrote:
> 
> On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote:
> > Should we introduce per-arch asm/elf.h files to hold the relevant flag 
> > definitions then?
> 
> On some architectures there are no bits left.  On others you'd need to go
> through whomever maintains the relevant psABI to get a bit officially
> allocated.  Really, it is very bad idea to use e_flags for this.

How does one find the relevant maintainers?

Even just the specs are harder to find in the authoritative location,
given the OSDL and FSG merge: the psabi documents at

http://www.linux-foundation.org/spec/refspecs/

all 404...
 
> If all you care about is running setuid LISP programs, you'd much better put
> your energy into fixing the buggy ELF dumper in it.
> 
>   Jakub

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

[PATCH 2.6.21 4/4] ehca: remove obsolete prototypes

[Hoang-Nam Nguyen]

Here is a patch for ehca_classes.h that removes obsolete prototypes.
Thanks
Nam


Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---


 ehca_classes.h |   14 --
 1 files changed, 14 deletions(-)


diff -Nurp infiniband_orig/drivers/infiniband/hw/ehca/ehca_classes.h 
infiniband_work/drivers/infiniband/hw/ehca/ehca_classes.h
--- infiniband_orig/drivers/infiniband/hw/ehca/ehca_classes.h   2007-01-20 
00:21:21.0 +0100
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_classes.h   2007-01-20 
00:23:46.0 +0100
@@ -250,20 +250,6 @@ struct ehca_ucontext {
struct ib_ucontext ib_ucontext;
 };
 
-struct ehca_module *ehca_module_new(void);
-
-int ehca_module_delete(struct ehca_module *me);
-
-int ehca_eq_ctor(struct ehca_eq *eq);
-
-int ehca_eq_dtor(struct ehca_eq *eq);
-
-struct ehca_shca *ehca_shca_new(void);
-
-int ehca_shca_delete(struct ehca_shca *me);
-
-struct ehca_sport *ehca_sport_new(struct ehca_shca *anchor);
-
 int ehca_init_pd_cache(void);
 void ehca_cleanup_pd_cache(void);
 int ehca_init_cq_cache(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.21 3/4] ehca: remove do_mmap()

[Hoang-Nam Nguyen]

This patch removes do_mmap() from ehca:
- Call remap_pfn_range() for hardware register block
- Use vm_insert_page() to register memory allocated for completion queues
and queue pairs
- The actual mmap() call/trigger is now controlled by user space, ie. libehca

Thanks
Nam


Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---


 ehca_classes.h |   15 +-
 ehca_cq.c  |   65 ++---
 ehca_iverbs.h  |8 -
 ehca_main.c|6 
 ehca_qp.c  |   78 ++-
 ehca_uverbs.c  |  395 +++--
 6 files changed, 204 insertions(+), 363 deletions(-)


diff -Nurp infiniband_orig/drivers/infiniband/hw/ehca/ehca_classes.h 
infiniband_work/drivers/infiniband/hw/ehca/ehca_classes.h
--- infiniband_orig/drivers/infiniband/hw/ehca/ehca_classes.h   2007-01-20 
00:19:10.0 +0100
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_classes.h   2007-01-20 
00:21:21.0 +0100
@@ -119,13 +119,14 @@ struct ehca_qp {
struct ipz_qp_handle ipz_qp_handle;
struct ehca_pfqp pf;
struct ib_qp_init_attr init_attr;
-   u64 uspace_squeue;
-   u64 uspace_rqueue;
-   u64 uspace_fwh;
struct ehca_cq *send_cq;
struct ehca_cq *recv_cq;
unsigned int sqerr_purgeflag;
struct hlist_node list_entries;
+   /* mmap counter for resources mapped into user space */
+   u32 mm_count_squeue;
+   u32 mm_count_rqueue;
+   u32 mm_count_galpa;
 };
 
 /* must be power of 2 */
@@ -142,13 +143,14 @@ struct ehca_cq {
struct ipz_cq_handle ipz_cq_handle;
struct ehca_pfcq pf;
spinlock_t cb_lock;
-   u64 uspace_queue;
-   u64 uspace_fwh;
struct hlist_head qp_hashtab[QP_HASHTAB_LEN];
struct list_head entry;
u32 nr_callbacks;
spinlock_t task_lock;
u32 ownpid;
+   /* mmap counter for resources mapped into user space */
+   u32 mm_count_queue;
+   u32 mm_count_galpa;
 };
 
 enum ehca_mr_flag {
@@ -283,7 +285,6 @@ extern int ehca_port_act_time;
 extern int ehca_use_hp_mr;
 
 struct ipzu_queue_resp {
-   u64 queue;/* points to first queue entry */
u32 qe_size;  /* queue entry size */
u32 act_nr_of_sg;
u32 queue_length; /* queue length allocated in bytes */
@@ -296,7 +297,6 @@ struct ehca_create_cq_resp {
u32 cq_number;
u32 token;
struct ipzu_queue_resp ipz_queue;
-   struct h_galpas galpas;
 };
 
 struct ehca_create_qp_resp {
@@ -309,7 +309,6 @@ struct ehca_create_qp_resp {
u32 dummy; /* padding for 8 byte alignment */
struct ipzu_queue_resp ipz_squeue;
struct ipzu_queue_resp ipz_rqueue;
-   struct h_galpas galpas;
 };
 
 struct ehca_alloc_cq_parms {
diff -Nurp infiniband_orig/drivers/infiniband/hw/ehca/ehca_cq.c 
infiniband_work/drivers/infiniband/hw/ehca/ehca_cq.c
--- infiniband_orig/drivers/infiniband/hw/ehca/ehca_cq.c2007-01-20 
00:19:10.0 +0100
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_cq.c2007-01-20 
00:21:21.0 +0100
@@ -267,7 +267,6 @@ struct ib_cq *ehca_create_cq(struct ib_d
if (context) {
struct ipz_queue *ipz_queue = _cq->ipz_queue;
struct ehca_create_cq_resp resp;
-   struct vm_area_struct *vma;
memset(, 0, sizeof(resp));
resp.cq_number = my_cq->cq_number;
resp.token = my_cq->token;
@@ -276,40 +275,14 @@ struct ib_cq *ehca_create_cq(struct ib_d
resp.ipz_queue.queue_length = ipz_queue->queue_length;
resp.ipz_queue.pagesize = ipz_queue->pagesize;
resp.ipz_queue.toggle_state = ipz_queue->toggle_state;
-   ret = ehca_mmap_nopage(((u64)(my_cq->token) << 32) | 0x1200,
-  ipz_queue->queue_length,
-  (void**)_queue.queue,
-  );
-   if (ret) {
-   ehca_err(device, "Could not mmap queue pages");
-   cq = ERR_PTR(ret);
-   goto create_cq_exit4;
-   }
-   my_cq->uspace_queue = resp.ipz_queue.queue;
-   resp.galpas = my_cq->galpas;
-   ret = ehca_mmap_register(my_cq->galpas.user.fw_handle,
-(void**)_handle,
-);
-   if (ret) {
-   ehca_err(device, "Could not mmap fw_handle");
-   cq = ERR_PTR(ret);
-   goto create_cq_exit5;
-   }
-   my_cq->uspace_fwh = (u64)resp.galpas.kernel.fw_handle;
if (ib_copy_to_udata(udata, , sizeof(resp))) {
ehca_err(device, "Copy to udata failed.");
-   goto create_cq_exit6;
+   goto create_cq_exit4;
}
}
 

[PATCH 2.6.21 1/4] ehca: fix improper use of yield with spinlock held

[Hoang-Nam Nguyen]

Here is a patch for ehca_cq.c that fixes improper use of yield
with spinlock held.
Thanks
Nam


Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---


 ehca_cq.c |5 -
 1 files changed, 4 insertions(+), 1 deletion(-)


diff -Nurp infiniband_orig/drivers/infiniband/hw/ehca/ehca_cq.c 
infiniband_work/drivers/infiniband/hw/ehca/ehca_cq.c
--- infiniband_orig/drivers/infiniband/hw/ehca/ehca_cq.c2007-01-19 
19:40:32.0 +0100
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_cq.c2007-01-20 
00:15:34.0 +0100
@@ -344,8 +344,11 @@ int ehca_destroy_cq(struct ib_cq *cq)
unsigned long flags;
 
spin_lock_irqsave(_cq_idr_lock, flags);
-   while (my_cq->nr_callbacks)
+   while (my_cq->nr_callbacks) {
+   spin_unlock_irqrestore(_cq_idr_lock, flags);
yield();
+   spin_lock_irqsave(_cq_idr_lock, flags);
+   }
 
idr_remove(_cq_idr, my_cq->token);
spin_unlock_irqrestore(_cq_idr_lock, 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 2.6.21 2/4] ehca: fix mismatched use of spin_unlock in irq handler

[Hoang-Nam Nguyen]

Here is a patch for ehca_irq.c that fixes mismatched use of spin_unlock
in irq handler.
Thanks
Nam


Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---


 ehca_irq.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)


diff -Nurp infiniband_orig/drivers/infiniband/hw/ehca/ehca_irq.c 
infiniband_work/drivers/infiniband/hw/ehca/ehca_irq.c
--- infiniband_orig/drivers/infiniband/hw/ehca/ehca_irq.c   2007-01-19 
19:40:32.0 +0100
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_irq.c   2007-01-23 
22:38:02.0 +0100
@@ -440,7 +440,8 @@ void ehca_tasklet_eq(unsigned long data)
cq = idr_find(_cq_idr, token);
 
if (cq == NULL) {
-   spin_unlock(_cq_idr_lock);
+   
spin_unlock_irqrestore(_cq_idr_lock,
+  flags);
break;
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.21 0/4] ehca: remove do_mmap() and some bug fixes

[Hoang-Nam Nguyen]

Hello Roland!
Here is a patch set for ehca as a result of previous disscussions
and comments:
1. fix improper use of yield within spinlock context
2. fix mismatched use of spin_unlock in irq handler
3. remove do_mmap()
4. remove obsolete prototypes
PS: I've sent the first two recently for 2.6.20, but adding here
for completeness for 2.6.21.
Thanks
Nam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2006-discuss] 2007 Linux Kernel Summit

[Sunil Naidu]

On 1/24/07, Josh Boyer <[EMAIL PROTECTED]> wrote:

>
> > Any other reasons am missing here?
>
> Cost of flying 70 mainly US/European developers to India.


Thanks James. I thought about this factor. Thinking about what are the
factors which make a Kernel developer to show interest on a particular
location.


You have to remember that the Kernel Summit is invite only.  Holding
the summit at a location doesn't really mean it's open to anyone
there.


Defnitely this could be held on invite only. Many Top forums happen in
India in this fashion. This initiatives itself would be like a booster
in a Rocket which gives *huge* impact.

I do strongly feel this would be a big push to Linux among community
(apart from corporates). Plus, a message sender too ;-) We can debate
on this...


josh


Thanks,

~Akula2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] videobuf_qbuf: fix? possible videobuf_queue->stream corruption and lockup

[Mauro Carvalho Chehab]

Em Ter, 2007-01-23 às 20:57 +0300, Oleg Nesterov escreveu:
> I am pretty sure the bug is real, but the patch may be wrong, please review.
> 
> We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
> means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.
> 
> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>

Chris/Adrian,

IMO, this should also be applied at -stable trees.
> 
> --- 6.19/drivers/media/video/video-buf.c~v4l_lockup   2006-11-17 
> 19:42:25.0 +0300
> +++ 6.19/drivers/media/video/video-buf.c  2007-01-23 19:44:19.0 
> +0300
> @@ -700,6 +700,7 @@ videobuf_qbuf(struct videobuf_queue *q,
>   goto done;
>   }
>   if (buf->state == STATE_QUEUED ||
> + buf->state == STATE_PREPARED ||
>   buf->state == STATE_ACTIVE) {
>   dprintk(1,"qbuf: buffer is already queued or active.\n");
>   goto done;
> 

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

[PATCH 2/2]: Fix BUG in cancel_dirty_pages on XFS

[David Chinner]

Make XFS use the new truncate_unmap_inode_pages_range()
function.

Signed-off-by: Dave Chinner <[EMAIL PROTECTED]>

---
 fs/xfs/linux-2.6/xfs_fs_subr.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_fs_subr.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_fs_subr.c   2007-01-23 
18:42:46.0 +1100
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_fs_subr.c2007-01-23 
18:44:53.955160806 +1100
@@ -32,7 +32,8 @@ fs_tosspages(
struct inode*ip = vn_to_inode(vp);
 
if (VN_CACHED(vp))
-   truncate_inode_pages(ip->i_mapping, first);
+   truncate_unmap_inode_pages_range(ip->i_mapping,
+   first, last, 1);
 }
 
 void
@@ -49,7 +50,8 @@ fs_flushinval_pages(
if (VN_TRUNC(vp))
VUNTRUNCATE(vp);
filemap_write_and_wait(ip->i_mapping);
-   truncate_inode_pages(ip->i_mapping, first);
+   truncate_unmap_inode_pages_range(ip->i_mapping,
+   first, last, 1);
}
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2]: Fix BUG in cancel_dirty_pages on XFS

[David Chinner]

With the recent changes to cancel_dirty_pages(), XFS will
dump warnings in the syslog because it can truncate_inode_pages()
on dirty mapped pages.

I've determined that this is indeed correct behaviour for XFS
as this can happen in the case of races on mmap()d files with
direct I/O. In this case when we do a direct I/O read, we
flush the dirty pages to disk, then truncate them out of the
page cache. Unfortunately, between the flush and the truncate
the mmap could dirty the page again. At this point we toss a
dirty page that is mapped.

None of the existing functions for truncating pages or invalidating
pages work in this situation. Invalidating a page only works for
non-dirty pages with non-dirty buffers, and they only work for
whole pages and XFS requires partial page truncation.

On top of that the page invalidation functions don't actually
call into the filesystem to invalidate the page and so the filesystem
can't actually invalidate the page properly (e.g. do stuff based on
private buffer head flags).

So that leaves us needing to use truncate semantics an the problem
is that none of them unmap pages in a non-racy manner - if they
unmap pages they do it separately tothe truncate of the page,
leading to races with mmap redirtying the page between the unmap and
the truncate ofthe page.

Hence we need a truncate function that unmaps the pages while they
are locked for truncate in a similar fashion to
invalidate_inode_pages2_range(). The following patch (unchanged from
the last time it was sent) does this. The XFS changes are in a
second patch.

The patch has been test on ia64 and x86-64 via XFSQA and a lot
of fsx mixing mmap and direct I/O operations.

Signed-off-by: Dave Chinner <[EMAIL PROTECTED]>

---
 
Index: 2.6.x-xfs-new/include/linux/mm.h
===
--- 2.6.x-xfs-new.orig/include/linux/mm.h   2007-01-15 15:09:57.0 
+1100
+++ 2.6.x-xfs-new/include/linux/mm.h2007-01-16 08:59:24.031897743 +1100
@@ -1060,6 +1060,8 @@ extern unsigned long page_unuse(struct p
 extern void truncate_inode_pages(struct address_space *, loff_t);
 extern void truncate_inode_pages_range(struct address_space *,
   loff_t lstart, loff_t lend);
+extern void truncate_unmap_inode_pages_range(struct address_space *,
+  loff_t lstart, loff_t lend, int unmap);
 
 /* generic vm_area_ops exported for stackable file systems */
 extern struct page *filemap_nopage(struct vm_area_struct *, unsigned long, int 
*);
Index: 2.6.x-xfs-new/mm/truncate.c
===
--- 2.6.x-xfs-new.orig/mm/truncate.c2007-01-16 08:59:23.947908876 +1100
+++ 2.6.x-xfs-new/mm/truncate.c 2007-01-16 09:35:53.102924243 +1100
@@ -59,7 +59,7 @@ void cancel_dirty_page(struct page *page
 
WARN_ON(++warncount < 5);
}
-   
+
if (TestClearPageDirty(page)) {
struct address_space *mapping = page->mapping;
if (mapping && mapping_cap_account_dirty(mapping)) {
@@ -122,16 +122,34 @@ invalidate_complete_page(struct address_
return ret;
 }
 
+/*
+ * This is a helper for truncate_unmap_inode_page. Unmap the page we
+ * are passed. Page must be locked by the caller.
+ */
+static void
+unmap_single_page(struct address_space *mapping, struct page *page)
+{
+   BUG_ON(!PageLocked(page));
+   while (page_mapped(page)) {
+   unmap_mapping_range(mapping,
+   (loff_t)page->index << PAGE_CACHE_SHIFT,
+   PAGE_CACHE_SIZE, 0);
+   }
+}
+
 /**
- * truncate_inode_pages - truncate range of pages specified by start and
+ * truncate_unmap_inode_pages_range - truncate range of pages specified by
+ * start and end byte offsets and optionally unmap them first.
  * end byte offsets
  * @mapping: mapping to truncate
  * @lstart: offset from which to truncate
  * @lend: offset to which to truncate
+ * @unmap: unmap whole truncated pages if non-zero
  *
  * Truncate the page cache, removing the pages that are between
  * specified offsets (and zeroing out partial page
- * (if lstart is not page aligned)).
+ * (if lstart is not page aligned)). If specified, unmap the pages
+ * before they are removed.
  *
  * Truncate takes two passes - the first pass is nonblocking.  It will not
  * block on page locks and it will not block on writeback.  The second pass
@@ -146,8 +164,8 @@ invalidate_complete_page(struct address_
  * mapping is large, it is probably the case that the final pages are the most
  * recently touched, and freeing happens in ascending file offset order.
  */
-void truncate_inode_pages_range(struct address_space *mapping,
-   loff_t lstart, loff_t lend)
+void truncate_unmap_inode_pages_range(struct address_space *mapping,
+   loff_t lstart, loff_t lend, int unmap)
 {
const pgoff_t