This patch adds the Intel Tolapai SMBus Controller text to i2c-i801 documentation. Signed-off-by:  Jason Gaston <jason.d.gaston@intel.com> --- linux-2.6.23-rc4/Documentation/i2c/busses/i2c-i801.orig 2007-08-30 15:56:39.000000000 -0700 +++ linux-2.6.23-rc4/Documentation/i2c/busses/i2c-i801 2007-08-30 15:57:32.000000000 -0700 @@ -13,7 +13,8 @@ * Intel 631xESB/632xESB (ESB2) * Intel 82801H (ICH8) * Intel ICH9 - Datasheets: Publicly available at the Intel website + * Intel...

This updated patch adds the Intel Tolapai LPC and SMBus Controller DID's. Signed-off-by:  Jason Gaston <jason.d.gaston@intel.com> --- linux-2.6.23-rc4/arch/i386/pci/irq.c.orig 2007-08-27 18:32:35.000000000 -0700 +++ linux-2.6.23-rc4/arch/i386/pci/irq.c 2007-08-28 16:58:31.000000000 -0700 @@ -550,6 +550,7 @@ case PCI_DEVICE_ID_INTEL_ICH9_3: case PCI_DEVICE_ID_INTEL_ICH9_4: case PCI_DEVICE_ID_INTEL_ICH9_5: + case PCI_DEVICE_ID_INTEL_Tolapai_0: r->name = "PIIX/ICH"; ...

This patch adds the Intel Tolapai RAID controller DID's for SATA support. Signed-off-by:  Jason Gaston <jason.d.gaston@intel.com> --- linux-2.6.23-rc4/drivers/ata/ahci.c.orig 2007-08-27 18:32:35.000000000 -0700 +++ linux-2.6.23-rc4/drivers/ata/ahci.c 2007-08-28 16:58:11.000000000 -0700 @@ -411,6 +411,8 @@ { PCI_VDEVICE(INTEL, 0x292f), board_ahci_pi }, /* ICH9M */ { PCI_VDEVICE(INTEL, 0x294d), board_ahci_pi }, /* ICH9 */ { PCI_VDEVICE(INTEL, 0x294e), board_ahci_pi }, /* ICH9M */ + ...

In the iforce driver we currently get this warning drivers/input/joystick/iforce/iforce-packets.c: In function 'iforce_get_id_packet': drivers/input/joystick/iforce/iforce-packets.c:249: warning: unused variable 'status' if CONFIG_JOYSTICK_IFORCE_USB is not defined. The warning is easy to avoid by simply moving the variable inside the only case in the switch that actually use it. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> --- diff --git a/drivers/input/joystick/iforce/if...

On 31/08/2007, Satyam Sharma <satyam@infradead.org> wrote: Here's an updated patch that actually works as intended. In the iforce driver we currently get this warning drivers/input/joystick/iforce/iforce-packets.c: In function 'iforce_get_id_packet': drivers/input/joystick/iforce/iforce-packets.c:249: warning: unused variable 'status' if CONFIG_JOYSTICK_IFORCE_USB is not defined. The warning is easy to avoid by simply moving the variable inside the only case in the switch ...

I am re-sending this after help from Ian and git-bisect. To me it's a show-stopper: I cannot find an acceptable workaround that I can implement. The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes several autofs mounts to fail silently - they just not appear when they should. I believe it's caused by the NFS change that forces multiple mounts from different directories under the same server side filesystem to have the same mount options by default, otherwise it returns EBUSY. For example, i...

