Re: [RFC] Tracking mlocked pages and moving them off the LRU

[Christoph Lameter]

Hmmm.. I have had no time to test this one yet but I think this should 
work. It uses the delayed method and a new page flag PageMlocked() with 
different semantics. Fix for page migration is also included.

Patch avoids to put new anonymous mlocked pages on the LRU. Maybe the same 
could be done for new pagecache pages?

I still need a solution for the problem of not having enough page flag 
bits on i386 NUMA.


Index: current/mm/vmscan.c
===
--- current.orig/mm/vmscan.c2007-02-03 10:53:15.0 -0800
+++ current/mm/vmscan.c 2007-02-04 22:59:01.0 -0800
@@ -516,10 +516,11 @@ static unsigned long shrink_page_list(st
if (page_mapped(page) && mapping) {
switch (try_to_unmap(page, 0)) {
case SWAP_FAIL:
-   case SWAP_MLOCK:
goto activate_locked;
case SWAP_AGAIN:
goto keep_locked;
+   case SWAP_MLOCK:
+   goto mlocked;
case SWAP_SUCCESS:
; /* try to free the page below */
}
@@ -594,6 +595,14 @@ free_it:
__pagevec_release_nonlru(&freed_pvec);
continue;
 
+mlocked:
+   ClearPageActive(page);
+   unlock_page(page);
+   __inc_zone_page_state(page, NR_MLOCK);
+   smp_wmb();
+   SetPageMlocked(page);
+   continue;
+
 activate_locked:
SetPageActive(page);
pgactivate++;
Index: current/mm/memory.c
===
--- current.orig/mm/memory.c2007-02-03 10:52:37.0 -0800
+++ current/mm/memory.c 2007-02-04 23:48:36.0 -0800
@@ -682,6 +682,8 @@ static unsigned long zap_pte_range(struc
file_rss--;
}
page_remove_rmap(page, vma);
+   if (PageMlocked(page) && vma->vm_flags & VM_LOCKED)
+   lru_cache_add_mlock(page);
tlb_remove_page(tlb, page);
continue;
}
@@ -898,6 +900,25 @@ unsigned long zap_page_range(struct vm_a
 }
 
 /*
+ * Add a new anonymous page
+ */
+void anon_add(struct vm_area_struct *vma, struct page *page,
+   unsigned long address)
+{
+   inc_mm_counter(vma->vm_mm, anon_rss);
+   if (vma->vm_flags & VM_LOCKED) {
+   /*
+* Page is new and therefore not on the LRU
+* so we can directly mark it as mlocked
+*/
+   SetPageMlocked(page);
+   inc_zone_page_state(page, NR_MLOCK);
+   } else
+   lru_cache_add_active(page);
+   page_add_new_anon_rmap(page, vma, address);
+}
+
+/*
  * Do a quick page-table lookup for a single page.
  */
 struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
@@ -2101,9 +2122,7 @@ static int do_anonymous_page(struct mm_s
page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
if (!pte_none(*page_table))
goto release;
-   inc_mm_counter(mm, anon_rss);
-   lru_cache_add_active(page);
-   page_add_new_anon_rmap(page, vma, address);
+   anon_add(vma, page, address);
} else {
/* Map the ZERO_PAGE - vm_page_prot is readonly */
page = ZERO_PAGE(address);
@@ -2247,11 +2266,9 @@ retry:
if (write_access)
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
set_pte_at(mm, address, page_table, entry);
-   if (anon) {
-   inc_mm_counter(mm, anon_rss);
-   lru_cache_add_active(new_page);
-   page_add_new_anon_rmap(new_page, vma, address);
-   } else {
+   if (anon)
+   anon_add(vma, new_page, address);
+   else {
inc_mm_counter(mm, file_rss);
page_add_file_rmap(new_page);
if (write_access) {
Index: current/drivers/base/node.c
===
--- current.orig/drivers/base/node.c2007-02-03 10:52:35.0 -0800
+++ current/drivers/base/node.c 2007-02-03 10:53:25.0 -0800
@@ -60,6 +60,7 @@ static ssize_t node_read_meminfo(struct 
   "Node %d FilePages:%8lu kB\n"
   "Node %d Mapped:   %8lu kB\n"
   "Node %d AnonPages:%8lu kB\n"
+  "Node %d Mlock:%8lu KB\n"
   "Node %d PageTables:   %8lu kB\n"
  

Re: [PATCH 1/3] Blackfin: architecture patch against Linux kernel 2.6.20

[Ben Nizette]

Wu, Bryan wrote:

Hi everyone,

This is the Blackfin architecture patch against Linux kernel 2.6.20,
again. As we promised, some issues are fixed in the latest release with
the help from lkml.

The blackfin-arch patch is at 
https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc

h-linux-2.6.20.patch


Hi!  Your mail client is monstering your emails to make them fit 70 
cols.  Kinda playing havoc with the diffstats and URLs here and the 
patches in the other emails in this series.  See if you can fix this and 
at least resend the patches in the other 2 emails.  Much easier to 
review then.


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

v2.6.20-rt1, yum/rpm

[Ingo Molnar]

i have released the v2.6.20-rt1 kernel, which can be downloaded from the 
usual place:

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

more info about the -rt patchset can be found in the RT wiki:

  http://rt.wiki.kernel.org

This is a fixes-only release. Since the -rt tree has been closely 
tracking Linus' upstream kernel since -rc1, no new issues are expected - 
please re-report if anything is still unfixed.

There are lots of changes relative to 2.6.19-rt6 (the last stable 
release), but these are mostly fixes and other gradual improvements. KVM
is now enabled in the yum kernel on both i686 and x86_64 (and has been
enabled since around -rc1-rt1), the -rt tree tracks kvm-trunk (which is
a bit fresher than upstream KVM) and has a few additional paravirt
speedups implemented and enabled.

to build a 2.6.20-rt1 tree, the following patches should be applied:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.tar.bz2
  http://redhat.com/~mingo/realtime-preempt/patch-2.6.20-rt1

the -rt YUM repository for Fedora Core 6 and 5, for architectures i686 
and x86_64 can be activated via:

   cd /etc/yum.repos.d
   wget http://people.redhat.com/~mingo/realtime-preempt/rt.repo

   yum install kernel-rt.x86_64   # on x86_64
   yum install kernel-rt  # on i686

   yum update kernel-rt   # refresh - or enable yum-updatesd

as usual, bugreports, fixes and suggestions are welcome,

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/

[PATCH 1/3] Blackfin: architecture patch against Linux kernel 2.6.20

[Wu, Bryan]

Hi everyone,

This is the Blackfin architecture patch against Linux kernel 2.6.20,
again. As we promised, some issues are fixed in the latest release with
the help from lkml.

The blackfin-arch patch is at 
https://blackfin.uclinux.org/gf/download/frsrelease/25/2490/blackfin-arc
h-linux-2.6.20.patch
Which, at 1.9M bytes, is too large to attach here. Please let me know if
you want me to do it anyway.

I understand that a full review is a huge job, but I'd appreciate a
pointer or two in the general direction that I need to take this in
order to get it acceptable for mainline.

Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 arch/blackfin/Kconfig  |  891 +++
 arch/blackfin/Makefile |   81 
 arch/blackfin/boot/Makefile|   27 
 arch/blackfin/defconfig| 1314 +++
 arch/blackfin/kernel/Makefile  |   13 
 arch/blackfin/kernel/asm-offsets.c |  138 +
 arch/blackfin/kernel/bfin_dma_5xx.c|  747 ++
 arch/blackfin/kernel/bfin_gpio.c   |  654 +
 arch/blackfin/kernel/bfin_ksyms.c  |  115 
 arch/blackfin/kernel/dma-mapping.c |  174 +
 arch/blackfin/kernel/dualcore_test.c   |   51 
 arch/blackfin/kernel/entry.S   |   92 
 arch/blackfin/kernel/init_task.c   |   63 
 arch/blackfin/kernel/irqchip.c |  144 +
 arch/blackfin/kernel/module.c  |  431 +++
 arch/blackfin/kernel/process.c |  348 ++
 arch/blackfin/kernel/ptrace.c  |  413 +++
 arch/blackfin/kernel/setup.c   |  894 +++
 arch/blackfin/kernel/signal.c  |  431 +++
 arch/blackfin/kernel/sys_bfin.c|  133 +
 arch/blackfin/kernel/time.c|  326 ++
 arch/blackfin/kernel/traps.c   |  622 +
 arch/blackfin/kernel/vmlinux.lds.S |  221 +
 arch/blackfin/lib/Makefile |   10 
 arch/blackfin/lib/ashldi3.c|   56 
 arch/blackfin/lib/ashrdi3.c|   57 
 arch/blackfin/lib/checksum.c   |  138 +
 arch/blackfin/lib/divsi3.S |  156 +
 arch/blackfin/lib/gcclib.h |   49 
 arch/blackfin/lib/ins.S|   71 
 arch/blackfin/lib/lshrdi3.c|   70 
 arch/blackfin/lib/memchr.S |   65 
 arch/blackfin/lib/memcmp.S |  110 
 arch/blackfin/lib/memcpy.S |  129 +
 arch/blackfin/lib/memmove.S|  103 
 arch/blackfin/lib/memset.S |  103 
 arch/blackfin/lib/modsi3.S |   74 
 arch/blackfin/lib/muldi3.c |   97 
 arch/blackfin/lib/outs.S   |   64 
 arch/blackfin/lib/strcmp.c |   11 
 arch/blackfin/lib/strcpy.c |   11 
 arch/blackfin/lib/strncmp.c|   11 
 arch/blackfin/lib/strncpy.c|   11 
 arch/blackfin/lib/udivsi3.S|  157 +
 arch/blackfin/lib/umodsi3.S|   63 
 arch/blackfin/mach-bf533/Kconfig   |   92 
 arch/blackfin/mach-bf533/Makefile  |9 
 arch/blackfin/mach-bf533/boards/Makefile   |8 
 arch/blackfin/mach-bf533/boards/cm_bf533.c |  271 ++
 arch/blackfin/mach-bf533/boards/ezkit.c|  231 +
 arch/blackfin/mach-bf533/boards/generic_board.c|   97 
 arch/blackfin/mach-bf533/boards/stamp.c|  328 ++
 arch/blackfin/mach-bf533/cpu.c |  163 +
 arch/blackfin/mach-bf533/head.S|  776 ++
 arch/blackfin/mach-bf533/ints-priority.c   |   67 
 arch/blackfin/mach-bf537/Kconfig   |  141 +
 arch/blackfin/mach-bf537/Makefile  |9 
 arch/blackfin/mach-bf537/boards/Makefile   |8 
 arch/blackfin/mach-bf537/boards/cm_bf537.c |  379 +++
 arch/blackfin/mach-bf537/boards/generic_board.c|  464 +++
 arch/blackfin/mach-bf537/boards/led.S  |  183 +
 arch/blackfin/mach-bf537/boards/pnav10.c   |  541 
 arch/blackfin/mach-bf537/boards/stamp.c|  575 
 arch/blackfin/mach-bf537/cpu.c |  163 +
 arch/blackfin/mach-bf537/head.S|  605 +
 arch/blackfin/mach-bf537/ints-priority.c   |   76 
 arch/blackfin/mach-bf561/Kconfig   |  222 +
 arch/blackfin/mach-bf561/Makefile  |9 
 arch/blackfin/mach-bf561/boards/Makefile   |6 
 arch/blackfin/mach-bf561/boards/cm_bf561.c |  295 ++
 arch/blackfin/mach-bf561/boards/ezkit.c|  151 +
 arch/bl

[PATCH 3/3] Blackfin: documents and maintainer patch

[Wu, Bryan]

Hi everyone,

This is the documents patche for Blackfin arch, also includes the
MAINTAINERS file change.

Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 Documentation/blackfin/00-INDEX  |   11 ++
 Documentation/blackfin/Filesystems   |  169
+++
 Documentation/blackfin/cache-lock.txt|   48 
 Documentation/blackfin/cachefeatures.txt |   65 +++
 MAINTAINERS  |   34 ++
 5 files changed, 327 insertions(+)
Index: git-merge/linux-2.6/Documentation/blackfin/00-INDEX
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ git-merge/linux-2.6/Documentation/blackfin/00-INDEX 2007-02-05
19:51:15.0 +0800
@@ -0,0 +1,11 @@
+00-INDEX
+   - This file
+
+cache-lock.txt
+   - HOWTO for blackfin cache locking.
+
+cachefeatures.txt
+   - Supported cache features.
+
+Filesystems
+   - Requirements for mounting the root file system.
Index: git-merge/linux-2.6/Documentation/blackfin/Filesystems
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ git-merge/linux-2.6/Documentation/blackfin/Filesystems
2007-02-05 19:51:15.0 +0800
@@ -0,0 +1,169 @@
+/*
+ * File: Documentation/blackfin/Filesystems
+ * Based on:
+ * Author:
+ *
+ * Created:
+ * Description:  This file contains the simple DMA Implementation for
Blackfin
+ *
+ * Rev:  $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $
+ *
+ * Modified:
+ *   Copyright 2004-2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ */
+
+   How to mount the root file system in uClinux/Blackfin
+   -
+
+1  Mounting EXT3 File system.
+   
+
+   Creating an EXT3 File system for uClinux/Blackfin:
+
+
+Please follow the steps to form the EXT3 File system and mount the same
as root
+file system.
+
+a  Make an ext3 file system as large as you want the final root
file
+   system.
+
+   mkfs.ext3  /dev/ram0 
+
+b  Mount this Empty file system on a free directory as:
+
+   mount -t ext3 /dev/ram0  ./test
+   where ./test is the empty directory.
+
+c  Copy your root fs directory that you have so carefully made
over.
+
+   cp -af  /tmp/my_final_rootfs_files/* ./test
+
+   (For ex: cp -af uClinux-dist/romfs/* ./test)
+
+d  If you have done everything right till now you should be able to
see
+   the required "root" dir's (that's etc, root, bin, lib, sbin...)
+
+e  Now unmount the file system
+
+   umount  ./test
+
+f  Create the root file system image.
+
+   dd if=/dev/ram0 bs=1k
count= \
+   > ext3fs.img
+
+
+Now you have to tell the kernel that will be mounting this file system
as
+rootfs.
+So do a make menuconfig under kernel and select the Ext3 journaling
file system
+support under File system --> submenu.
+
+
+2. Mounting EXT2 File system.
+   -
+
+By default the ext2 file system image will be created if you invoke
make from
+the top uClinux-dist directory.
+
+
+3. Mounting CRAMFS File System
+   
+
+To create a CRAMFS file system image execute the command
+
+   mkfs.cramfs ./test cramfs.img
+
+   where ./test is the target directory.
+
+
+4. Mounting ROMFS File System
+   --
+
+To create a ROMFS file system image execute the command
+
+   genromfs -v -V "ROMdisk" -f romfs.img -d ./test
+
+   where ./test is the target directory
+
+
+5. Mounting the JFFS2 Filesystem
+   -
+
+To create a compressed JFFS filesystem (JFFS2), please execute the
command
+
+   mkfs.jffs2 -d ./test -o jffs2.img
+
+   where ./test is the target directory.
+
+However, please make sure the following is in your kernel config.
+
+/*
+ * RAM/ROM/Flash chip drivers
+ */
+#define CONFIG_MTD_CFI 1
+#define CONFIG_MTD_ROM 1
+/*
+ * Mapping drivers for chip access
+ */
+#define CONFIG_MTD_COMPLEX_MAPPINGS 1
+#define CONFIG_MTD_BF533 1
+#undef CONFIG_MTD_UCLINUX
+
+Through the u-boot boot loader, use the jffs2.img in the corresponding
+partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c.
+
+NOTE - Currently the Flash driver is available only for EZKIT.
Watch out for a
+   STAMP driver soon.
+
+
+6. Mounting the NFS File system
+   -
+
+   For mounting the NFS please do the following in the kernel
config.
+
+   In Networking Support --> Networking options --> TCP/IP
networking -->
+   IP: kernel level autoconfiguration
+
+   Enable BOOTP Support.
+
+   In Kernel hacking --> Compiled-in kernel boot parameter add the
follow

[PATCH 2/3] Blackfin: serial driver for Blackfin architecture against Linux kernel 2.6.20

[Wu, Bryan]

Hi everyone,

This is the serial driver supports Blackfin processors. It is designed
for the serial core framework.

Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
---
 drivers/serial/Kconfig  |   94 
 drivers/serial/Makefile |1
 drivers/serial/bfin_5xx.c   | 1029

 include/linux/serial_core.h |3
 4 files changed, 1127 insertions(+)
Index: git-merge/linux-2.6/drivers/serial/Kconfig
===
--- git-merge.orig/linux-2.6/drivers/serial/Kconfig 2007-02-05
18:56:04.0 +0800
+++ git-merge/linux-2.6/drivers/serial/Kconfig  2007-02-05
19:10:58.0 +0800
@@ -498,6 +498,100 @@
  your boot loader (lilo or loadlin) about how to pass options
to the
  kernel at boot time.)
 
+config SERIAL_BFIN
+   tristate "Blackfin serial port support (EXPERIMENTAL)"
+   depends on BFIN && EXPERIMENTAL
+   select SERIAL_CORE
+   select SERIAL_BFIN_UART0 if (BF531 || BF532 || BF533 || BF561)
+   help
+ Add support for the built-in UARTs on the Blackfin.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bfin_5xx.
+
+config SERIAL_BFIN_CONSOLE
+   bool "Console on Blackfin serial port"
+   depends on SERIAL_BFIN
+   select SERIAL_CORE_CONSOLE
+
+choice
+   prompt  "Blackfin UART Mode"
+   depends on SERIAL_BFIN
+   default SERIAL_BFIN_DMA
+   help
+ This driver supports the built-in serial ports of the Blackfin
family
+ of CPUs
+
+config SERIAL_BFIN_DMA
+   bool "Blackfin UART DMA mode"
+   depends on DMA_UNCACHED_1M
+   help
+ This driver works under DMA mode. If this option is selected,
the
+ blackfin simple dma driver is also enabled.
+
+config SERIAL_BFIN_PIO
+   bool "Blackfin UART PIO mode"
+   help
+ This driver works under PIO mode.
+
+endchoice
+
+config SERIAL_BFIN_UART0
+   bool "Enable UART0"
+   depends on SERIAL_BFIN
+   help
+ Enable UART0
+
+config BFIN_UART0_CTSRTS
+   bool "Enable UART0 hardware flow control"
+   depends on SERIAL_BFIN_UART0
+   help
+ Enable hardware flow control in the driver. Using GPIO emulate
the CTS/RTS
+ signal.
+
+config UART0_CTS_PIN
+   int "UART0 CTS pin"
+   depends on BFIN_UART0_CTSRTS
+   default 23
+   help
+ The default pin is GPIO_GP7.
+ Refer to ./include/asm-blackfin/gpio.h to see the GPIO map.
+
+config UART0_RTS_PIN
+   int "UART0 RTS pin"
+   depends on BFIN_UART0_CTSRTS
+   default 22
+   help
+ The default pin is GPIO_GP6.
+ Refer to ./include/asm-blackfin/gpio.h to see the GPIO map.
+
+config SERIAL_BFIN_UART1
+   bool "Enable UART1"
+   depends on SERIAL_BFIN && BF537
+   help
+ Enable UART1
+
+config BFIN_UART1_CTSRTS
+   bool "Enable UART1 hardware flow control"
+   depends on SERIAL_BFIN_UART1
+   help
+ Enable hardware flow control in the driver. Using GPIO emulate
the CTS/RTS
+ signal.
+
+config UART1_CTS_PIN
+   int "UART1 CTS pin"
+   depends on BFIN_UART1_CTSRTS
+   default -1
+   help
+ Refer to ./include/asm-blackfin/gpio.h to see the GPIO map.
+
+config UART1_RTS_PIN
+   int "UART1 RTS pin"
+   depends on BFIN_UART1_CTSRTS
+   default -1
+   help
+ Refer to ./include/asm-blackfin/gpio.h to see the GPIO map.
+
 config SERIAL_IMX
bool "IMX serial port support"
depends on ARM && ARCH_IMX
Index: git-merge/linux-2.6/drivers/serial/Makefile
===
--- git-merge.orig/linux-2.6/drivers/serial/Makefile2007-02-05
18:56:04.0 +0800
+++ git-merge/linux-2.6/drivers/serial/Makefile 2007-02-05
19:10:58.0 +0800
@@ -26,6 +26,7 @@
 obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
 obj-$(CONFIG_SERIAL_PXA) += pxa.o
 obj-$(CONFIG_SERIAL_SA1100) += sa1100.o
+obj-$(CONFIG_SERIAL_BFIN) += bfin_5xx.o
 obj-$(CONFIG_SERIAL_S3C2410) += s3c2410.o
 obj-$(CONFIG_SERIAL_SUNCORE) += suncore.o
 obj-$(CONFIG_SERIAL_SUNHV) += sunhv.o
Index: git-merge/linux-2.6/drivers/serial/bfin_5xx.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ git-merge/linux-2.6/drivers/serial/bfin_5xx.c   2007-02-05
19:14:21.0 +0800
@@ -0,0 +1,1029 @@
+/*
+ * File: drivers/serial/bfin_5xx.c
+ * Based on: Based on drivers/serial/sa1100.c
+ * Author:   Aubrey Li <[EMAIL PROTECTED]>
+ *
+ * Created:
+ * Description:  Driver for blackfin 5xx serial ports
+ *
+ * Rev:  $Id: bfin_5xx.c,v 1.19 2006/09/24 02:33:53 aubrey Exp
$
+ *
+ * Modified:
+ *   Copyright 2006 Analog Devices Inc.
+ *
+ * Bugs: Enter bugs at http://blackfin.uclinux.org/
+ *
+ * This program is free software; you can redistribut

Re: 2.6.19.2 oops after resume from ram (corruption?)

[Luming Yu]

On 2/1/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:

On Thu, 2007-02-01 at 08:42 +1100, Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2007-01-31 at 11:56 +0100, Mike Galbraith wrote:
> > Greetings,
> >
> > I received the below upon first poke of firefox icon after a resume.
>
> Are you able to reproduce it reliably? Failing that, could you try
> enabling some the kernel configuration options that help with debugging
> memory corruption (slab corruption checking in particular will probably
> be the most useful thing here).

No, it's a never before seen event.  That said, I have had a couple of
dead box after resume events with other kernels in the last few months,
so I may have had corruption of a more deadly variety.  Unfortunately,
when I'm resuming, my serial console box is almost guaranteed to be off.


if you have dead serial console, or no serial console at all on you
laptop. Probably you can try the alternative of firewire with
http://www.suse.de/~bk/firewire/
Ah,  linux S3 resume is still a problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regarding generic AIO, async syscalls precedent + some benchmarks by lighttpd

[Christopher Smith]

Davide Libenzi wrote:
Yes, that is some very interesting data IMO. I did not bench the GUASI 
(userspace async thread library) against AIO, but those numbers show that a 
*userspace* async syscall wrapper interface performs in the ballpark of AIO.
This leads to some hope about the ability to effectively deploy the kernel 
generic async AIO (being it fibril or kthreads based) as low-impact async 
provider for basically anything.
  


SGI's kaio patch to linux kind of went that route (using kthreads) for 
non-SCSI async IO. It wasn't a bad way to go, but at least for 
disk-based access they achieved much better results when they could go 
right to the hardware.


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

Re: 2.6.19.2 oops after resume from ram (corruption?)

[Mike Galbraith]

On Sun, 2007-02-04 at 16:43 +0100, Pavel Machek wrote:
> Hi!
> 
> > I received the below upon first poke of firefox icon after a resume.  
> > 
> > See attachment (evolution refuses to inline it).
> 
> Is it repeatable? You may want to try with smaller set of
> modules... prism54 is quite unusual...

Nope, rogue event... so far.  Prism54 is my wlan card.  (useless dang
thing, can't convince it to do encryption)

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Tracking mlocked pages and moving them off the LRU

[Christoph Lameter]

On Sun, 4 Feb 2007, Arjan van de Ven wrote:

> 
> > Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty 
> > ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on 
> > mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific 
> > number of mlocked pages. The nice thing about ZVCs is that it allows
> > easy access to counts on different levels.
> 
> however... mlocked pages still can be dirty, and want to be written back
> at some point ;)

Yes that is why we need to add them to the count of total pages.
 
> I can see the point of doing dirty ratio as percentage of the LRU size,
> but in that case you don't need to track NR_MLOCK, only the total LRU
> size. (And yes it'll be sometimes optimistic because not all mlock'd
> pages are moved off the lru yet, but I doubt you'll have that as a
> problem in practice)

The dirty ratio with the ZVCS would be

NR_DIRTY + NR_UNSTABLE_NFS
/ 
NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK


I think we need a PageMlocked after all for the delayed NR_MLOCK 
approach but it needs to have different semantics in order to make
it work. With the patch that I posted earlier we could actually return
a page to the LRU in zap_pte_range while something else is keeping
a page off the LRU (i.e. Page migration is occurring and suddenly the 
page is reclaimed since zap_pte_range put it back). So PageMlocked needs 
to be set in shrink_list() in order to clarify that the page was taken 
off the LRU lists due to it being mlocked and not for other reasons. 
zap_pte_range then needs to check for PageMlocked before putting the 
page onto the LRU.

If we do that then we can observer the state transitions and have an 
accurate count. The delayed accounting problem can probably be 
somewhat remedied by putting new mlocked pages not on the LRU and 
counting them directly. Page migration can simply clear the PageMlocked 
bit and then treat the page as if it was taken off the LRU.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kexec: Fix CONFIG_SMP=n compilation V2 (ia64)

[Magnus Damm]

kexec: Fix CONFIG_SMP=n compilation V2 (ia64)

Kexec support for 2.6.20 on ia64 does not build properly using a config
made up by CONFIG_SMP=n and CONFIG_HOTPLUG_CPU=n:

  CC  arch/ia64/kernel/machine_kexec.o
arch/ia64/kernel/machine_kexec.c: In function `machine_shutdown':
arch/ia64/kernel/machine_kexec.c:77: warning: implicit declaration of function 
`cpu_down'
  AS  arch/ia64/kernel/relocate_kernel.o
  CC  arch/ia64/kernel/crash.o
arch/ia64/kernel/crash.c: In function `kdump_cpu_freeze':
arch/ia64/kernel/crash.c:139: warning: implicit declaration of function 
`ia64_jump_to_sal'
arch/ia64/kernel/crash.c:139: error: `sal_boot_rendez_state' undeclared (first 
use in this function)
arch/ia64/kernel/crash.c:139: error: (Each undeclared identifier is reported 
only once
arch/ia64/kernel/crash.c:139: error: for each function it appears in.)
arch/ia64/kernel/crash.c: At top level:
arch/ia64/kernel/crash.c:84: warning: 'kdump_wait_cpu_freeze' defined but not 
used
make[1]: *** [arch/ia64/kernel/crash.o] Error 1
make: *** [arch/ia64/kernel] Error 2

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
---

 Applies on top of 2.6.20.

 arch/ia64/kernel/crash.c |   11 +++
 arch/ia64/kernel/machine_kexec.c |2 ++
 2 files changed, 9 insertions(+), 4 deletions(-)

--- 0002/arch/ia64/kernel/crash.c
+++ work/arch/ia64/kernel/crash.c   2007-02-02 20:31:18.0 +0900
@@ -79,6 +79,7 @@ crash_save_this_cpu()
final_note(buf);
 }
 
+#ifdef CONFIG_SMP
 static int
 kdump_wait_cpu_freeze(void)
 {
@@ -91,6 +92,7 @@ kdump_wait_cpu_freeze(void)
}
return 1;
 }
+#endif
 
 void
 machine_crash_shutdown(struct pt_regs *pt)
@@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
atomic_inc(&kdump_cpu_freezed);
kdump_status[cpuid] = 1;
mb();
-   if (cpuid == 0) {
-   for (;;)
-   cpu_relax();
-   } else
+#ifdef CONFIG_HOTPLUG_CPU
+   if (cpuid != 0)
ia64_jump_to_sal(&sal_boot_rendez_state[cpuid]);
+#endif
+   for (;;)
+   cpu_relax();
 }
 
 static int
--- 0002/arch/ia64/kernel/machine_kexec.c
+++ work/arch/ia64/kernel/machine_kexec.c   2007-02-02 20:56:24.0 
+0900
@@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
 
 void machine_shutdown(void)
 {
+#ifdef CONFIG_HOTPLUG_CPU
int cpu;
 
for_each_online_cpu(cpu) {
if (cpu != smp_processor_id())
cpu_down(cpu);
}
+#endif
kexec_disable_iosapic();
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Intel chooses not to support its HECI/QPS Chip in Linux?

[Arjan van de Ven]

On Sun, 2007-02-04 at 10:57 -0500, Justin Piszcz wrote:
> Hi,
> 
> Anyone from Intel that reads LKML, could you provide an update as to what 
> is happening with support for your HECI Controller/QPS chip, which is used 
> on 965 (and possibly other?) chipsets.

I asked the right folks and the word I got was "Soon". The code we have
needs some major cleanups before it's suitable for lkml posting... but
it'll be there soon. We're working on the cleanups full time We'll
send an update when we're further along
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)

[Magnus Damm]

On 2/3/07, Horms <[EMAIL PROTECTED]> wrote:

On Fri, Feb 02, 2007 at 08:53:00PM +0900, Magnus Damm wrote:
> On 2/2/07, Magnus Damm <[EMAIL PROTECTED]> wrote:
> > On 2/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > Magnus Damm <[EMAIL PROTECTED]> wrote:
> > >
> > > > kexec: Fix CONFIG_SMP=n compilation (ia64)
> > > >
> > > > This patch makes it possible to compile kexec for ia64 without SMP 
support.
> > > > --- 0002/arch/ia64/kernel/machine_kexec.c
> > > > +++ work/arch/ia64/kernel/machine_kexec.c 2007-02-01 
12:35:46.0 +0900
> > > > @@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
> > > >
> > > >  void machine_shutdown(void)
> > > >  {
> > > > +#ifdef CONFIG_SMP
> > > >   int cpu;
> > > >
> > > >   for_each_online_cpu(cpu) {
> > > >   if (cpu != smp_processor_id())
> > > >   cpu_down(cpu);
> > > >   }
> > > > +#endif
> > > >   kexec_disable_iosapic();
> > > >  }
> > >
> > > hm.  I suspect this one should have been #ifndef CONFIG_HOTPLUG_CPU?
>
> Re-reading this I assume you mean #ifdef CONFIG_HOTPLUG_CPU.
>
> I would be happy to resend a new updated version of the patch, but I
> wonder if it may be better to fail miserably during the build than
> fail silently in the case of CONFIG_SMP=y but CONFIG_HOTPLUG_CPU=n.

There used to be alternate code for the CONFIG_SMP +
!CONFIG_HOTPLUG_CPU, but this was removed because it was determined to
be flakey and not maintainable (I can dig up the threads if you want).
I think that this means that if we have CONFIG_KEXEC and CONFIG_SMP then
CONFIG_HOTPLUG_CPU is required. I think this is expressable in Kconfig
somehow.


My mistake, the following lines from linux-2.6.20/arch/ia64/Kconfig
seem to handle this case already:

config KEXEC
bool "kexec system call (EXPERIMENTAL)"
depends on EXPERIMENTAL && !IA64_HP_SIM && (!SMP || HOTPLUG_CPU)

I'll send an updated patch in a short while. Thanks!

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

Re: 2.6.20 -- Loads of section mismatches

[Vivek Goyal]

On Mon, Feb 05, 2007 at 12:06:47AM +0200, Alon Bar-Lev wrote:
> On 2/5/07, Miles Lane <[EMAIL PROTECTED]> wrote:
> >Are any of these worth fixing?
> 
> I am preparing a patch for this.
> I will submit it soon.
> 

Many of those warnings I have already fixed. I had posted quite a few
patches. Looks like some of these have not made into mainline yet.
For ex...

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/x86_64-mm-move-startup_32-in-texthead-section.patch

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc6/2.6.20-rc6-mm3/broken-out/x86_64-mm-break-init-in-two-parts-to-avoid-modpost-warnings.patch

I think I should trace the status of all the patches I had posted.

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

Re: forcedeth problems on 2.6.20-rc6-mm3

[Daniel Barkalow]

On Sun, 4 Feb 2007, Robert Hancock wrote:

> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to
> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get
> received and so the machine can't get an IP address. I tried reverting all the
> -mm changes to drivers/net/forcedeth.c, which didn't help. The network
> controller shares an IRQ with the USB OHCI controller which is receiving
> interrupts, so it doesn't seem like an interrupt routing problem, though I
> suppose something wierd could be happening there.

IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using 
it, but the kernel thinks enabling it didn't work? I think there's a 
module option for forcedeth to disable MSI, which might be worth a try to 
see if it has any effect.

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

what does "busses" (drivers/i2c/busses) mean?

[Conke Hu]

what does the directory name drivers/i2c/busses mean? did it mean bus(es)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: forcedeth problems on 2.6.20-rc6-mm3

[Andrew Morton]

On Sun, 04 Feb 2007 23:48:33 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:

> Andrew Morton wrote:
> > On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> > 
> >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 
> >> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get 
> >> received and so the machine can't get an IP address. I tried reverting 
> >> all the -mm changes to drivers/net/forcedeth.c, which didn't help. The 
> >> network controller shares an IRQ with the USB OHCI controller which is 
> >> receiving interrupts, so it doesn't seem like an interrupt routing 
> >> problem, though I suppose something wierd could be happening there.
> >>
> >> This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.
> >>
> >> Any suggestions on how to debug/what to try reverting to see what's 
> >> causing this?
> > 
> > There are many forcedeth changes in git-netdev-all.patch.  Can you
> > try reverting drivers/net/forcedeth.c back to the unpatched version
> > from 2.6.20-rc6?
> > 
> > Thanks.
> > 
> 
> That's essentially what I did, it didn't appear to help. I assume the
> problem must lie elsewhere..
> 

doh, I missed that.

It's presumably not the driver and nobody else seems to be hitting this, so
it must be something peculiar to your setup.  But I don't know what it
might be, sorry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

[Arjan van de Ven]

> > On the other side, the overhead you need to add for every single syscall
> > that might block for the M:N threads and the associated complications
> > which make it far harder to conform to POSIX IMHO far outweight the costs
> > of going into the kernel for a context switch.
> 
> That really wasn't my question, Arjan said that switching real threads 
> wasn't a context switch in the hardware sense, and I was asking if I 
> missed something.

a hardware context switch is basically a CR3 change with associated tlb
flush. That is the part that is the most expensive of a context switch.
Just going into the kernel and getting out with a different EIP/ESP is
really cheap, in the order of "a few hundred cycles"; not a heck of a
lot more expensive than a simple getpid or other simple system call.


>  It may be cheap, but it would seem to be a context 
> switch none-the-less.

it includes a privilege level switch, not so much a full context
switch...

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.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: Eeek! page_mapcount(page) went negative! (-1)

[David Liontooth]

Randy Dunlap wrote:
> On Sun, 04 Feb 2007 20:48:30 -0800 David Liontooth wrote:
>
>   
>> David Liontooth wrote:
>> 
>>> Running a script called thumbnails, which uses imagemagick's convert
>>> utility, I got this on a mainline 2.6.16.38:
>>>
>>> Feb  4 17:04:01 prato /USR/SBIN/CRON[17173]: (tna) CMD (thumbnails
>>> /db2/2006/2006-11/2006-11-16)
>>>
>>> Feb  4 17:20:49 prato kernel: swap_free: Unused swap offset entry 0080
>>> Feb  4 17:20:49 prato kernel: convert[23078]: segfault at
>>> 8000 rip 2b885c7d6590 rsp 7fa49308 error 4
>>> Feb  4 17:20:50 prato kernel: convert[23113]: segfault at
>>> 8010 rip 2b0914f305aa rsp 7f984340 error 4
>>>
>>> Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
>>> Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
>>> Feb  4 17:50:57 prato kernel: Eeek! page_mapcount(page) went negative! (-1)
>>> Feb  4 17:50:57 prato kernel:   page->flags = 100083c
>>> Feb  4 17:50:57 prato kernel:   page->count = 2
>>> Feb  4 17:50:57 prato kernel:   page->mapping = 81002604c670
>>> Feb  4 17:50:57 prato kernel: --- [cut here ] - [please
>>> bite here ] -
>>> Feb  4 17:50:57 prato kernel: Kernel BUG at mm/rmap.c:560
>>> Feb  4 17:50:57 prato kernel: invalid opcode:  [1] SMP
>>> Feb  4 17:50:57 prato kernel: CPU 1
>>> Feb 4 17:50:57 prato kernel: Modules linked in: lirc_serial lirc_dev
>>> saa7134_alsa tuner saa7134 video_buf compat_ioctl32 v4l2_common v4l1_compat
>>> ir_kbd_i2c ir_common videodev skge ehci_hcd ohci_hcd psmouse pcspkr evdev
>>> Feb  4 17:50:57 prato kernel: Pid: 29168, comm: thumbnails Tainted:
>>> GF 2.6.16.38 #1
>>> Feb  4 17:50:57 prato kernel: RIP: 0010:[]
>>> {page_remove_rmap+117}
>>> Feb  4 17:50:57 prato kernel: RSP: 0018:81000bc6dde8  EFLAGS: 00010286
>>> Feb  4 17:50:57 prato kernel: RAX:  RBX:
>>> 810001d1b290 RCX: 6507
>>> Feb  4 17:50:57 prato kernel: RDX: ff01 RSI:
>>> 0292 RDI: 80465dfc
>>> Feb  4 17:50:57 prato kernel: RBP: 3be9e000 R08:
>>>  R09: 0001
>>> Feb  4 17:50:57 prato kernel: R10: 0010 R11:
>>>  R12: 0062f000
>>> Feb  4 17:50:57 prato kernel: R13: 810015ed7178 R14:
>>> 006d6000 R15: 810001e12220
>>> Feb  4 17:50:57 prato kernel: FS:  2b444df8a6d0()
>>> GS:810001fc5ac0() knlGS:
>>> Feb  4 17:50:57 prato kernel: CS:  0010 DS:  ES:  CR0:
>>> 8005003b
>>> Feb  4 17:50:57 prato kernel: CR2: 2b444ddb61f0 CR3:
>>> 13f22000 CR4: 06e0
>>> Feb  4 17:50:57 prato kernel: Process thumbnails (pid: 29168, threadinfo
>>> 81000bc6c000, task 81003fe25160)
>>> Feb  4 17:50:57 prato kernel: Stack: 810001d1b290 801519da
>>>  81000bc6dec8
>>> Feb  4 17:50:57 prato kernel: 
>>> 81002955d648 81000bc6ded0
>>> Feb  4 17:50:57 prato kernel: 00012cf477b8
>>> Feb  4 17:50:57 prato kernel: Call Trace:
>>> {unmap_vmas+1012} {exit_mmap+120}
>>> Feb  4 17:50:57 prato kernel:{mmput+40}
>>> {do_exit+489}
>>> Feb  4 17:50:57 prato kernel:   
>>> {sys_exit_group+0} {system_call+126}
>>> Feb  4 17:50:57 prato kernel:
>>> Feb  4 17:50:57 prato kernel: Code: 0f 0b 68 f8 21 40 80 c2 30 02 5b 48
>>> 83 ce ff bf 20 00 00 00
>>> Feb  4 17:50:57 prato kernel: RIP
>>> {page_remove_rmap+117} RSP 
>>> Feb  4 17:50:57 prato kernel:  <1>Fixing recursive fault but reboot is
>>> needed!
>>> Feb  4 17:52:52 prato kernel: Bad page state in process 'kswapd0'
>>> Feb  4 17:52:52 prato kernel: page:810001d1b290
>>> flags:0x0108 mapping: mapcount:-1 count:0
>>> Feb  4 17:52:52 prato kernel: Trying to fix it up, but a reboot is needed
>>> Feb  4 17:52:52 prato kernel: Backtrace:
>>> Feb  4 17:52:52 prato kernel:
>>> Feb  4 17:52:52 prato kernel: Call Trace:
>>> {bad_page+80} {free_hot_cold_page+116}
>>> Feb  4 17:52:52 prato kernel:   
>>> {__pagevec_free+33}
>>> {__pagevec_release_nonlru+122}
>>> Feb  4 17:52:52 prato kernel:   
>>> {shrink_zone+2280} {balance_pgdat+527}
>>> Feb  4 17:52:52 prato kernel:{kswapd+265}
>>> {autoremove_wake_function+0}
>>> Feb  4 17:52:52 prato kernel:{child_rip+8}
>>> {kswapd+0}
>>> Feb  4 17:52:52 prato kernel:{child_rip+0}
>>>
>>> lspci
>>>
>>> 00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
>>> 00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
>>> 00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
>>> (rev a1)
>>> 00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
>>> 00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
>>> 00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
>>> Controller (rev

Re: [PATCH] note that dri-devel is subscribers-only

[Dave Airlie]

dri-devel is subscribers-only, so note that in MAINTAINERS.



It isn't subscribers only AFAIK, it is moderated so stuff does make it 
through eventually..


Dave.



Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
MAINTAINERS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2620-pv.orig/MAINTAINERS
+++ linux-2620-pv/MAINTAINERS
@@ -1126,7 +1126,7 @@ S:Supported
DRM DRIVERS
P:  David Airlie
M:  [EMAIL PROTECTED]
-L: dri-devel@lists.sourceforge.net
+L: dri-devel@lists.sourceforge.net (subscribers-only)
T:  git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
S:  Maintained




--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

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

Re: forcedeth problems on 2.6.20-rc6-mm3

[Robert Hancock]

Andrew Morton wrote:

On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get 
received and so the machine can't get an IP address. I tried reverting 
all the -mm changes to drivers/net/forcedeth.c, which didn't help. The 
network controller shares an IRQ with the USB OHCI controller which is 
receiving interrupts, so it doesn't seem like an interrupt routing 
problem, though I suppose something wierd could be happening there.


This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.

Any suggestions on how to debug/what to try reverting to see what's 
causing this?


There are many forcedeth changes in git-netdev-all.patch.  Can you
try reverting drivers/net/forcedeth.c back to the unpatched version
from 2.6.20-rc6?

Thanks.



That's essentially what I did, it didn't appear to help. I assume the
problem must lie elsewhere..

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

[PATCH] note that dri-devel is subscribers-only

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

dri-devel is subscribers-only, so note that in MAINTAINERS.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 MAINTAINERS |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2620-pv.orig/MAINTAINERS
+++ linux-2620-pv/MAINTAINERS
@@ -1126,7 +1126,7 @@ S:Supported
 DRM DRIVERS
 P: David Airlie
 M: [EMAIL PROTECTED]
-L: dri-devel@lists.sourceforge.net
+L: dri-devel@lists.sourceforge.net (subscribers-only)
 T: git kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
 S: Maintained
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unexpected Acknowledgement / Stalled Connections

[Baruch Even]

* Parag Warudkar <[EMAIL PROTECTED]> [070205 00:57]:
> On 2/4/07, Parag Warudkar <[EMAIL PROTECTED]> wrote:
> >I am running 2.6.20 and have trouble with stalled connections. For
> >instance, if I try to download a debian ISO image using wget, the
> >connection runs fine for few seconds and then stalls for ever.
> >
> >In my router logs I see a ton of messages like the below -
> >
> >[INFO] Sun Feb 04 17:22:03 2007 Blocked incoming TCP packet from
> >192.168.0.174:34090 to 130.239.18.138:80 with unexpected
> >acknowledgement 3269301836 (expected 3269343453 to 3269408989)
> >
> >Where 192.168.0.174 is my laptop running FC6 and kernel 2.6.20 and
> >130.239.18.138 is whatever cdimage.debian.org resolves to atm.
> >
> >What's going on here? Any TCP/IP tunable that I can set/turn on/off to
> >prevent this from happening?
> 
> Turning tcp_sack off seems to cure it. Turning it on again makes the
> connections stall. Seems like the D-Link router doesn't like the SACKs
> linux sends?

You can also try to disable tcp_window_scaling.

Can you provide a tcpdump trace of the connection? Traces with and
without SACK would be appreciated, also a trace with SACK but without
window scaling would be useful. I only need the headers of the packet so
-s 60 (the default) will be fine.

There was a change in 2.6.20 that I put but it should only have affected
the sender side and even then only the way it interpreted the data and
not things it sent on the wire.

Trying the dl with previous kernels can also help, if only to try and
pinpoint where things went bad, assuming it is in the kernel. This
sounds like a bad implementation of ACK window checks that ICSA requires
for firewall product certification.

Baruch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] arch M68KNOMMU: user ARRAY_SIZE macro when appropriate

[Greg Ungerer]

Hi Ahmed,

Ahmed S. Darwish wrote:

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no M68KNOMMU board at hand.


Compiled and tested on m68knommu, no problems.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>

Regards
Greg





diff --git a/arch/m68knommu/kernel/ptrace.c b/arch/m68knommu/kernel/ptrace.c
index 9130119..72d3496 100644
--- a/arch/m68knommu/kernel/ptrace.c
+++ b/arch/m68knommu/kernel/ptrace.c
@@ -62,7 +62,7 @@ static inline long get_reg(struct task_struct *task, int 
regno)
 
 	if (regno == PT_USP)

addr = &task->thread.usp;
-   else if (regno < sizeof(regoff)/sizeof(regoff[0]))
+   else if (regno < ARRAY_SIZE(regoff))
addr = (unsigned long *)(task->thread.esp0 + regoff[regno]);
else
return 0;
@@ -79,7 +79,7 @@ static inline int put_reg(struct task_struct *task, int regno,
 
 	if (regno == PT_USP)

addr = &task->thread.usp;
-   else if (regno < sizeof(regoff)/sizeof(regoff[0]))
+   else if (regno < ARRAY_SIZE(regoff))
addr = (unsigned long *) (task->thread.esp0 + regoff[regno]);
else
return -1;
diff --git a/arch/m68knommu/kernel/traps.c b/arch/m68knommu/kernel/traps.c
index 9129b3a..bed5f47 100644
--- a/arch/m68knommu/kernel/traps.c
+++ b/arch/m68knommu/kernel/traps.c
@@ -158,7 +158,7 @@ void show_stack(struct task_struct *task, unsigned long 
*stack)
 void bad_super_trap(struct frame *fp)
 {
console_verbose();
-   if (fp->ptregs.vector < 4*sizeof(vec_names)/sizeof(vec_names[0]))
+   if (fp->ptregs.vector < 4 * ARRAY_SIZE(vec_names))
printk (KERN_WARNING "*** %s ***   FORMAT=%X\n",
vec_names[(fp->ptregs.vector) >> 2],
fp->ptregs.format);



--

Greg Ungerer  --  Chief Software Dude   EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company  PHONE:   +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] update README.drm (bugzilla #7933)

[Randy Dunlap]

From: Randy Dunlap <[EMAIL PROTECTED]>

Update URLs in drivers/char/drm/README.drm, to take care of
kernel bugzilla #7933.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 drivers/char/drm/README.drm |   15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

--- linux-2620-pv.orig/drivers/char/drm/README.drm
+++ linux-2620-pv/drivers/char/drm/README.drm
@@ -1,6 +1,6 @@
 
 * For the very latest on DRI development, please see:  *
-* http://dri.sourceforge.net/  *
+* http://dri.freedesktop.org/wiki/FrontPage*
 
 
 The Direct Rendering Manager (drm) is a device-independent kernel-level
@@ -26,21 +26,20 @@ ways:
 
 
 Documentation on the DRI is available from:
-http://precisioninsight.com/piinsights.html
+http://dri.freedesktop.org/wiki/Documentation
+http://sourceforge.net/project/showfiles.php?group_id=387
+http://dri.sourceforge.net/doc/
 
 For specific information about kernel-level support, see:
 
 The Direct Rendering Manager, Kernel Support for the Direct Rendering
 Infrastructure
-http://precisioninsight.com/dr/drm.html
+http://dri.sourceforge.net/doc/drm_low_level.html
 
 Hardware Locking for the Direct Rendering Infrastructure
-http://precisioninsight.com/dr/locking.html
+http://dri.sourceforge.net/doc/hardware_locking_low_level.html
 
 A Security Analysis of the Direct Rendering Infrastructure
-http://precisioninsight.com/dr/security.html
+http://dri.sourceforge.net/doc/security_low_level.html
 
 
-* For the very latest on DRI development, please see:  *
-* http://dri.sourceforge.net/  *
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Eeek! page_mapcount(page) went negative! (-1)

[Randy Dunlap]

On Sun, 04 Feb 2007 20:48:30 -0800 David Liontooth wrote:

> David Liontooth wrote:
> > Running a script called thumbnails, which uses imagemagick's convert
> > utility, I got this on a mainline 2.6.16.38:
> >
> > Feb  4 17:04:01 prato /USR/SBIN/CRON[17173]: (tna) CMD (thumbnails
> > /db2/2006/2006-11/2006-11-16)
> >
> > Feb  4 17:20:49 prato kernel: swap_free: Unused swap offset entry 0080
> > Feb  4 17:20:49 prato kernel: convert[23078]: segfault at
> > 8000 rip 2b885c7d6590 rsp 7fa49308 error 4
> > Feb  4 17:20:50 prato kernel: convert[23113]: segfault at
> > 8010 rip 2b0914f305aa rsp 7f984340 error 4
> >
> > Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
> > Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
> > Feb  4 17:50:57 prato kernel: Eeek! page_mapcount(page) went negative! (-1)
> > Feb  4 17:50:57 prato kernel:   page->flags = 100083c
> > Feb  4 17:50:57 prato kernel:   page->count = 2
> > Feb  4 17:50:57 prato kernel:   page->mapping = 81002604c670
> > Feb  4 17:50:57 prato kernel: --- [cut here ] - [please
> > bite here ] -
> > Feb  4 17:50:57 prato kernel: Kernel BUG at mm/rmap.c:560
> > Feb  4 17:50:57 prato kernel: invalid opcode:  [1] SMP
> > Feb  4 17:50:57 prato kernel: CPU 1
> > Feb 4 17:50:57 prato kernel: Modules linked in: lirc_serial lirc_dev
> > saa7134_alsa tuner saa7134 video_buf compat_ioctl32 v4l2_common v4l1_compat
> > ir_kbd_i2c ir_common videodev skge ehci_hcd ohci_hcd psmouse pcspkr evdev
> > Feb  4 17:50:57 prato kernel: Pid: 29168, comm: thumbnails Tainted:
> > GF 2.6.16.38 #1
> > Feb  4 17:50:57 prato kernel: RIP: 0010:[]
> > {page_remove_rmap+117}
> > Feb  4 17:50:57 prato kernel: RSP: 0018:81000bc6dde8  EFLAGS: 00010286
> > Feb  4 17:50:57 prato kernel: RAX:  RBX:
> > 810001d1b290 RCX: 6507
> > Feb  4 17:50:57 prato kernel: RDX: ff01 RSI:
> > 0292 RDI: 80465dfc
> > Feb  4 17:50:57 prato kernel: RBP: 3be9e000 R08:
> >  R09: 0001
> > Feb  4 17:50:57 prato kernel: R10: 0010 R11:
> >  R12: 0062f000
> > Feb  4 17:50:57 prato kernel: R13: 810015ed7178 R14:
> > 006d6000 R15: 810001e12220
> > Feb  4 17:50:57 prato kernel: FS:  2b444df8a6d0()
> > GS:810001fc5ac0() knlGS:
> > Feb  4 17:50:57 prato kernel: CS:  0010 DS:  ES:  CR0:
> > 8005003b
> > Feb  4 17:50:57 prato kernel: CR2: 2b444ddb61f0 CR3:
> > 13f22000 CR4: 06e0
> > Feb  4 17:50:57 prato kernel: Process thumbnails (pid: 29168, threadinfo
> > 81000bc6c000, task 81003fe25160)
> > Feb  4 17:50:57 prato kernel: Stack: 810001d1b290 801519da
> >  81000bc6dec8
> > Feb  4 17:50:57 prato kernel: 
> > 81002955d648 81000bc6ded0
> > Feb  4 17:50:57 prato kernel: 00012cf477b8
> > Feb  4 17:50:57 prato kernel: Call Trace:
> > {unmap_vmas+1012} {exit_mmap+120}
> > Feb  4 17:50:57 prato kernel:{mmput+40}
> > {do_exit+489}
> > Feb  4 17:50:57 prato kernel:   
> > {sys_exit_group+0} {system_call+126}
> > Feb  4 17:50:57 prato kernel:
> > Feb  4 17:50:57 prato kernel: Code: 0f 0b 68 f8 21 40 80 c2 30 02 5b 48
> > 83 ce ff bf 20 00 00 00
> > Feb  4 17:50:57 prato kernel: RIP
> > {page_remove_rmap+117} RSP 
> > Feb  4 17:50:57 prato kernel:  <1>Fixing recursive fault but reboot is
> > needed!
> > Feb  4 17:52:52 prato kernel: Bad page state in process 'kswapd0'
> > Feb  4 17:52:52 prato kernel: page:810001d1b290
> > flags:0x0108 mapping: mapcount:-1 count:0
> > Feb  4 17:52:52 prato kernel: Trying to fix it up, but a reboot is needed
> > Feb  4 17:52:52 prato kernel: Backtrace:
> > Feb  4 17:52:52 prato kernel:
> > Feb  4 17:52:52 prato kernel: Call Trace:
> > {bad_page+80} {free_hot_cold_page+116}
> > Feb  4 17:52:52 prato kernel:   
> > {__pagevec_free+33}
> > {__pagevec_release_nonlru+122}
> > Feb  4 17:52:52 prato kernel:   
> > {shrink_zone+2280} {balance_pgdat+527}
> > Feb  4 17:52:52 prato kernel:{kswapd+265}
> > {autoremove_wake_function+0}
> > Feb  4 17:52:52 prato kernel:{child_rip+8}
> > {kswapd+0}
> > Feb  4 17:52:52 prato kernel:{child_rip+0}
> >
> > lspci
> >
> > 00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
> > 00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
> > 00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
> > (rev a1)
> > 00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
> > 00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
> > 00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
> > Controller (rev a2)
> > 00:06.0 Multimedia audio con

Re: forcedeth problems on 2.6.20-rc6-mm3

[Andrew Morton]

On Sun, 04 Feb 2007 23:13:09 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:

> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 
> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get 
> received and so the machine can't get an IP address. I tried reverting 
> all the -mm changes to drivers/net/forcedeth.c, which didn't help. The 
> network controller shares an IRQ with the USB OHCI controller which is 
> receiving interrupts, so it doesn't seem like an interrupt routing 
> problem, though I suppose something wierd could be happening there.
> 
> This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.
> 
> Any suggestions on how to debug/what to try reverting to see what's 
> causing this?

There are many forcedeth changes in git-netdev-all.patch.  Can you
try reverting drivers/net/forcedeth.c back to the unpatched version
from 2.6.20-rc6?

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/

[PATCH -mm] sata_nv: propagate ata_pci_device_do_resume return value

[Robert Hancock]

ata_pci_device_do_resume can fail if the PCI device couldn't be re-enabled.
Update sata_nv to propagate the return value from this call and to
not try to do any other resume activities if it fails. Fixes a compile
warning.

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

--- linux-2.6.20-rc6-mm3edit/drivers/ata/sata_nv.c.beforeresumechange   
2007-02-04 22:18:49.0 -0600
+++ linux-2.6.20-rc6-mm3edit/drivers/ata/sata_nv.c  2007-02-04 
22:20:06.0 -0600
@@ -1604,8 +1604,11 @@ static int nv_pci_device_resume(struct p
{
struct ata_host *host = dev_get_drvdata(&pdev->dev);
struct nv_host_priv *hpriv = host->private_data;
+   int rc;

-   ata_pci_device_do_resume(pdev);
+   rc = ata_pci_device_do_resume(pdev);
+   if(rc)
+   return rc;

if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
if(hpriv->type >= CK804) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -mm] sata_nv: wait for response on entering/leaving ADMA mode

[Robert Hancock]

Update sata_nv to wait for the controller to indicate via the status register
that it has entered the requested state when switching between ADMA mode and
register mode. This issue came up recently when debugging some problems with
cache flush command timeouts and while it didn't appear to fix that problem,
this is something we should likely be doing in any case.

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

--- linux-2.6.20-rc6-mm3/drivers/ata/sata_nv.c  2007-02-04 21:48:25.0 
-0600
+++ linux-2.6.20-rc6-mm3edit/drivers/ata/sata_nv.c  2007-02-04 
22:13:36.0 -0600
@@ -507,14 +507,38 @@ static void nv_adma_register_mode(struct
{
struct nv_adma_port_priv *pp = ap->private_data;
void __iomem *mmio = pp->ctl_block;
-   u16 tmp;
+   u16 tmp, status;
+   int count = 0;

if (pp->flags & NV_ADMA_PORT_REGISTER_MODE)
return;

+   status = readw(mmio + NV_ADMA_STAT);
+   while(!(status & NV_ADMA_STAT_IDLE) && count < 20) {
+   ndelay(50);
+   status = readw(mmio + NV_ADMA_STAT);
+   count++;
+   }
+   if(count == 20)
+   ata_port_printk(ap, KERN_WARNING,
+   "timeout waiting for ADMA IDLE, stat=0x%hx\n",
+   status);
+
tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp & ~NV_ADMA_CTL_GO, mmio + NV_ADMA_CTL);

+   count = 0;
+   status = readw(mmio + NV_ADMA_STAT);
+   while(!(status & NV_ADMA_STAT_LEGACY) && count < 20) {
+   ndelay(50);
+   status = readw(mmio + NV_ADMA_STAT);
+   count++;
+   }
+   if(count == 20)
+   ata_port_printk(ap, KERN_WARNING,
+"timeout waiting for ADMA LEGACY, stat=0x%hx\n",
+status);
+
pp->flags |= NV_ADMA_PORT_REGISTER_MODE;
}

@@ -522,7 +546,8 @@ static void nv_adma_mode(struct ata_port
{
struct nv_adma_port_priv *pp = ap->private_data;
void __iomem *mmio = pp->ctl_block;
-   u16 tmp;
+   u16 tmp, status;
+   int count = 0;

if (!(pp->flags & NV_ADMA_PORT_REGISTER_MODE))
return;
@@ -532,6 +557,18 @@ static void nv_adma_mode(struct ata_port
tmp = readw(mmio + NV_ADMA_CTL);
writew(tmp | NV_ADMA_CTL_GO, mmio + NV_ADMA_CTL);

+   status = readw(mmio + NV_ADMA_STAT);
+   while(((status & NV_ADMA_STAT_LEGACY) ||
+ !(status & NV_ADMA_STAT_IDLE)) && count < 20) {
+   ndelay(50);
+   status = readw(mmio + NV_ADMA_STAT);
+   count++;
+   }
+   if(count == 20)
+   ata_port_printk(ap, KERN_WARNING,
+   "timeout waiting for ADMA LEGACY clear and IDLE, 
stat=0x%hx\n",
+   status);
+
pp->flags &= ~NV_ADMA_PORT_REGISTER_MODE;
}



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

forcedeth problems on 2.6.20-rc6-mm3

[Robert Hancock]

Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 
2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get 
received and so the machine can't get an IP address. I tried reverting 
all the -mm changes to drivers/net/forcedeth.c, which didn't help. The 
network controller shares an IRQ with the USB OHCI controller which is 
receiving interrupts, so it doesn't seem like an interrupt routing 
problem, though I suppose something wierd could be happening there.


This is on an Asus A8N-SLI Deluxe (CK804 chipset) on x86_64.

Any suggestions on how to debug/what to try reverting to see what's 
causing this?


--
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] fix unaligned exception in /drivers/net/wireless/orinoco.c

[Pavel Roskin]

On Fri, 2007-02-02 at 15:20 -0500, John W. Linville wrote:
> On Thu, Jan 18, 2007 at 09:57:18AM -, Hennerich, Michael wrote:
> > 
> > This short patch prevents an unaligned exception to occur. (GCC 4.1)
> > tmp is defined as char pointer while it is later accessed as short.

Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>

> This patch seems fine, such as it is.  But, it seems like it might
> also be appropriate to change hermes_read_ltv and/or hermes_read_words
> to not take void * parameters?  This patch would still be needed,
> but it might be more obvious to future coders?

I agree.  If we use any optimization that requires alignment of the
buffer for aligned access, it needs to be clearly specified and
(ideally) enforced.

I've tried to make a patch, but it seems to be a bigger effort than I
expected.  It turns out that hermes_clear_words() is not doing what it
should (although it would only affect some buggy firmwares), and it's
clear that I just cannot replace a couple of arguments and hope for the
best.  I need to dust off my 802.11b cards and re-test everything.

I've started orinoco branch locally, and I hope I'll be able to clean
the driver from all that bitrot soon.

-- 
Regards,
Pavel Roskin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] drivers/isdn/gigaset: new M101 driver

[Andrew Morton]

On Mon, 05 Feb 2007 02:42:09 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:

> Am 04.02.2007 02:56 schrieb Andrew Morton:
> > On Sun, 04 Feb 2007 02:32:41 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> > 
>  +spin_lock_irqsave(&cs->cmdlock, flags);
>  +cb = cs->cmdbuf;
>  +spin_unlock_irqrestore(&cs->cmdlock, flags);
> >>> It is doubtful if the locking here does anything useful.
> >> It assures atomicity when reading the cs->cmdbuf pointer.
> > 
> > I think it's bogus.  If the quantity being copied here is more than 32-bits
> > then yes, a lock is appropriate.  But if it's a single word then it's
> > unlikely that the locking does anything useful.  Or there might be a bug
> > here.
> 
> It's a pointer. Are reads and writes of pointer sized objects
> guaranteed to be atomic on every platform?

Yup - we make the same assumption about longs in various places.

It's a bit strange to read a pointer which can be changing at the
same time.  Because the local copy will no longer represent the
thing which it was just copied from.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 013 of 14] knfsd: SUNRPC: support IPv6 addresses in RPC server's UDP receive path.

[Josef Sipek]

On Fri, Feb 02, 2007 at 03:40:44PM +1100, NeilBrown wrote:
...
> diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
> --- .prev/net/sunrpc/svcsock.c2007-02-02 15:22:40.0 +1100
> +++ ./net/sunrpc/svcsock.c2007-02-02 15:22:58.0 +1100
> @@ -715,13 +715,55 @@ svc_write_space(struct sock *sk)
>   }
>  }
>  
> +static void svc_udp_get_sender_address(struct svc_rqst *rqstp,
> + struct sk_buff *skb)
> +{
> + switch (rqstp->rq_sock->sk_sk->sk_family) {
> + case AF_INET:
> + /* this seems to come from net/ipv4/udp.c:udp_recvmsg */
> + do {
> + struct sockaddr_in *sin = svc_addr_in(rqstp);
> +
> + sin->sin_family = AF_INET;
> + sin->sin_port = skb->h.uh->source;
> + sin->sin_addr.s_addr = skb->nh.iph->saddr;
> + rqstp->rq_addrlen = sizeof(struct sockaddr_in);
> + /* Remember which interface received this request */
> + rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
> + } while (0);
> + break;

Why the while(0) ?

> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> + case AF_INET6:
> + /* this is derived from net/ipv6/udp.c:udpv6_recvmesg */
> + do {
> + struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp);
> +
> + sin6->sin6_family = AF_INET6;
> + sin6->sin6_port = skb->h.uh->source;
> + sin6->sin6_flowinfo = 0;
> + sin6->sin6_scope_id = 0;
> + if (ipv6_addr_type(&sin6->sin6_addr) &
> + IPV6_ADDR_LINKLOCAL)
> + sin6->sin6_scope_id = IP6CB(skb)->iif;
> + ipv6_addr_copy(&sin6->sin6_addr,
> + &skb->nh.ipv6h->saddr);
> + rqstp->rq_addrlen = sizeof(struct sockaddr_in);
> + /* Remember which interface received this request */
> + ipv6_addr_copy(&rqstp->rq_daddr.addr6,
> + &skb->nh.ipv6h->saddr);
> + } while (0);
> + break;

Ditto.

Josef "Jeff" Sipek.

-- 
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
- Abbie Hoffman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Eeek! page_mapcount(page) went negative! (-1)

[David Liontooth]

David Liontooth wrote:
> Running a script called thumbnails, which uses imagemagick's convert
> utility, I got this on a mainline 2.6.16.38:
>
> Feb  4 17:04:01 prato /USR/SBIN/CRON[17173]: (tna) CMD (thumbnails
> /db2/2006/2006-11/2006-11-16)
>
> Feb  4 17:20:49 prato kernel: swap_free: Unused swap offset entry 0080
> Feb  4 17:20:49 prato kernel: convert[23078]: segfault at
> 8000 rip 2b885c7d6590 rsp 7fa49308 error 4
> Feb  4 17:20:50 prato kernel: convert[23113]: segfault at
> 8010 rip 2b0914f305aa rsp 7f984340 error 4
>
> Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
> Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
> Feb  4 17:50:57 prato kernel: Eeek! page_mapcount(page) went negative! (-1)
> Feb  4 17:50:57 prato kernel:   page->flags = 100083c
> Feb  4 17:50:57 prato kernel:   page->count = 2
> Feb  4 17:50:57 prato kernel:   page->mapping = 81002604c670
> Feb  4 17:50:57 prato kernel: --- [cut here ] - [please
> bite here ] -
> Feb  4 17:50:57 prato kernel: Kernel BUG at mm/rmap.c:560
> Feb  4 17:50:57 prato kernel: invalid opcode:  [1] SMP
> Feb  4 17:50:57 prato kernel: CPU 1
> Feb 4 17:50:57 prato kernel: Modules linked in: lirc_serial lirc_dev
> saa7134_alsa tuner saa7134 video_buf compat_ioctl32 v4l2_common v4l1_compat
> ir_kbd_i2c ir_common videodev skge ehci_hcd ohci_hcd psmouse pcspkr evdev
> Feb  4 17:50:57 prato kernel: Pid: 29168, comm: thumbnails Tainted:
> GF 2.6.16.38 #1
> Feb  4 17:50:57 prato kernel: RIP: 0010:[]
> {page_remove_rmap+117}
> Feb  4 17:50:57 prato kernel: RSP: 0018:81000bc6dde8  EFLAGS: 00010286
> Feb  4 17:50:57 prato kernel: RAX:  RBX:
> 810001d1b290 RCX: 6507
> Feb  4 17:50:57 prato kernel: RDX: ff01 RSI:
> 0292 RDI: 80465dfc
> Feb  4 17:50:57 prato kernel: RBP: 3be9e000 R08:
>  R09: 0001
> Feb  4 17:50:57 prato kernel: R10: 0010 R11:
>  R12: 0062f000
> Feb  4 17:50:57 prato kernel: R13: 810015ed7178 R14:
> 006d6000 R15: 810001e12220
> Feb  4 17:50:57 prato kernel: FS:  2b444df8a6d0()
> GS:810001fc5ac0() knlGS:
> Feb  4 17:50:57 prato kernel: CS:  0010 DS:  ES:  CR0:
> 8005003b
> Feb  4 17:50:57 prato kernel: CR2: 2b444ddb61f0 CR3:
> 13f22000 CR4: 06e0
> Feb  4 17:50:57 prato kernel: Process thumbnails (pid: 29168, threadinfo
> 81000bc6c000, task 81003fe25160)
> Feb  4 17:50:57 prato kernel: Stack: 810001d1b290 801519da
>  81000bc6dec8
> Feb  4 17:50:57 prato kernel: 
> 81002955d648 81000bc6ded0
> Feb  4 17:50:57 prato kernel: 00012cf477b8
> Feb  4 17:50:57 prato kernel: Call Trace:
> {unmap_vmas+1012} {exit_mmap+120}
> Feb  4 17:50:57 prato kernel:{mmput+40}
> {do_exit+489}
> Feb  4 17:50:57 prato kernel:   
> {sys_exit_group+0} {system_call+126}
> Feb  4 17:50:57 prato kernel:
> Feb  4 17:50:57 prato kernel: Code: 0f 0b 68 f8 21 40 80 c2 30 02 5b 48
> 83 ce ff bf 20 00 00 00
> Feb  4 17:50:57 prato kernel: RIP
> {page_remove_rmap+117} RSP 
> Feb  4 17:50:57 prato kernel:  <1>Fixing recursive fault but reboot is
> needed!
> Feb  4 17:52:52 prato kernel: Bad page state in process 'kswapd0'
> Feb  4 17:52:52 prato kernel: page:810001d1b290
> flags:0x0108 mapping: mapcount:-1 count:0
> Feb  4 17:52:52 prato kernel: Trying to fix it up, but a reboot is needed
> Feb  4 17:52:52 prato kernel: Backtrace:
> Feb  4 17:52:52 prato kernel:
> Feb  4 17:52:52 prato kernel: Call Trace:
> {bad_page+80} {free_hot_cold_page+116}
> Feb  4 17:52:52 prato kernel:   
> {__pagevec_free+33}
> {__pagevec_release_nonlru+122}
> Feb  4 17:52:52 prato kernel:   
> {shrink_zone+2280} {balance_pgdat+527}
> Feb  4 17:52:52 prato kernel:{kswapd+265}
> {autoremove_wake_function+0}
> Feb  4 17:52:52 prato kernel:{child_rip+8}
> {kswapd+0}
> Feb  4 17:52:52 prato kernel:{child_rip+0}
>
> lspci
>
> 00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
> 00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
> 00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
> (rev a1)
> 00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
> 00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
> 00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
> Controller (rev a2)
> 00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb
> AC'97 Audio Controller (rev a1)
> 00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller
> (v2.5) (rev a2)
> 00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller
> (v2.5) (rev a2)

clocksource v13

[Daniel Walker]

I released another version of my clocksource update. I incorporated some
of Ingo's suggestions. I also tested my changes on an older Sony Vaio
where the TSC stops in C2/C3. I noticed that generic time already marks
the TSC unstable if the system enters C2/C3 . So the verify code doesn't
need to run. If I disable that the TSC is detect the same with both sets
of changes. I haven't found a VAIO that has random frequency changes. If
it's a rare condition we can use the DMI black list to avoid using it on
those system.

Download from,

ftp://source.mvista.com/pub/dwalker/clocksource/clocksource-v13/


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: 2.6.20 PCI Cannot allocate resource region 2

[H. Peter Anvin]

Luming Yu wrote:


*  Known BIOS problems we have to work around:
*  - bogus I/O addresses above 64K used


On non-x86 architectures this might be just fine.

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

Re: Timeouts on ICH7 PATA drive with ata_piix; ide_generic works perfectly

[Luming Yu]

From the dmesg, I found a problem NOT relative to the PATA driver.

I would like to know if cpu freq driver works? If not, please enter a
acpi bug on bugzilla.kernel.org.

"[   17.368000] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT,
Index (0FFFD) is beyond end of object [20060707]
[   17.368000] ACPI Error (psparse-0537): Method parse/execution
failed [\_PR_.CPU1._PSS] (Node c1468ba8), AE_AML_PACKAGE_LIMIT
[   17.368000] ACPI Exception (acpi_processor-0235):
AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20060707]
[   17.368000] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT,
Index (0FFFD) is beyond end of object [20060707]
[   17.368000] ACPI Error (psparse-0537): Method parse/execution
failed [\_PR_.CPU2._PSS] (Node c14689f0), AE_AML_PACKAGE_LIMIT
[   17.368000] ACPI Exception (acpi_processor-0235):
AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20060707]
"

On 2/4/07, Keenan Pepper <[EMAIL PROTECTED]> wrote:

I just upgraded the kernel on my System76 Gazelle laptop (basically an
ASUS Z62FP without the Microsoft tax) and the hard drive began
freezing every few minutes. I blacklisted ata_piix and the problem
went away, so that really narrows down where the bug has to be. Here's
the relevant part of the dmesg:

[  924.00] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[  924.00] ata1.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0
cdb 0x25 data 8 in
[  924.00]  res 40/00:03:00:00:00/00:00:00:00:00/b0 Emask
0x4 (timeout)
[  931.004000] ata1: port is slow to respond, please be patient (Status 0xd0)
[  954.028000] ata1: port failed to respond (30 secs, Status 0xd0)
[  954.028000] ata1: soft resetting port
[  954.38] ata1.00: configured for UDMA/100
[  954.56] ata1.01: configured for UDMA/33
[  954.56] ata1: EH complete

Complete dmesg and lspci -vvx are attached; please CC me because I'm
not subscribed. My sincere apologies if this is already fixed in the
main kernel.

Keenan Pepper



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

Re: NCPFS and brittle connections

[Petr Vandrovec]

Pierre Ossman wrote:

Petr Vandrovec wrote:

Problem is with these pointers - reply_buf & server->packet.  Now code
will just read packet from server->packet, and write result to
reply_buf, most probably transmiting some random data to network, and
overwriting innocent memory on receiption...  I believe that you need
to make copies of server->packet/size for transmission, and some
simillar solution for receive as well.  As both request & response can
be up to ~66000 bytes.


Hmm.. I thought server->packet was protected until the packet was
completed, independent of the process that issued it. Looking closer I
see that this isn't quite the case.

How about this... We allocate two buffers at startup, one for outgoing
and one for incoming. Then we use these during the actual transmission,
copying back and forth as need. Then we just need to avoid the final
response copy if the process has gone belly up.


You must not allow anybody to reuse transmit buffer until you are done 
with all retransmits and received reply from server...  That's why code 
uses same buffer for both request and reply - you never need both, and 
as maximum size is more or less same for both (65KB), it avoid problem 
that you would need two 65KB buffers in worst case.



Now my next question in that case is, what is the purpose of
server->packet. Couldn't this buffer be provided by the caller like the
response buffer?


Then you would need to do vmalloc (or maybe kmalloc for some cases) on 
each request transmit & receive.  And only very few callers provide 
receive buffer - most of them does ncp_request() which receives reply to 
server->packet, without doing any additional allocation - there are only 
three callers which use ncp_request2 - two of them (ioctl, 
ncp_read_bounce) do that because copy_to_user is not allowed while 
ncp_server is locked, and third one (search for file set) does that 
because caller may need to issue additional NCP calls while parsing its 
result.  But everybody else gets away with no memory allocation.

Petr


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

Re: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC

[許恆嘉]

Dear Francois:

Thanks for your comments. They are very informative. Since I am a novice 
in the submission process, I learn a lot from them.


My answers with the keyword "ANS:" are under where your  questions are 
posed.


About the MAC initialization which is tiring you, I can explain. 
RTL8110SC has a different MAC initialization with RTL8110S/SB. My 
hardware colleague finds a way that is compatible for all of them. And I 
follow it.


Best Regards,
Edward 2007/02/05

Francois Romieu 提到:


<[EMAIL PROTECTED]> :
[...]
 


@@ -123,8 +155,8 @@ static const int multicast_filter_limit
#define MAC_ADDR_LEN 6

#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before
first PCI xfer. */
-#define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
-#define TX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
+#define RX_DMA_BURST 7 /* Maximum PCI burst, '7' is unlimited */
+#define TX_DMA_BURST 7 /* Maximum PCI burst, '6' is 1024 */
   



Ok.

[...]
 


@@ -179,45 +208,18 @@ static const struct {
u8 mac_version;
u32 RxConfigMask; /* Clears the bits supported by this chip */
} rtl_chip_info[] = {
- _R("RTL8169", RTL_GIGA_MAC_VER_01, 0xff7e1880),
- _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_02, 0xff7e1880),
- _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_03, 0xff7e1880),
- _R("RTL8169sb/8110sb", RTL_GIGA_MAC_VER_04, 0xff7e1880),
- _R("RTL8169sc/8110sc", RTL_GIGA_MAC_VER_05, 0xff7e1880),
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
- _R("RTL8168b/8111b", RTL_GIGA_MAC_VER_12, 0xff7e1880), // PCI-E
- _R("RTL8101e", RTL_GIGA_MAC_VER_13, 0xff7e1880), // PCI-E 8139
- _R("RTL8100e", RTL_GIGA_MAC_VER_14, 0xff7e1880), // PCI-E 8139
- _R("RTL8100e", RTL_GIGA_MAC_VER_15, 0xff7e1880) // PCI-E 8139
+ _R("RTL8169", RTL_GIGA_MAC_VER_8169, 0xff7e1880),
+ _R("RTL8169S/8110S", RTL_GIGA_MAC_VER_8169S, 0xff7e1880),
+ _R("RTL8169S/8110S", RTL_GIGA_MAC_VER_8110S, 0xff7e1880),
+ _R("RTL8169SB/8110SB", RTL_GIGA_MAC_VER_8169SB, 0xff7e1880),
+ _R("RTL8169SC/8110SC", RTL_GIGA_MAC_VER_8110SCd, 0xff7e1880),
+ _R("RTL8169SC/8110SC", RTL_GIGA_MAC_VER_8110SCe, 0xff7e1880),
   



This part includes a rename of the RTL_GIGA_MAC_VER_XYZ which induces
no user-visible changes beside a new "RTL8169SC/8110SC" identifier.

If I correctly read the patch, it should go along the 0x9800
mask in rtl8169_get_mac_version.
 


ANS:
1. Since this driver is developed for Realtek PCI gigabit ethernet 
controllers, I delete these items that is not in this category. For 
PCI-E products, there are two drivers for them. r8168.c for Realtek 
PCI-E gigabit ethernet controller. r8101.c for Realtek PCI-E fast 
ethernet controllers.


2. Since there are two hardware version of RTL8110SC, two hardward ID 
hardwired in TCR is used for RTL8110SC. The first RTL8110SC has 
0x1800 as its hardward ID, while the second one has 0x9800. The 
second RTL81110SC uses 31 bit in TCR which is never used before. 
Therefore,  the  mask  to extract hardware version from TCR is 0xFC80 .



[...]
 


static struct pci_device_id rtl8169_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8129), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8136), 0, 0, RTL_CFG_2 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), 0, 0, RTL_CFG_2 },
- { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x1259, 0xc107), 0, 0, RTL_CFG_0 },
- { PCI_DEVICE(0x16ec, 0x0116), 0, 0, RTL_CFG_0 },
- { PCI_VENDOR_ID_LINKSYS, 0x1032,
- PCI_ANY_ID, 0x0024, 0, 0, RTL_CFG_0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8167), },
   



