ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8...
- Various fixes against 2.6.23-rc7-mm1.
- I repulled the subsystem git trees, but not the subsystem quilt trees.

  Large amounts of stuff broke as a result - not a bad effort for 24 hours :(
- git-sched.patch broke and was dropped
- The cpuidle code wasn't readded to the acpi tree today, so it still isn't in

  2.6.23-rc8-mm1.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1

  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the

  mm-commits mailing list.
        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
- If you hit a bug in -mm and it is not obvious which patch caused it, it is

  most valuable if you can perform a bisection search to identify which patch

  introduced the bug.  Instructions for this process are at
        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
  But beware that this process takes some time (around ten rebuilds and

  reboots), so consider reporting the bug first and if we cannot immediately

  identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing

  list on any email.
- When reporting bugs in this kernel via email, please also rewrite the

  email Subject: in some manner to reflect the nature of the bug.  Some

  developers filter by Subject: when looking for messages to read.
- Occasional snapshots of the -mm lineup are uploaded to

  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on

  the mm-commits list.
Changes since 2.6.23-rc7-mm1:
 git-acpi.patch

 git-alsa.patch

 git-arm.patch

 git-audit-master.patch

 git-avr32.pa...
[ message continues ]

I don't know if this is a regression, I hadn't suspend working before rc7-mm1

(rc7-mm1 is the same), but

X -> kill X -> console (OK)

X -> suspend (2ram) -> resume -> kill X -> black screen (no signal), reboot

stucks at some point after some services are shutted down
X driver: intel (compiled from git)

agp dmesg part:

Linux agpgart interface v0.102

agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup X.Org

on some chipset/BIOS combos (see DEBUG_AGP_PM in intel-agp.c)
Is this what should I try?
agpgart: Detected an Intel G33 Chipset.

agpgart: Detected 8192K stolen memory.

agpgart: AGP aperture is 256M @ 0xd0000000

[drm] Initialized drm 1.1.0 20060810

ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16

[drm] Initialized i915 1.6.0 20060119 on minor 0
thanks,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

Hi
I've applied the 2.6.23-rc8-mm1 patch, and I've got a new directory

"mips" at root of my linux source. This directory only contain :

"bcm947xx/wgt634u.c"
I think that this directory "bcm947xx" should be added in "arch/mips"

subdirectory.
regards,

trem
-

Hi Andy,
One the patch you created in -mm is causing compile warning.

Here is the fix. Please verify.
Thanks,

Badari
arch/powerpc/mm/init_64.c: In function `vmemmap_populated':

arch/powerpc/mm/init_64.c:211: warning: passing arg 1 of `vmemmap_section_start' makes pointer from integer without a cast
vmemmap_section_start() gets called with an argument which is unsigned long.
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Index: linux-2.6.23-rc8/arch/powerpc/mm/init_64.c

===================================================================

--- linux-2.6.23-rc8.orig/arch/powerpc/mm/init_64.c	2007-09-25 09:18:13.000000000 -0700

+++ linux-2.6.23-rc8/arch/powerpc/mm/init_64.c	2007-09-25 14:50:44.000000000 -0700

@@ -189,10 +189,9 @@ void pgtable_cache_init(void)

  * do this by hand as the proffered address may not be correctly aligned.

  * Subtraction of non-aligned pointers produces undefined results.

  */

-unsigned long __meminit vmemmap_section_start(struct page *page)

+unsigned long __meminit vmemmap_section_start(unsigned long page)

 {

-	unsigned long offset = ((unsigned long)page) -

-						((unsigned long)(vmemmap));

+	unsigned long offset = page - ((unsigned long)(vmemmap));
 	/* Return the pfn of the start of the section. */

 	return (offset / sizeof(struct page)) & PAGE_SECTION_MASK;
-

Clearly correct.  
-apw

-

Hello,
	Similar (the same?) as in 2.6.23-rc6-mm1?
http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg208812.html
  CC [M]  drivers/kvm/ioapic.o

drivers/kvm/ioapic.c: In function 'ioapic_deliver':

drivers/kvm/ioapic.c:208: error: 'dest_LowestPrio' undeclared (first use in this function)

drivers/kvm/ioapic.c:208: error: (Each undeclared identifier is reported only once

drivers/kvm/ioapic.c:208: error: for each function it appears in.)

drivers/kvm/ioapic.c:219: error: 'dest_Fixed' undeclared (first use in this function)

make[2]: *** [drivers/kvm/ioapic.o] Error 1

make[1]: *** [drivers/kvm] Error 2

make: *** [drivers] Error 2
Regards,
	Mariusz

We now include asm/io_apic.h like we should.  Has that file changed in -mm?
--

error compiling committee.c: too many arguments to function
-

CONFIG_X86_IO_APIC isn't set.

-

Why should that matter?  we're just pulling that file for the definitions.
I'll try to compile without it here and see how it breaks.
--

error compiling committee.c: too many arguments to function
-

Hi Andrew,
The 2.6.23-rc8-mm1 kernel linking fails on the powerpc (P5+) box
  CC      init/version.o

  LD      init/built-in.o

  LD      .tmp_vmlinux1

drivers/built-in.o: In function `memory_block_action':

/root/scrap/linux-2.6.23-rc8/drivers/base/memory.c:188: undefined reference to `.remove_memory'

make: *** [.tmp_vmlinux1] Error 1
# gcc -v

Using built-in specs.

Target: powerpc64-suse-linux

Configured with: ../configure --enable-threads=posix --prefix=/usr

--with-local-prefix=/usr/local --infodir=/usr/share/info

--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib

--enable-languages=c,c++,objc,fortran,obj-c++,java,ada

--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2

--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib

--with-system-zlib --enable-shared --enable-__cxa_atexit

--enable-libstdcxx-allocator=new --program-suffix=-4.1

--enable-version-specific-runtime-libs --without-system-libunwind

--with-cpu=default32 --enable-secureplt --with-long-double-128 --host=powerpc64-suse-linux

Thread model: posix

gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
 # ld -v

GNU ld version 2.17.50.0.5 20060927 (SUSE Linux)
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

-

On Wed, 26 Sep 2007 01:30:02 +0530

Maybe my patch is the problem. could you give me your .config ?
Thanks,

-Kame
-

On Wed, 26 Sep 2007 10:32:05 +0900

Ah, memory hot remove is selectable even if the arch doesn't support it....sorry.
ok, this is fix.
Thanks,

-Kame

==

MEMORY_HOTREMOVE config option is selectable even it arch doesn't support it.

This fix it.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Index: linux-2.6.23-rc8-mm1/arch/ia64/Kconfig

===================================================================

--- linux-2.6.23-rc8-mm1.orig/arch/ia64/Kconfig

+++ linux-2.6.23-rc8-mm1/arch/ia64/Kconfig

@@ -305,6 +305,9 @@ config HOTPLUG_CPU

 config ARCH_ENABLE_MEMORY_HOTPLUG

 	def_bool y
+config ARCH_ENABLE_MEMORY_HOTREMOVE

+	def_bool y

+

 config SCHED_SMT

 	bool "SMT scheduler support"

 	depends on SMP

Index: linux-2.6.23-rc8-mm1/mm/Kconfig

===================================================================

--- linux-2.6.23-rc8-mm1.orig/mm/Kconfig

+++ linux-2.6.23-rc8-mm1/mm/Kconfig

@@ -141,7 +141,7 @@ config MEMORY_HOTPLUG_SPARSE
 config MEMORY_HOTREMOVE

 	bool "Allow for memory hot remove"

-	depends on MEMORY_HOTPLUG

+	depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE

 	depends on MIGRATION
 # Heavily threaded applications may benefit from splitting the mm-wide
-

Hi Kame,
Thanks, your patch fixes the problem.
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

-

I ran into the same thing earlier. Here is the fix I made.
Thanks,

Badari
Memory hotplug remove is currently supported only on IA64
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Index: linux-2.6.23-rc8/mm/Kconfig

===================================================================

--- linux-2.6.23-rc8.orig/mm/Kconfig	2007-09-25 14:44:03.000000000 -0700

+++ linux-2.6.23-rc8/mm/Kconfig	2007-09-25 14:44:48.000000000 -0700

@@ -143,6 +143,7 @@ config MEMORY_HOTREMOVE

 	bool "Allow for memory hot remove"

 	depends on MEMORY_HOTPLUG

 	depends on MIGRATION

+	depends on (IA64)
 # Heavily threaded applications may benefit from splitting the mm-wide

 # page_table_lock, so that faults on different parts of the user address
-

Hi Badari,
Thanks, your patch fixed the problem.
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

-

in unionfs debug.c:
#if BITS_PER_LONG == 32

#define POISONED_PTR		((void*) 0x5a5a5a5a)

#elif BITS_PER_LONG == 64

#define POISONED_PTR		((void*) 0x5a5a5a5a5a5a5a5a)

#else

#error Unknown BITS_PER_LONG value

#endif /* BITS_PER_LONG != known */
We try to keep all poison values in include/linux/poison.h so that

when digging around for them, it's easier to locate the one in

question.
Also, on x86_64, the 64-bit version wants a L or UL suffix:
fs/unionfs/debug.c:96:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long

fs/unionfs/debug.c:264:30: warning: constant 0x5a5a5a5a5a5a5a5a is so big it is long
---

~Randy

Phaedrus says that Quality is about caring.

-

This also fixes a compile warning on 64-bit systems.
Cc: ezk@cs.sunysb.edu

Signed-off-by: Josef 'Jeff' Sipek <jsipek@cs.sunysb.edu>

---

 fs/unionfs/debug.c     |   12 ++----------

 fs/unionfs/union.h     |    1 +

 include/linux/poison.h |    3 +++

 3 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/fs/unionfs/debug.c b/fs/unionfs/debug.c

index f678534..aa6a76a 100644

--- a/fs/unionfs/debug.c

+++ b/fs/unionfs/debug.c

@@ -25,14 +25,6 @@

 		}							\

 	} while (0)
