ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2...
- In response to various people needing to get at the mm tree in a timely

  fashion I have created "MM of the minute", at
	http://userweb.kernel.org/~akpm/mmotm/
  I'll upload the patch queue there multiple times per day.  I will attempt

  to ensure that the patches in there actually apply, but they sure as heck

  won't all compile and run.
- 2.6.24-rc2-mm1 may oops during shutdown and reboot.  This is due to

  gregkh-driver-kset-convert-sys-devices-system-to-use-kset_create.patch.

  It's a known problem, but if you have additional insights into what causes

  it, feel free to let Greg know.
- Added the pci hotplug development quilt tree to the -mm lineup, from

  http://www.kernel.org/pub/linux/kernel/people/kristen/pci-hotplug/

  (Kristen Carlson Accardi <kristen.c.accardi@intel.com>)
- Added the x86 development tree to the -mm lineup (Thomas Gleixner

  <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>)
- Probably added other git trees too - I often forget to explicitly mention

  them.
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 fi...
[ message continues ]

Doesn't boot here:
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

Floppy drive(s): fd0 is 1.44M

floppy0: Floppy io-port 0x03f2 in use

INFO: trying to register non-static key.

the code is fine but needs lockdep annotation.

turning off the locking correctness validator.
Call Trace:

 [<ffffffff80251f88>] __lock_acquire+0x1b7/0xcd0

 [<ffffffff80252e8e>] lock_acquire+0x51/0x6c

 [<ffffffff8035bd62>] kobject_add+0x9b/0x197

 [<ffffffff80598ce2>] _spin_lock+0x1e/0x27

 [<ffffffff8035bd62>] kobject_add+0x9b/0x197

 [<ffffffff802c9a42>] register_disk+0x48/0x209

 [<ffffffff80355d14>] add_disk+0x34/0x3d

 [<ffffffff8083cdb4>] rd_init+0x172/0x1e1

 [<ffffffff8082063a>] kernel_init+0x175/0x2e6

 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139

 [<ffffffff80598779>] trace_hardirqs_on_thunk+0x35/0x3a

 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139

 [<ffffffff8020c628>] child_rip+0xa/0x12

 [<ffffffff8020bd3f>] restore_args+0x0/0x30

 [<ffffffff808204c5>] kernel_init+0x0/0x2e6

 [<ffffffff8020c61e>] child_rip+0x0/0x12
INFO: lockdep is turned off.

BUG: spinlock lockup on CPU#0, swapper/1, FFFF81001FA2BED0
Call Trace:

 [<ffffffff80363632>] _raw_spin_lock+0xd1/0xf8

 [<ffffffff8035bd62>] kobject_add+0x9b/0x197

 [<ffffffff8035bd62>] kobject_add+0x9b/0x197

 [<ffffffff802c9a42>] register_disk+0x48/0x209

 [<ffffffff80355d14>] add_disk+0x34/0x3d

 [<ffffffff8083cdb4>] rd_init+0x172/0x1e1

 [<ffffffff8082063a>] kernel_init+0x175/0x2e6

 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139

 [<ffffffff80598779>] trace_hardirqs_on_thunk+0x35/0x3a

 [<ffffffff8025194c>] trace_hardirqs_on+0x115/0x139

 [<ffffffff8020c628>] child_rip+0xa/0x12

 [<ffffffff8020bd3f>] restore_args+0x0/0x30

 [<ffffffff808204c5>] kernel_init+0x0/0x2e6

 [<ffffffff8020c61e>] child_rip+0x0/0x12
INF...
[ message continues ]

I'd suspect the driver tree.  I think I'll need to do a quick -mm2 without

that tree present.
-

I am just verifying whether reverting kset changes fixes this, will let

you know soon.
--

Jiri Kosina

-

OK, so I reverted

gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made me

also revert gregkh-driver-kobject-remove-subsystem_register-functions and

gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both the

error message from lockdep and more importantly the spinlock lockup have

gone, and the system with these patches reverted boots for me fine.
Well not that fine, I still see (which is the same backtrace that caused

the lockup with plain -rc2-mm1, but doesn't make the machine hang):
floppy0: Floppy io-port 0x03f2 in use

WARNING: at lib/kref.c:33 kref_get()
Call Trace:

 [<ffffffff8035bd43>] kobject_add+0x9b/0x197

 [<ffffffff8035c6e1>] kref_get+0x2f/0x36

 [<ffffffff8035b82f>] kobject_get+0x12/0x17

 [<ffffffff8035bd55>] kobject_add+0xad/0x197

 [<ffffffff802c9a36>] register_disk+0x48/0x205

 [<ffffffff80355cf3>] add_disk+0x34/0x3d

 [<ffffffff8083cd99>] rd_init+0x172/0x1e1

 [<ffffffff8082063a>] kernel_init+0x175/0x2e6

 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139

 [<ffffffff80598769>] trace_hardirqs_on_thunk+0x35/0x3a

 [<ffffffff8025193c>] trace_hardirqs_on+0x115/0x139

 [<ffffffff8020c628>] child_rip+0xa/0x12

 [<ffffffff8020bd3f>] restore_args+0x0/0x30

 [<ffffffff808204c5>] kernel_init+0x0/0x2e6

 [<ffffffff8020c61e>] child_rip+0x0/0x12
--

Jiri Kosina

-

And this goes away when

gregkh-driver-remove-struct-kobj_type-from-struct-kset is reverted.
--

Jiri Kosina

-

someone is trying to call kref_get on a kobject that has not been

initialized yet, which could be the reason the newer patches break

something, as the pointers are not set up properly with a call to

kobject_init() first.
But, alloc_disk() should have been called on this gendisk for it to work

properly at all, unless something is trashing that structure?
I'm way confused...
greg k-h

-

This patch, as found by Dave Young, should fix the issue:
I'll roll it into my larger patchset so that Andrew will get it

automatically next release, but here it is for people to use now.
thanks,
greg k-h
--------------
From: Greg Kroah-Hartman <gregkh@suse.de>

Subject: fix bug with adding new block devices in -mm
need to set the kset before initializing the kobject.
---

 block/genhd.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/block/genhd.c

+++ b/block/genhd.c

@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino

 			}

 		}

 		disk->minors = minors;

-		kobject_init(&disk->kobj);

 		disk->kobj.kset = block_kset;

 		disk->kobj.ktype = &ktype_block;

+		kobject_init(&disk->kobj);

 		rand_initialize_disk(disk);

 		INIT_WORK(&disk->async_notify,

 			media_change_notify_thread);

-

Hmm, something strange going on here. With this patch applied on top of

2.6.24-rc2-mm1, I can't see no lockup or warning from kobjects code, which

is good. But this happens:
...

Creating device nodes with udev

resume device  not found (ignoring)

Waiting for device

/dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6 to appear:

ok

showconsole: Warning: the ioctl TIOCGDEV is not known by the kernel

fsck 1.40.2 (12-Jul-2007)

[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a

/dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6

Error writing block 1542 (Attempt to write block from filesystem resulted

in short write).
/dev/disk/by-id/scsi-SATA_HDS722516VLSA80_VN6D3ECDE5BD9D-part6: UNEXPECTED

INCONSISTENCY; RUN fsck MANUALLY.

        (i.e., without -a or -p options)

Error writing block 1542 (Attempt to write block from filesystem resulted in short write).                                                                                         
(and this keeps looping forever).
However the very same kernel, with the very same .config, but with just 
	gregkh-driver-kset-convert-block_subsys-to-use-kset_create

	gregkh-driver-kobject-remove-subsystem_register-functions

	gregkh-driver-kset-remove-decl_subsys-macro
reverted, boots perfectly fine.
--

Jiri Kosina

-

On Thu, 15 Nov 2007 22:41:41 +0100 (CET)
Yup.  Please apply the fix from

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2...

-

Right, thanks.
OK, so I confirm that the fix from Dave fixes the lockup that I am

obtaining with rc2-mm1 and also the warning from wrong kref reference

count (lib/kref.c:33 kref_get()) is gone.
--

Jiri Kosina

-

Hi,

Could you please add signed-off by me?
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Regards

dave

-

Sure, but I've modified the original patch to not include this bug in

the first place, so there's really not much to sign off on there, sorry.
I will add your name as helping out with it, if that's ok.
thanks,
greg k-h

-

Ok,  thanks.
Regards

dave

-

$ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.24-rc2-mm1

error: no such remote ref refs/tags/v2.6.24-rc2-mm1

fatal: Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
I can see the v2.6.24-rc2-mm1 tag on

http://git.kernel.org/?p=linux/kernel/git/smurf/linux-trees.git;a=summary

though, so there seems to be something fishy ... ?
--

Jiri Kosina

-

Hi,
Yeah, the import took too long and thus broke.
Should be fixed by now.

--

Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de

   Protocol for transmitting files between systems on the Internet. 2. vt.

   To {beam} a file using the File Transfer Protocol. 3. Sometimes used as

   a generic even for file transfers not using {FTP}. "Lemme get a copy of

   "Wuthering Heights" ftp'd from uunet."

-

Hi Matthias,
hmm, still doesn't work even if I try to fetch the tag directly from hera

(i.e. not waiting for sync to git mirrors on kernel.org):
$ git-fetch jikos@master.kernel.org:/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.24-rc2-mm1

error: refs/heads/master points nowhere!

error: refs/heads/master points nowhere!

error: no such remote ref refs/tags/v2.6.24-rc2-mm1

fatal: Fetch failure: jikos@master.kernel.org:/pub/scm/linux/kernel/git/smurf/linux-trees.git
--

Jiri Kosina

-

Hi,
*Sigh* fixed. I hope. ;-)

--

Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de

Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de

 - -

Just about every computer on the market today runs Unix, except the Mac

(and nobody cares about it).

		-- Bill Joy 6/21/85

-

Yes, now it works. Thanks a lot,
--

Jiri Kosina

-

Hi,

Boot failed on my machine. hand copy some messages.
First with BLK_DEV_RAM=y
BUG kmalloc-64 Poison overwritting:

Alloced in kset_create

Freed in kobject_cleanup
--cut--

alloc_disk_node

rd_init

kernel_init

--cut--
Then config ramdisk as module, build and reboot:
BUG: unable handle paging resuest at 6b6b6b6b

EIP is kobject_add 0xc4/0x150
--cut--

kobject_set_name

register_disk

add_disk

exact_match

exact_lock

loop_init

--cut--
Regards

dave

--cut--

-

erp.  Can you send the config over please?
And which distro/version is that machine running?
Thanks.

-

Hi,andrew
slackware 11
config as follows:

#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.24-rc2-mm1

# Wed Nov 14 13:50:01 2007

#

CONFIG_X86_32=y

CONFIG_GENERIC_TIME=y

CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_CLOCKSOURCE_WATCHDOG=y

CONFIG_GENERIC_CLOCKEVENTS=y

CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

CONFIG_LOCKDEP_SUPPORT=y

CONFIG_STACKTRACE_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_X86=y

CONFIG_FAST_CMPXCHG_LOCAL=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