The current driver is intended to handle the whole set of PCI IDs
which would be removed by the patch. Thoug some combination of
chipset and motherboard do not work as expected, the gigabit
chipsets have been reported to work.

Please elaborate if there is a good reason to remove any ID.
 


ANS:
I have explained my point about this in last question. This driver is 
developed for Realtek PCI gigabit ethernet controllers. Although some 
vendors may use Realtek solutions with their own PCI DIDs and VIDs, they 
should customize this driver and maintained the customized driver on 
their own.


 


@@ -230,8 +232,9 @@ static struct {
} debug = { -1 };

enum RTL8169_registers {
- MAC0 = 0, /* Ethernet hardware address. */
- MAR0 = 8, /* Multicast filter. */
+ MAC0 = 0x00, /* Ethernet hardware address. */
+ MAC4 = 0x04,
+ MAR0 = 0x08, /* Multicast filter. */
   



New register. Ok.

 


CounterAddrLow = 0x10,
CounterAddrHigh = 0x14,
TxDescStartAddrLow = 0x20,
@@ -260,6 +263,7 @@ enum RTL8169_registers {
TBI_ANAR = 0x68,
TBI_LPAR = 0x6A,
PHYstatus = 0x6C,
+ Offset_7Ch = 0x7C,
   



Can you provide a more descriptive name for this register ?

 


ANS:
The MAC register 0x7C is for tuning the driving capability in PCI 33MHz 
and 66MHz. It should be 

Re: Bcm43xx oops after suspend to disk

[Larry Finger]

Rafael J. Wysocki wrote:
> On Sunday, 4 February 2007 18:42, Larry Finger wrote:
>> roucaries bastien wrote:
>>> Sorry for the delay it works. This time I can use iwlist eth scan.
>>> I have some difficulties to associate and I need to rmmod/modprobe in
>>> order to associate but it is another problem linked to a really weak
>>> power.
>> Bastien,
>>
>> Please try this patch instead.
> 
> Hm, it doesn't seem to apply to the mainline version of the driver.  Any 
> chance
> for a fix against 2.6.20?

Please try this one. I forgot about some other stuff in my working copy of 
wireless-2.6.

Larry



Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3617,6 +3617,7 @@ error:
 static int bcm43xx_init_board(struct bcm43xx_private *bcm)
 {
int err;
+   struct bcm43xx_phyinfo *phy = bcm43xx_current_phy(bcm);

mutex_lock(&(bcm)->mutex);

@@ -3637,6 +3638,8 @@ static int bcm43xx_init_board(struct bcm
if (err)
goto err_sysfs_unreg;
bcm43xx_periodic_tasks_setup(bcm);
+   /* force initial LO calibration */
+   phy->lo_control->txctl2 = 0x;

/*FIXME: This should be handled by softmac instead. */
schedule_delayed_work(&bcm->softmac->associnfo.work, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

On 2/5/07, Manu Abraham <[EMAIL PROTECTED]> wrote:

Hi,

I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
the message is slightly different in 2.6.17.7)

PCI Cannot allocate resource region 2 of device :02:0a.0

Just did a search about this message around the kernel source tree.
The interesting thing is that I see the following comments at several
different arch/drivers files. Is it related to your problem?

*  Known BIOS problems we have to work around:
*  - I/O or memory regions not configured
*  - regions configured, but not enabled in the command register
*  - bogus I/O addresses above 64K used
 *  - expansion ROMs left enabled (this may sound harmless, but given
 *the fact the PCI specs explicitly allow address decoders to be
 *shared between expansion ROMs and other resource regions, it's
*at least dangerous)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Eeek! page_mapcount(page) went negative! (-1)

[David Liontooth]

Running a script called thumbnails, which uses imagemagick's convert
utility, I got this on a mainline 2.6.16.38:

Feb  4 17:04:01 prato /USR/SBIN/CRON[17173]: (tna) CMD (thumbnails
/db2/2006/2006-11/2006-11-16)

Feb  4 17:20:49 prato kernel: swap_free: Unused swap offset entry 0080
Feb  4 17:20:49 prato kernel: convert[23078]: segfault at
8000 rip 2b885c7d6590 rsp 7fa49308 error 4
Feb  4 17:20:50 prato kernel: convert[23113]: segfault at
8010 rip 2b0914f305aa rsp 7f984340 error 4

Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
Feb  4 17:50:57 prato kernel: swap_free: Unused swap offset entry 0080
Feb  4 17:50:57 prato kernel: Eeek! page_mapcount(page) went negative! (-1)
Feb  4 17:50:57 prato kernel:   page->flags = 100083c
Feb  4 17:50:57 prato kernel:   page->count = 2
Feb  4 17:50:57 prato kernel:   page->mapping = 81002604c670
Feb  4 17:50:57 prato kernel: --- [cut here ] - [please
bite here ] -
Feb  4 17:50:57 prato kernel: Kernel BUG at mm/rmap.c:560
Feb  4 17:50:57 prato kernel: invalid opcode:  [1] SMP
Feb  4 17:50:57 prato kernel: CPU 1
Feb 4 17:50:57 prato kernel: Modules linked in: lirc_serial lirc_dev
saa7134_alsa tuner saa7134 video_buf compat_ioctl32 v4l2_common v4l1_compat
ir_kbd_i2c ir_common videodev skge ehci_hcd ohci_hcd psmouse pcspkr evdev
Feb  4 17:50:57 prato kernel: Pid: 29168, comm: thumbnails Tainted:
GF 2.6.16.38 #1
Feb  4 17:50:57 prato kernel: RIP: 0010:[]
{page_remove_rmap+117}
Feb  4 17:50:57 prato kernel: RSP: 0018:81000bc6dde8  EFLAGS: 00010286
Feb  4 17:50:57 prato kernel: RAX:  RBX:
810001d1b290 RCX: 6507
Feb  4 17:50:57 prato kernel: RDX: ff01 RSI:
0292 RDI: 80465dfc
Feb  4 17:50:57 prato kernel: RBP: 3be9e000 R08:
 R09: 0001
Feb  4 17:50:57 prato kernel: R10: 0010 R11:
 R12: 0062f000
Feb  4 17:50:57 prato kernel: R13: 810015ed7178 R14:
006d6000 R15: 810001e12220
Feb  4 17:50:57 prato kernel: FS:  2b444df8a6d0()
GS:810001fc5ac0() knlGS:
Feb  4 17:50:57 prato kernel: CS:  0010 DS:  ES:  CR0:
8005003b
Feb  4 17:50:57 prato kernel: CR2: 2b444ddb61f0 CR3:
13f22000 CR4: 06e0
Feb  4 17:50:57 prato kernel: Process thumbnails (pid: 29168, threadinfo
81000bc6c000, task 81003fe25160)
Feb  4 17:50:57 prato kernel: Stack: 810001d1b290 801519da
 81000bc6dec8
Feb  4 17:50:57 prato kernel: 
81002955d648 81000bc6ded0
Feb  4 17:50:57 prato kernel: 00012cf477b8
Feb  4 17:50:57 prato kernel: Call Trace:
{unmap_vmas+1012} {exit_mmap+120}
Feb  4 17:50:57 prato kernel:{mmput+40}
{do_exit+489}
Feb  4 17:50:57 prato kernel:   
{sys_exit_group+0} {system_call+126}
Feb  4 17:50:57 prato kernel:
Feb  4 17:50:57 prato kernel: Code: 0f 0b 68 f8 21 40 80 c2 30 02 5b 48
83 ce ff bf 20 00 00 00
Feb  4 17:50:57 prato kernel: RIP
{page_remove_rmap+117} RSP 
Feb  4 17:50:57 prato kernel:  <1>Fixing recursive fault but reboot is
needed!
Feb  4 17:52:52 prato kernel: Bad page state in process 'kswapd0'
Feb  4 17:52:52 prato kernel: page:810001d1b290
flags:0x0108 mapping: mapcount:-1 count:0
Feb  4 17:52:52 prato kernel: Trying to fix it up, but a reboot is needed
Feb  4 17:52:52 prato kernel: Backtrace:
Feb  4 17:52:52 prato kernel:
Feb  4 17:52:52 prato kernel: Call Trace:
{bad_page+80} {free_hot_cold_page+116}
Feb  4 17:52:52 prato kernel:   
{__pagevec_free+33}
{__pagevec_release_nonlru+122}
Feb  4 17:52:52 prato kernel:   
{shrink_zone+2280} {balance_pgdat+527}
Feb  4 17:52:52 prato kernel:{kswapd+265}
{autoremove_wake_function+0}
Feb  4 17:52:52 prato kernel:{child_rip+8}
{kswapd+0}
Feb  4 17:52:52 prato kernel:{child_rip+0}

lspci

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management
(rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0
Controller (rev a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb
AC'97 Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller
(v2.5) (rev a2)
00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller
(v2.5) (rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI
Bridge (rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge
(rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [A

[PATCH 2.6.20] arch ARM: Use ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no ARM machine at hand.
Thanks,

diff --git a/arch/arm/kernel/ecard.c b/arch/arm/kernel/ecard.c
index 71257e3..f1c0fb9 100644
--- a/arch/arm/kernel/ecard.c
+++ b/arch/arm/kernel/ecard.c
@@ -1009,7 +1009,7 @@ ecard_probe(int slot, card_type_t type)
ec->fiqmask = 4;
}
 
-   for (i = 0; i < sizeof(blacklist) / sizeof(*blacklist); i++)
+   for (i = 0; i < ARRAY_SIZE(blacklist); i++)
if (blacklist[i].manufacturer == ec->cid.manufacturer &&
blacklist[i].product == ec->cid.product) {
ec->card_desc = blacklist[i].type;
diff --git a/arch/arm26/kernel/ecard.c b/arch/arm26/kernel/ecard.c
index 9dbc172..e2bcefc 100644
--- a/arch/arm26/kernel/ecard.c
+++ b/arch/arm26/kernel/ecard.c
@@ -665,7 +665,7 @@ ecard_probe(int slot, card_type_t type)
ec->fiqmask = 4;
}
 
-   for (i = 0; i < sizeof(blacklist) / sizeof(*blacklist); i++)
+   for (i = 0; i < ARRAY_SIZE(blacklist); i++)
if (blacklist[i].manufacturer == ec->cid.manufacturer &&
blacklist[i].product == ec->cid.product) {
ec->card_desc = blacklist[i].type;

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

[PATCH 2.6.20] arch M68K: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked since I have no m68k machine at hand.

diff --git a/arch/m68k/kernel/ptrace.c b/arch/m68k/kernel/ptrace.c
index ef89060..7fd2720 100644
--- a/arch/m68k/kernel/ptrace.c
+++ b/arch/m68k/kernel/ptrace.c
@@ -76,7 +76,7 @@ static inline long get_reg(struct task_struct *task, int 
regno)
 
if (regno == PT_USP)
addr = &task->thread.usp;
-   else if (regno < sizeof(regoff)/sizeof(regoff[0]))
+   else if (regno < ARRAY_SIZE(regoff))
addr = (unsigned long *)(task->thread.esp0 + regoff[regno]);
else
return 0;
@@ -93,7 +93,7 @@ static inline int put_reg(struct task_struct *task, int regno,
 
if (regno == PT_USP)
addr = &task->thread.usp;
-   else if (regno < sizeof(regoff)/sizeof(regoff[0]))
+   else if (regno < ARRAY_SIZE(regoff))
addr = (unsigned long *)(task->thread.esp0 + regoff[regno]);
else
return -1;
diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 759fa24..a27a4fa 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -1011,7 +1011,7 @@ EXPORT_SYMBOL(dump_stack);
 void bad_super_trap (struct frame *fp)
 {
console_verbose();
-   if (fp->ptregs.vector < 4*sizeof(vec_names)/sizeof(vec_names[0]))
+   if (fp->ptregs.vector < 4 * ARRAY_SIZE(vec_names))
printk ("*** %s ***   FORMAT=%X\n",
vec_names[(fp->ptregs.vector) >> 2],
fp->ptregs.format);


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

[PATCH 2.6.20] arch PPC: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no PowerPC machine at hand.
Thanks,

diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
index 31e5118..d407007 100644
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -14,6 +14,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -654,7 +655,7 @@ void rh_dump(rh_info_t * info)
int maxnr;
int i, nr;
 
-   maxnr = sizeof(st) / sizeof(st[0]);
+   maxnr = ARRAY_SIZE(st);
 
printk(KERN_INFO
   "info @0x%p (%d slots empty / %d max)\n",
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
index d8d299b..01e48d8 100644
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -77,7 +77,7 @@ static struct mtd_partition mpc8xxads_partitions[] = {
}
 };
 
-#define mpc8xxads_part_num (sizeof (mpc8xxads_partitions) / sizeof 
(mpc8xxads_partitions[0]))
+#define mpc8xxads_part_num ARRAY_SIZE(mpc8xxads_partitions)
 
 #endif
 
diff --git a/arch/ppc/xmon/ppc-opc.c b/arch/ppc/xmon/ppc-opc.c
index 533a6c9..034313c 100644
--- a/arch/ppc/xmon/ppc-opc.c
+++ b/arch/ppc/xmon/ppc-opc.c
@@ -19,6 +19,7 @@ along with this file; see the file COPYING.  If not, write to 
the Free
 Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
*/
 
 #include 
+#include 
 #include "ansidecl.h"
 #include "ppc.h"
 
@@ -2669,8 +2670,7 @@ const struct powerpc_opcode powerpc_opcodes[] = {
 
 };
 
-const int powerpc_num_opcodes =
-  sizeof (powerpc_opcodes) / sizeof (powerpc_opcodes[0]);
+const int powerpc_num_opcodes = ARRAY_SIZE(powerpc_opcodes);
 
 /* The macro table.  This is only used by the assembler.  */
 
@@ -2717,5 +2717,4 @@ const struct powerpc_macro powerpc_macros[] = {
 
 };
 
-const int powerpc_num_macros =
-  sizeof (powerpc_macros) / sizeof (powerpc_macros[0]);
+const int powerpc_num_macros = ARRAY_SIZE(powerpc_macros);

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

[PATCH 2.6.20] arch PowerPC: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no PowerPC machine at hand.
Thanks,

diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c
index 57bf991..54b7b2b 100644
--- a/arch/powerpc/lib/rheap.c
+++ b/arch/powerpc/lib/rheap.c
@@ -14,6 +14,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -670,7 +671,7 @@ void rh_dump(rh_info_t * info)
int maxnr;
int i, nr;
 
-   maxnr = sizeof(st) / sizeof(st[0]);
+   maxnr = ARRAY_SIZE(st);
 
printk(KERN_INFO
   "info @0x%p (%d slots empty / %d max)\n",
diff --git a/arch/powerpc/xmon/ppc-opc.c b/arch/powerpc/xmon/ppc-opc.c
index 5d841f4..af3780e 100644
--- a/arch/powerpc/xmon/ppc-opc.c
+++ b/arch/powerpc/xmon/ppc-opc.c
@@ -21,6 +21,7 @@
02110-1301, USA.  */
 
 #include 
+#include 
 #include "nonstdio.h"
 #include "ppc.h"
 
@@ -4932,8 +4933,7 @@ const struct powerpc_opcode powerpc_opcodes[] = {
 
 };
 
-const int powerpc_num_opcodes =
-  sizeof (powerpc_opcodes) / sizeof (powerpc_opcodes[0]);
+const int powerpc_num_opcodes = ARRAY_SIZE(powerpc_opcodes);
 
 /* The macro table.  This is only used by the assembler.  */
 
@@ -4989,5 +4989,4 @@ const struct powerpc_macro powerpc_macros[] = {
 { "clrlslwi.",4,  PPCCOM,  "rlwinm. %0,%1,%3,(%2)-(%3),31-(%3)" },
 };
 
-const int powerpc_num_macros =
-  sizeof (powerpc_macros) / sizeof (powerpc_macros[0]);
+const int powerpc_num_macros = ARRAY_SIZE(powerpc_macros);
diff --git a/arch/powerpc/xmon/spu-opc.c b/arch/powerpc/xmon/spu-opc.c
index efffde9..530df3d 100644
--- a/arch/powerpc/xmon/spu-opc.c
+++ b/arch/powerpc/xmon/spu-opc.c
@@ -18,6 +18,7 @@
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.  */
 
+#include 
 #include "spu.h"
 
 /* This file holds the Spu opcode table */
@@ -40,5 +41,4 @@ const struct spu_opcode spu_opcodes[] = {
 #undef APUOPFB
 };
 
-const int spu_num_opcodes =
-  sizeof (spu_opcodes) / sizeof (spu_opcodes[0]);
+const int spu_num_opcodes = ARRAY_SIZE(spu_opcodes);


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

[PATCH 2.6.20] arch MIPS: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no MIPS board at hand.
Thanks,

diff --git a/arch/mips/jmr3927/rbhma3100/setup.c 
b/arch/mips/jmr3927/rbhma3100/setup.c
index 138f25e..7ca3d6d 100644
--- a/arch/mips/jmr3927/rbhma3100/setup.c
+++ b/arch/mips/jmr3927/rbhma3100/setup.c
@@ -434,7 +434,7 @@ void __init tx3927_setup(void)
 
/* DMA */
tx3927_dmaptr->mcr = 0;
-   for (i = 0; i < sizeof(tx3927_dmaptr->ch) / 
sizeof(tx3927_dmaptr->ch[0]); i++) {
+   for (i = 0; i < ARRAY_SIZE(tx3927_dmaptr->ch); i++) {
/* reset channel */
tx3927_dmaptr->ch[i].ccr = TX3927_DMA_CCR_CHRST;
tx3927_dmaptr->ch[i].ccr = 0;
diff --git a/arch/mips/arc/identify.c b/arch/mips/arc/identify.c
index 3ba7c47..4b90736 100644
--- a/arch/mips/arc/identify.c
+++ b/arch/mips/arc/identify.c
@@ -77,7 +77,7 @@ static struct smatch * __init string_to_mach(const char *s)
 {
int i;
 
-   for (i = 0; i < (sizeof(mach_table) / sizeof (mach_table[0])); i++) {
+   for (i = 0; i < ARRAY_SIZE(mach_table); i++) {
if (!strcmp(s, mach_table[i].arcname))
return &mach_table[i];
}
diff --git a/arch/mips/mips-boards/atlas/atlas_int.c 
b/arch/mips/mips-boards/atlas/atlas_int.c
index 43dba6c..4929f4d 100644
--- a/arch/mips/mips-boards/atlas/atlas_int.c
+++ b/arch/mips/mips-boards/atlas/atlas_int.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -220,7 +221,7 @@ msc_irqmap_t __initdata msc_irqmap[] = {
{MSC01C_INT_TMR,MSC01_IRQ_EDGE, 0},
{MSC01C_INT_PCI,MSC01_IRQ_LEVEL, 0},
 };
-int __initdata msc_nr_irqs = sizeof(msc_irqmap) / sizeof(*msc_irqmap);
+int __initdata msc_nr_irqs = ARRAY_SIZE(msc_irqmap);
 
 msc_irqmap_t __initdata msc_eicirqmap[] = {
{MSC01E_INT_SW0,MSC01_IRQ_LEVEL, 0},
@@ -231,7 +232,7 @@ msc_irqmap_t __initdata msc_eicirqmap[] = {
{MSC01E_INT_PERFCTR,MSC01_IRQ_LEVEL, 0},
{MSC01E_INT_CPUCTR, MSC01_IRQ_LEVEL, 0}
 };
-int __initdata msc_nr_eicirqs = sizeof(msc_eicirqmap) / sizeof(*msc_eicirqmap);
+int __initdata msc_nr_eicirqs = ARRAY_SIZE(msc_eicirqmap);
 
 void __init arch_init_irq(void)
 {
diff --git a/arch/mips/mips-boards/malta/malta_int.c 
b/arch/mips/mips-boards/malta/malta_int.c
index 90ad5bf..b28edf5 100644
--- a/arch/mips/mips-boards/malta/malta_int.c
+++ b/arch/mips/mips-boards/malta/malta_int.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -289,7 +290,7 @@ msc_irqmap_t __initdata msc_irqmap[] = {
{MSC01C_INT_TMR,MSC01_IRQ_EDGE, 0},
{MSC01C_INT_PCI,MSC01_IRQ_LEVEL, 0},
 };
-int __initdata msc_nr_irqs = sizeof(msc_irqmap)/sizeof(msc_irqmap_t);
+int __initdata msc_nr_irqs = ARRAY_SIZE(msc_irqmap);
 
 msc_irqmap_t __initdata msc_eicirqmap[] = {
{MSC01E_INT_SW0,MSC01_IRQ_LEVEL, 0},
@@ -303,7 +304,7 @@ msc_irqmap_t __initdata msc_eicirqmap[] = {
{MSC01E_INT_PERFCTR,MSC01_IRQ_LEVEL, 0},
{MSC01E_INT_CPUCTR, MSC01_IRQ_LEVEL, 0}
 };
-int __initdata msc_nr_eicirqs = sizeof(msc_eicirqmap)/sizeof(msc_irqmap_t);
+int __initdata msc_nr_eicirqs = ARRAY_SIZE(msc_eicirqmap);
 
 void __init arch_init_irq(void)
 {
diff --git a/arch/mips/pci/fixup-vr4133.c b/arch/mips/pci/fixup-vr4133.c
index 597b897..6e09f38 100644
--- a/arch/mips/pci/fixup-vr4133.c
+++ b/arch/mips/pci/fixup-vr4133.c
@@ -17,6 +17,7 @@
  */
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -142,7 +143,7 @@ int rockhopper_get_irq(struct pci_dev *dev, u8 pin, u8 slot)
if (bus == NULL)
return -1;
 
-   for (i = 0; i < sizeof (int_map) / sizeof (int_map[0]); i++) {
+   for (i = 0; i < ARRAY_SIZE(int_map); i++) {
if (int_map[i].bus == bus->number && int_map[i].slot == slot) {
int line;
for (line = 0; line < 4; line++)

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

[PATCH 2.6.20] arch V850: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no V850 board at hand.
Thanks,

diff --git a/arch/v850/kernel/anna.c b/arch/v850/kernel/anna.c
index 40892d3..0e42904 100644
--- a/arch/v850/kernel/anna.c
+++ b/arch/v850/kernel/anna.c
@@ -114,7 +114,7 @@ static struct v850e_intc_irq_init irq_inits[] = {
{ "ST",  IRQ_INTST(0),  IRQ_INTST_NUM,  3, 5 },
{ 0 }
 };
-#define NUM_IRQ_INITS ((sizeof irq_inits / sizeof irq_inits[0]) - 1)
+#define NUM_IRQ_INITS (ARRAY_SIZE(irq_inits) - 1)
 
 static struct hw_interrupt_type hw_itypes[NUM_IRQ_INITS];
 
diff --git a/arch/v850/kernel/as85ep1.c b/arch/v850/kernel/as85ep1.c
index 5352f8a..18437bc 100644
--- a/arch/v850/kernel/as85ep1.c
+++ b/arch/v850/kernel/as85ep1.c
@@ -142,7 +142,7 @@ static struct v850e_intc_irq_init irq_inits[] = {
{ "ST",  IRQ_INTST(0),  IRQ_INTST_NUM,  3, 5 },
{ 0 }
 };
-#define NUM_IRQ_INITS ((sizeof irq_inits / sizeof irq_inits[0]) - 1)
+#define NUM_IRQ_INITS (ARRAY_SIZE(irq_inits) - 1)
 
 static struct hw_interrupt_type hw_itypes[NUM_IRQ_INITS];
 
diff --git a/arch/v850/kernel/fpga85e2c.c b/arch/v850/kernel/fpga85e2c.c
index cb04a69..5c49235 100644
--- a/arch/v850/kernel/fpga85e2c.c
+++ b/arch/v850/kernel/fpga85e2c.c
@@ -138,7 +138,7 @@ struct v850e_intc_irq_init irq_inits[] = {
{ "RPU", IRQ_RPU(0),IRQ_RPU_NUM,1, 6 },
{ 0 }
 };
-#define NUM_IRQ_INITS ((sizeof irq_inits / sizeof irq_inits[0]) - 1)
+#define NUM_IRQ_INITS (ARRAY_SIZE(irq_inits) - 1)
 
 struct hw_interrupt_type hw_itypes[NUM_IRQ_INITS];
 
diff --git a/arch/v850/kernel/gbus_int.c b/arch/v850/kernel/gbus_int.c
index 25d636e..b2bcc25 100644
--- a/arch/v850/kernel/gbus_int.c
+++ b/arch/v850/kernel/gbus_int.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -36,7 +37,7 @@ struct used_gint {
{ 1, GBUS_INT_PRIORITY_HIGH },
{ 3, GBUS_INT_PRIORITY_LOW }
 };
-#define NUM_USED_GINTS (sizeof used_gint / sizeof used_gint[0])
+#define NUM_USED_GINTS ARRAY_SIZE(used_gint)
 
 /* A table of which GINT is used by each GBUS interrupts (they are
assigned based on priority).  */
@@ -231,8 +232,7 @@ struct gbus_int_irq_init gbus_irq_inits[] __initdata = {
{ "GBUS_INT", IRQ_GBUS_INT(0), IRQ_GBUS_INT_NUM, 1, 6},
{ 0 }
 };
-#define NUM_GBUS_IRQ_INITS  \
-   ((sizeof gbus_irq_inits / sizeof gbus_irq_inits[0]) - 1)
+#define NUM_GBUS_IRQ_INITS (ARRAY_SIZE(gbus_irq_inits) - 1)
 
 static struct hw_interrupt_type gbus_hw_itypes[NUM_GBUS_IRQ_INITS];
 
diff --git a/arch/v850/kernel/ma.c b/arch/v850/kernel/ma.c
index 2aa8ab0..143774d 100644
--- a/arch/v850/kernel/ma.c
+++ b/arch/v850/kernel/ma.c
@@ -43,7 +43,7 @@ static struct v850e_intc_irq_init irq_inits[] = {
{ "ST",  IRQ_INTST(0),  IRQ_INTST_NUM,  4, 5 },
{ 0 }
 };
-#define NUM_IRQ_INITS ((sizeof irq_inits / sizeof irq_inits[0]) - 1)
+#define NUM_IRQ_INITS (ARRAY_SIZE(irq_inits) - 1)
 
 static struct hw_interrupt_type hw_itypes[NUM_IRQ_INITS];
 
diff --git a/arch/v850/kernel/me2.c b/arch/v850/kernel/me2.c
index 14b0c88..38be5c1 100644
--- a/arch/v850/kernel/me2.c
+++ b/arch/v850/kernel/me2.c
@@ -44,7 +44,7 @@ static struct v850e_intc_irq_init irq_inits[] = {
{ "UBTITO", IRQ_INTUBTITO(0), IRQ_INTUBTITO_NUM, 5, 4 },
{ 0 }
 };
-#define NUM_IRQ_INITS ((sizeof irq_inits / sizeof irq_inits[0]) - 1)
+#define NUM_IRQ_INITS (ARRAY_SIZE(irq_inits) - 1)
 
 static struct hw_interrupt_type hw_itypes[NUM_IRQ_INITS];
 
diff --git a/arch/v850/kernel/rte_cb.c b/arch/v850/kernel/rte_cb.c
index 0f7f6cd..43018e1 100644
--- a/arch/v850/kernel/rte_cb.c
+++ b/arch/v850/kernel/rte_cb.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -176,8 +177,7 @@ static struct gbus_int_irq_init gbus_irq_inits[] = {
 #endif
{ 0 }
 };
-#define NUM_GBUS_IRQ_INITS  \
-   ((sizeof gbus_irq_inits / sizeof gbus_irq_inits[0]) - 1)
+#define NUM_GBUS_IRQ_INITS (ARRAY_SIZE(gbus_irq_inits) - 1)
 
 static struct hw_interrupt_type gbus_hw_itypes[NUM_GBUS_IRQ_INITS];
 
diff --git a/arch/v850/kernel/rte_mb_a_pci.c b/arch/v850/kernel/rte_mb_a_pci.c
index 35213fa..35a4bd5 100644
--- a/arch/v850/kernel/rte_mb_a_pci.c
+++ b/arch/v850/kernel/rte_mb_a_pci.c
@@ -70,8 +70,7 @@ static struct mb_pci_dev_irq mb_pci_dev_irqs[] = {
/* PCI slot 2 */
{ 9,IRQ_MB_A_PCI2(0),   1 }
 };
-#define NUM_MB_PCI_DEV_IRQS \
-  (sizeof mb_pci_dev_irqs / sizeof mb_pci_dev_irqs[0])
+#define NUM_MB_PCI_DEV_IRQS ARRAY_SIZE(mb_pci_dev_irqs)
 
 
 /* PCI configuration primitives.  */
diff --git a/arch/v850/kernel/rte_me2_cb.c b/arch/v850/kernel/rte_me2_cb.c
index 3be355a..46803d4 100644
--- a/arch/v850/kernel/rte_me2_cb.c
+++ b/arch/v850/kernel/rte_me2_cb.c
@@ -170,8 +170,7 @@ static struct cb_pic_irq_init cb_pic_irq_inits[] = {
{ "CB_EXTTM2",   IRQ_CB_EXTTM2,   1, 1, 6 },
{ 0 }
 

[PATCH 2.6.20] arch M68KNOMMU: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no M68KNOMMU board at hand.
Thanks,

diff --git a/arch/m68knommu/kernel/ptrace.c b/arch/m68knommu/kernel/ptrace.c
index 9130119..72d3496 100644
--- a/arch/m68knommu/kernel/ptrace.c
+++ b/arch/m68knommu/kernel/ptrace.c
@@ -62,7 +62,7 @@ static inline long get_reg(struct task_struct *task, int 
regno)
 
if (regno == PT_USP)
addr = &task->thread.usp;
-   else if (regno < sizeof(regoff)/sizeof(regoff[0]))
+   else if (regno < ARRAY_SIZE(regoff))
addr = (unsigned long *)(task->thread.esp0 + regoff[regno]);
else
return 0;
@@ -79,7 +79,7 @@ static inline int put_reg(struct task_struct *task, int regno,
 
if (regno == PT_USP)
addr = &task->thread.usp;
-   else if (regno < sizeof(regoff)/sizeof(regoff[0]))
+   else if (regno < ARRAY_SIZE(regoff))
addr = (unsigned long *) (task->thread.esp0 + regoff[regno]);
else
return -1;
diff --git a/arch/m68knommu/kernel/traps.c b/arch/m68knommu/kernel/traps.c
index 9129b3a..bed5f47 100644
--- a/arch/m68knommu/kernel/traps.c
+++ b/arch/m68knommu/kernel/traps.c
@@ -158,7 +158,7 @@ void show_stack(struct task_struct *task, unsigned long 
*stack)
 void bad_super_trap(struct frame *fp)
 {
console_verbose();
-   if (fp->ptregs.vector < 4*sizeof(vec_names)/sizeof(vec_names[0]))
+   if (fp->ptregs.vector < 4 * ARRAY_SIZE(vec_names))
printk (KERN_WARNING "*** %s ***   FORMAT=%X\n",
vec_names[(fp->ptregs.vector) >> 2],
fp->ptregs.format);

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

[PATCH 2.6.20] arch CRIS: user ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi all,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked since I have no CRIS machine at hand.

diff --git a/arch/cris/arch-v10/drivers/axisflashmap.c 
b/arch/cris/arch-v10/drivers/axisflashmap.c
index ffade19..c5d90fc 100644
--- a/arch/cris/arch-v10/drivers/axisflashmap.c
+++ b/arch/cris/arch-v10/drivers/axisflashmap.c
@@ -359,8 +359,7 @@ static struct mtd_info *flash_probe(void)
 * So we use the MTD concatenation layer instead of further
 * complicating the probing procedure.
 */
-   mtd_cse = mtd_concat_create(mtds,
-   sizeof(mtds) / sizeof(mtds[0]),
+   mtd_cse = mtd_concat_create(mtds, ARRAY_SIZE(mtds), 
"cse0+cse1");
 #else
printk(KERN_ERR "%s and %s: Cannot concatenate due to kernel "
diff --git a/arch/cris/mm/tlb.c b/arch/cris/mm/tlb.c
index 0df390a..c4a98e2 100644
--- a/arch/cris/mm/tlb.c
+++ b/arch/cris/mm/tlb.c
@@ -8,6 +8,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #define D(x)
@@ -100,7 +101,7 @@ tlb_init(void)
 
/* clear the page_id map */
 
-   for (i = 1; i < sizeof (page_id_map) / sizeof (page_id_map[0]); i++)
+   for (i = 1; i < ARRAY_SIZE(page_id_map); i++)
page_id_map[i] = NULL;

/* invalidate the entire TLB */

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

[PATCH 2.6.20] arch AVR32: Use ARRAY_SIZE macro when appropriate

[Ahmed S. Darwish]

Hi Haavard,

A patch to use ARRAY_SIZE macro already defined in linux/kernel.h

Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile checked cause I have no AVR32 machine at hand.
Thanks,

diff --git a/arch/avr32/kernel/setup.c b/arch/avr32/kernel/setup.c
index a342116..c6734ae 100644
--- a/arch/avr32/kernel/setup.c
+++ b/arch/avr32/kernel/setup.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -174,8 +175,7 @@ static int __init parse_tag_mem_range(struct tag *tag,
 * Copy the data so the bootmem init code doesn't need to care
 * about it.
 */
-   if (mem_range_next_free >=
-   (sizeof(mem_range_cache) / sizeof(mem_range_cache[0])))
+   if (mem_range_next_free >= ARRAY_SIZE(mem_range_cache))
panic("Physical memory map too complex!\n");
 
new = &mem_range_cache[mem_range_next_free++];

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

[PATCH 00] A series of patches to use ARRAY_SIZE macro under arch/

[Ahmed S. Darwish]

Hi, all

A series of patches to use ARRAY_SIZE macro under the `arch' subtree. 
Each architecture has its own mail/patch as a reply to this thread.
Those patches are not compile-tested as I don't have needed machines but
I tried hard to make sure that they are hopefully correct.
Patches can be applied cleanly on 2.6.20.

arm/kernel/ecard.c   |2 +-
arm26/kernel/ecard.c |2 +-
avr32/kernel/setup.c |4 ++--
cris/arch-v10/drivers/axisflashmap.c |3 +--
cris/mm/tlb.c|3 ++-
m68k/kernel/ptrace.c |4 ++--
m68k/kernel/traps.c  |2 +-
m68knommu/kernel/ptrace.c|4 ++--
m68knommu/kernel/traps.c |2 +-
mips/arc/identify.c  |2 +-
mips/jmr3927/rbhma3100/setup.c   |2 +-
mips/mips-boards/atlas/atlas_int.c   |5 +++--
mips/mips-boards/malta/malta_int.c   |5 +++--
mips/pci/fixup-vr4133.c  |3 ++-
powerpc/lib/rheap.c  |3 ++-
powerpc/xmon/ppc-opc.c   |7 +++
powerpc/xmon/spu-opc.c   |4 ++--
ppc/lib/rheap.c  |3 ++-
ppc/syslib/m8xx_setup.c  |2 +-
ppc/xmon/ppc-opc.c   |7 +++
v850/kernel/anna.c   |2 +-
v850/kernel/as85ep1.c|2 +-
v850/kernel/fpga85e2c.c  |2 +-
v850/kernel/gbus_int.c   |6 +++---
v850/kernel/ma.c |2 +-
v850/kernel/me2.c|2 +-
v850/kernel/rte_cb.c |4 ++--
v850/kernel/rte_mb_a_pci.c   |3 +--
v850/kernel/rte_me2_cb.c |3 +--
v850/kernel/teg.c|2 +-
30 files changed, 49 insertions(+), 48 deletions(-)

Thanks,
-- 
Ahmed S. Darwish
http://darwish-07.blogspot.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/

[ANNOUNCE][RFC] PlugSched-6.5 for 2.6.20

[Peter Williams]

The main change in this version is a change to the scheduler driver 
interface to take account of recent changes to the load balancing code.


A patch for 2.6.20 is available at:



Very Brief Documentation:

You can select a default scheduler at kernel build time.  If you wish to
boot with a scheduler other than the default it can be selected at boot
time by adding:

cpusched=

to the boot command line where  is one of: ingosched,
ingo_ll, nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs
or zaphod.  If you don't change the default when you build the kernel
the default scheduler will be ingosched (which is the normal scheduler).

The scheduler in force on a running system can be determined by the
contents of:

/proc/scheduler

Control parameters for the scheduler can be read/set via files in:

/sys/cpusched//

Peter
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce

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

Re: [Cbe-oss-dev] [PATCH 0/7] RFC: Cell SPE logos

[Benjamin Herrenschmidt]

On Sun, 2007-02-04 at 14:32 +0100, Pavel Machek wrote:
> Hi1
> 
> > I would like to hear your opinions about the patchset below (updated version
> > compared to yesterday, lkml added to the CC list).
> 
> Can you just blast these pictures from userspace? There's really no
> excuse to advertise SPEs from kernel
> 
> What's next, I have powerful Intel graphics chipset in here, perhaps
> it is as powerful as SPE, shall I start adding little pictures for its
> pipelines?

By the same token, there is no excuse to have the logo code at all in
the kernel in the first place... it's cool though :-) And it's a config
option, so you don't have to have it

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: ntp

[zhangxiliang]

Hello.
When I use the ntpd service, I see if I use the client attempt to connect 
the server repeat before the server is ready, the ntpd on server can not be 
ready all the times.

Sometimes the waiting time maybe very long.

- Original Message - 
From: "Matti Aarnio" <[EMAIL PROTECTED]>
To: "zhangxiliang" <[EMAIL PROTECTED]>
Cc: "Linux Kernel Mailing List" 
Sent: Friday, February 02, 2007 5:10 PM
Subject: Re: ntp


> On Fri, Feb 02, 2007 at 04:47:26PM +0800, zhangxiliang wrote:
>> When i start the ntp service successful on server, the client must
>> ntpdate with the server after waiting a moment.
>> The moment may be 3~5 minutes, or it may be 10~15 minutes. I don't
>> know why it happens?
>
> The  ntp server  takes several external clock comparisons to know its
> local running environments (hosts) clock behaviour.
>
> Before it knows that, it has no real knowledge of what the time is,
> and it won't report anything out.
>
> In my environments I have couple local machines (usually doing
> something else too) assigned as network local NTP servers, and
> all other machines refer to them.
>
>
>> Regards
>> Zhang Xiliang
>> MAIL:[EMAIL PROTECTED]
>
> /Matti Aarnio
> 



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] drivers/isdn/gigaset: new M101 driver

[Tilman Schmidt]

Am 04.02.2007 02:56 schrieb Andrew Morton:
> On Sun, 04 Feb 2007 02:32:41 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> 
 +  spin_lock_irqsave(&cs->cmdlock, flags);
 +  cb = cs->cmdbuf;
 +  spin_unlock_irqrestore(&cs->cmdlock, flags);
>>> It is doubtful if the locking here does anything useful.
>> It assures atomicity when reading the cs->cmdbuf pointer.
> 
> I think it's bogus.  If the quantity being copied here is more than 32-bits
> then yes, a lock is appropriate.  But if it's a single word then it's
> unlikely that the locking does anything useful.  Or there might be a bug
> here.

It's a pointer. Are reads and writes of pointer sized objects
guaranteed to be atomic on every platform? If so, I'll happily
omit the locking.

 +  spin_lock_irqsave(&cs->cmdlock, flags);
 +  cb->prev = cs->lastcmdbuf;
 +  if (cs->lastcmdbuf)
 +  cs->lastcmdbuf->next = cb;
 +  else {
 +  cs->cmdbuf = cb;
 +  cs->curlen = len;
 +  }
 +  cs->cmdbytes += len;
 +  cs->lastcmdbuf = cb;
 +  spin_unlock_irqrestore(&cs->cmdlock, flags);
>>> Would the use of list_heads simplify things here?
>> I don't think so. The operations in list.h do not keep track of
>> the total byte count, and adding that in a race-free way appears
>> non-trivial.
> 
> Maintaining a byte count isn't related to maintaining a list.

Sure. But your question was whether the list.h operations would
simplify this code. AFAICS it wouldn't, because the necessity
of maintaining the byte count would complicate a list.h based
solution beyond the current one. Also, this is part of the
interface with the components of the Gigaset driver which are
already part of the kernel. Changing this to a list_head now
would require significant changes in those other parts, too.

 +  tail = atomic_read(&inbuf->tail);
 +  head = atomic_read(&inbuf->head);
 +  gig_dbg(DEBUG_INTR, "buffer state: %u -> %u, receive %u bytes",
 +  head, tail, count);
 +
 +  if (head <= tail) {
 +  n = RBUFSIZE - tail;
 +  if (count >= n) {
 +  /* buffer wraparound */
 +  memcpy(inbuf->data + tail, buf, n);
 +  tail = 0;
 +  buf += n;
 +  count -= n;
 +  } else {
 +  memcpy(inbuf->data + tail, buf, count);
 +  tail += count;
 +  buf += count;
 +  count = 0;
 +  }
 +  }
>>> Perhaps the (fairly revolting) circ_buf.h can be used for this stuff.
>> It probably could, but IMHO readability would suffer rather than improve.
> 
> How about kernel/kfifo.c?

That would indeed fit the bill. But again, this code matches
parts of drivers/isdn/gigaset which are already in the kernel,
and changing it here would require significant corresponding
changes in those other parts.

I'll gladly consider your last two propositions (list_head for
cs->lastcmdbuf and kfifo for cs->inbuf) for a future revision of
the entire set of drivers in drivers/isdn/gigaset, but it goes
way beyond the scope of the present patch, which merely aims at
adding the missing M101 hardware driver.

Thanks,
Tilman

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



signature.asc
Description: OpenPGP digital signature

Re: Bcm43xx oops after suspend to disk

[Rafael J. Wysocki]

On Sunday, 4 February 2007 18:42, Larry Finger wrote:
> roucaries bastien wrote:
> > 
> > Sorry for the delay it works. This time I can use iwlist eth scan.
> > I have some difficulties to associate and I need to rmmod/modprobe in
> > order to associate but it is another problem linked to a really weak
> > power.
> 
> Bastien,
> 
> Please try this patch instead.

Hm, it doesn't seem to apply to the mainline version of the driver.  Any chance
for a fix against 2.6.20?

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

2.6.20 PCI Cannot allocate resource region 2

[Manu Abraham]

Hi,

I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
the message is slightly different in 2.6.17.7)

PCI Cannot allocate resource region 2 of device :02:0a.0
PCI Error while updating region 000:02:0a.0/5 (f3e4 != 0200)
PCI Error while updating region 000:02:0a.0/5 (high  != 4e351)

lspci shows me a bit weird status BIST is running (on 2.6.17.7)
on 2.6.20, the line which says BIST is running, does not exist.

I have attached the lspci outputs on both 2.6.17.7 and 2.6.20

The device is a PCI 2.2 compliant device a multimedia bridge device
called Mantis.
The card is a plain 32 bit PCI card in a 32 bit PCI slot on an Asus
P4C800 motherboard.

looking at lspci output, the last 3 PCI devices are using the same chip.

The last 2 devices are Rev 1 chips, whereas the one which is acting a
bit strange is a newer version from the same vendor.

Any ideas as to why it could not allocate the region ?

Thanks,
Manu
00:00.0 0600: 8086:2578 (rev 02)
Subsystem: 1043:80f6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 0604: 8086:2579 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1d.0 0c03: 8086:24d2 (rev 02)
Subsystem: 1043:80a6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1f.0 0601: 8086:24d0 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- 
Region 1: I/O ports at 
Region 2: I/O ports at 
Region 3: I/O ports at 
Region 4: I/O ports at fc00 [size=16]
Region 5: Memory at 3000 (32-bit, non-prefetchable) [size=1K]

00:1f.2 0101: 8086:24d1 (rev 02) (prog-if 8f)
Subsystem: 1043:80a6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 

02:03.0 0c00: 1106:3044 (rev 80) (prog-if 10)
Subsystem: 1043:808a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR+  (32-bit, prefetchable) [disabled]
Region 4: Memory at  (32-bit, non-prefetchable) [disabled]
Region 5: Memory at  (64-bit, non-prefetchable) 
[disabled]
Expansion ROM at e9b01000 [disabled] [size=4K]

02:0c.0 0480: 1822:4e35 (rev 01)
Subsystem: 1822:0014
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- 00:00.0 0600: 8086:2578 (rev 02)
Subsystem: 1043:80f6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 0604: 8086:2579 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1d.0 0c03: 8086:24d2 (rev 02)
Subsystem: 1043:80a6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
Reset- FastB2B-

00:1f.0 0601: 8086:24d0 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 

02:03.0 0c00: 1106:3044 (rev 80) (prog-if 10)
Subsystem: 1043:808a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR+  (32-bit, prefetchable) [disabled]
Region 4: Memory at  (32-bit, non-prefetchable) [disabled]
Region 5: Memory at  (64-bit, non-prefetchable) 
[disabled] [size=32]
Expansion ROM at e9b01000 [disabled] [size=4K]

02:0c.0 0480: 1822:4e35 (r

RE: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)

[Zou, Nanhai]

> -Original Message-
> From: Horms [mailto:[EMAIL PROTECTED]
> Sent: 2007年2月3日 11:28
> To: Magnus Damm
> Cc: Andrew Morton; Magnus Damm; Luck, Tony; linux-ia64@vger.kernel.org; Zou,
> Nanhai; fastboot@lists.osdl.org; linux-kernel@vger.kernel.org
> Subject: Re: [Fastboot] [PATCH] kexec: Fix CONFIG_SMP=n compilation (ia64)
> 
> On Fri, Feb 02, 2007 at 08:53:00PM +0900, Magnus Damm wrote:
> > On 2/2/07, Magnus Damm <[EMAIL PROTECTED]> wrote:
> > > On 2/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > Magnus Damm <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > kexec: Fix CONFIG_SMP=n compilation (ia64)
> > > > >
> > > > > This patch makes it possible to compile kexec for ia64 without SMP
> support.
> > > > > --- 0002/arch/ia64/kernel/machine_kexec.c
> > > > > +++ work/arch/ia64/kernel/machine_kexec.c 2007-02-01
> 12:35:46.0 +0900
> > > > > @@ -70,12 +70,14 @@ void machine_kexec_cleanup(struct kimage
> > > > >
> > > > >  void machine_shutdown(void)
> > > > >  {
> > > > > +#ifdef CONFIG_SMP
> > > > >   int cpu;
> > > > >
> > > > >   for_each_online_cpu(cpu) {
> > > > >   if (cpu != smp_processor_id())
> > > > >   cpu_down(cpu);
> > > > >   }
> > > > > +#endif
> > > > >   kexec_disable_iosapic();
> > > > >  }
> > > >
> > > > hm.  I suspect this one should have been #ifndef CONFIG_HOTPLUG_CPU?
> >
> > Re-reading this I assume you mean #ifdef CONFIG_HOTPLUG_CPU.
> >
> > I would be happy to resend a new updated version of the patch, but I
> > wonder if it may be better to fail miserably during the build than
> > fail silently in the case of CONFIG_SMP=y but CONFIG_HOTPLUG_CPU=n.
> 
> There used to be alternate code for the CONFIG_SMP +
> !CONFIG_HOTPLUG_CPU, but this was removed because it was determined to
> be flakey and not maintainable (I can dig up the threads if you want).
> I think that this means that if we have CONFIG_KEXEC and CONFIG_SMP then
> CONFIG_HOTPLUG_CPU is required. I think this is expressable in Kconfig
> somehow.
> 


Yes, CONFIG_HOTPLUG_CPU is required by Kexec.
But CONFIG_HOTPLUG_CPU is not required by Kdump except SN platform.

Zou Nan hai
> --
> Horms
>   H: http://www.vergenet.net/~horms/
>   W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC

[David Miller]

From: Daniel Kabs <[EMAIL PROTECTED]>
Date: Mon, 29 Jan 2007 12:59:49 +0100

> I use unix domain datagram sockets for IPC, e.g. I receive messages by 
> calling recv().
> 
> "man 2 recv" tells me about the flags argument to a recv() call, namely:
> 
>  MSG_TRUNC
>   Return  the  real  length of the packet, even when it was longer
>   than the passed buffer. Only valid for packet sockets.
> 
> Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect 
> message truncation due to insufficient buffer size.

What part of "Only valid for packet sockets" from the manual page
escapes you?  :-))

It's a feature which only was meant to be valid for AF_PACKET sockets.

What UDP is doing is different, it's returning the full packet length
when the packet is larger then the given buffer size, but it does this
irregardless of whether you set MSG_TRUNC in the recvmsg() passed-in
flags.  UDP itself sets the MSG_TRUNC flag when it detects this
situation.

I checked the history and our AF_UNIX sockets have always behaved like
this.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] MAINTAINERS, remove two dead e-mail

[Jiri Slaby]

Bartlomiej Zolnierkiewicz napsal(a):
> On 2/4/07, Greg KH <[EMAIL PROTECTED]> wrote:
>> On Sun, Feb 04, 2007 at 12:05:17PM +0100, Jiri Slaby wrote:
>> > Please, are you experiencing this too? Maybe it's about to be 
>> removed from
>> > MAINTAINERS?
>> > Diagnostic-Code: X-Postfix; host mail.cyclades.com[64.186.161.6] 
>> said: 550
>> ><[EMAIL PROTECTED]>: Recipient address rejected: undeliverable 
>> address:
>> >host usmail.cyclades.com[64.186.161.37] said: 550 
>> [EMAIL PROTECTED]
>> >No
>> >such user (in reply to RCPT TO command) (in reply to RCPT TO 
>> command)
>>
>> Yes, I got it too.
> 
> me too
> 
> Jiri, while at it maybe you could also try to verify the situation with
> the other @cyclades.com email address from the MAINTAINERS file
> ([EMAIL PROTECTED] for pc300 driver)?

Not even this one exists
550 [EMAIL PROTECTED] No such user

--

MAINTAINERS, remove two dead e-mail

Cyclades no longer serves the 2 e-mails listed in MAINTAINERS.
Remove them and mark those entries as Orphaned.

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

---
commit 9409f7e4a66eeb82b494d1f7371808dffa51bbe0
tree e3f505b099ee60ecfade367a39a602cbd6db5085
parent e04ecea3d2a26acd32e48da422f233973a5c0dd4
author Jiri Slaby <[EMAIL PROTECTED]> Mon, 05 Feb 2007 01:43:25 +0100
committer Jiri Slaby <[EMAIL PROTECTED]> Mon, 05 Feb 2007 01:43:25 +0100

 MAINTAINERS |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index be02ad7..da74a33 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -996,14 +996,12 @@ L:[EMAIL PROTECTED]
 S: Maintained
 
 CYCLADES ASYNC MUX DRIVER
-M: [EMAIL PROTECTED]
 W: http://www.cyclades.com/
-S: Supported
+S: Orphan
 
 CYCLADES PC300 DRIVER
-M: [EMAIL PROTECTED]
 W: http://www.cyclades.com/
-S: Supported
+S: Orphan
 
 DAMA SLAVE for AX.25
 P: Joerg Reuter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] remove tcp header from tcp_v4_check (take #2)

[David Miller]

From: Frederik Deweerdt <[EMAIL PROTECTED]>
Date: Fri, 12 Jan 2007 13:55:14 +

> On Fri, Jan 12, 2007 at 01:33:09PM +, Frederik Deweerdt wrote:
> > On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
> > > 
> > >   
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc4-mm1/
> > > 
> Hi,
> 
> Sorry for the resend, I forgot the Signed-off-by line, and noticed a
> whitespace breakage in ipt_REJECT.
> The tcphdr struct passed to tcp_v4_check is not used, the following
> patch removes it from the parameter list.
> This adds the netfilter modifications missing in the patch I sent
> for rc3-mm1.
> 
> Regards,
> Frederik 
> 
> Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>

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

Re: [PATCH 2.6.19 2/2] X.25: Adds /proc/net/x25/forward to view active forwarded calls.

[David Miller]

From: ahendry <[EMAIL PROTECTED]>
Date: Thu, 04 Jan 2007 14:37:15 +1100

> View the active forwarded call list
> cat /proc/net/x25/forward
> 
> Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]>

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

Re: [PATCH] Fix d_path for lazy unmounts

[Neil Brown]

On Friday February 2, [EMAIL PROTECTED] wrote:
> Hello,
> 
> here is a bugfix to d_path. Please apply (after 2.6.20).

Looks good!  Just a couple of little comments (to prove that I have
really read it and thought about it :-)

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

Reviewed-by: NeilBrown <[EMAIL PROTECTED]>

> 
> Index: linux-2.6/fs/dcache.c
> ===
> --- linux-2.6.orig/fs/dcache.c
> +++ linux-2.6/fs/dcache.c
> @@ -1739,45 +1739,43 @@ shouldnt_be_hashed:
>   * @rootmnt: vfsmnt to which the root dentry belongs
>   * @buffer: buffer to return value in
>   * @buflen: buffer length
> + * @fail_deleted: what to return for deleted files
>   *
> - * Convert a dentry into an ASCII path name. If the entry has been deleted
> - * the string " (deleted)" is appended. Note that this is ambiguous.
> + * Convert a dentry into an ASCII path name. If the entry has been deleted,
> + * then if @fail_deleted is true, ERR_PTR(-ENOENT) is returned. Otherwise,
> + * the the string " (deleted)" is appended. Note that this is ambiguous.

The behaviour in the face of a lazy unmount should be clarified in
this comment.

And I cannot help wondering if that behaviour should - in some cases -
be 'fail'.

i.e. if sys_getcwd is called on a directory that is no longer
connected to the root, it isn't clear to me that it should return
without an error.
Without your patch it can return garbage which is clearly wrong.
With you patch it will return a relative path name, which is also
wrong (it isn't a valid path that leads to the current working directory).
I would suggest that 'fail_deleted' be (e.g.) changed to
'fail_condition' where two conditions are defined
#define DPATH_FAIL_DELETED 1
#define DPATH_FAIL_DISCONNECTED 2

and both these are passed in by sys_getcwd.


> @@ -1791,33 +1789,49 @@ static char * __d_path( struct dentry *d
>   parent = dentry->d_parent;
>   prefetch(parent);
>   namelen = dentry->d_name.len;
> - buflen -= namelen + 1;
> - if (buflen < 0)
> + if (buflen <= namelen)
>   goto Elong;

This bothers me.  You appear to be comparing buflen with namelen, but
are about the change buflen by 'namelen + 1'.  It looks like a bug.

In reality, you are comparing "buflen < namelen+1" but spelling it as
"buflen <= namelen".  I would prefer the full spelling with least room
for confusion.


> - end -= namelen;
> - memcpy(end, dentry->d_name.name, namelen);
> - *--end = '/';
> - retval = end;
> + buflen -= namelen + 1;
> + buffer -= namelen;
> + memcpy(buffer, dentry->d_name.name, namelen);
> + *--buffer = '/';

This wouldn't be my preference either.  It is important that 'buflen'
and 'buffer' move in step, but when I see
buflen -= namelen + 1;
buffer -= namelen;
it looks like they aren't.  Maybe:
> + buflen -= namelen + 1;
> + buffer -= namelen + 1;
> + memcpy(buffer+1, dentry->d_name.name, namelen);
> + *buffer = '/';

or am I being too picky?

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: regarding generic AIO, async syscalls precedent + some benchmarks by lighttpd

[Davide Libenzi]

On Sun, 4 Feb 2007, bert hubert wrote:

> >From two comments posted to my "blog"
> http://blog.netherlabs.nl/articles/2007/02/04/a-synchronous-programming
> 
> Excerpted from the diary of Dragonfly BSD,
> http://www.dragonflybsd.org/status/diary.shtml 
> 
>  Remove the asynchronous syscall interface. It was an idea before its time.
>  However, keep the formalization of the syscall arguments structures.
> 
> The original async syscall interface was committed in
> http://leaf.dragonflybsd.org/mailarchive/commits/2004-08/msg00067.html
> 
> Comment by Jan Kneschke, lighttpd developer, noting the lack of and need for
> aio_stat():
> 
>  Reading this article feels like reading the code I wrote in the last days
>  for lighttpd. Even if the network-io was async since the start
>  (non-blocking), the file-io wasn't. Worst of all was the stat() syscall
>  which doesn't have a async interface even in POSIX AIO. So it had to be
>  implemented with threads on our own. At http://www.lighttpd.net/benchmark/
>  you can see the impact of async vs. blocking syscalls.
> 
> Perhaps relevant.

Yes, that is some very interesting data IMO. I did not bench the GUASI 
(userspace async thread library) against AIO, but those numbers show that a 
*userspace* async syscall wrapper interface performs in the ballpark of AIO.
This leads to some hope about the ability to effectively deploy the kernel 
generic async AIO (being it fibril or kthreads based) as low-impact async 
provider for basically anything.



- Davide


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

Re: 2.6.20-rc6-mm3 BUG in drm_ioctl with Rage 128 card

[Dave Jones]

On Sun, Feb 04, 2007 at 02:26:59PM -0500, Eric Buddington wrote:
 > On Sun, Feb 04, 2007 at 11:00:05AM +0100, Thomas Hellstr?m wrote:
 > > Eric,
 > > Sorry for the breakage. Can you try the attached patch and see if it 
 > > fixes the problem.
 > > 
 > > /Thomas
 > 
 > Thomas,
 > 
 > Thanks! That seems to fix it:

Great.  Thomas, can you resend me that patch with a description & Signed-off-by 
?
(Also for some reason that one looks like it was MIME damaged, git-am wouldn't 
eat it)

Dave

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

Re: Free Linux Driver Development!

[Oleg Verych]

> From: devzero web.de
> Newsgroups: gmane.linux.kernel
> Subject: Re: Free Linux Driver Development!
> Date: Sun, 04 Feb 2007 22:37:33 +0100
> Organization: http://freemail.web.de/
> Archived-At: 

> First off, compliments to this announcement, I liked it very much!
>
> Some comment regarding those "volunteers, waiting to get some real work" :)
>
>> > OK, but why isn't your army of volunteers fixing them?
>
>> They don't know about them, or they don't have the hardware to test?
>> Seriously, let the kernel-janitor's project know about any issues you
>> have and they will be glad to jump on it.  Those people are just
>> chomping a the bit to do something a bit bigger than "compiler warning
>> cleanups" :)
>
> So many times i have seen good ideas brought up, kernel patches being 
> written, posted to lkml, being developed outside mainline for a while and 
> then being forgotten some time later due to lack of energy of some individual 
> to get this into mainline.
>
> If there is an noticeably number of talented programmers (unfortunately, i`m 
> not) , so why not "feeding" them the right way ? Where is those public and 
> transparent and moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, 
> sorted by priorities, with sort of a "vote for this feature"-button, so those 
> guys have something they can pick up? There is so much great stuff and ideas 
> out there where they could put their work onto or getting involved, it just 
> needs to be found or sort of being "managed" a little bit better.
>
> For myself, i`m waiting for so quite some things to get "one step further", 
> but they are more or less tied to some single individuals, for which you just 
> cannot send some "hey, what`s up with your project"-message every second day. 
> The interest in many nice projects often is quite low and evolution quite 
> slow, but not only because of the fact that they aren`t great, but more 
> because of not getting widely known. It`s not always missing specs, it`s also 
> some missing noise/feedback for different features or missing of some 
> "driving force" to bring things forward. How should one developer know that 
> somebody needs a feature if those who could probably need it don`t request 
> it? Maybe just because of the fact that they even imagine that such feature 
> would be possible ?
>
> Where is those efforts for fixing/integrating fantastic cowloop?
> What about badram/badmem patch ?
> Compressed Ccaching ?
> Somebody helping with development of dm-loop or extend loop.c to support more 
> than 256 devices ?
> Replacement of proprietary, unstable and unelegant vmware-lopp for being able 
> to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace 
> could be some infrastructure for this, but the author seems to have other 
> priorities
> dm-cow, zfs-fuse - anybody ?
> Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent 
> implementations, but both got stuck at some early experimental stage) 

A quick answer for philosophers:
   

For example, i don't know if somebody volunteered to be a bug-buddy in
google, see Andrew's 2.6.20-rc6-mm1 announcement. It seems no, as he
still forwards bugzilla reports to developers/maintainers.

I myself am new. But anyway, i can write a little bit of HOWTO

-- effectively handle (among others) LKML, to break free from myths,

-- to not afraid emacs as good editor for issues like symbol-searching (TAGS),
   whitespace, spell (typos) and such,

-- having linux tree up-today with small bandwidth: mirrors, patches, quilt

of course if such things prevent people from participating.

[:(ot) As for Greg's message, imho somebody was bored. There is plenty  ;]
[: of work *in* the kernel, not only in drivers/ related part of it...  ;]

> Just my 2 cents. 

So my.


Greetings.
--
-o--=O`C  info emacs : not found  /. .\ ( is there any reason to live? )
 #oo'L O  info make  : not found  o (yes --- R.I.P. FSF+RMS)
<___=E M  man gcc: not found`-- ( viva Debian Operating System )

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

Re: Timeouts on ICH7 PATA drive with ata_piix; ide_generic worksperfectly

[Keenan Pepper]

Tejun Heo wrote:

* Does putting in a readable CD or DVD make any difference?


Yes, I ran for an hour with an audio CD in the drive and there were no timeouts.


* Does the problem occur in single mode where no HAL or whatever is running?


No, there were no timeouts in single mode even without a CD in the drive.


Auch, scrap the last paragraph. You actually did. Sorry about that. ;-)


Well, partly my fault for letting Gmail give it the wrong MIME type.
Should have made the filenames end in .txt.


I see your controller is ICH7 and the errors are over ten minutes apart.
It really seems that HAL, smartd, hddtemp or whatever is poking the dvd
writer and it isn't happy about it. In addition to the above questions,
you can read cd/dvd's using the drive, right?


Yes, the optical drive itself works great; I can even burn DVDs.

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

Re: Unexpected Acknowledgement / Stalled Connections

[Parag Warudkar]

On 2/4/07, Parag Warudkar <[EMAIL PROTECTED]> wrote:

I am running 2.6.20 and have trouble with stalled connections. For
instance, if I try to download a debian ISO image using wget, the
connection runs fine for few seconds and then stalls for ever.

In my router logs I see a ton of messages like the below -

[INFO] Sun Feb 04 17:22:03 2007 Blocked incoming TCP packet from
192.168.0.174:34090 to 130.239.18.138:80 with unexpected
acknowledgement 3269301836 (expected 3269343453 to 3269408989)

Where 192.168.0.174 is my laptop running FC6 and kernel 2.6.20 and
130.239.18.138 is whatever cdimage.debian.org resolves to atm.

What's going on here? Any TCP/IP tunable that I can set/turn on/off to
prevent this from happening?


Turning tcp_sack off seems to cure it. Turning it on again makes the
connections stall. Seems like the D-Link router doesn't like the SACKs
linux sends?

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

regarding generic AIO, async syscalls precedent + some benchmarks by lighttpd

[bert hubert]

>From two comments posted to my "blog"
http://blog.netherlabs.nl/articles/2007/02/04/a-synchronous-programming

Excerpted from the diary of Dragonfly BSD,
http://www.dragonflybsd.org/status/diary.shtml 

 Remove the asynchronous syscall interface. It was an idea before its time.
 However, keep the formalization of the syscall arguments structures.

The original async syscall interface was committed in
http://leaf.dragonflybsd.org/mailarchive/commits/2004-08/msg00067.html

Comment by Jan Kneschke, lighttpd developer, noting the lack of and need for
aio_stat():

 Reading this article feels like reading the code I wrote in the last days
 for lighttpd. Even if the network-io was async since the start
 (non-blocking), the file-io wasn't. Worst of all was the stat() syscall
 which doesn't have a async interface even in POSIX AIO. So it had to be
 implemented with threads on our own. At http://www.lighttpd.net/benchmark/
 you can see the impact of async vs. blocking syscalls.

Perhaps relevant.

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

[Davide Libenzi]

On Sun, 4 Feb 2007, Jakub Jelinek wrote:

> On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
> > Arjan van de Ven wrote:
> > >>Because user threading can avoid context switches, there will always be 
> > >>cases where it will outperform o/s threads for hardware reasons.
> > >
> > >actually.. switching from one "real" thread to another in Linux is not
> > >an actual context switch in the hardware sense... at least this part of
> > >your argument seems to be incorrect ;)
> > >
> > How does that work? Switching between kernel threads requires going into 
> > the kernel, user level thread switches are all done in user mode.
> > 
> > Do you have some way to change o/s threads w/o going into the kernel?
> 
> But going into kernel is not very expensive on Linux.
> 
> On the other side, the overhead you need to add for every single syscall
> that might block for the M:N threads and the associated complications
> which make it far harder to conform to POSIX IMHO far outweight the costs
> of going into the kernel for a context switch.

Agreed, definitely. A libpcl (using swapcontext(3)) cobench is about 50 
times faster than an context switch measured by lmbench (although I have 
serious doubts about about the ability of lat_ctx to measure it - but 
that's another story) on an Opteron 254. One may say "Wow! Really?!?".
The point is, who cares. We are talking about differences between 
super-fast (~2us) and ultra-fast (~0.04us).
The time (and code) that you'll have to drop in the syscall path to handle 
M:N is very likely to make you lose way more of what you gain by avoiding 
an OS context switch (a "soft" context switch you still have to do it).
Either use N:N (requires locking, but spread over multiple CPUs) or 1:N 
(I/O driven state machines or coroutines - no locking, once-CPU bound).



- Davide


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

Re: 2.6.20-rc7 regression on intel-agp

[Dave Jones]

On Sun, Feb 04, 2007 at 01:08:46PM -0800, Randy Dunlap wrote:
 > On Sun, 04 Feb 2007 22:00:16 +0100 Eric Piel wrote:
 > 
 > > 04.02.2007 18:18, Dave Jones wrote/a écrit:
 > > > On Sun, Feb 04, 2007 at 04:51:38PM +0100, Eric Piel wrote:
 > > >  > Hello,
 > > >  > 
 > > >  > I've got a regression in 2.6.20-rc7 (-rc6 was fine) due to commit 
 > > >  > 4b95320fc4d21b0ff2f8604305dd6c851aff6096 ([AGPGART] intel_agp: 
 > > > restore 
 > > >  > graphics device's pci space early in resume).
 > > :
 > > > 
 > > > There's an ugly patch below which does the latter. Give it a try?
 > > Thanks a lot, this made the trick... to some extends at least. I can 
 > > suspend to disk and resume fine. The framebuffer is not garble neither, 
 > > however nothing is displayed after resuming :-S Well, it's probably 
 > > enough to be applied before 2.6.20.
 > 
 > Missed that.  Please send it to [EMAIL PROTECTED] .

Done.  It's also in agpgart.git, waiting for Linus to pull when
he's ready to open the floodgates for .21 again.

Dave

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

Unexpected Acknowledgement / Stalled Connections

[Parag Warudkar]

I am running 2.6.20 and have trouble with stalled connections. For
instance, if I try to download a debian ISO image using wget, the
connection runs fine for few seconds and then stalls for ever.

In my router logs I see a ton of messages like the below -

[INFO] Sun Feb 04 17:22:03 2007 Blocked incoming TCP packet from
192.168.0.174:34090 to 130.239.18.138:80 with unexpected
acknowledgement 3269301836 (expected 3269343453 to 3269408989)

Where 192.168.0.174 is my laptop running FC6 and kernel 2.6.20 and
130.239.18.138 is whatever cdimage.debian.org resolves to atm.

What's going on here? Any TCP/IP tunable that I can set/turn on/off to
prevent this from happening?

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

Re: More pata_ stuff

[Alan]

On Sun, 4 Feb 2007 20:59:23 +0100
"Patrick Ale" <[EMAIL PROTECTED]> wrote:

> On 2/4/07, Patrick Ale <[EMAIL PROTECTED]> wrote:
> > On 2/4/07, Alan <[EMAIL PROTECTED]> wrote:
> > \
> > > OLDPIIX is for "old" PIIX devices only - from pentium era. It does not
> > > cover the later chips at all
> 
> Just to make sure, this is a P2 SMP board, Slot A, doesnt even support P3 
> CPUs.
> The board is something like, 5 years old or so. Which driver *should*
> work for me?
> 
> The board even has *gasp* ISA slots and doesnt support anything more
> than UDMA33 :D

Send an lspci -vvxxx and it'll be easy to tell, or to find out if you
have a variant which has been overlooked
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20 -- Loads of section mismatches

[Alon Bar-Lev]

On 2/5/07, Miles Lane <[EMAIL PROTECTED]> wrote:

Are any of these worth fixing?


I am preparing a patch for this.
I will submit it soon.

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

2.6.20 -- Loads of section mismatches

[Miles Lane]

Are any of these worth fixing?

WARNING: vmlinux - Section mismatch: reference to
.init.data:boot_params from .text between '_text' (at offset
0xc0100036) and 'checkCPUtype'
WARNING: vmlinux - Section mismatch: reference to
.init.data:boot_params from .text between '_text' (at offset
0xc0100044) and 'checkCPUtype'
WARNING: vmlinux - Section mismatch: reference to
.init.data:init_pg_tables_end from .text between '_text' (at offset
0xc01000a6) and 'checkCPUtype'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc01000d5) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc01000df) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc01000fe) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc010010f) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc0100115) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc010011b) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc0100121) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc0100137) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc0100141) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc010014a) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'checkCPUtype' (at offset
0xc0100150) and 'is486'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'check_x87' (at offset
0xc01001b4) and 'setup_pda'
WARNING: vmlinux - Section mismatch: reference to
.init.data:new_cpu_data from .text between 'check_x87' (at offset
0xc01001d2) and 'setup_pda'
WARNING: vmlinux - Section mismatch: reference to
.init.text:start_kernel from .text between 'is386' (at offset
0xc01001ae) and 'check_x87'
WARNING: vmlinux - Section mismatch: reference to
.init.text:spawn_ksoftirqd from .text between 'init' (at offset
0xc0100392) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:spawn_softlockup_task from .text between 'init' (at offset
0xc0100397) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:APIC_init_uniprocessor from .text between 'init' (at offset
0xc010039c) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:sched_init_smp from .text between 'init' (at offset
0xc01003a1) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:usermodehelper_init from .text between 'init' (at offset
0xc01003ab) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:driver_init from .text between 'init' (at offset
0xc01003b0) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:sysctl_init from .text between 'init' (at offset
0xc01003b5) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between 'init' (at offset 0xc01003cf) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to .init.data: from
.text between 'init' (at offset 0xc010040d) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:prepare_namespace from .text between 'init' (at offset
0xc01004e5) and 'rest_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:lockdep_init from .text between 'lockdep_init_map' (at
offset 0xc012e6a9) and 'save_trace'
WARNING: vmlinux - Section mismatch: reference to
.init.text:lockdep_init from .text between 'lockdep_reset_lock' (at
offset 0xc012f3fb) and 'lockdep_off'
WARNING: vmlinux - Section mismatch: reference to
.init.text:lockdep_init from .text between '__lock_acquire' (at offset
0xc01304e4) and 'lock_acquire'
WARNING: vmlinux - Section mismatch: reference to
.init.text:__alloc_bootmem_node from .text between
'init_currently_empty_zone' (at offset 0xc013f92a) and
'free_area_init_node'
WARNING: vmlinux - Section mismatch: reference to
.init.text:zone_spanned_pages_in_node from .text between
'free_area_init_node' (at offset 0xc013fa12) and 'build_all_zonelists'
WARNING: vmlinux - Section mismatch: reference to
.init.text:zone_absent_pages_in_node from .text between
'free_area_init_node' (at offset 0xc013fa3c) and 'build_all_zonelists'
WARNING: vmlinux - Section mismatch: reference to
.init.text:zone_spanned_pages_in_node from .text between
'free_area_init_node' (at offset 

Re: [ANN] Userspace M-on-N threading model implementation. Alpha release.

[Bill Davidsen]

Jakub Jelinek wrote:

On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
  

Arjan van de Ven wrote:

Because user threading can avoid context switches, there will always be 
cases where it will outperform o/s threads for hardware reasons.


actually.. switching from one "real" thread to another in Linux is not
an actual context switch in the hardware sense... at least this part of
your argument seems to be incorrect ;)

  
How does that work? Switching between kernel threads requires going into 
the kernel, user level thread switches are all done in user mode.


Do you have some way to change o/s threads w/o going into the kernel?



But going into kernel is not very expensive on Linux.

On the other side, the overhead you need to add for every single syscall
that might block for the M:N threads and the associated complications
which make it far harder to conform to POSIX IMHO far outweight the costs
of going into the kernel for a context switch.


That really wasn't my question, Arjan said that switching real threads 
wasn't a context switch in the hardware sense, and I was asking if I 
missed something. It may be cheap, but it would seem to be a context 
switch none-the-less.


--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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

[PATCH] Fix MTRR compat ioctl

[Zwane Mwaikambo]

The MTRR compat code wasn't calling the lowlevel MTRR setup due to a 
switch block not handling the compat case.

Before:
(WW) I810(0): Failed to set up write-combining range (0xd000,0x1000)

After:
reg00: base=0x (   0MB), size=1024MB: write-back, count=1
reg01: base=0x4000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x5f70 (1527MB), size=   1MB: uncachable, count=1
reg03: base=0x5f80 (1528MB), size=   8MB: uncachable, count=1
reg04: base=0xd000 (3328MB), size= 256MB: write-combining, count=1

Signed-off-by: Zwane Mwaikambo <[EMAIL PROTECTED]>

Index: arch/i386/kernel/cpu/mtrr/if.c
===
RCS file: /home/cvsroot/linux-2.6.20-rc6-mm1/arch/i386/kernel/cpu/mtrr/if.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 if.c
--- arch/i386/kernel/cpu/mtrr/if.c  30 Jan 2007 05:28:30 -  1.1.1.1
+++ arch/i386/kernel/cpu/mtrr/if.c  4 Feb 2007 21:36:57 -
@@ -158,8 +158,9 @@ mtrr_ioctl(struct file *file, unsigned i
struct mtrr_sentry sentry;
struct mtrr_gentry gentry;
void __user *arg = (void __user *) __arg;
+   unsigned int compat_cmd = cmd;
 
-   switch (cmd) {
+   switch (compat_cmd) {
case MTRRIOC_ADD_ENTRY:
case MTRRIOC_SET_ENTRY:
case MTRRIOC_DEL_ENTRY:
@@ -177,14 +178,20 @@ mtrr_ioctl(struct file *file, unsigned i
return -EFAULT;
break;
 #ifdef CONFIG_COMPAT
-   case MTRRIOC32_ADD_ENTRY:
-   case MTRRIOC32_SET_ENTRY:
-   case MTRRIOC32_DEL_ENTRY:
-   case MTRRIOC32_KILL_ENTRY:
-   case MTRRIOC32_ADD_PAGE_ENTRY:
-   case MTRRIOC32_SET_PAGE_ENTRY:
-   case MTRRIOC32_DEL_PAGE_ENTRY:
-   case MTRRIOC32_KILL_PAGE_ENTRY: {
+#define MTRR_COMPAT_OP(op, type)\
+   case MTRRIOC32_##op:\
+   cmd = MTRRIOC_##op; \
+   goto compat_get_##type
+
+   MTRR_COMPAT_OP(ADD_ENTRY, sentry);
+   MTRR_COMPAT_OP(SET_ENTRY, sentry);
+   MTRR_COMPAT_OP(DEL_ENTRY, sentry);
+   MTRR_COMPAT_OP(KILL_ENTRY, sentry);
+   MTRR_COMPAT_OP(ADD_PAGE_ENTRY, sentry);
+   MTRR_COMPAT_OP(SET_PAGE_ENTRY, sentry);
+   MTRR_COMPAT_OP(DEL_PAGE_ENTRY, sentry);
+   MTRR_COMPAT_OP(KILL_PAGE_ENTRY, sentry);
+compat_get_sentry: {
struct mtrr_sentry32 __user *s32 = (struct mtrr_sentry32 __user 
*)__arg;
err = get_user(sentry.base, &s32->base);
err |= get_user(sentry.size, &s32->size);
@@ -193,8 +200,9 @@ mtrr_ioctl(struct file *file, unsigned i
return err;
break;
}
-   case MTRRIOC32_GET_ENTRY:
-   case MTRRIOC32_GET_PAGE_ENTRY: {
+   MTRR_COMPAT_OP(GET_ENTRY, gentry);
+   MTRR_COMPAT_OP(GET_PAGE_ENTRY, gentry);
+compat_get_gentry: {
struct mtrr_gentry32 __user *g32 = (struct mtrr_gentry32 __user 
*)__arg;
err = get_user(gentry.regnum, &g32->regnum);
err |= get_user(gentry.base, &g32->base);
@@ -204,6 +212,7 @@ mtrr_ioctl(struct file *file, unsigned i
return err;
break;
}
+#undef MTRR_COMPAT_OP
 #endif
}
 
@@ -317,7 +326,7 @@ mtrr_ioctl(struct file *file, unsigned i
if (err)
return err;
 
-   switch(cmd) {
+   switch(compat_cmd) {
case MTRRIOC_GET_ENTRY:
case MTRRIOC_GET_PAGE_ENTRY:
if (copy_to_user(arg, &gentry, sizeof gentry))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[devzero]

First off, compliments to this announcement, I liked it very much!

Some comment regarding those "volunteers, waiting to get some real work" :)

> > OK, but why isn't your army of volunteers fixing them?

> They don't know about them, or they don't have the hardware to test?
> Seriously, let the kernel-janitor's project know about any issues you
> have and they will be glad to jump on it.  Those people are just
> chomping a the bit to do something a bit bigger than "compiler warning
> cleanups" :)

So many times i have seen good ideas brought up, kernel patches being written, 
posted to lkml, being developed outside mainline for a while and then being 
forgotten some time later due to lack of energy of some individual to get this 
into mainline.

If there is an noticeably number of talented programmers (unfortunately, i`m 
not) , so why not "feeding" them the right way ? Where is those public and 
transparent and moderated Linux-Kernel "ToDo"- or "Keep an eye on"-list, sorted 
by priorities, with sort of a "vote for this feature"-button, so those guys 
have something they can pick up? There is so much great stuff and ideas out 
there where they could put their work onto or getting involved, it just needs 
to be found or sort of being "managed" a little bit better.

For myself, i`m waiting for so quite some things to get "one step further", but 
they are more or less tied to some single individuals, for which you just 
cannot send some "hey, what`s up with your project"-message every second day. 
The interest in many nice projects often is quite low and evolution quite slow, 
but not only because of the fact that they aren`t great, but more because of 
not getting widely known. It`s not always missing specs, it`s also some missing 
noise/feedback for different features or missing of some "driving force" to 
bring things forward. How should one developer know that somebody needs a 
feature if those who could probably need it don`t request it? Maybe just 
because of the fact that they even imagine that such feature would be possible ?

Where is those efforts for fixing/integrating fantastic cowloop?
What about badram/badmem patch ?
Compressed Ccaching ?
Somebody helping with development of dm-loop or extend loop.c to support more 
than 256 devices ?
Replacement of proprietary, unstable and unelegant vmware-lopp for being able 
to mount vmware .vmdk files ? Internal Spec for this is open, dm-userspace 
could be some infrastructure for this, but the author seems to have other 
priorities
dm-cow, zfs-fuse - anybody ?
Kernel based target for AoE (Ata over Ethernet) ?  (there are two independent 
implementations, but both got stuck at some early experimental stage) 

Just my 2 cents. 

Roland K.
Sysadmin/System Engineer

ps:
This isn`t meant to criticise any of you kernel developers since you`re doing 
fantastic work!


___
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=02

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

Re: Free Linux Driver Development!

[Christer Weinigel]

Greg KH <[EMAIL PROTECTED]> writes:

> Or perhaps your device just needs to add some flow control to it :)

Physical processes are hard to pause. :-)

But yes, adding a 16kByte FIFO before the FT245 would have made life
so much easier for me, but unfortunately the thing that drives the
hardware choice is cost, cost and cost.  

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

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

Re: [Linux-fbdev-devel] radeonfb: Can't use the dvi port

[Benjamin Herrenschmidt]

> I`ve compiled raeonfb debug in the kernel:
> Dec 26 14:52:05 frodo kernel: hStart = 1664, hEnd = 1856, hTotal = 2160
> Dec 26 14:52:05 frodo kernel: vStart = 1201, vEnd = 1204, vTotal = 1250
> Dec 26 14:52:05 frodo kernel: h_total_disp = 0xc7010d hsync_strt_wid = 
> 0x18067a
> Dec 26 14:52:05 frodo kernel: v_total_disp = 0x4af04e1 vsync_strt_wid = 
> 0x304b0
> Dec 26 14:52:05 frodo kernel: pixclock = 6172
> Dec 26 14:52:05 frodo kernel: freq = 16202
> Dec 26 14:52:05 frodo kernel: freq = 16202, PLL min = 2, PLL max = 4
> Dec 26 14:52:05 frodo kernel: ref_div = 12, ref_clk = 2700, output_freq = 
> 32404
> Dec 26 14:52:05 frodo kernel: ref_div = 12, ref_clk = 2700, output_freq = 
> 32404
> Dec 26 14:52:05 frodo kernel: post div = 0x1
> Dec 26 14:52:05 frodo kernel: fb_div = 0x90
> Dec 26 14:52:05 frodo kernel: ppll_div_3 = 0x10090
> 
> My card:
> 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If 
> [Radeon 9000] (rev 01)
> 
> Switching to the analog port works well.

Can I have the -full- dmesg log ?

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: Super Kernel Sunday!

[Kevin K]

On Feb 4, 2007, at 1:40 PM, Bauke Jan Douma wrote:


Linus Torvalds wrote on 04-02-07 20:10:

Walter Dickweed I know, but who is this Superbowl Sunday?

bjd


Doesn't it have something to do with the World Series or World Cup?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Giuseppe Bilotta]

On 2/4/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote:

Giuseppe, can you send me the EDID block of your monitor?


I'd gladly do it, if I knew how to retrieve it ... because apparently,
get-edid doesn't work, even though both the nv driver for X and
nvidiafb manage to retrieve it.

This is the output from get-edid

"""
get-edid: get-edid version 1.4.1

Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful

VBE version 300
VBE string at 0x0 "NVidia"

VBE/DDC service about to be called
Report DDC capabilities

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful

Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination does not support DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
Read EDID

Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call failed

The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
"""

Anything else I can try?

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

Re: 2.6.20-rc7 regression on intel-agp

[Randy Dunlap]

On Sun, 04 Feb 2007 22:00:16 +0100 Eric Piel wrote:

> 04.02.2007 18:18, Dave Jones wrote/a écrit:
> > On Sun, Feb 04, 2007 at 04:51:38PM +0100, Eric Piel wrote:
> >  > Hello,
> >  > 
> >  > I've got a regression in 2.6.20-rc7 (-rc6 was fine) due to commit 
> >  > 4b95320fc4d21b0ff2f8604305dd6c851aff6096 ([AGPGART] intel_agp: restore 
> >  > graphics device's pci space early in resume).
> :
> > 
> > There's an ugly patch below which does the latter. Give it a try?
> Thanks a lot, this made the trick... to some extends at least. I can 
> suspend to disk and resume fine. The framebuffer is not garble neither, 
> however nothing is displayed after resuming :-S Well, it's probably 
> enough to be applied before 2.6.20.

Missed that.  Please send it to [EMAIL PROTECTED] .

> Attached is the new dmesg, just in case you are interested.
> 
> See you,
> Eric

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

RE: O_NONBLOCK setting "leak" outside of a process??

[David Schwartz]

> > *Every* blocking fd operation should be followed by a check to
> > see if the
> > operation failed, succeeded, or partially succeeded. If it partially
> > succeeded, it needs to be continued. If it failed, you need to
> > check if the
> > error is fatal or transient. If transient, you need to back off
> > and retry.
> > It has, sadly, always been this way. (Programs can get signals,
> > debuggers
> > can interrupt a system call, the unexpected happens.)

> Well, that's partly nonsense.  The only error condition which is
> always being
> checked in correctly written software is EINTR - if you've got an
> interrupt,
> continue/retry the I/O.

> Checking and retrying for EAGAIN is umm.. plain wrong.  You'll get a nice
> busywait eating 100% CPU this way, till the I/O actually happens, and will
> get another the next try.

I said back off and retry.

> Checking I/Os for every possible weird condition is just non-productive.
>
> It's like this:
>
>   if (fcntl(fd, F_SETFL, ~O_NONBLOCK) < 0)  error_out();
>   if (fcntl(fd, F_GETFL, 0) & O_NOBLOCK) ??? what to do?
>   while(do_something())
> if (fcntl(fd, F_GETFL, 0) & O_NOBLOCK)
>   if (fcntl(fd, F_SETFL, ~O_NONBLOCK) < 0)  error_out();
>
> (don't pay attention to ~O_NONBLOCK thing - it's wrong, but it's
> used like that just to show the "idea" - which is to clear O_NONBLOCK)

I agree that checking for a condition that there's no sane way to handle is
non-productive. But here we're talking about testing for a condition that
has been proven to happen and for which a sane way to handle it is
obvious -- back off and retry.

> Which is a complete nonsense.  It's either set or cleared, and once
> set or cleared it should stay that way, period.  Until the app changes
> it again.

Until anything with access to it changes it.

> >> Worse, it cannot be worked around by dup() because duped fds
> >> are still sharing O_NONBLOCK. How can I work around this?
> >
> > If this causes your code a problem, your code is broken. What
> > does your code
>
> With dup() - maybe.  But definitely NOT with fork().

With 'fork', you either give the other process the file descriptor or you
share it. Any shared resource requires cooperation for sane results.

> > currently do if it gets a non-fatal error from a blocking
> > operation? If it
> > does anything other than back off and retry, it's mishandling
> > the condition.

> Retrying I/O in case of EAGAIN is *wrong*.  See above.

You missed the "back off" part.

DS


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

PCI BIST is running

[Manu Abraham]

Hi,

I have 3 similar PCI cards all 32 bit in 32 bit PCI slots on a x86 (32 bit) CPU

On booting up 2.6.17.7, i get this message,

PCI: Unable to handle 64-bit address space for device 02:0a.0

i get one more message stating that an address could not be mapped for
the same slot.

running lspci, i get thus ..

All the 3 PCI cards are the same except that the first one is Rev 08
card and the others Rev 01


can somebody point me as to what's happening on the first card ? I
understand that some Built In Self Test is Running, but syill don't
understand why it doesn't terminate or so


Thanks,
Manu

02:0a.0 4e35: 1800:4e35 (rev 08) (prog-if 18)
Subsystem: 002c:c200
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR+  (32-bit, prefetchable) [disabled]
Region 4: Memory at  (32-bit, non-prefetchable) [disabled]
Region 5: Memory at  (64-bit, non-prefetchable) 
[disabled]
Expansion ROM at e9b01000 [disabled] [size=4K]

02:0c.0 0480: 1822:4e35 (rev 01)
Subsystem: 1822:0014
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.20-rc7 regression on intel-agp

[Eric Piel]

04.02.2007 18:18, Dave Jones wrote/a écrit:

On Sun, Feb 04, 2007 at 04:51:38PM +0100, Eric Piel wrote:
 > Hello,
 > 
 > I've got a regression in 2.6.20-rc7 (-rc6 was fine) due to commit 
 > 4b95320fc4d21b0ff2f8604305dd6c851aff6096 ([AGPGART] intel_agp: restore 
 > graphics device's pci space early in resume).

:


There's an ugly patch below which does the latter. Give it a try?
Thanks a lot, this made the trick... to some extends at least. I can 
suspend to disk and resume fine. The framebuffer is not garble neither, 
however nothing is displayed after resuming :-S Well, it's probably 
enough to be applied before 2.6.20.


Attached is the new dmesg, just in case you are interested.

See you,
Eric
Linux version 2.6.20-rc7-eric-usbas ([EMAIL PROTECTED]) (gcc version 4.1.2 
20070115 (prerelease) (4.1.2-0.20070115.1mdv2007.1)) #12 PREEMPT Sun Feb 4 
20:39:10 CET 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start:  size: 0009f400 end: 
0009f400 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 0009f400 size: 0c00 end: 
000a type: 2
copy_e820_map() start: 000cc000 size: 4000 end: 
000d type: 2
copy_e820_map() start: 000e4800 size: 0001b800 end: 
0010 type: 2
copy_e820_map() start: 0010 size: 1fd7 end: 
1fe7 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 1fe7 size: fc00 end: 
1fe7fc00 type: 3
copy_e820_map() start: 1fe7fc00 size: 0400 end: 
1fe8 type: 4
copy_e820_map() start: 1fe8 size: 0018 end: 
2000 type: 2
copy_e820_map() start: ff80 size: 0040 end: 
ffc0 type: 2
copy_e820_map() start: fff0 size: 0010 end: 
0001 type: 2
 BIOS-e820:  - 0009f400 (usable)
 BIOS-e820: 0009f400 - 000a (reserved)
 BIOS-e820: 000cc000 - 000d (reserved)
 BIOS-e820: 000e4800 - 0010 (reserved)
 BIOS-e820: 0010 - 1fe7 (usable)
 BIOS-e820: 1fe7 - 1fe7fc00 (ACPI data)
 BIOS-e820: 1fe7fc00 - 1fe8 (ACPI NVS)
 BIOS-e820: 1fe8 - 2000 (reserved)
 BIOS-e820: ff80 - ffc0 (reserved)
 BIOS-e820: fff0 - 0001 (reserved)
510MB LOWMEM available.
Entering add_active_range(0, 0, 130672) 0 entries of 256 used
Zone PFN ranges:
  DMA 0 -> 4096
  Normal   4096 ->   130672
early_node_map[1] active PFN ranges
0:0 ->   130672
On node 0 totalpages: 130672
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 988 pages used for memmap
  Normal zone: 125588 pages, LIFO batch:31
DMI present.
ACPI: RSDP (v000 PTLTD ) @ 0x000f6550
ACPI: RSDT (v001 PTLTD   RSDT   0x0604  LTP 0x) @ 0x1fe7b9f3
ACPI: FADT (v001 Acer   TM6100x0604 Acer 0x0001) @ 0x1fe7fb64
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x0604  LTP 0x0001) @ 0x1fe7fbd8
ACPI: DSDT (v001  INTEL SolanoM2 0x0604 MSFT 0x010d) @ 0x
ACPI: PM-Timer IO Port: 0x1008
Allocating PCI resources starting at 3000 (gap: 2000:df80)
Detected 698.514 MHz processor.
Built 1 zonelists.  Total pages: 129652
Kernel command line: BOOT_IMAGE=2.6.20-rc7-eric-usbas root=LABEL=racine lapic 
resume=/dev/sda7 
video=i810fb:xres:1024,yres:768,hsync1:32,hsync2:48,vsync1:50,vsync2:70,vram:2,bpp:16,mtrr:1
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
mapped APIC to d000 (fee0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c03e1000 soft=c03e
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 514104k/522688k available (1915k kernel code, 7908k reserved, 833k 
data, 168k init, 0k highmem)
virtual kernel memory layout:
fixmap  : 0x7000 - 0xf000   (  32 kB)
vmalloc : 0xe080 - 0x5000   ( 503 MB)
lowmem  : 0xc000 - 0xdfe7   ( 510 MB)
  .init : 0xc03b1000 - 0xc03db000   ( 168 kB)
  .data : 0xc02ded89 - 0xc03af534   ( 833 kB)
  .text : 0xc010 - 0xc02ded89   (1915 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1398.93 BogoMIPS (lpj=2329490)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff     
 
C

Re: Super Kernel Sunday!

[Gene Heskett]

On Sunday 04 February 2007 14:40, Bauke Jan Douma wrote:
>Linus Torvalds wrote on 04-02-07 20:10:
>
>Walter Dickweed I know, but who is this Superbowl Sunday?
>
>bjd

See what Linus meant, folks?  Chuckle...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Free Linux Driver Development!

[Bill Davidsen]

Jan Engelhardt wrote:

On Jan 31 2007 08:34, David Hollis wrote:

Conversely, I've seen many cases of drivers that are developed by the
community, but kept out-of-kernel forever due to various reasons.  Some
of them are due to the code quality and the developers not accepting the
feedback to get the drivers into shape to be 'kernel worthy', sometimes
it seems to be a lack of interest from the developers to merge upstream.
Maybe because they think they would lose control or something?


Putting the "codingstyle" control aside, often it's because things look
too hackish. Take ipt_ROUTE as an example. It won't get included, since
the "proper" way to do it would be using MARK and iproute2. But many users
don't get that [no criticism here], because ipt_ROUTE is so much easier.
(Probably because iproute2 and other netlink-using tools, like tc, lack
thorough documentation.)

Doing it by MARK a tables and rules is an ugly method, and like anything 
with is spread over many places (the mangle table to MARK), then 'rules' 
and 'tables', spreading an action into many places increases the chances 
of getting parts out of sync and having the whole not work as intended. 
And the 'ip' man page defines everything in BNF, which was hot stuff 
when Algol-60 came out (1960) but which is only readable to people who 
use it frequently.


The ipt_ROUTE allows putting all parts of of the action, from defining 
the set of matching packets to specifying the desired result, the 
routing. And if that changes, it need only change in one place.


Making good administration difficult because it fits some pedantic metal 
model is NOT a good way to decide which features to offer in a kernel.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -rt] Make RCU-boost and rcutorture threads freezable

[Nigel Cunningham]

Hi.

On Sat, 2007-02-03 at 20:22 -0800, Paul E. McKenney wrote:
> This patch removes PF_NOFREEZE from the rcutorture and RCU-boost threads,
> adding try_to_freeze() calls as required.  Passes the usual tests, but
> I don't have a good freeze test handy as yet.
> 
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>

Only a quick glance, but it looks great to me.

Thanks Paul!

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 there any Hard-disk shock-protection for 2.6.18 and above?

[Pavel Machek]

Hi1

> >> >> +module_param_named(protect_method, libata_protect_method, int, 0444);
> >> >> +MODULE_PARM_DESC(protect_method, "hdaps disk protection method  
> >> >> (0=autodetect, 1=unload, 2=standby)");
> >> >
> >> > Should this be configurable by module parameter? Why not tell each
> >> > unload what to do?
> [...]
> >> > Is /sys interface right thing to do?
> >> 
> >> Probably, you're right here. Since this feature is actually drive
> >> specific, it should not really be set globally as a libata or ide-disk
> >> parameter but specifically for each drive connected. Perhaps we should
> >> add another attribute to /sys/block/*/queue or enhance the scope of
> >> /sys/block/*/queue/protect?
> >
> > Certainly better than current solution. Or maybe ioctl similar to wat
> > hdparm uses?
> 
> I'm not quite sure what you have in mind wrt ioctls. I'm still
> convinced that the administrator should take a conscious decision when
> forcing an idle immediate with unload feature on a drive which doesn't
> announce this capability according to the specs. This is because I
> have no idea as to how drives might react if they don't support it.
> Perhaps we should consult linux-ide on this topic.

Yep, I guess linux-ide would have some comments.

> So, here is a patch in which your remarks and suggestions have been
> incorporated. Additionally, I've added the requested kernel doc file

Additional suggestion is to keep lines < 80 columns Sorry it took
me so long to comment.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c

[Stefan Richter]

David Moore wrote:
[...]
> considering the severity of this one-liner bug, I would like to
> request that this simplified patch make it into 2.6.20, despite how
> close we are to the final cut.

So we were too close. Maybe the -stable team likes to have it in 2.6.20.1.

> It fixes real crashes:
> http://lists.opensuse.org/opensuse-bugs/2006-12/msg02943.html
> http://qa.mandriva.com/show_bug.cgi?id=28224
> http://www.pchdtv.com/forum/viewtopic.php?t=2063&sid=a959a14a4c2db0eebaab7b0df56103ce

and FireWire crashes too.

> --- linux-2.6.19.x86_64/lib/swiotlb.c.orig2007-02-04 13:18:41.0 
> -0500
> +++ linux-2.6.19.x86_64/lib/swiotlb.c 2007-02-04 13:19:43.0 -0500
> @@ -750,7 +750,7 @@ swiotlb_sync_sg(struct device *hwdev, st
>  
>   for (i = 0; i < nelems; i++, sg++)
>   if (sg->dma_address != SG_ENT_PHYS_ADDRESS(sg))
> - sync_single(hwdev, (void *) sg->dma_address,
> + sync_single(hwdev, phys_to_virt(sg->dma_address),
>   sg->dma_length, dir, target);
>  }
>  
-- 
Stefan Richter
-=-=-=== --=- --=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] workqueue: don't migrate pending works from the dead CPU

[Oleg Nesterov]

Currently CPU_DEAD uses kthread_stop() to stop cwq->thread and then
transfers cwq->worklist to another CPU. However, it is very unlikely
that worker_thread() will notice kthread_should_stop() before flushing
cwq->worklist. It is only possible if worker_thread() was preempted
after run_workqueue(cwq), a new work_struct was added, and CPU_DEAD
happened before cwq->thread has a chance to run.

This means that take_over_work() mostly adds unneeded complications.
Note also that kthread_stop() is not good per se, wake_up_process()
may confuse work->func() if it sleeps waiting for some event.

Remove take_over_work() and migrate_sequence complications. CPU_DEAD
sets the cwq->should_stop flag (introduced by this patch) and waits
for cwq->thread to flush cwq->worklist and exit. Because the dead CPU
is not on cpu_online_map, no more works can be added to that cwq.

cpu_populated_map was introduced to optimize for_each_possible_cpu(),
it is not strictly needed, and it is more a documentation in fact.

Saves 418 bytes.

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

--- 6.20-rc6-mm3/kernel/workqueue.c~1_rework2007-02-03 21:17:50.0 
+0300
+++ 6.20-rc6-mm3/kernel/workqueue.c 2007-02-04 21:35:15.0 +0300
@@ -43,10 +43,11 @@ struct cpu_workqueue_struct {
 
struct list_head worklist;
wait_queue_head_t more_work;
+   struct work_struct *current_work;
 
struct workqueue_struct *wq;
struct task_struct *thread;
-   struct work_struct *current_work;
+   int should_stop;
 
int run_depth;  /* Detect run_workqueue() recursion depth */
 } cacheline_aligned;
@@ -64,11 +65,12 @@ struct workqueue_struct {
 
 /* All the per-cpu workqueues on the system, for hotplug cpu to add/remove
threads to each one as cpus come/go. */
-static long migrate_sequence __read_mostly;
 static DEFINE_MUTEX(workqueue_mutex);
 static LIST_HEAD(workqueues);
 
-static int singlethread_cpu;
+static int singlethread_cpu __read_mostly;
+/* optimization, we could use cpu_possible_map */
+static cpumask_t cpu_populated_map __read_mostly;
 
 /* If it's single threaded, it isn't in the list of workqueues. */
 static inline int is_single_threaded(struct workqueue_struct *wq)
@@ -344,10 +346,28 @@ static void run_workqueue(struct cpu_wor
spin_unlock_irqrestore(&cwq->lock, flags);
 }
 
+/*
+ * NOTE: the caller must not touch *cwq if this func returns true
+ */
+static int cwq_should_stop(struct cpu_workqueue_struct *cwq)
+{
+   int should_stop = cwq->should_stop;
+
+   if (unlikely(should_stop)) {
+   spin_lock_irq(&cwq->lock);
+   should_stop = cwq->should_stop && list_empty(&cwq->worklist);
+   if (should_stop)
+   cwq->thread = NULL;
+   spin_unlock_irq(&cwq->lock);
+   }
+
+   return should_stop;
+}
+
 static int worker_thread(void *__cwq)
 {
struct cpu_workqueue_struct *cwq = __cwq;
-   DECLARE_WAITQUEUE(wait, current);
+   DEFINE_WAIT(wait);
struct k_sigaction sa;
sigset_t blocked;
 
@@ -373,23 +393,21 @@ static int worker_thread(void *__cwq)
siginitset(&sa.sa.sa_mask, sigmask(SIGCHLD));
do_sigaction(SIGCHLD, &sa, (struct k_sigaction *)0);
 
-   set_current_state(TASK_INTERRUPTIBLE);
-   while (!kthread_should_stop()) {
+   for (;;) {
if (cwq->wq->freezeable)
try_to_freeze();
 
-   add_wait_queue(&cwq->more_work, &wait);
-   if (list_empty(&cwq->worklist))
+   prepare_to_wait(&cwq->more_work, &wait, TASK_INTERRUPTIBLE);
+   if (!cwq->should_stop && list_empty(&cwq->worklist))
schedule();
-   else
-   __set_current_state(TASK_RUNNING);
-   remove_wait_queue(&cwq->more_work, &wait);
+   finish_wait(&cwq->more_work, &wait);
 
-   if (!list_empty(&cwq->worklist))
-   run_workqueue(cwq);
-   set_current_state(TASK_INTERRUPTIBLE);
+   if (cwq_should_stop(cwq))
+   break;
+
+   run_workqueue(cwq);
}
-   __set_current_state(TASK_RUNNING);
+
return 0;
 }
 
@@ -454,20 +472,13 @@ static void flush_cpu_workqueue(struct c
  */
 void fastcall flush_workqueue(struct workqueue_struct *wq)
 {
-   if (is_single_threaded(wq)) {
-   /* Always use first cpu's area. */
+   if (is_single_threaded(wq))
flush_cpu_workqueue(per_cpu_ptr(wq->cpu_wq, singlethread_cpu));
-   } else {
-   long sequence;
+   else {
int cpu;
-again:
-   sequence = migrate_sequence;
 
-   for_each_possible_cpu(cpu)
+   for_each_cpu_mask(cpu, cpu_populated_map)
flush_cpu_workqueue(per_cpu_ptr(wq->cpu_wq, cpu));
-
-   if (unlikely(sequence != migrate_sequence))

[PATCH 0/1] workqueue: don't migrate pending works from the dead CPU

[Oleg Nesterov]

Andrew, please drop the workqueue-rework-threads-hotplug-management.patch,
and please take this one (feel free to just kill me instead).

We have workqueue callbacks (slab for example) which assume that CPU is
stable during the execution since cwq->thread is pinned to a processor.
With or without that patch this is not true with CONFIG_HOTPLUG_CPU, and
the problem is not connected to workqueue.c.

However, my patch makes the things worse, because CPU_UP_PREPARE creates
cwq->thread which is not pinned to CPU until CPU_ONLINE. This is solvable,
but needs a serious complication, so this patch can't be considered as a
cleanup.

The new patch removes take_over_work() and friends (as the old one did),
but retains an unfortunate property of the current implementation: the
workqueue_mutex is held from CPU_LOCK_ACQUIRE to CPU_LOCK_RELEASE, and
CPU_DEAD stops cwq->thread synchronously.

This means that cpu-hotplug callbacks can't create/destroy workqueues
(Gautham needs this?), and work->func() can't share a lock with cpu hotplug.
May be we can change this later, but this needs a separate patch.

Srivatsa, do you have any objections?

The new patch is very similar (in fact, a subset), I don't send incremental
update because this will break changelogs.

Oleg.

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

Re: Timeouts on ICH7 PATA drive with ata_piix; ide_generic worksperfectly

[Keenan Pepper]

Andrew Morton wrote:

From what version of the kernel did you upgrade?
It is very helpful for us to knwo the latest version which worked OK.


The ata_piix driver never worked correctly. The last kernel I used,
2.6.17, used ide_generic by default, so the ata_piix bug never showed
up. Sorry if that was unclear.

Keenan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ipv4: remove a call to skb_queue_len() in inet_diag.c

[David Miller]

From: Thomas Hisch <[EMAIL PROTECTED]>
Date: Sun, 4 Feb 2007 15:29:21 +0100

> remove unneeded call to skb_queue_len (skb_dequeue already checks queuelen) 
> and
> replace a sizeof() by a Netlink Macro
> 
> Signed-off-by: Thomas Hisch <[EMAIL PROTECTED]>

You don't understand the code you are editing :-)

We want to process the number of packets present when we
start the function, other threads can add more packets to
the queue meanwhile and we don't want to keep dequeueing
in that case or else we can theoretically run forever with
a fast enough producer.

Also, please post all networking patches to netdev@vger.kernel.org,
the majority of the networking developers do not read linux-kernel.

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

Re: More pata_ stuff

[Patrick Ale]

It's working, thanks :)

I was confused by this ATA_PIIX driver needing to be enabled, I
genuinly thought and read it was the SATA driver.

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: [ANN] Userspace M-on-N threading model implementation. Alpha release.

[Jakub Jelinek]

On Sun, Feb 04, 2007 at 03:12:32PM -0500, Bill Davidsen wrote:
> Arjan van de Ven wrote:
> >>Because user threading can avoid context switches, there will always be 
> >>cases where it will outperform o/s threads for hardware reasons.
> >
> >actually.. switching from one "real" thread to another in Linux is not
> >an actual context switch in the hardware sense... at least this part of
> >your argument seems to be incorrect ;)
> >
> How does that work? Switching between kernel threads requires going into 
> the kernel, user level thread switches are all done in user mode.
> 
> Do you have some way to change o/s threads w/o going into the kernel?

But going into kernel is not very expensive on Linux.

On the other side, the overhead you need to add for every single syscall
that might block for the M:N threads and the associated complications
which make it far harder to conform to POSIX IMHO far outweight the costs
of going into the kernel for a context switch.

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

Re: [Linux-fbdev-devel] [PATCH] nvidiafb: allow ignoring EDID info

[Luca Tettamanti]

Il Tue, Jan 30, 2007 at 09:33:01PM +0100, Luca Tettamanti ha scritto: 
> Il Mon, Jan 29, 2007 at 03:37:22PM +0100, Giuseppe Bilotta ha scritto: 
> > On 1/29/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > > > > > Because most users won't even be aware of the module option: 
> > > > > > they'll just
> > > > > > know that their card doesn't work right.
> > > > >
> > > > > This isn't a card problem this is a monitor problem, the card just
> > > > > passes through the edid data from the monitor... or else the
> > > > > programming of the card registers from edid is wrong..
> > > >
> > > > In which case the same problem would occur with different video cards, 
> > > > so
> > > > this patch should be some generic thing, available to all drivers, no?
> > >
> > > It should be in the fb layer not card specific.. as it may happen on any 
> > > card...
> > 
> > Although solving the problem at the fb layer level is probably the
> > correct/best way to do it, I am not aware of people having problems
> > with broken EDIDs and non-nVidia cards. By contrast, workarounds for
> > nVidia and broken EDIDs is a very common thing to do even on Windows.
> 
> Not all drivers have support for reading EDID information, so in many
> cases it just "works". My old monitor had garbage in the EDID eeprom and
> I had to pass "ignore_edid" to radeonfb (before I reprogrammed the
> eeprom that is :P).
> 
> > Plus, providing an fb-layer-level solution is way beyond my kernel
> > programming experience :)
> 
> I'll try to code something in the weekend.

I'm somewhat stuck. fbmon has the library functions to parse and
optionally fix EDID block, but it lacks the knowledge of the source of
the data; IOW it's not possible to ignore the EDID coming from a certain
head, the flag would be global (which may be less that optimal with
multi-head setups).
So instead of adding an option I'd use the existing broken EDID db,
adding another state (say 'unfixable') which causes the data to be
discarded. Comments?

Giuseppe, can you send me the EDID block of your monitor?

Luca
-- 
Sbagliare ? umano, ma per incasinare davvero le cose serve un computer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 PULL] MMC updates

[Pierre Ossman]

Yay! First post!

Linus, please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git for-linus

to receive the following updates:

 MAINTAINERS  |2 +-
 drivers/misc/tifm_7xx1.c |  402 ++
 drivers/misc/tifm_core.c |   65 +--
 drivers/mmc/at91_mci.c   |3 +
 drivers/mmc/au1xmmc.c|   13 +-
 drivers/mmc/imxmmc.c |4 +-
 drivers/mmc/mmc.c|  182 
 drivers/mmc/mmc_block.c  |   15 +-
 drivers/mmc/mmc_queue.c  |2 +-
 drivers/mmc/mmc_sysfs.c  |2 +-
 drivers/mmc/mmci.c   |   15 +-
 drivers/mmc/omap.c   |6 +-
 drivers/mmc/pxamci.c |   10 +
 drivers/mmc/sdhci.c  |   91 +
 drivers/mmc/sdhci.h  |2 -
 drivers/mmc/tifm_sd.c|  487 +++---
 drivers/mmc/wbsd.c   |  102 ++---
 drivers/mmc/wbsd.h   |1 -
 include/linux/mmc/card.h |3 +
 include/linux/mmc/host.h |   10 +-
 include/linux/mmc/mmc.h  |1 +
 include/linux/mmc/protocol.h |   13 +-
 include/linux/pci_ids.h  |4 +
 include/linux/tifm.h |   35 ++--
 24 files changed, 891 insertions(+), 579 deletions(-)

Alex Dubov (15):
  tifm_sd: alter order of the states in the command handler
  tifm_sd: use kmap_atomic instead of kmap for PIO data buffer
  tifm_sd: Switch software timeout handler from work_struct to timer
  tifm_sd: fix hardware timeout setup
  tifm_sd: restructure initialization, removal and command handling
  tifm_sd: prettify
  Remove unused return value from signal_irq callback
  Add dummy_signal_irq function to save check in ISR
  tifm_7xx1: simplify eject function
  tifm_7xx1: Merge media insert and media remove functions
  tifm_7xx1: switch from workqueue to kthread
  tifm_7xx1: recognize device 0xac8f as supported
  tifm_7xx1: prettify
  tifm_core: add suspend/resume infrastructure for tifm devices
  tifm_sd: add suspend and resume functionality

Darren Salt (1):
  mmc: Power quirk for ENE controllers

Manuel Lauss (2):
  mmc: au1xmmc: implement proper ro switch detection
  mmc: au1xmmc: return errors for unknown response types

Philip Langdale (1):
  mmc: Add support for SDHC cards

Pierre Ossman (13):
  mmc: replace host->card_busy
  mmc: let host be parent of cards
  mmc: Allow host drivers to specify a max block size
  mmc: Allow host drivers to specify max block count
  mmc: Handle wbsd's stupid command list
  mmc: Graceful fallback for fancy features
  mmc: change wbsd mailing list
  mmc: Proper unclaim in mmc_block
  mmc: handle pci_enable_device() return value in sdhci
  mmc: wbsd: replace kmap with page_address
  mmc: sdhci: replace kmap with page_address
  mmc: sdhci: fix voltage ocr
  mmc: tifm: replace kmap with page_address

-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.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/