Well, it depends on how you define "better". In this particular scenario, the maps read as follows: tools -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve rs=3,actimeo=600 fs1.domain.com:/a/tools share -fstype=nfs,udp,rw,intr,nosuid,nodev,rsize=8192,wsize=8192,mountvers=3,nfsve rs=3 fs1.domain.com:/a/share The only difference is in the actimeo (I don't even know what it means). Is this enough to fail a mount? More importantly, it is a regression. My understand...

There are two disjoint directories. I am wondering why there would be cache coherency issues in this case? Is this Linus nfs implementation specific or "working" as in "I can mount the directory and do my work". And there has Fine. These are all very nice theories, but I just want to report this regression and hope it won't cause any big problems for any users out there. -

Every engineer in our organization mounts it too. No problem until now. It's not very conservative to suddenly change default behavior and break autofs mounts. There is not even one kernel message that "_tells_ user why No. I have no other choice as I explained before. Hua -

-- Thanks, Steve -

Signed-off-by: Rob Landley <rob@landley.net> ecryptfs.txt moved into Documentation/filesystems, so move the 00-INDEX entry. --- linux-2.6.23-rc4/Documentation/00-INDEX 2007-08-27 20:32:35.000000000 -0500 +++ linux-new/Documentation/00-INDEX 2007-08-30 14:43:15.000000000 -0500 @@ -134,8 +134,6 @@ - info on Linux Digital Video Broadcast (DVB) subsystem. early-userspace/ - info about initramfs, klibc, and userspace early during boot. -ecryptfs.txt - - docs on eCryptfs: stacked cryptogra...

Signed-off-by: Rob Landley <rob@landley.net> Index two unindexed documentation files. --- linux-2.6.23-rc4/Documentation/arm/00-INDEX 2007-08-27 20:32:35.000000000 -0500 +++ linux-new/Documentation/arm/00-INDEX 2007-08-30 14:27:15.000000000 -0500 @@ -20,3 +20,7 @@ - description of the virtual memory layout nwfpe - NWFPE floating point emulator documentation +Porting + - Symbol definitions for porting Linux to a new ARM machine. +Setup + - Kernel initialization parameters on ARM Lin...

Typo, the description should be Changelog for version 2 1. Back end tracking is done in bytes, round up values of the limit if the specified value is not a multiple of page size. Display memory.usage and memory.limit in bytes (Dave Hansen, Paul Menage) Change the interface to use bytes instead of pages. Page sizes can vary across platforms and configurations. A new strategy routine has been added to the resource counters infrastructure to format the data as desired. Suggested by Davi...

commit 1d8715b388c978b0f1b1bf4812fcee0e73b023d7 was added between 2.6.22.4 and 2.6.22.5 to cure a locking problem, but it seems to have introduced another (worse?) one. With a jffs2 filesystem (on block2mtd) on a 2.6.22.5 kernel, if I do anything that appends to a file with many small writes, I get what looks like a deadlock between the writer and the jffs2 gc thread. For example: # while true; do echo >> /some/file/on/jffs2; done will result in the bash hanging in D state, with these ...

On Thu, 30 Aug 2007, Randy Dunlap wrote: ... i just the other day submitted a patch to remove that backward compatibility, and the m68k portion of it has already been acked by geert uytterhoeven. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ======================================================================== -

The same objection applies to this as to the previous one. In that respect, an Ack from a maintainer of an almost unused architecture is meaningless (sorry, Geert.) -hpa -

Robert's patch. -hpa -

Acked-by: Rob Landley <rob@landley.net> Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -

Ok, I must admit I didn't check with sparse since it seemed pointless - we usually never cast void pointers to other pointer types, specifically because the C language nicely guarantees that the right thing will happen without the cast. Sometimes we have to cast them to integer types, su sure we need the cast there. But what on earth makes a "zd_addr_t *" so special that we have to explicitly cast a "void *" to that type? I see it's defined as typedef u32 __nocast zd_addr_t; in drivers/net/w...

http://marc.info/?l=linux-netdev&m=117113743902549&w=1 -

--- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -

I thought I had seen that bug. Module init function execution does not seem serialized enough, so the init function of one module seems to be able to be called in parallel with several other modules in turn being loaded, executing their init functions and even becoming live first class citizens. Function sys_init_module in Linux 2.6.22.x and 2.6.23-rc4 kernel/module.c does not hold module_mutex when executing the init functions of the modules. __________________________________ Alles wa...

Hi Clemens, what do you mean by "overwrites it"? It just probably merges your vma with the newly created one, right? -- Jiri Kosina -

I don't seem to get what is the issue here. Your mapping is not removed, only the VMAs are merged together into one larger VMA if they have neighbouring address ranges and compatible protection bits. See vma_merge(). -- Jiri Kosina -

Which is exactly in compliance with what POSIX says about MAP_FIXED mmaps - see http://opengroup.org/onlinepubs/007908799/xsh/mmap.html -- Jiri Kosina -