CONFIG_QUICKLIST=y

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

# CONFIG_GENERIC_GPIO is not set

CONFIG_GENERIC_HWEIGHT=y

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#

# General setup

#

CONFIG_EXPERIMENTAL=y

CONFIG_LOCK_KERNEL=y

CONFIG_INIT_ENV_ARG_LIMIT=32

CONFIG_LOCALVERSION=""

# CONFIG_LOCALVERSION_AUTO is not set

CONFIG_SWAP=y

CONFIG_SYSVIPC=y

CONFIG_SYSVIPC_SYSCTL=y

CONFIG_POSIX_MQUEUE=y

CONFIG_BSD_PROCESS_ACCT=y

# CONFIG_BSD_PROCESS_ACCT_V3 is not set

# CONFIG_TASKSTATS is not set

# CONFIG_USER_NS is not set

# CONFIG_PID_NS is not set

# CONFIG_AUDIT is not set

CONFIG_IKCONFIG=y

CONFIG_IKCONFIG_PROC=y

CONFIG_LOG_BUF_SHIFT=16

# CONFIG_CGROUPS is not set

CONFIG_FAIR_GROUP_SCHED=y

CONFIG_FAIR_USER_SCHED=y

# CONFIG_FAIR_CGROUP_SCHED is not set

CONFIG_SYSFS_DEPRECATED=y

# CONFIG_RELAY is not set

CONFIG_BLK_DEV_INITRD=y

CONFIG_INITRAMFS_SOURCE=""

# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

CONFIG_SYSCTL=y

# CONFIG_EMBEDDED is not set

CONFIG_UID16=y

CONFIG_SYSCTL_SYSCALL=y

CONFIG_KALLSYMS=y

# CONFIG_KALLSYMS_EXTRA_PASS is not set

CONFIG_HOTPLUG=y

CONFIG_PRINTK=y

CONFIG_BUG=y

CONFIG_ELF_CORE=y

CONFIG_BASE_FULL=y

CONFIG_FUTEX=y

CONFIG_ANON_INODES=y

CONFIG_EPOLL=y

CONFIG_SIGNALFD=y

CONFIG_EVENTFD=y

CONFIG_SHMEM=y

CONFIG_VM_EVENT_COUNTERS=y

CONFIG_SLUB_DEBUG=y

# CONFIG_SLAB is not set

CONFIG_SLUB=y

# CONFIG_SLOB is not set

CONFIG_PROC_PAGE_MONITOR=y

CONFIG_RT_MUTEXES=y

# CONFIG_T...
[ message continues ]

OK, I can reproduce that on the Vaio, thanks.
oops: http://userweb.kernel.org/~akpm/dsc00037.jpg

config: (what you sent)

dmesg: http://userweb.kernel.org/~akpm/dmesg-sony.txt
An inspired guess led me to suspect the driver tree.  The offending patch

is gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch.
There's some kobject warning which comes out when

gregkh-driver-kset-convert-block_subsys-to-use-kset_create.patch isn't

applied.  More bisecting coming up..
-

Hi,

I do some printk debug, the problem hide in the kobject.c line 256 in

kobject_add

seems  at

list_add_tail(&kobj->entry,&kobj->kset->list);
Regards

dave

-

That's just wierd.  I'll try to figure this out...
Kay, any thoughts, I can use any hint anyone has here :)
thanks,
greg k-h

-

Hmm, I tried to reproduce, but none of my boxes shows that.
Could it be an init-order problem, where something tries to use the

block subsystem? Before it is initialized with:

  block/genhd.c :: subsys_initcall(genhd_device_init);
If that's the case, we have an old bug that nobody noticed with static

structures, which are zeroed that time, but definitely not properly

initialized.
I'll try to build loop non-modular now, and see if that makes the bug

appear here.
Kay
-

Hi Kay,
my .config with which I reproduc this on 2.6.24-rc2-mm1 reliably can be

obtained from http://www.jikos.cz/jikos/junk/.config
--

Jiri Kosina

-

Hmm, that config doesn't do anything here, and if I make it boot, it

does not show the bug.
Could you possibly enable kobject debugging and see if that exposes

something, maybe something goes wrong with the kset refcount and it gets

released while in use.
Kay
-

Hi,

I would do that.

BTW, The bug report as EIP  at __list_add with CONFIG_DEBUG_LIST=y
Regards

dave

-

Yeah, that hints that the kset, which contains the list, is not

allocated at the time it is used, or it is already released (kfree)

again by some buggy logic.
All this could not happen before, as the kset was statically in memory.

It may be an old bug, that just never crashed anything. We already fixed

a bunch of similar things, that showed up while doing this patch set.
Thanks,

Kay
-

Now with the DEBUG_KOBJECT set , nothing more info.

But this time the EIP is at the strnlen (called by printk -- line 239

of kobject.c)
EIP is at strnlen +0x9/0x20

EAX 6b6b6b6b EBX c05487c14 ecx 6b6b6b6b EDX fffffffe

---cut---
If you need more infomation, I will copy more (no camera in hand)
Regards

dave

-

Yes, I debugged it, there's some new findings.

It is freed by put_disk.

The floppy driver alloc_disk and then call put_disk without register_disk.

in kobject_cleanup line 551:

if(s)

	kset_put(s);

Now the kset is set in alloc_disk after kobject_init, so it is not refereced yet.

please try this patch:
block/genhd.c |    2 +-

1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/block/genhd.c linux.new/block/genhd.c

--- linux/block/genhd.c	2007-11-15 15:59:11.000000000 +0800

+++ linux.new/block/genhd.c	2007-11-15 15:59:39.000000000 +0800

@@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino

 			}

 		}

 		disk->minors = minors;

-		kobject_init(&disk->kobj);

 		disk->kobj.kset = block_kset;

 		disk->kobj.ktype = &ktype_block;

+		kobject_init(&disk->kobj);

 		rand_initialize_disk(disk);

 		INIT_WORK(&disk->async_notify,

 			media_change_notify_thread);

-

Ah, yes, that is a bug, and it's my fault, let me go fix that in my

patch series.  Thanks a lot for finding this.
Does this patch fix your problem?
thanks,
greg k-h

-

Oh, this is an old bug, that just didn't crash with the static ksets, it

did all the refcounting wrong, but nobody noticed it because the kset

data was still there.
Kay
-

No, I messed it up when I did the initial kset changes.  If you look at

2.6.24-rc2, it's correct there:

		disk->minors = minors;

		kobj_set_kset_s(disk,block_subsys);

		kobject_init(&disk->kobj);
I have no idea why I switched those lines around, sorry about that.
greg k-h

-

Yeah, that looks like it.
It still does not fail here, but I can simulate the behavior of

floppy.c, and that gets fixed by your patch. Great!
Thanks a lot,

Kay
-

[   11.863390] ACPI: AC Adapter [ACAD] (on-line)

[   11.868004] ACPI: Battery Slot [BAT1] (battery present)

[   11.922945] Real Time Clock Driver v1.12ac

[   11.923078] intel_rng: FWH not detected

[   11.923160] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

[   14.934078] floppy0: no floppy controllers found

[   14.934616] WARNING: at lib/kref.c:33 kref_get()

[   14.934690]  [<c0242810>] kref_get+0x40/0x50

[   14.934766]  [<c024185f>] kobject_get+0xf/0x20

[   14.934839]  [<c0241e7f>] kobject_add+0x14f/0x1a0

[   14.934917]  [<c0241c8e>] kobject_set_name+0x7e/0xc0

[   14.934998]  [<c01b82af>] register_disk+0x3f/0x200

[   14.935078]  [<c02392ff>] blk_register_region+0x2f/0x40

[   14.935164]  [<c0239349>] add_disk+0x39/0x50

[   14.935234]  [<c0238b80>] exact_match+0x0/0x10

[   14.935306]  [<c0239120>] exact_lock+0x0/0x10

[   14.935378]  [<c051b73b>] loop_init+0x13b/0x190

[   14.935453]  [<c0500570>] kernel_init+0x130/0x300

[   14.935532]  [<c010428e>] ret_from_fork+0x6/0x1c

[   14.938302]  [<c0500440>] kernel_init+0x0/0x300

[   14.941033]  [<c0500440>] kernel_init+0x0/0x300

[   14.943732]  [<c0104f8f>] kernel_thread_helper+0x7/0x18

[   14.946436]  =======================

[   14.949535] loop: module loaded

[   14.952336] e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI

[   14.955022] e100: Copyright(c) 1999-2006 Intel Corporation

[   14.957813] ACPI: PCI Interrupt 0000:06:08.0[A] -> GSI 20 (level, low) -> IRQ
Caused by gregkh-driver-remove-struct-kobj_type-from-struct-kset.patch

-

Breaks nfsv4 in a rather funny way:
treogen ~ # cd /usr/portage/x

treogen x # touch bla

touch: cannot touch `bla': File exists

treogen x # mkdir bla

treogen x # touch bla/bla

touch: cannot touch `bla/bla': File exists

treogen x # ls -lad *

drwxr-xr-x 2 root root 6 Nov 14 20:03 bla

treogen x # ls -la *

total 0

drwxr-xr-x 2 root root  6 Nov 14 20:03 .

drwxr-xr-x 3 root root 16 Nov 14 20:03 ..

treogen x #
So I can create new directories, but not new files. Reading files works normal.
The client is 2.6.24-rc2-mm1, the server 2.6.22-gentoo-r9.

The fstab-line from the client:

192.168.2.4:/portage    /usr/portage            nfs4

rw,noatime,nodiratime,intr 0 0
2.6.23-mm1 as client worked, some 2.6.24-rc1-git? also.
Otherwise the new -mm worked OK for me, no errors visible in the syslog.

It even fixed the ACPI Exception from regression bug 9320.

Now the output is:

[   83.125873] scsi8 : pata_amd

[   83.125917] scsi9 : pata_amd

[   83.127062] ata9: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14

[   83.127064] ata10: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15

[   83.194917] ata9.01: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133

[   83.194920] ata9.01: 490234752 sectors, multi 16: LBA48

[   83.194929] ata9: nv_mode_filter: 0x7f39f&0x701f->0x701f,

BIOS=0x7000 (0xc00000) ACPI=0x701f (900:60:0x14)

[   83.197327] ata9.01: configured for UDMA/33

[   83.197348] ata10: port disabled. ignoring.

[   83.197428] scsi 8:0:1:0: Direct-Access     ATA      Maxtor 6L250R0

  BAH4 PQ: 0 ANSI: 5

[   83.197487] sd 8:0:1:0: [sdd] 490234752 512-byte hardware sectors (251000 MB)

[   83.197496] sd 8:0:1:0: [sdd] Write Protect is off

[   83.197498] sd 8:0:1:0: [sdd] Mode Sense: 00 3a 00 00

[   83.197510] sd 8:0:1:0: [sdd] Write cache: enabled, read cache:

enabled, doesn't support DPO or FUA