-#if BITS_PER_LONG == 32

-#define POISONED_PTR		((void*) 0x5a5a5a5a)

-#elif BITS_PER_LONG == 64

-#define POISONED_PTR		((void*) 0x5a5a5a5a5a5a5a5a)

-#else

-#error Unknown BITS_PER_LONG value

-#endif /* BITS_PER_LONG != known */

-

 /*

  * __unionfs_check_{inode,dentry,file} perform exhaustive sanity checking on

  * the fan-out of various Unionfs objects.  We check that no lower objects

@@ -93,7 +85,7 @@ void __unionfs_check_inode(const struct inode *inode,

 				printk(" Ci5: inode/linode=%p:%p bindex=%d "

 				       "istart/end=%d:%d\n", inode,

 				       lower_inode, bindex, istart, iend);

-			} else if (lower_inode == POISONED_PTR) {

+			} else if (lower_inode == UNIONFS_POISONED_PTR) {

 				/* freed inode! */

 				PRINT_CALLER(fname, fxn, line);

 				printk(" Ci6: inode/linode=%p:%p bindex=%d "

@@ -261,7 +253,7 @@ void __unionfs_check_dentry(const struct dentry *dentry,

 				printk(" CI5: dentry/linode=%p:%p bindex=%d "

 				       "istart/end=%d:%d\n", dentry,

 				       lower_inode, bindex, istart, iend);

-			} else if (lower_inode == POISONED_PTR) {

+			} else if (lower_inode == UNIONFS_POISONED_PTR) {

 				/* freed inode! */

 				PRINT_CALLER(fname, fxn, line);

 				printk(" CI6: dentry/linode=%p:%p bindex=%d "

diff --git a/fs/unionfs/union.h b/fs/unionfs/union.h

index 9ec5f82..3b6881a 100644

--- a/fs/unionfs/union.h

+++ b/fs/unionfs/union.h

@@ -43,6 +43,7 @@

 #include <linux/fs_stack.h>

 #include <linux/magic.h>

 #include <linux/log2.h>

+#include <li...
[ message continues ]

Ok, I had a brain-fart...ignore this patch.
Jeff.
--

We have joy, we have fun, we have Linux on a Sun...

-

Right. I didn't want to introduce this kind of ifdef, the 0x5a pattern is

also the same as POISON_INUSE. I guess, using the 32-bit poison value should
Strange...I didn't get the warning when I compile tested; but it's valid.
Josef 'Jeff' Sipek.
--

Research, n.:

  Consider Columbus:

    He didn't know where he was going.

    When he got there he didn't know where he was.

    When he got back he didn't know where he had been.

    And he did it all on someone else's money.

-

Dereferencing unintialized "usb3" pointer in ufs_fill_super() is not

going to work. gcc even warns about this.
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000014e

printing eip: f9a3b1a2 *pde = 00000000

Oops: 0000 [#1] PREEMPT

last sysfs file: /block/loop7/removable

Modules linked in: ufs loop usbhid ehci_hcd snd_intel8x0 snd_ac97_codec uhci_hcd rtc ac97_bus usbcore thermal button processor sr_mod evdev cdrom
Pid: 1066, comm: mount Not tainted (2.6.23-rc8-mm1 #1)

EIP: 0060:[<f9a3b1a2>] EFLAGS: 00010286 CPU: 0

EIP is at ufs_fill_super+0x52f/0x12e5 [ufs]

EAX: 00000002 EBX: c39c4960 ECX: c0176465 EDX: 00000000

ESI: c38c5000 EDI: c387f800 EBP: 00000600 ESP: c3816d3c

 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068

Process mount (pid: 1066, ti=c3816000 task=c38f34d0 task.ti=c3816000)

last branch before last exception/interrupt

 from c0130fc0 (lockdep_on+0xb/0xc)

 to c0118d82 (vprintk+0x29f/0x2fb)

Stack: 00000010 00000000 00000600 00000000 c3816db4 0038c0d8 00000000 c3816dd4

       ffffffff 00000002 00000200 00000600 00002130 00002000 c39c4960 c01b1355

       c3816d94 c3816d94 c0187966 c3816db4 00000020 c0347b9b c280680c 00000400

Call Trace:

 [<c01b1355>] snprintf+0x1f/0x22

 [<c0187966>] disk_name+0x79/0x83

 [<c015c49b>] get_sb_bdev+0xdc/0x11a

 [<c016ca6d>] alloc_vfsmnt+0x8d/0xb3

 [<f9a39e3c>] ufs_get_sb+0x20/0x25 [ufs]

 [<f9a3ac73>] ufs_fill_super+0x0/0x12e5 [ufs]

 [<c015c09c>] vfs_kern_mount+0x40/0x79

 [<c016d601>] do_mount+0x6c0/0x7e3

 [<c02c82a3>] _spin_unlock+0x25/0x3b

 [<c01318dc>] mark_held_locks+0x39/0x53

 [<c013fd1d>] find_lock_page+0xf/0x84

 [<c014456f>] get_page_from_freelist+0x21e/0x3f0

 [<c0131ab0>] trace_hardirqs_on+0x118/0x13b

 [<c0144599>] get_page_from_freelist+0x248/0x3f0

 [<c01582f1>] kmem_cache_alloc+0x68/0x9b

 [<c016be18>] copy_mount_options+0x26/0x109

 [<c016d79b>] sys_mount+0x77/0xb3

 [<c0103db2>] sysenter_past_e...
[ message continues ]

2.6.23-rc6-mm1, 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1 all fail to link

correctly on a powerpc machine (elm3b19) in our test grid.  It fails as

below:
    LD      vmlinux.o

  ld: dynreloc miscount for fs/built-in.o, section .opd

  ld: can not edit opd Bad value

  make: *** [vmlinux.o] Error 1
Compiler versions and linker versions as below:
root@elm3b19:~/apw/linux-2.6.22# gcc -v

Using built-in specs.

Target: powerpc-linux-gnu

Configured with: ../src/configure -v

--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr

--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared

--with-system-zlib --libexecdir=/usr/lib --enable-nls

--without-included-gettext --enable-threads=posix --program-suffix=-4.0

--enable-__cxa_atexit --enable-libstdcxx-allocator=mt

--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm

--enable-java-awt=gtk-default --enable-gtk-cairo

--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre

--enable-mpfr --disable-softfloat

--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32

--disable-werror --enable-checking=release powerpc-linux-gnu

Thread model: posix

gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)

root@elm3b19:~/apw/linux-2.6.22# ld -v

GNU ld version 2.16.1 Debian GNU/Linux
As suggested elsewhere I have had a go at tracking this down.  Previous

problems of this kind were introduced as a result of using 'weak'

declarations to provide default implementations.  This investigation led

me to the following commit:
  commit c60473b5d32ea6cf4561232bc852bacd3a513528

  Author: Jiri Kosina <jkosina@suse.cz>

  Date:   Sat Sep 15 01:49:49 2007 +0000
    i386-and-x86_64-randomize-brk
Backing this change out seems to get us past this problem.  If we are to

support compilers of this age, and I believe we currently do, then we

probabally need to avoid the weak declarations and use the Kconfig

system to provide the alternatives here.
Jiri?
-apw

-

Hi,
actually, my first patch wasn't using weak symbols, but I have been

convinced that it's the way to go(tm). Please see

http://lkml.org/lkml/2007/9/1/131 and the ongoing thread.
I am fine with replacing the brk randomization patch with the one that

wasn't using weak symbols (posted in the mentioned thread too), I have no

strong opinion either way.
Thanks,
--

Jiri Kosina

SUSE Labs

-

Ok, this problem seems to still persist in 2.6.23-rc8-mm2.  It seems

we have three options from here:
1) update the compiler support list to exclude these compilers, or

2) back this change out, or

3) switch to the version not using __weak.
The latter seems to be the least intrusive change.  As no-one closer

to the problem is stepping up to make the decision I will propose

we go with the third option here.
-apw

-

Andrew,
if you agree with Andy that we should support compilers that don't work

with __weak, please drop i386-and-x86_64-randomize-brk.patch and replace

it with the one below instead (this has been already posted at

http://lkml.org/lkml/2007/8/31/113). Thanks.
From: Jiri Kosina <jkosina@suse.cz>
i386 and x86_64: randomize brk()
This patch randomizes the location of the heap (brk) for i386 and x86_64.

The range is randomized in the range starting at current brk location up

to 0x02000000 offset for both architectures. This, together with

pie-executable-randomization.patch and

pie-executable-randomization-fix.patch, should make the address space

randomization on i386 and x86_64 complete.
The empty stubs are not added for architectures that don't support ELF

binaries, namely blackfin, h8300, m68knommu and v850.
Arjan says:
This is known to break older versions of some emacs variants, whose dumper

code assumed that the last variable declared in the program is equal to

the start of the dynamically allocated memory region.
(The dumper is the code where emacs effectively dumps core at the end of

it's compilation stage; this coredump is then loaded as the main program

during normal use)
iirc this was 5 years or so; we found this way back when I was at RH and

we first did the security stuff there (including this brk randomization).

It wasn't all variants of emacs, and it got fixed as a result (I vaguely

remember that emacs already had code to deal with it for other archs/oses,

just ifdeffed wrongly).
It's a rare and wrong assumption as a general thing, just on x86 it mostly

happened to be true (but to be honest, it'll break too if gcc does

something fancy or if the linker does a non-standard order).  Still its

something we should at least document.
Note 2: afaik it only broke the emacs *build*.  I'm not 100% sure about

that (it IS 5 years ago) though.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/arch/i386/kernel/p...
[ message continues ]

On Thu, 27 Sep 2007 14:13:21 +0200 (CEST)
Because we already have a declaration in the correct place?

-

Some time passed since I have written the patch, but I remember that this

was needed, otherwise under some circumstances the build failed, but I

don't remember details ... I will try to look at it more in a while.
But it definitely was needed to work with that horrible

include-huge-c-file-from-another-one.
Thanks,
--

Jiri Kosina

SUSE Labs

-

We have quite a few instances of __weak in there.  What is special about
That's a better patch anyway.  We often use __weak because people

can't be bothered doing all that editing.

-

The bug we trigger is an ld bug - not a compiler bug.

What happens is that we have the same function defined weak twice.

In fs/ we include binfmt_elf.o in the build because

CONFIG_BINFMT_ELF is set.

And in arch/powerpc/kernel/binfmt_elf32.c:

we do an: #include "../../../fs/binfmt_elf.c"
Without actually trying it out I assume we trigger the ld bug

because we define the same weak function twice.
And this is a non-typical situation.
	Sam

-

Kill two unused variables in drivers/usb/misc/sisusbvga/sisusb.c.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---

 drivers/usb/misc/sisusbvga/sisusb.c |    2 --

 1 file changed, 2 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/usb/misc/sisusbvga/sisusb.c

===================================================================

--- linux-2.6.23-rc8-mm1.orig/drivers/usb/misc/sisusbvga/sisusb.c

+++ linux-2.6.23-rc8-mm1/drivers/usb/misc/sisusbvga/sisusb.c

@@ -3316,8 +3316,6 @@ static struct usb_driver sisusb_driver =
 static int __init usb_sisusb_init(void)

 {

-	int retval;

-	struct sisusb_usb_data *sisusb;
 #ifdef INCL_SISUSB_CON

 	sisusb_init_concode();

-

Yes, there's been a lot of breakage in netdev land:
git-net-fix-macec.patch

git-net-sky2-fixups.patch

git-net-fix-wireless-kconfig.patch

git-net-fix-spidernet-build.patch

git-net-sctp-build-fix.patch

spider_net_ethtool-keep-up-with-recent-netdev-stats-changes.patch

pasemi_mac-build-fix-after-recent-netdev-stats.patch

git-net-fix-pasemi_mac.patch

make-mv643xx_ethc-build-again.patch
but we're getting there.  It looks like ibmn_newemac is more busted than

most...

-

This patch kills a may-be-used-uninitialized warning.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---

 fs/udf/balloc.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.23-rc8-mm1/fs/udf/balloc.c

===================================================================

--- linux-2.6.23-rc8-mm1.orig/fs/udf/balloc.c

+++ linux-2.6.23-rc8-mm1/fs/udf/balloc.c

@@ -689,7 +689,7 @@ static int udf_table_new_block(struct su

 	uint32_t spread = 0xFFFFFFFF, nspread = 0xFFFFFFFF;

 	uint32_t newblock = 0, adsize;

 	uint32_t elen, goal_elen = 0;

-	kernel_lb_addr eloc, goal_eloc;

+	kernel_lb_addr eloc, uninitialized_var(goal_eloc);

 	struct extent_position epos, goal_epos;

 	int8_t etype;
-

Hi Andrew,
The build error reported at http://lkml.org/lkml/2007/9/20/210 for the

drivers/ata/pata_scc.c is seen in both 2.6.23-rc7-mm1 and 2.6.23-rc8-mm1.
The patch proposed for this build error at http://lkml.org/lkml/2007/9/21/557

is not seen in the latest 2.6.23-rc8-mm1 patch's.
--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

-

The followup to that report wasn't clear to me and I was hoping that Alan
Alan didn't comment on that one.  afacit it is needed in Jeff's

git-libata-all tree.  I'll merge it and see what happens.
-