[   83.197542] sd 8:0:1:0: [sdd] 490234752 512-byte hardware sectors (251000 MB)

[   83.197549] sd 8:0:1:0: [sdd] Write Protect is off

[   83.197551] sd 8:0:1:0: [sdd] Mode Sen...
[ message continues ]

hm.  I guess that means I get to do yet another git-bisect.  Either the nfs
OK, thanks.
-

Seems like you would lose that bet.
I don't have the time to finish the bisect, but there are only 19

patches remaining and three of them look like the prime suspects:
20709a71062a02d0271424f78c547dc733e863fe use-struct-path-in-struct-svc_expkey

b07dd17327f38b9a5401415c0fbf816e6cd0051b

use-struct-path-in-struct-svc_export-checkpatch-fixes

a0886174a1bc1b7c172d40c1e416ba7e48a35ffd use-struct-path-in-struct-svc_export

62e954810588af549580026c3d8718e7717837d0

d_path-make-get_dcookie-use-a-struct-path-argument-checkpatch-fixes

06719d94df24e67ccecf38cf4c6879188dd3f18a

d_path-make-get_dcookie-use-a-struct-path-argument

979a6d93394b28eee31f3322177827ec938eb34f

d_path-make-proc_get_link-use-a-struct-path-argument

59b0e6c59449dc2fc2366d54f76470056483f9e6

d_path-use-struct-path-in-struct-avc_audit_data-checkpatch-fixes

f15c39b7240e37ba89433aba610bfa10bd22b4f7

d_path-use-struct-path-in-struct-avc_audit_data

84556ff61beaacc32d7bcba3d644d4d8d6539356 d_path-kerneldoc-cleanup

5087403994daedc7bfd338f65b7dc69216b03e2e

one-less-parameter-to-__d_path-checkpatch-fixes

b610833be56ae170d33d91ee4325b70d38d6f28b one-less-parameter-to-__d_path

7395eaf4a37d80dd657e1b527de0cf9c94b4f866 introduce-path_put-unionfs

dde9146c8a1cec65d3d62ff0cbbea03598ccf1f5

embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-unionfs

5fc66f255cfc1780ca22b7ddcd2d91d1abd68e48 introduce-path_get-unionfs

0ef3d8718cc6732ed2d8294cee8838bf451bd133 make-set_fs_rootpwd-take-a-struct-path

be604962ef9505c13e2ce757c0c557bd2f9fd19e use-struct-path-in-fs_struct

b87fbae44dd2eb0fe803f888d8f7fa1fb820553c introduce-path_get

9780697f9e775cbcf62b18780036fbb03b76100f

use-path_put-in-a-few-places-instead-of-mntdput

53923d3167a3820ec21ba6464da80395a5d32dce introduce-path_put
(sha1 come from

git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git)
I added Jan Blunck to the recipents, as he wrote

use-struct-path-in-struct-svc_expkey and

use-struct-path-in-struct-svc_export
Torsten

-

These patches only change the server code. Hard to imagine how this could

break the client. The other patches are pure cleanups only.
Regards,

	Jan
--

Jan Blunck <jblunck@suse.de>

-

While the next bisect proved that these patches are innocent, I'm

still blaming you for my problems. ;)
The problem with the first bisect-try was, that everything between

bisect-good: r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename

and

bisect-bad: use-struct-path-in-struct-svc_export

did not compile like this:
  CC [M]  fs/nfsd/vfs.o

fs/nfsd/vfs.c: In function 'nfsd_rename':

fs/nfsd/vfs.c:1695: error: request for member 'mnt' in something not a

structure or union

make[2]: *** [fs/nfsd/vfs.o] Error 1

make[1]: *** [fs/nfsd] Error 2

make: *** [fs] Error 2
This is cause by: nfsd-fix-wrong-mnt_writer-count-in-rename
With this patch reverted I was able to finish the bisect:
Good: move-struct-path-into-its-own-header

...: embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt

Bad: embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt-checkpatch-fixes
As you also wrote

embed-a-struct-path-into-struct-nameidata-instead-of-nd-dentrymnt , I

would like to ask you to take another look at it.
The only thing that looks suspicious to me in that patch is the

following change in nfs4_atomic_open(), nfs4_open_revalidate() and

nfs4_proc_create()
-	struct path path = {

-		.mnt = nd->mnt,

-		.dentry = dentry,

-	};

+	struct path path = nd->path;
This changes the path.dentry from the explizit parameter 'dentry' to

the embedded dentry from the parameter 'nd'.
Hope this helps.
Torsten

-

Ouch! You are totally right. This really looks wrong and I even don't remember

how that went into the patch. Can you test if the following patch fixes the

problem? (BTW: thanks for the detailed analysis)
Thanks,

Jan
---
Subject: Embed a struct path into struct nameidata breakes NFSv4
I accidently break NFSv4. Here is the original report by Torsten Kaiser:
 > > Breaks nfsv4 in a rather funny way:

 > >

 > > treogen ~ # cd /usr/portage/x

 > > treogen x # touch bla

 > > touch: cannot touch `bla': File exists

 > > treogen x # mkdir bla

 > > treogen x # touch bla/bla

 > > touch: cannot touch `bla/bla': File exists

 > > treogen x # ls -lad *

 > > drwxr-xr-x 2 root root 6 Nov 14 20:03 bla

 > > treogen x # ls -la *

 > > total 0

 > > drwxr-xr-x 2 root root  6 Nov 14 20:03 .

 > > drwxr-xr-x 3 root root 16 Nov 14 20:03 ..

 > > treogen x #
Signed-off-by: Jan Blunck <jblunck@suse.de>

---

 fs/nfs/nfs4proc.c |   15 ++++++++++++---

 1 file changed, 12 insertions(+), 3 deletions(-)
Index: b/fs/nfs/nfs4proc.c

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

--- a/fs/nfs/nfs4proc.c

+++ b/fs/nfs/nfs4proc.c

@@ -1372,7 +1372,10 @@ out_close:

 struct dentry *

 nfs4_atomic_open(struct inode *dir, struct dentry *dentry, struct nameidata *nd)

 {

-	struct path path = nd->path;

+	struct path path = {

+		.mnt = nd->path.mnt,

+		.dentry = dentry,

+	};

 	struct iattr attr;

 	struct rpc_cred *cred;

 	struct nfs4_state *state;

@@ -1411,7 +1414,10 @@ nfs4_atomic_open(struct inode *dir, stru

 int

 nfs4_open_revalidate(struct inode *dir, struct dentry *dentry, int openflags, struct nameidata *nd)

 {

-	struct path path = nd->path;

+	struct path path = {

+		.mnt = nd->path.mnt,

+		.dentry = dentry,

+	};

 	struct rpc_cred *cred;

 	struct nfs4_state *state;
@@ -1860,7 +1866,10 @@ static int

 nfs4_proc_create(struct inode...
[ message continues ]

This patch fixes the above nfs problem, I can create files again.
But shortly after starting to use the nfs share my system locked up

nearly completely.
I was using emerge (Gentoos package manager) to upgrade a package,

according to its output it just was finished downloading it (via wget

onto the nfs share) and the next step should normally be a

checksumming of the new file. emerge did not print anything out, so it

hang either at the end of the download, or during the checksumming.
The desktop froze completely, I was no longer able to move the mouse.

The system still responded to SysRq and ping, but logging in via ssh

was not possible.
I captured SysRq+W on a serial console, then used SysRq+P:

[  944.142371] SysRq : Show Regs

[  944.145415] CPU 3:

[  944.147500] Modules linked in: radeon drm nfsd exportfs ipv6

w83792d tuner tea5767 tda8290 tuner_xc2028 tda9887 tuner_simple mt20xx

tea5761 tvaudio msp3400 bttv ir_common compat_ioctl32 videobuf_dma_sg

videobuf_core btcx_risc tveeprom videodev usbhid v4l2_common

v4l1_compat hid sg i2c_nforce2 pata_amd

[  944.175225] Pid: 605, comm: rpciod/3 Not tainted 2.6.24-rc2-mm1 #4

[  944.181573] RIP: 0010:[<ffffffff805b0542>]  [<ffffffff805b0542>]

_spin_lock_irqsave+0x12/0x30

[  944.190342] RSP: 0018:ffff81007ef33e28  EFLAGS: 00000286

[  944.195801] RAX: 0000000000000286 RBX: ffff81007ef33e60 RCX: 0000000000000000

[  944.203115] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff81011e107960

[  944.210440] RBP: ffff81011cc6c588 R08: ffff8100db918130 R09: ffff81011cc6c540

[  944.217774] R10: 0000000000000000 R11: ffffffff80266390 R12: ffff8100d2d693a8

[  944.225098] R13: ffff81011cc6c588 R14: ffff8100d2d693a8 R15: ffffffff80302726

[  944.232424] FS:  00007f9e739d96f0(0000) GS:ffff81011ff12700(0000)

knlGS:0000000000000000

[  944.240717] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b

[  944.246625] CR2: 0000000001b691d0 CR3: 0000000069861000 CR4: 00000000000006e0

[  944.253948] DR0: 0000000000000000 DR1: 0000000000000000 ...
[ message continues ]

On Thu, 15 Nov 2007 22:24:12 +0100
argh.  I'd incorrectly worked out that

nfsd-fix-wrong-mnt_writer-count-in-rename.patch was a fix against

r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename.patch however

it is in fact a fix against use-struct-path-in-struct-svc_export.patch.
My life sucks.

-

I think the placement was correct, but the patch itself was made

against a tree that already contained the changes from

use-struct-path-in-struct-svc_export.patch.

nfsd-fix-wrong-mnt_writer-count-in-rename.patch should have used the

old naming ex_mnt and only use-struct-path-in-struct-svc_export.patch

should have changed it to ex_path.mnt.
Torsten

-

Sorry to have bothered you. But these were the only ones that touched

any nfs code.

But this list was wrong anyway.
I just found out that I botched the bisect, now doing the wrong part again.

(compile error scrolled of the screen and I copied/tested the same kernel again)
Torsten

-

treogen mm-test # git bisect good

Bisecting: 1245 revisions left to test after this

[4d88b06571b9d45e9cb52d8ad5dbf196ba280ff3] git-scsi-misc
I'm working on it... ;)
Torsten

-

Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64.

echo mem >/sys/power/state

causes shut down of disk(s) and blinking cursor on 1,1 position.

The last working was 2.6.23-rc8-mm2. I haven't tested

2.6.23-mm1, since it didn't work for me.
As usual, I don't know how to debug this and what other info is needed, any

thoughts?
regards,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

Does the current mainline work?
Rafael

-

Yes.
The offending -mm patch is

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when

the patch is applied.
regards,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University
-

Thanks for tracking this down.  Alan, any thoughts?
thanks,
greg k-h

-

It's a driver problem somewhere.  Probably not one of the most common

drivers because I don't see the same problem here (but then I'm not

testing -mm).
The thing to do is figure out which driver is causing the problem.

Jiri, try enabling CONFIG_DEBUG_DRIVER.  If there's also a config

option to prevent the console from being suspended, set it as well.

Then you should be able to tell which driver is making trouble.
Alan Stern
-

I think no unusual hardware inside:
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35 Express DRAM Controller

(rev 02)

        Subsystem: Intel Corporation 82G33/G31/P35 Express DRAM Controller

        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-

Stepping- SERR- FastB2B-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-

<MAbort+ >SERR- <PERR-

        Latency: 0

        Capabilities: [e0] Vendor Specific Information

00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00

10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29

30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express

Integrated Graphics Controller (rev 02) (prog-if 00 [VGA])

        Subsystem: Intel Corporation 82G33/G31 Express Integrated Graphics

Controller

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-

Stepping- SERR- FastB2B-

        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-

<MAbort- >SERR- <PERR-

        Latency: 0

        Interrupt: pin A routed to IRQ 16

        Region 0: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]

        Region 1: I/O ports at ec00 [size=8]

        Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]

        Region 3: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]

        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0

Enable-

                Address: 00000000  Data: 0000

        Capabilities: [d0] Power Management version 2

                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA

PME(D0-,D1-,D2-,D3hot-,D3cold-)

                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00: 86 80 c2 29 07 00 90 00 02 00 00 03 00 00 00 00

10: 00 00 a8 ff 01 ec 00 00 08 00 00 d0 00 00 90 ff

20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29

30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 0...
[ message continues ]

Guess I'll have to try running 2.6.24-rc2-mm1 on my own system.  In the

meantime, you can try adding some printk statements to

drivers/base/power/main.c.  In particular, see whether

lock_all_devices() gets called from device_suspend(), whether it

returns, and how far dpm_suspend() manages to get.
Alan Stern
-

Eh, no, this (/proc/cmdline):

ro root=/dev/md1 reboo1 vga=1 2 no_console_suspend
regards,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

I'm not sure.
Please try to set CONFIG_PM_VERBOSE.

-

I finally got 2.6.24-rc2-mm1 working.  Andrew, how come those two

recent patches from Greg and Kay (the ones changing alloc_disk_node()

and system_bus_init()) aren't in your hot-fixes directory?
There's still a problem.  During bootup I get this:
	floppy0: Floppy io-port 0x03f2 in use
That's not supposed to happen; the floppy disk should be working

perfectly.  Is this a known problem?
Back to the main topic...  My system hibernates and resumes with no

apparent problem.  Jiri, it looks like you'll have to do some debug

tracing of the routines in drivers/base/power/main.c.
Alan Stern
-

Nice update scripts wiped kern.* from syslog config file out, hence no
Beside this two nothing strange:
dpm_suspend: b 00:06

WARNING: at /home/l/latest/bughunt/kernel/resource.c:185 __release_resource()
Call Trace:

 [<ffffffff8023f7b5>] release_resource+0xb5/0xf0

 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130

 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90

 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0

 [<ffffffff803b9f73>] suspend_device+0x113/0x180

 [<ffffffff803ba330>] device_suspend+0x200/0x320

 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170

 [<ffffffff80266bd9>] enter_state+0x209/0x270

 [<ffffffff80266cef>] state_store+0xaf/0xf0

 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20

 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140

 [<ffffffff80299cc7>] vfs_write+0xc7/0x170

 [<ffffffff8029a360>] sys_write+0x50/0x90

 [<ffffffff8020bcde>] system_call+0x7e/0x83
WARNING: at /home/l/latest/bughunt/kernel/resource.c:189 __release_resource()
Call Trace:

 [<ffffffff8023f7e0>] release_resource+0xe0/0xf0

 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130

 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90

 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0

 [<ffffffff803b9f73>] suspend_device+0x113/0x180

 [<ffffffff803ba330>] device_suspend+0x200/0x320

 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170

 [<ffffffff80266bd9>] enter_state+0x209/0x270

 [<ffffffff80266cef>] state_store+0xaf/0xf0

 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20

 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140

 [<ffffffff80299cc7>] vfs_write+0xc7/0x170

 [<ffffffff8029a360>] sys_write+0x50/0x90

 [<ffffffff8020bcde>] system_call+0x7e/0x83

...

dpm_suspend: b 0000:00:1f.5

ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND

ACPI Error (psparse-0537): Method parse/execution failed

[\_SB_.PCI0.SAT1.CHN0...
[ message continues ]

BTW output from that tree minus the patch:

_cpu_down: s

_cpu_down: t

CPU 1 is now offline

SMP alternatives: switching to UP code

_cpu_down: u

notifier_call_chain: c FFFFFFFF80232370 1

notifier_call_chain: c FFFFFFFF8026EF10 1

notifier_call_chain: c FFFFFFFF8024B8F0 1

notifier_call_chain: c FFFFFFFF802419E0 1

notifier_call_chain: c FFFFFFFF80255B50 1

notifier_call_chain: c FFFFFFFF80250C40 1

notifier_call_chain: c FFFFFFFF8028E8F0 1

notifier_call_chain: c FFFFFFFF802B59C0 1

notifier_call_chain: c FFFFFFFF80323460 1

notifier_call_chain: c FFFFFFFF80270990 0

notifier_call_chain: c FFFFFFFF8023D5D0 1

notifier_call_chain: c FFFFFFFF80266090 1

notifier_call_chain: c FFFFFFFF802320A0 1

notifier_call_chain: c FFFFFFFF80249DA0 1

notifier_call_chain: c FFFFFFFF80318440 1

notifier_call_chain: c FFFFFFFF8047BE80 1

notifier_call_chain: c FFFFFFFF80212F40 0

notifier_call_chain: c FFFFFFFF80216350 1

notifier_call_chain: c FFFFFFFF80217220 1

notifier_call_chain: c FFFFFFFF80218120 1

_cpu_down: v

_cpu_down: w

_cpu_down: x

_cpu_down: y

_cpu_down: z

disable_nonboot_cpus: 3 0
regards,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.
Can you try to see what happens (with the patch applied) if

-

After commenting out

//device_initcall(thermal_throttle_init_device);

it looks like this:

http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png
regards,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

Can you also make the new System-map available, please?

-

Sure:

http://www.fi.muni.cz/~xslaby/sklad/System.map1

-

The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

is apparently cpu_swap_callback() which is not called in

http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
Can you verify that cpu_swap_callback() gets called if the patch is not

applied?

-

Last... Note, that it's only first 20 invokations of notifiers, there are
Does this still apply?

-

You'll get more useful results if you redo your changes to

notifier_call_chain().  Have it print out the address of the routine

_before_ making the call, and don't limit it to 20.  That way you'll

know exactly which notifier routine ends up hanging.
Alan Stern
-

The problem is, that notifier_call_chain is called again and again zillion times

by somebody else...
Anyway you led me to another idea:

* _cpu_down

        printk("%s: u\n", __func__);

        BUBAK=1;

        /* CPU is completely dead: tell everyone.  Too late to complain. */

        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod,

                                    hcpu) == NOTIFY_BAD)

                BUG();

        BUBAK=0;

-----

* notifier_call_chain

        unsigned int a = val & 0x88000;

        unsigned int yes = a == 0x88000;
        nb = rcu_dereference(*nl);
        if (a && a != 0x88000)

                printk("Somebody calls with val: %lx\n", val);

        else

                val &= ~0x88000;
        while (nb && nr_to_call) {

                next_nb = rcu_dereference(nb->next);

                if (unlikely(BUBAK && yes))

                        printk("%s: %p\n", __func__, nb->notifier_call);

                ret = nb->notifier_call(nb, val, v);

-----

gives coretemp_cpu_callback -> coretemp_device_remove ->

platform_device_unregister, so coretemp seems to be what I have and you don't.
-

Aah, we probably should let coretemp people known.
Whole thread:

http://marc.info/?t=119507205800001&r=1&w=2
Just in case you are curious:

http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.diff

produces:

http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.png
-

Yes.
For the coretemp developers: coretemp_cpu_callback() needs to be more

careful about what it does.  During a system sleep transition (suspend,

hibernate, resume) it isn't possible to register or unregister a

device.  Attempts to register will fail and attempts to unregister will

block until the system sleep is over -- and for this callback that

means hanging.
It's not clear what the best way is to fix this.  Perhaps the CPU

notification should be sent along with a special flag indicating that

the CPU transition is part of a system sleep (although this seems

racy).  Perhaps the driver should notice when a system sleep begins,

and defer all CPU-change handling until after the sleep is over.
Alan Stern
-

Well I wrote the driver. Thanks for the clarification. If I recall correctly I

looked how this part should be done from others drivers. Now while checking

what happened to the file, seems Rafael added something related.
maybe it does exist?  CPU_DOWN_PREPARE ?
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;...
Unfortunately I'm not very familiar with this, calling the

coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode

driver, seems it just hide sysfs interface from user.
Thanks,

Rudolf

-

Well, in principle you can use the observation that the _FROZEN versions

are used during suspend/hibernation.  Thus, if you only unregister the device

for CPU_DEAD, but you won't do that for CPU_DEAD_FROZEN, it will work as long
In fact, it's already done that way and I don't think it's racy (see above).
Greetings,

Rafael

-

I'm not sure exactly what you want to do here.  But it seems like a

waste to unregister the coretemp devices at the start of a system sleep

and then register them back at the end.
Could you simply leave the devices registered throughout the entire

sleep?  Of course, at the end you would have to check that all the CPUs

really did come back up, and unregister the devices for the CPUs that

are still offline.
Alan Stern
-

Hi all:
AFAICT from that documentation, it would have been better to unregister

the device on CPU_DOWN_PREPARE anyway.  CPU_DEAD seems to be too late -
Is it possible to unregister a driver on CPU_DOWN_PREPARE_FROZEN?  If

so, then the simplest fix would be the patch below (Jiri: feel free to

try it). Otherwise it would take a bit of refactoring to bring the sysfs

interface down/up for suspend/resume.
commit ce9c7b78c839a6304696d90083eac08baad524ce

Author: Mark M. Hoffman <mhoffman@lightlink.com>

Date:   Tue Nov 20 07:51:50 2007 -0500
    hwmon: (coretemp) fix suspend/resume hang
    Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c

index 5c82ec7..afe2d31 100644

--- a/drivers/hwmon/coretemp.c

+++ b/drivers/hwmon/coretemp.c

@@ -338,10 +338,12 @@ static int coretemp_cpu_callback(struct notifier_block *nfb,

 	switch (action) {

 	case CPU_ONLINE:

 	case CPU_ONLINE_FROZEN:

+	case CPU_DOWN_FAILED:

+	case CPU_DOWN_FAILED_FROZEN:

 		coretemp_device_add(cpu);

 		break;

-	case CPU_DEAD:

-	case CPU_DEAD_FROZEN:

+	case CPU_DOWN_PREPARE:

+	case CPU_DOWN_PREPARE_FROZEN:

 		coretemp_device_remove(cpu);

 		break;

 	}

--

Mark M. Hoffman

mhoffman@lightlink.com
-

No.  In that case the suspend core is holding the device's mutex and your

attempt to unregister it will deadlock with it.
Do you _have_ _to_ unregister the device at all?  Why don't you just leave

it registered on CPU_DOWN_PREPARE_FROZEN?  The CPU is not going away

physically in this case and it's _guaranteed_ that _cpu_up() will be called on
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

Sorry for the delay, this (trimmed version) solves the problem!
thanks,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

This leaves the device registered if for some reason the number of CPUs

after resuming from hibernation is smaller than the number of CPUs

before hibernation.  Of course, in theory that's never supposed to

happen...
Alan Stern
-

Yes, that clearly would be a bug.
Rafael

-

You can use a global variable to switch the logging only before the CPU

hotunplug done by the suspend code.  You just need to hack

disable_nonboot_cpus() for that.

-

If I understand you correctly, that's what BUBAK variable is there for. But it

is still called again and again while the suspend code runs...
regards,

--

Jiri Slaby (jirislaby@gmail.com)

Faculty of Informatics, Masaryk University

-

Ah, yes.
You can count the number of calls and then make it print the information for

the last, say, 20 of them.
Greetings,

Rafael

-

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

would be ideal, please.  It's pretty quick.  I did it about six times

yesterday evening :(

-

Uff clone-prepare-to-recycle-clone_detached-and-clone_stopped.patch *really* spams.

Looks like some programs are using this 'deprecated flag'. 
Could this have some CONFIG_SPAM_ME_PLEASE ?;)
This is what I got in some minutes :
--dmesg|grep 'used deprecated clone flags'|sed 's/.*] //'|sort -u

fork(): process `artsd' used deprecated clone flags 0x400000

fork(): process `firefox-bin' used deprecated clone flags 0x400000

fork(): process `gcompris' used deprecated clone flags 0x400000

fork(): process `qgit' used deprecated clone flags 0x400000

fork(): process `thunderbird-bin' used deprecated clone flags 0x400000

fork(): process `wish' used deprecated clone flags 0x400000

fork(): process `xchat' used deprecated clone flags 0x400000

fork(): process `kdbus' used deprecated clone flags 0x400000
--dmesg|grep 'used deprecated clone flags'|wc -l

151
Gabriel
-

hm, that was supposed to shut itself off after 100 messages:
	if (unlikely(clone_flags & (CLONE_DETACHED|CLONE_STOPPED))) {

		static int __read_mostly count = 100;
		if (count && printk_ratelimit()) {

			char comm[TASK_COMM_LEN];
			count--;

			printk(KERN_INFO "fork(): process `%s' used deprecated "

					"clone flags 0x%lx\n",

				get_task_comm(comm, current),

				clone_flags & (CLONE_DETACHED|CLONE_STOPPED));

		}

	}
I don't see how you got 151 instances.  I guess I'm having another stupid

day.
Oh well.  That's CLONE_DETACHED and I think Ulrich's question just got

answered.
Which distro/version are you running?
Thanks for letting us know....

-

Andrew Morton wrote:
It looks like a simple race, two threads do count-- before doing

if(count), resulting in an almost infinite loop.  Probably.
atomic_test_and_dec might work.
-

I'm using Frugalware Linux 'current' right now with the following software :
 -- sh scripts/ver_linux

 If some fields are empty or look unusual you may have an old version.

 Compare to the current minimal requirements in Documentation/Changes.
 Linux lara 2.6.24-rc2-mm1 #4 SMP Wed Nov 14 05:47:48 CET 2007 i686 Intel(R) Xeon(TM) CPU 2.00GHz GenuineIntel GNU/Linux
 Gnu C                  4.2.2

 Gnu make               3.81

 binutils               2.18.50.0.2.20071001

 util-linux             2.13

 mount                  2.13

 module-init-tools      3.2.2

 e2fsprogs              1.40.2

 xfsprogs               2.9.4

 pcmciautils            014

 Linux C Library        2.7

 Dynamic linker (ldd)   2.7

 Linux C++ Library      so.6.0

 Procps                 3.2.7

 Net-tools              1.60

 Kbd                    1.12

 Sh-utils               6.9

 udev                   116
-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
People should really compile their glibc better than this.  The sources

still use it but only if you compile for compatibility with kernels

before 2.6.2.  Nobody should need to need such backward compatibility.
- --

➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (GNU/Linux)

Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHOoMs2ijCOnn/RHQRAn+rAJ91vQoJRpuyPJipNLFn+3g6bajDtwCgs9fm

moefStvq8QdvOxVLLDPUC1o=

=GsVU

-----END PGP SIGNATURE-----

-

I got it to boot but .. 
...
[   43.942963] usb-storage: device scan complete

[   43.943801] scsi 3:0:0:0: Direct-Access     Maxtor 6 Y080L0           0811 PQ: 0 ANSI: 0

[   43.946643] sd 3:0:0:0: [sdd] 160086528 512-byte hardware sectors (81964 MB)

[   43.947885] sd 3:0:0:0: [sdd] Test WP failed, assume Write Enabled

[   43.947892] sd 3:0:0:0: [sdd] Assuming drive cache: write through

[   43.949146] sd 3:0:0:0: [sdd] 160086528 512-byte hardware sectors (81964 MB)

[   43.950386] sd 3:0:0:0: [sdd] Test WP failed, assume Write Enabled

[   43.950394] sd 3:0:0:0: [sdd] Assuming drive cache: write through

[   43.950528]  sdd:<6>sd 3:0:0:0: [sdd] Result: hostbyte=0x07 driverbyte=0x10

[   43.972849] end_request: I/O error, dev sdd, sector 0

[   43.972896] Buffer I/O error on device sdd, logical block 0

[   43.976837] sd 3:0:0:0: [sdd] Result: hostbyte=0x07 driverbyte=0x10

[   43.976844] end_request: I/O error, dev sdd, sector 0

[   43.976849] Buffer I/O error on device sdd, logical block 0

[   43.976985]  unable to read partition table

[   43.977273] sd 3:0:0:0: [sdd] Attached SCSI disk

[   43.977601] sd 3:0:0:0: Attached scsi generic sg4 type 0

[   44.667163] sd 3:0:0:0: [sdd] Result: hostbyte=0x07 driverbyte=0x10

[   44.667178] end_request: I/O error, dev sdd, sector 0

[   44.667189] Buffer I/O error on device sdd, logical block 0

[   44.667372] Buffer I/O error on device sdd, logical block 1

[   44.667534] Buffer I/O error on device sdd, logical block 2

[   44.667709] Buffer I/O error on device sdd, logical block 3

[   44.672165] sd 3:0:0:0: [sdd] Result: hostbyte=0x07 driverbyte=0x10

[   44.672180] end_request: I/O error, dev sdd, sector 0

[   44.672192] Buffer I/O error on device sdd, logical block 0
...
USB broken here and these I/O errors just spams a lot more later on 
dmesg |grep 'I/O error'|wc -l

61
...

[   45.030261] input: Power Button (CM) as /devices/virtual/input/input4

[   45.031331] BUG: sleeping function called from invalid context at kernel/rwsem...
[ message continues ]

All this BUG / WARNINGS are caused by *-qos* patches. Reverting this 3 patches makes the BUGs go away :
latencyc-use-qos-infrastructure.patch

pm-qos-infrastructure-and-interface.patch

pm-qos-infrastructure-and-interface-static-initialization-with-blocking-notifiers.patch
Gabriel
-

This looks like the same issue Rafael saw.
Try the patch in the following post:
http://marc.info/?l=linux-kernel&m=119265627228498&w=2
--mgross
-

Well that's not very good.  _I_ can go fishing in my lkml archives for random

patches but not everyone is set up to do that.  And the diff to which you

refer gets 100% rejects against rc2-mm1 anyway.
Please prepare a tested, changelogged patch against rc2-mm1 asap.

-

I'm having difficulty coming up with a .config that boots, I'll continue

working on this but the following is what I'm pretty confident will fix

the warnings.  
You should hold off until I get a system booting 2.6.24-rc2-mm1 before

taking this.
pm-qos-remove-locks-around-blocking-notifier-registration.patch
Changelog:

Remove spin locking around blocking notifier calls that can sleep.
--mgross
Signed-off-by: mark gross <mgross@linux.intel.com>
Index: linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c

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

--- linux-2.6.24-rc2-mm1.orig/kernel/pm_qos_params.c	2007-11-15 11:09:27.000000000 -0800

+++ linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c	2007-11-15 11:10:08.000000000 -0800

@@ -319,13 +319,10 @@

  */

  int pm_qos_add_notifier(int pm_qos_class, struct notifier_block *notifier)

 {

-	unsigned long flags;

 	int retval;
-	spin_lock_irqsave(&pm_qos_lock, flags);

 	retval = blocking_notifier_chain_register(

 			pm_qos_array[pm_qos_class]->notifiers, notifier);

-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 	return retval;

 }

@@ -341,13 +338,10 @@

  */

 int pm_qos_remove_notifier(int pm_qos_class, struct notifier_block *notifier)

 {

-	unsigned long flags;

 	int retval;
-	spin_lock_irqsave(&pm_qos_lock, flags);

 	retval = blocking_notifier_chain_unregister(

 			pm_qos_array[pm_qos_class]->notifiers, notifier);

-	spin_unlock_irqrestore(&pm_qos_lock, flags);
 	return retval;

 }

-

-

pm-qos-remove-locks-around-blocking-notifier.patch
I have done some testing with this fix, I think it addresses all the

sleep within a held lock warnings reported.
please apply.
Changelog:

Remove spin locking around all blocking notifier calls that can sleep.

I had to re-structure some of the code to avoid locking issues.
--mgross
Signed-off-by: mark gross <mgross@linux.intel.com>
Index: linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c

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

--- linux-2.6.24-rc2-mm1.orig/kernel/pm_qos_params.c	2007-11-15 11:09:27.000000000 -0800

+++ linux-2.6.24-rc2-mm1/kernel/pm_qos_params.c	2007-11-15 14:10:09.000000000 -0800

@@ -135,13 +135,14 @@

 }
-

-/* assumes pm_qos_lock is held */

 static void update_target(int target)

 {

 	s32 extreme_value;

 	struct requirement_list *node;

+	unsigned long flags;

+	int call_notifier = 0;
+	spin_lock_irqsave(&pm_qos_lock, flags);

 	extreme_value = pm_qos_array[target]->default_value;

 	list_for_each_entry(node,

 			&pm_qos_array[target]->requirements.list, list) {

@@ -149,13 +150,16 @@

 				extreme_value, node->value);

 	}

 	if (pm_qos_array[target]->target_value != extreme_value) {

+		call_notifier = 1;

 		pm_qos_array[target]->target_value = extreme_value;

 		pr_debug(KERN_ERR "new target for qos %d is %d\n", target,

 			pm_qos_array[target]->target_value);

-		blocking_notifier_call_chain(pm_qos_array[target]->notifiers,

-			(unsigned long) pm_qos_array[target]->target_value,

-						NULL);

 	}

+	spin_unlock_irqrestore(&pm_qos_lock, flags);

+

+	if (call_notifier)

+		blocking_notifier_call_chain(pm_qos_array[target]->notifiers,

+			(unsigned long) extreme_value, NULL);

 }
 static int register_pm_qos_misc(struct pm_qos_object *qos)

@@ -227,8 +231,8 @@

 		spin_lock_irqsave(&pm_qos_lock, flags);

 		list_add(&dep->list,

 			&pm_qos_array[pm_qos_class]->requirements.list);

-		update_target(pm_qos_cl...
[ message continues ]

I'm able to boot and have done a bit of testing and this patch wasn't

good enough.  I'm sending a new one in a min.
-

my bad.  I didn't catch the 24-rc2-mm1 baseline for this issue.  I'll

look at this right way.
--mgross

-

I'm sorry for not being clear, this patch is already in your tree from a

few weeks ago.  I was pointing Gabriel at the fix from back then.
--mgross

-

But this bug report is against 2.6.24-rc2-mm1, released two days ago?

-

Matt, are these the errors you were worried about with the patch we were

just talking about tha tis in my tree?
Rest of error log left below so you can see...
thanks,
> CONFIG_JFS_POSIX_ACL

I can't tell from these logs.
The key question (in relation to the allow_restart patch) is this:  Was

everything working fine until a START_STOP was sent to the device?
The SCSI layers used to send devices START_STOP to almost every device as

part of initialization.  I think we switched all of that to use

TEST_UNIT_READY instead.
The patch you've got should re-enable START_STOP to be sent.  The SCSI

layers (I'm told, but haven't verified myself) only send START_STOP if the

device reports that it needs a startup command.
CONFIG_USB_STORAGE_DEBUG will generate a *lot* of debug output.  But, it

should be pretty easy to see if START_STOP was sent at all, and if it

caused the problems.
Matt
P.S. Worst case, the issue we're talking about here would only cause the

device firmware to crash, which would eventually lead to a disconnect.

That shouldn't have caused the much more severe problems shown in the log

you sent.
--=20

Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=

net=20

Maintainer, Linux USB Mass Storage Driver
DP: And judging from the scores, Stef has the sma... =20

T:  LET'S NOT GO THERE!

					-- Dust Puppy and Tanya

User Friendly, 12/11/1997

There is the dmesg with CONFIG_USB_STORAGE_DEBUG :
Gabriel

-

That code got replaced recently but I have no idea about it.
( http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=shortlog  see the patches from Boaz Harrosh) 
srb->resid got replaced by scsi_get_resid() it I see that right.
Gabriel

-

The replacement looks, to my eye, to be logically correct.  The patch was

pretty clean.
Then again, I haven't looked at what is "under the hood" of the accessor

functions.  Perhaps there is a side-effect somewhere in there?
Perhaps a quick debugging test -- print the value of scsi_get_resid(srb)

just after it's initialized to zero at the top of

usb_stor_invoke_transport(), and then just after the call to

us->transport().
The first print should show a value of zero.  The debug log says that the

transport should have left it as zero.  If it's actually coming back from

us->transport() as a non-zero value, then we'll need to check all the

modifications to usb_stor_Bulk_transport to see where srb->resid is being

changed.
Matt
--=20

Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=

net=20

Maintainer, Linux USB Mass Storage Driver
A:  The most ironic oxymoron wins ...

DP: "Microsoft Works"

A:  Uh, okay, you win.

					-- A.J. & Dust Puppy

User Friendly, 1/18/1998

I have found the bug. My bad sorry about that. Patch below

It is because I switched from use of usb_stor_bulk_transfer_sg()

to usb_stor_bulk_transfer_sglist, but forgot the residual handling.
(Please send scsi bugs to scsi list. My lkml mental filters are

much higher, Sorry for not seeing this yesterday)
----

From: Boaz Harrosh <bharrosh@panasas.com>

Date: Thu, 15 Nov 2007 20:07:56 +0200
  wrong resid handling fixed
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>

---

 drivers/usb/storage/transport.c |    7 ++++---

 1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c

index d3a84a2..d9f4912 100644

--- a/drivers/usb/storage/transport.c

+++ b/drivers/usb/storage/transport.c

@@ -465,11 +465,12 @@ static int usb_stor_bulk_transfer_sglist(struct us_data *us, unsigned int pipe,

 int usb_stor_bulk_srb(struct us_data* us, unsigned int pipe,

 		      struct scsi_cmnd* srb)

 {

-	int resid = scsi_get_resid(srb);

+	unsigned int partial;

 	int result = usb_stor_bulk_transfer_sglist(us, pipe, scsi_sglist(srb),

 				      scsi_sg_count(srb), scsi_bufflen(srb),

-				      &resid);

-	scsi_set_resid(srb, resid);

+				      &partial);

+

+	scsi_set_resid(srb, scsi_bufflen(srb) - partial);

 	return result;

 }
--

1.5.3.1
-

-

Hello,
	Another parenthesis fix.
Regards,
	Mariusz
Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
 include/asm-parisc/pgalloc.h |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc2-mm1-a/include/asm-parisc/pgalloc.h	2007-11-15 11:36:44.000000000 +0100

+++ linux-2.6.24-rc2-mm1-b/include/asm-parisc/pgalloc.h	2007-11-15 11:37:17.000000000 +0100

@@ -141,7 +141,7 @@ static inline void pte_free_kernel(struc

 static inline void pte_free_kernel(struct mm_struct *mm, struct page *pte)

 {

 	pgtable_page_dtor(pte);

-	pte_free_kernel(page_address((pte));

+	pte_free_kernel(page_address(pte));

 }
 #define check_pgt_cache()	do { } while (0)

-

Hello,
	Fails to build here:
  LD      .tmp_vmlinux1

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

/home/sp3fxc/linux/linux-2.6.24-rc2-mm1/drivers/acpi/processor_idle.c:305: undefined reference to `local_apic_timer_c2_ok'

make: *** [.tmp_vmlinux1] Error 1
Regards,
	Mariusz

hmm, looks like you're missing CONFIG_X86_LOCAL_APIC

so does this go away when you add CONFIG_SMP

or CONFIG_X86_UP_APIC?

-

Yes it does. In both cases.
Regards,
	Mariusz

-

Here's a patch, from Kay, to fix this issue.
If anyone still has problems after applying this patch, with shutdown

things, please let me know.
I'll roll it into my larger patchset so that Andrew can get it

automatically for the next release.
thanks,
greg k-h

----------------
From: Kay Sievers

Subject: fix oops in device_shutdown()
---

 drivers/base/sys.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/base/sys.c

+++ b/drivers/base/sys.c

@@ -451,7 +451,7 @@ int sysdev_resume(void)

 int __init system_bus_init(void)

 {

 	system_kset = kset_create_and_register("system", NULL,

-					       NULL, devices_kset);

+					       &devices_kset->kobj, NULL);

 	if (!system_kset)

 		return -ENOMEM;

 	return 0;

-

On Thu, 15 Nov 2007 11:25:37 -0800
hm, thanks.
Did we hunt down that warning I found?
umm.. this:
[   11.863390] ACPI: AC Adapter [ACAD] (on-line)

[   11.868004] ACPI: Battery Slot [BAT1] (battery present)

[   11.922945] Real Time Clock Driver v1.12ac

[   11.923078] intel_rng: FWH not detected

[   11.923160] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

[   14.934078] floppy0: no floppy controllers found

[   14.934616] WARNING: at lib/kref.c:33 kref_get()

[   14.934690]  [<c0242810>] kref_get+0x40/0x50

[   14.934766]  [<c024185f>] kobject_get+0xf/0x20

[   14.934839]  [<c0241e7f>] kobject_add+0x14f/0x1a0

[   14.934917]  [<c0241c8e>] kobject_set_name+0x7e/0xc0

[   14.934998]  [<c01b82af>] register_disk+0x3f/0x200

[   14.935078]  [<c02392ff>] blk_register_region+0x2f/0x40

[   14.935164]  [<c0239349>] add_disk+0x39/0x50

[   14.935234]  [<c0238b80>] exact_match+0x0/0x10

[   14.935306]  [<c0239120>] exact_lock+0x0/0x10

[   14.935378]  [<c051b73b>] loop_init+0x13b/0x190

[   14.935453]  [<c0500570>] kernel_init+0x130/0x300

[   14.935532]  [<c010428e>] ret_from_fork+0x6/0x1c

[   14.938302]  [<c0500440>] kernel_init+0x0/0x300

[   14.941033]  [<c0500440>] kernel_init+0x0/0x300

[   14.943732]  [<c0104f8f>] kernel_thread_helper+0x7/0x18

[   14.946436]  =======================

[   14.949535] loop: module loaded

[   14.952336] e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI

[   14.955022] e100: Copyright(c) 1999-2006 Intel Corporation

[   14.957813] ACPI: PCI Interrupt 0000:06:08.0[A] -> GSI 20 (level, low) -> IRQ
Caused by gregkh-driver-remove-struct-kobj_type-from-struct-kset.patch

-

Yes, that should be fixed with the gendisk patch I just sent out.  It

was an error I caused with the above mentioned patch :(
Really strange that I could never duplicate it here...
thanks,
greg k-h

-

Fixes for memory hotplug compile and .section handling.
This patch fixes following bugs

==

WARNING: vmlinux.o(.text+0x1d07c): Section mismatch: reference to .init.text:f

ind_e820_area (between 'init_memory_mapping' and 'arch_add_memory')

WARNING: vmlinux.o(.text+0x946b5): Section mismatch: reference to .init.text:

__alloc_bootmem_node (between 'vmemmap_alloc_block' and 'vmemmap_pgd_populate')
ERROR: "memory_add_physaddr_to_nid" [drivers/acpi/acpi_memhotplug.ko] undefined!

make[1]: *** [__modpost

==
This patch does

 1. export memory_add_physaddr_to_nid().

 2. changes __init to __init_refok find_early_table_space() (x86/mm/init_64.c)

 3. changes __init_refok to __meminit in mm/sparse.c (This is bug.)

 4. add wrapper function to call bootmem allocator without warning.
 After seeing "3", I thought simple __init_refok is dangerous and decided to

 add wrapper function to call bootmem, is this style acceptable ?
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
 arch/x86/mm/init_64.c |    2 +-

 arch/x86/mm/srat_64.c |    1 +

 mm/sparse-vmemmap.c   |   13 ++++++++++++-

 mm/sparse.c           |   12 ++++++++++--

 4 files changed, 24 insertions(+), 4 deletions(-)
Index: linux-2.6.24-rc2-mm1/arch/x86/mm/srat_64.c

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

--- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/srat_64.c

+++ linux-2.6.24-rc2-mm1/arch/x86/mm/srat_64.c

@@ -562,3 +562,4 @@ int memory_add_physaddr_to_nid(u64 start

 	return ret;

 }
+EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);

Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c

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

--- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c

+++ linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c

@@ -319,7 +319,7 @@ static void __meminit phys_pud_init(pud_

 	__flush_tlb();

 } 
-static void __init find_early_table_space(unsigned long end)

+static void __init_refok find_early_table_space(unsigned long end)

 {

 	unsigned lon...
[ message continues ]

Can you explain "this is bug" for me.  The routine was __init_refok and

therefore ! __init and therefore always present.  The logic there must

guarentee it only calls the bootmem allocator in early boot, and the logic

has not changed with the annotation change so it should have been safe.

If by "this is bug" you are saying this is the cause of the warning then
The point of that wrapper being you only allow calls to that one function

to be __init_refok, and all other function calls in the calling function

will be checked as that function remains __init/__meminit or not as

appropriate.  That seems like a good idea.
Also any code which is __init_refok is implicitly in its own section.

I assume that means it cannot be __init, ie any function so declared will

never be freed even if otherwise it might be __init.  In this case the

calling function would naturally be __meminit, ie __init if hotplug is

not enabled.  Moving the one call to a separate function makes the code
This indirect makes sense for the sparse safety aspect, only letting the

caller use this one routine.  I wonder if the name should be more

explicit.  earlyonly_bootmem_alloc() or something, so that a later

reader knows from the call site that this is magical and care needs to

be exercised here.
As this is local to this file, this should also be static I presume.  Or

indeed perhaps if we picked a namespace such as the proposed earlyonly_

for functions with this annotation we could have just one copy, and
Reviewed-by: Andy Whitcroft <apw@shadowen.org>
-apw

-

On Thu, 15 Nov 2007 09:39:15 +0000

Sorry I misunderstood that  __init.refok is a section which is freed after boot.

ok.
Thank you for review.
-Kame
-

Hi KAMEZAWA,
Thanks for the patch, it resolves memory_add_physaddr_to_nid() build

error for me.
 Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

 Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
 arch/x86/mm/init_64.c |    2 +-

 arch/x86/mm/srat_64.c |    1 +

 mm/sparse-vmemmap.c   |   13 ++++++++++++-

 mm/sparse.c           |   12 ++++++++++--

 4 files changed, 24 insertions(+), 4 deletions(-)
===================================================================

--- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/srat_64.c

+++ linux-2.6.24-rc2-mm1/arch/x86/mm/srat_64.c

@@ -562,3 +562,4 @@ int memory_add_physaddr_to_nid(u64 start

 	return ret;

 }
+EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);

Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c

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

--- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c

+++ linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c

@@ -319,7 +319,7 @@ static void __meminit phys_pud_init(pud_

 	__flush_tlb();

 } 
-static void __init find_early_table_space(unsigned long end)

+static void __init_refok find_early_table_space(unsigned long end)

 {

 	unsigned long puds, pmds, tables, start;
Index: linux-2.6.24-rc2-mm1/mm/sparse.c

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

--- linux-2.6.24-rc2-mm1.orig/mm/sparse.c

+++ linux-2.6.24-rc2-mm1/mm/sparse.c

@@ -55,7 +55,15 @@ static inline void set_section_nid(unsig

 #endif
 #ifdef CONFIG_SPARSEMEM_EXTREME

-static struct mem_section noinline __init_refok *sparse_index_alloc(int nid)

+/*

+ * for avoiding section mismatch.

+ */

+static void __init_refok *__call_bootmem_alloc(int nid, int array_size)

+{

+	return alloc_bootmem_node(NODE_DATA(nid), array_size);

+}

+

+static struct mem_section noinline __meminit *sparse_index_alloc(int nid)

 {

 	struct mem_section *section = NULL;

 	unsigned long array_size = SECTIONS_PER_ROOT *

@@ -64,7 +72,7 @@ static struct mem_section noinline __ini

...
[ message continues ]

eek.
What I now need to do with this patch is
- Work out which patches in -mm it is actually fixing.
- If that is more than one patch then split this patch up into multiple ones.
- Stage the one or more fixup patches immediately after the patches which

  they are fixing (with appropriate names: foo-fix.patch fixes foo.patch)
And that's OK - it's what I do.  But if you already have some idea which

patch you're actually fixing then it really helps me if you can tell me

which one it was, please - there's no point in having me duplicate your

work.
Plus it does look like this is three patches in one (at least)...
Thanks.

-

On Thu, 15 Nov 2007 00:56:57 -0800

Sorry, I'll divide them and repost with suitable explanation, soon.
Thanks,

-Kame
-

memory hotplug fix against 2.6.23-rc2-mm1.
Changelog

 - Divided into 3 patches

 - dropped patch against mm/sparse.c ( This was my misunderstanding.)

 - merged Andy's suggestion.
All patches are related to memory hotplug.
[1/3] ... export memory_add_physaddr_to_nid to acpi memory hotplug

[2/3] ... fix section mismatch in mm/sparse_vmemmap.c

[3/3] ... fix section mismatch in arch/x86/mm/init_64.c
Thank you for all helps.
Thanks,

-Kame
-

Changes __meminit to __init_refok.

==

WARNING: vmlinux.o(.text+0x1d07c): Section mismatch: reference to

.init.text:find_e820_area (between 'init_memory_mapping' and 'arch_add_memory')

==
Changelog:

 * changes __init_refok from find_early_table_space() to

   init_memory_mapping().
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
 arch/x86/mm/init_64.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c

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

--- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c

+++ linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c

@@ -347,7 +347,7 @@ static void __init find_early_table_spac

 /* Setup the direct mapping of the physical memory at PAGE_OFFSET.

    This runs before bootmem is initialized and gets pages directly from the

    physical memory. To access them they are temporarily mapped. */

-void __meminit init_memory_mapping(unsigned long start, unsigned long end)

+void __init_refok init_memory_mapping(unsigned long start, unsigned long end)

 {

 	unsigned long next; 
-

On Thu, 15 Nov 2007 19:36:39 +0900
again, I _think_ this fixes a bug in mainline.  Can you check that please?

-

On Thu, 15 Nov 2007 16:59:35 -0800

Yes, this section mismatch happens on 2.6.24-rc2.
Thanks,

-Kame
-

Fixes section mismatch below.
WARNING: vmlinux.o(.text+0x946b5): Section mismatch: reference to .init.text:'

__alloc_bootmem_node (between 'vmemmap_alloc_block' and 'vmemmap_pgd_populate')
Changelog

 - changed bootmem alloc wrapper function's name to be

	__earlyonly_bootmem_alloc().
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
 mm/sparse-vmemmap.c |   12 +++++++++++-

 1 file changed, 11 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc2-mm1/mm/sparse-vmemmap.c

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

--- linux-2.6.24-rc2-mm1.orig/mm/sparse-vmemmap.c

+++ linux-2.6.24-rc2-mm1/mm/sparse-vmemmap.c

@@ -34,6 +34,16 @@

  * or to back the page tables that are used to create the mapping.

  * Uses the main allocators if they are available, else bootmem.

  */

+

+static void * __init_refok __earlyonly_bootmem_alloc(int node,

+				unsigned long size,

+				unsigned long align,

+				unsigned long goal)

+{

+	return __alloc_bootmem_node(NODE_DATA(node), size, align, goal);

+}

+

+

 void * __meminit vmemmap_alloc_block(unsigned long size, int node)

 {

 	/* If the main allocator is up use that, fallback to bootmem. */

@@ -44,7 +54,7 @@ void * __meminit vmemmap_alloc_block(uns

 			return page_address(page);

 		return NULL;

 	} else

-		return __alloc_bootmem_node(NODE_DATA(node), size, size,

+		return __earlyonly_bootmem_alloc(node, size, size,

 				__pa(MAX_DMA_ADDRESS));

 }
-

On Thu, 15 Nov 2007 19:35:44 +0900
AFACIT this is applicable to mainline?
-

On Thu, 15 Nov 2007 16:53:30 -0800

yes. I think so.
Thanks,

-Kame
-

Fix following reference error (when CONFIG_ACPI_HOTPLUG_MEMORY=m)
==

 ERROR: "memory_add_physaddr_to_nid" [drivers/acpi/acpi_memhotplug.ko]

 undefined!

==
Changelog:

 - EXPORT_SYMBOL to EXPORT_SYMBOL_GPL.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
 arch/x86/mm/srat_64.c |    1 +

 1 file changed, 1 insertion(+)
Index: linux-2.6.24-rc2-mm1/arch/x86/mm/srat_64.c

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

--- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/srat_64.c

+++ linux-2.6.24-rc2-mm1/arch/x86/mm/srat_64.c

@@ -562,3 +562,4 @@ int memory_add_physaddr_to_nid(u64 start

 	return ret;

 }
+EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
-

All of our machines with QLogics ISP1020 cards seem to have lost them on

boot with 2.6.24-rc1-mm1+hotfixes.
# lspci

0000:00:0a.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide

SCSI (rev 05)
# lspci -n

0000:00:0a.0 0100: 1077:1020 (rev 05)
# lspci -v -v

0000:00:0a.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 05)

        Subsystem: QLogic Corp.: Unknown device 0000

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-

        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

        Latency: 248, Cache Line Size: 0x08 (32 bytes)

        Interrupt: pin A routed to IRQ 23

        Region 0: I/O ports at fc00 [size=256]

        Region 1: Memory at fa000000 (32-bit, non-prefetchable) [size=4K]
These devices are normally reported as below, which I note is not as a

1020?
qla1280: QLA1040 found on PCI bus 0, dev 10

scsi(0:0): Resetting SCSI BUS

scsi0 : QLogic QLA1040 PCI to SCSI Host Adapter

	Firmware version:  7.65.06, Driver version 3.26
There is nothing major around in the area so I am somewhat bemused.
-apw

-

When testing some of the later 2.6.24-rc2-mm1+hotfix combinations on three

of our test systems one job from each batch (1/4) failed.  In each case the

machine appears to have booted normally all the way to a login: prompt.

However in the failed boots the networking though apparently initialised

completely and correctly (as far as I can tell from the console output), is

reported as not responding to ssh connections.  The network interface seems

to have been initialised on the right port, and the ssh daemons started.
Two of the machines are powerpc boxes, the other an older x86_64.

One machine is 4/4 in testing, just one.  Most of the other machines are

still not able to compile this stack so do not contribute to our knowledge.
Any ideas?
-apw

-

I see this as well - the computer boots fine but no network.  The only clues

in the dmesg are:
[  294.097876] warning: process `dhclient' gets w/ old libcap

[  294.097893] warning: process `dhclient' sets w/ old libcap
So I'll try backing up the patch series to before:
add-64-bit-capability-support-to-the-kernel.patch
or so, and see if that's the problem.  If anyone has any other ideas, let me

know.
--

Kevin Winchester

-

unsubscribe linux-kernel

-

On Thu, 15 Nov 2007 20:28:29 -0400
Yes, that's a good one to suspect.
-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Hi,
This warning is just saying that you might want to reconsider

recompiling your dhclient with a newer libcap - which has native support

for 64-bit capabilities. This is supposed to be informative, and not be

associated with any particular error.
- From your comments, you believe that this patch causes something in your

boot process to fail. Can you supply some detail about the version of

dhclient you are using? I'd like to understand exactly what it is doing

(via libcap).
Thanks
Andrew
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHPnlIQheEq9QabfIRAlglAKCG2NG1xnwMT8G/Lk8GoEPwtBzq9QCdFLYi

k+pt5Sd2AdtOJ+TjMIt1y6g=

=5wpX

-----END PGP SIGNATURE-----

-

The machine which show this problem for me are using static network

configurations, so I don't know if libcap is still in the mix there.
I've just compared the boot logs from a successful and unsuccessful boot

on this kernel, and I don't see that particular message, nor do I see

any significant differences overall.
Perlexed.
-apw

-

The boot succeeds (and appears to bring initialize the network adapter

properly - it autonegotiates a 100Mbps link speed), but the dhcp client is

never able to get an address.  However, applying the rc2-mm1 patch series up

to just before:
  add-64-bit-capability-support-to-the-kernel.patch
results in a working kernel.  Applying just this patch causes the failure.  To

be sure, I also tried applying the above patch plus the following ones:
  add-64-bit-capability-support-to-the-kernel-checkpatch-fixes.patch

  add-64-bit-capability-support-to-the-kernel-fix.patch

  add-64-bit-capability-support-to-the-kernel-fix-fix.patch

  remove-unnecessary-include-from-include-linux-capabilityh.patch
but the problem still occurs even with all of these.
As to versions, I'm running Kubuntu gutsy, so I have the default:
dhcp3-client           3.0.5-3ubuntu4

libcap1                1:1.10-14build1
packages installed.
Let me know if you need any other information, or if you have a patch you

would like tested.
--

Kevin Winchester

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Kevin,
Can you try this quick hack?
diff --git a/kernel/capability.c b/kernel/capability.c

index e57d1aa..4088610 100644

- --- a/kernel/capability.c

+++ b/kernel/capability.c

@@ -109,7 +109,7 @@ out:

                        kdata[i].permitted = pP.cap[i];

                        kdata[i].inheritable = pI.cap[i];

                }

- -               while (i < _LINUX_CAPABILITY_U32S) {

+               while (0 && (i < _LINUX_CAPABILITY_U32S)) {

                        if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {

                                /* Cannot represent w/ legacy structure */

                                return -ERANGE;
Thanks
Andrew
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHP37LQheEq9QabfIRAst5AJ9Nsw0RtF2NDuUAMvQZh5OFWEB4ugCeIxMH

lp5/Ka7SJZLIrQpZDijrd1E=

=GN18

-----END PGP SIGNATURE-----

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Oh, and the reason your patch turned up incorrect in my mailer and on

lkml seems to be the PGP signature.  I didn't have your public key, so

my mail client just left the full PGP-signed text in, which includes

escaping of '-' characters.  LKML must also ignore the signature.  Once

I added your public key, the patch shows up correctly in my client at least.
(I guess everyone else probably knew this already...but at least I

learned something new today)
- --

Kevin Winchester

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP5QdKPGFQbiQ3tQRAqimAJwOSGDSM2wXeLbm+sBKehGf/haNpACfX7Cb

IALnPxwlgShR6Xb+XQclBro=

=xFUp

-----END PGP SIGNATURE-----

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Well, something went wrong with the patch - it has extra negative signs

in my mail reader, and on lkml, but now that I've hit reply and it's

been quoted, it looks fine in my mail client.  So I have no idea what

went on.
However, I got around the problem by making the code change manually -

and my network connection is now working.  Looking at the code being

bypassed:
    if (pE.cap[i] || pP.cap[i] || pP.cap[i])
looks somewhat weird as it is testing the same condition twice.  Should

it have been:
    if (pE.cap[i] || pP.cap[i] || pI.cap[i])
?
I'm about to test that change instead of bypassing the loop, so I'll let

you know the results.
- --

Kevin Winchester
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP4xGKPGFQbiQ3tQRAooWAJ9c6exhOiD4VUZ04hS9z77/RmERUACfauTE

BV/JAexzlm2zSmG4laYi+HQ=

=IPkA

-----END PGP SIGNATURE-----

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
Yes, that was also a bug. However, upon reflection (and as per my "0 &&"

hack), I now believe these few lines of code are problematic in general.
Thanks for reporting this bug. I'll post a more clear patch (that isn't

GPG'd).
Cheers
Andrew

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.7 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP5vy+bHCR3gb8jsRAliTAKCvCsfZuNN7Og57S0s8O4SZNveSUwCgq4VP

vHUE/S+x09l5I24E2/rmLj4=

=JaWT

-----END PGP SIGNATURE-----

-

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1
No, this still results in a dead network connection, although it is

probably a correct change.  I suppose giving the loop even more reasons

to return -ERANGE wasn't going to be helpful.
- --

Kevin Winchester
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHP5KXKPGFQbiQ3tQRAilbAJ9h3qtO9sb9+ctVU0pxzCBjysy06QCdE1Wd

M5V3+0BWyn04p0UeUq/KSlw=

=663t

-----END PGP SIGNATURE-----

-

That's the winner.  The changelog indicates that the patch is meant to keep

compatibility with older userspace, so I guess it didn't quite keep as much

compatibility as it wanted.
I have no idea what I'm doing, but I'll take a look at the patch anyway...
--

Kevin Winchester

-

On Thu, 15 Nov 2007 21:01:32 -0400
OK, thanks for working that out - I'll temporarily drop that patch until we

get it sorted.
-

We seem to have some general problem with mkfs for all filesystems.

I am seeing this across at least three test systems although

most are unable to compile this kernel :(, even with the hotfix.

Basically, all mkfs operations for any filsystem type are failing,

ext2 reports this as "short write", various others are mentioning

pwrite and pwrite64 returning bad things:
ext2: Could not write 8 blocks in inode table starting at 851970:

	Attempt to write block from filesystem resulted in short

	write
reiserfs: bwrite: write 4096 bytes returned -1 (block=851968,

	dev=3): No space left on device
xfs: mkfs.xfs: pwrite64 failed: No space left on device
Nothing is reported in dmesg at the time as far as I can tell.  From the

ext2 log I would swear we get this error on a block number far below that

which is reported written successfully, though I cannot say I trust mkfs.
Nothing obvious has changed pwrite or block/* to my eye, so heck knows

where this is coming from.  2.6.24-rc2 works on these same systems as

goes the latest 2.6.24-rc2-git5.
Full mkfs output below.
-apw
*** elm3b6, x86_64:
mke2fs 1.37 (21-Mar-2005)

Filesystem label=

OS type: Linux

Block size=4096 (log=2)

Fragment size=4096 (log=2)

1465920 inodes, 2929854 blocks

146492 blocks (5.00%) reserved for the super user

First data block=0

90 block groups

32768 blocks per group, 32768 fragments per group

16288 inodes per group

Superblock backups stored on blocks:

	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
mkfs.ext2: Attempt to write block from filesystem resulted in short write while zeroing block 2929824 at end of filesystem

Writing inode tables:

Could not write 8 blocks in inode table starting at 851970: Attempt to write block from filesystem resulted in short write

===

mkfs.jfs version 1.1.7, 22-Jul-2004

The specified disk did not finish formatting.

===

mkfs.reiserfs 3.6.19 (2003 www.namesys.com)

[...]

Guessing about desired format.. Kernel 2.6.24-rc2-mm1-autokern1 is runni...
[ message continues ]

It was mm-fix-blkdev-size-calculation-in-generic_write_checks.patch.
Odd, I thought that looked OK.
Here's a revert (uploaded to hot-fixes/, too):
--- a/mm/filemap.c~revert-mm-fix-blkdev-size-calculation-in-generic_write_checks

+++ a/mm/filemap.c

@@ -1855,11 +1855,9 @@ inline int generic_write_checks(struct f

 	} else {

 #ifdef CONFIG_BLOCK

 		loff_t isize;

-		unsigned int blksize;

 		if (bdev_read_only(I_BDEV(inode)))

 			return -EPERM;

-		blksize = block_size(I_BDEV(inode));

-		isize = i_size_read(inode) & ~(blksize - 1);

+		isize = i_size_read(inode);

 		if (*pos >= isize) {

 			if (*count || *pos > isize)

 				return -ENOSPC;

_
-

Oh my ..., I'm truly sorry. When i've sent this patch to Andrew first time

he ask me to remake it in order to make it less intrusive. When later

i've found what patch was buggy because of incorrect int to loff_t conversion

isize = i_size_read(inode) & ~(blksize - 1);

                              ^^^^^^^^^^^^^^
-

[POWERPC] Fix dependencies for FSL_DMA
From a powerpc allyesconfig build:
drivers/dma/fsldma.c:504: error: implicit declaration of function 'bus_to_virt'
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: mm/drivers/dma/Kconfig

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

--- mm.orig/drivers/dma/Kconfig

+++ mm/drivers/dma/Kconfig

@@ -36,7 +36,7 @@ config INTEL_IOP_ADMA
 config FSL_DMA

 	bool "Freescale MPC85xx/MPC83xx DMA support"

-	depends on PPC

+	depends on PPC && VIRT_TO_BUS

 	select DMA_ENGINE

 	---help---

 	  Enable support for the Freescale DMA engine. Now, it support

-

Fixes:

  CC [M]  drivers/infiniband/ulp/ipoib/ipoib_main.o

drivers/infiniband/ulp/ipoib/ipoib_main.c: In function ‘ipoib_init_module’:

drivers/infiniband/ulp/ipoib/ipoib_main.c:1269: error: invalid lvalue in assignment
In the case where CONFIG_INFINIBAND_IPOIB_CM is not defined ipoib_max_conn_qp is #defined to 0.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
 drivers/infiniband/ulp/ipoib/ipoib_main.c |    3 ++-

 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c b/drivers/infiniband/ulp/ipoib/ipoib_main.c

index 623458e..aeb5a01 100644

--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c

+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c

@@ -1265,8 +1265,9 @@ static int __init ipoib_init_module(void)

 	ipoib_sendq_size = roundup_pow_of_two(ipoib_sendq_size);

 	ipoib_sendq_size = min(ipoib_sendq_size, IPOIB_MAX_QUEUE_SIZE);

 	ipoib_sendq_size = max(ipoib_sendq_size, IPOIB_MIN_QUEUE_SIZE);

-

+#ifdef CONFIG_INFINIBAND_IPOIB_CM

 	ipoib_max_conn_qp = min(ipoib_max_conn_qp, IPOIB_CM_MAX_CONN_QP);

+#endif
 	ret = ipoib_register_debugfs();

 	if (ret)
Yours Tony
  linux.conf.au        http://linux.conf.au/ || http://lca2008.linux.org.au/

  Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!

-

The patch fixes the compile although having a variable name #defined as 0

seems a bit of an unexpected suprise.
Either way, when applied with the hotfixes, bl6-13 on
--

--

Mel Gorman

Part-time Phd Student                          Linux Technology Center

University of Limerick                         IBM Dublin Software Lab

-