Re: 2.6.17-mm1

Re: 2.6.17-mm1

[Martin Bligh]

On 16x NUMA-Q, got a panic running dbench across different fs's.


BUG: unable to handle kernel NULL pointer dereference at virtual address 
00000000
  printing eip:
c0154030
*pde = 2589f001
*pte = 00000000
Oops: 0000 [#1]
8K_STACKS SMP
last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
Modules linked in:
CPU:    1
EIP:    0060:[<c0154030>]    Not tainted VLI
EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
EIP is at s_show+0xe5/0x28e
eax: c038efe0   ebx: e744ef60   ecx: 00000000   edx: 00000000
esi: c038efe0   edi: 00000000   ebp: e744b2c0   esp: e67aff14
ds: 007b   es: 007b   ss: 0068
Process cp (pid: 7295, ti=e67ae000 task=e1521570 task.ti=e67ae000)
Stack: 00000000 00000000 00000000 00000072 00000c66 e64a78c0 e744b2c0 
00000000
        00001000 c01724e5 e64a78c0 e744b2c0 0000087e 00000000 0000005c 
00000000
        0000005b 00000000 e6754720 bfc8afa0 e67affa4 00001000 c0156e80 
e6754720
Call Trace:
  [<c01724e5>] seq_read+0x195/0x262
  [<c0156e80>] vfs_read+0x88/0x11e
  [<c0157160>] sys_read+0x3b/0x63
  [<c036d07f>] syscall_call+0x7/0xb
Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
0f 18 00 90 39 da 75 c9 8b 53 10 8b 02 0f 18 00 90 8d 43
EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:e67aff14

Got a very similar panic on a flat SMP box too:

BUG: unable to handle kernel paging request at virtual address 00100100
  printing eip:
c0154030
*pde = 2f2fa001
*pte = 00000000
Oops: 0000 [#1]
8K_STACKS SMP
last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
Modules linked in:
CPU:    1
EIP:    0060:[<c0154030>]    Not tainted VLI
EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
EIP is at s_show+0xe5/0x28e
eax: c038efe0   ebx: dffead60   ecx: 00000000   edx: 00100100
esi: c038efe0   edi: 00000000   ebp: dffe7660   esp: f69a7f14
ds: 007b   es: 007b   ss: 0068
Process cp (pid: 7190, ti=f69a6000 task=f64dc570 task.ti=f69a6000)
Stack: 00000000 00000000 00000000 0000003f 00000328 f650a620 dffe7660 
00000000
        00001000 c01724e5 f650a620 dffe7660 00000909 00000000 0000005d 
00000000
        0000005c 00000000 ed4d3200 bff47a70 f69a7fa4 00001000 c0156e80 
ed4d3200
Call Trace:
  [<c01724e5>] seq_read+0x195/0x262
  [<c0156e80>] vfs_read+0x88/0x11e
  [<c0157160>] sys_read+0x3b/0x63
  [<c036d07f>] syscall_call+0x7/0xb
Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
8d 74 26 00 39 da 75 c9 8b 53 10 8b 02 8d 74 26 00 8d 43
EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:f69a7f14

Re: 2.6.17-mm1

[Andrew Morton]

On Fri, 23 Jun 2006 12:23:54 -0700
Martin Bligh <mbligh@mbligh.org> wrote:

> On 16x NUMA-Q, got a panic running dbench across different fs's.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address 
> 00000000
>   printing eip:
> c0154030
> *pde = 2589f001
> *pte = 00000000
> Oops: 0000 [#1]
> 8K_STACKS SMP
> last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
> Modules linked in:
> CPU:    1
> EIP:    0060:[<c0154030>]    Not tainted VLI
> EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
> EIP is at s_show+0xe5/0x28e
> eax: c038efe0   ebx: e744ef60   ecx: 00000000   edx: 00000000
> esi: c038efe0   edi: 00000000   ebp: e744b2c0   esp: e67aff14
> ds: 007b   es: 007b   ss: 0068
> Process cp (pid: 7295, ti=e67ae000 task=e1521570 task.ti=e67ae000)
> Stack: 00000000 00000000 00000000 00000072 00000c66 e64a78c0 e744b2c0 
> 00000000
>         00001000 c01724e5 e64a78c0 e744b2c0 0000087e 00000000 0000005c 
> 00000000
>         0000005b 00000000 e6754720 bfc8afa0 e67affa4 00001000 c0156e80 
> e6754720
> Call Trace:
>   [<c01724e5>] seq_read+0x195/0x262
>   [<c0156e80>] vfs_read+0x88/0x11e
>   [<c0157160>] sys_read+0x3b/0x63
>   [<c036d07f>] syscall_call+0x7/0xb
> Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
> 0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
> 0f 18 00 90 39 da 75 c9 8b 53 10 8b 02 0f 18 00 90 8d 43
> EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:e67aff14

That's a null-pointer deref

> Got a very similar panic on a flat SMP box too:
> 
> BUG: unable to handle kernel paging request at virtual address 00100100
>   printing eip:
> c0154030
> *pde = 2f2fa001
> *pte = 00000000
> Oops: 0000 [#1]
> 8K_STACKS SMP
> last sysfs file: /devices/pci0000:00/0000:00:0a.0/resource
> Modules linked in:
> CPU:    1
> EIP:    0060:[<c0154030>]    Not tainted VLI
> EFLAGS: 00010006   (2.6.17-mm1-autokern1 #1)
> EIP is at s_show+0xe5/0x28e
> eax: c038efe0   ebx: dffead60   ecx: 00000000   edx: 00100100
> esi: c038efe0   edi: 00000000   ebp: dffe7660   esp: f69a7f14
> ds: 007b   es: 007b   ss: 0068
> Process cp (pid: 7190, ti=f69a6000 task=f64dc570 task.ti=f69a6000)
> Stack: 00000000 00000000 00000000 0000003f 00000328 f650a620 dffe7660 
> 00000000
>         00001000 c01724e5 f650a620 dffe7660 00000909 00000000 0000005d 
> 00000000
>         0000005c 00000000 ed4d3200 bff47a70 f69a7fa4 00001000 c0156e80 
> ed4d3200
> Call Trace:
>   [<c01724e5>] seq_read+0x195/0x262
>   [<c0156e80>] vfs_read+0x88/0x11e
>   [<c0157160>] sys_read+0x3b/0x63
>   [<c036d07f>] syscall_call+0x7/0xb
> Code: 10 3b 8d d4 00 00 00 75 0a 85 f6 b8 a0 ef 38 c0 0f 44 f0 85 c9 75 
> 0a 85 f6 b8 e0 ef 38 c0 0f 44 f0 01 4c 24 10 ff 44 24 0c 8b 12 <8b> 02 
> 8d 74 26 00 39 da 75 c9 8b 53 10 8b 02 8d 74 26 00 8d 43
> EIP: [<c0154030>] s_show+0xe5/0x28e SS:ESP 0068:f69a7f14

And that's LIST_POISON1.

The only s_show()s I can see are in slab and in kallsyms.

It would help if you could gdb these guys, work out file-n-line.

And it would be super-good if you could revert
slab-stop-using-list_for_each.patch and retest.  

Re: 2.6.17-mm1

[Paulo Marques]

Andrew Morton wrote:
> And that's LIST_POISON1.
> 
> The only s_show()s I can see are in slab and in kallsyms.
>
> It would help if you could gdb these guys, work out file-n-line.

I just checked s_show in kernel/kallsyms.c and I can not see how it 
could BUG without BUG'ing in s_next first, because that function only 
formats the information that has been gathered by s_next.

> And it would be super-good if you could revert
> slab-stop-using-list_for_each.patch and retest.  

My bet goes to slab's s_show, too. Besides, that code in kallsyms has 
been like that for a very long time, IIRC.

-- 
Paulo Marques - www.grupopie.com

Pointy-Haired Boss: I don't see anything that could stand in our way.
            Dilbert: Sanity? Reality? The laws of physics?

Re: 2.6.17-mm1

[Chuck Ebbert]

In-Reply-To: <20060623143004.6af78d68.akpm@osdl.org>

On Fri, 23 Jun 2006 14:30:04 -0700, Andrew Morton wrote:

> On Fri, 23 Jun 2006 12:23:54 -0700
> Martin Bligh <mbligh@mbligh.org> wrote:
> 
> > On 16x NUMA-Q, got a panic running dbench across different fs's.

> > Got a very similar panic on a flat SMP box too:
> > 
> > BUG: unable to handle kernel paging request at virtual address 00100100

> And that's LIST_POISON1.
> 
> The only s_show()s I can see are in slab and in kallsyms.
> 
> It would help if you could gdb these guys, work out file-n-line.

It's definitely in slab, in one of the loops walking the full, partial
and free chains.

> 
> And it would be super-good if you could revert
> slab-stop-using-list_for_each.patch and retest.  

I don't think that's the problem.  It really looks like a corrupted list.

How does this keep showing up in slab all the time?  Broken locking?

And also, looking at the prefetching in the list macros, it can have the
same effect as list_for_each_safe -- _if_ the compiler decides to save
the pointer it passed to prefetch().  In this case it didn't...

-- 
Chuck
 "You can't read a newspaper if you can't read."  --George W. Bush

Re: 2.6.17-mm1

[Martin Bligh]

Seems to dive into an endless loop in compile.

http://test.kernel.org/abat/37068/debug/test.log.0

   CHK     include/linux/compile.h
   UPD     include/linux/compile.h
   CC      init/version.o
   CC      init/initramfs.o
   CC      init/calibrate.o
   LD      init/built-in.o
   HOSTCC  usr/gen_init_cpio
   SYMLINK usr/include/asm -> include/asm-x86_64
   GEN     usr/klibc/syscalls/SYSCALLS.i
   GEN     usr/klibc/syscalls/syscalls.nrs
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk
   GEN     usr/klibc/syscalls/typesize.c
   KLIBCCC usr/klibc/syscalls/typesize.o
   OBJCOPY usr/klibc/syscalls/typesize.bin
   GEN     usr/klibc/syscalls/syscalls.mk

etc etc. for ever.

On both x86_64 and ppc64.

M.

Re: 2.6.17-mm1

[Mattia Dongili]

On Wed, Jun 21, 2006 at 11:19:55AM -0700, Martin Bligh wrote:
> Seems to dive into an endless loop in compile.
> 
> http://test.kernel.org/abat/37068/debug/test.log.0
> 
>   CHK     include/linux/compile.h
>   UPD     include/linux/compile.h
>   CC      init/version.o
>   CC      init/initramfs.o
>   CC      init/calibrate.o
>   LD      init/built-in.o
>   HOSTCC  usr/gen_init_cpio
>   SYMLINK usr/include/asm -> include/asm-x86_64
>   GEN     usr/klibc/syscalls/SYSCALLS.i
>   GEN     usr/klibc/syscalls/syscalls.nrs
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
[...]
> etc etc. for ever.
> 
> On both x86_64 and ppc64.

me too, on 586

.config is here: http://oioio.altervista.org/linux/config-2.6.17-mm1
-- 
mattia
:wq!

Re: 2.6.17-mm1

[H. Peter Anvin]

Mattia Dongili wrote:
> On Wed, Jun 21, 2006 at 11:19:55AM -0700, Martin Bligh wrote:
>> Seems to dive into an endless loop in compile.
>>
>> http://test.kernel.org/abat/37068/debug/test.log.0
>>
>>   CHK     include/linux/compile.h
>>   UPD     include/linux/compile.h
>>   CC      init/version.o
>>   CC      init/initramfs.o
>>   CC      init/calibrate.o
>>   LD      init/built-in.o
>>   HOSTCC  usr/gen_init_cpio
>>   SYMLINK usr/include/asm -> include/asm-x86_64
>>   GEN     usr/klibc/syscalls/SYSCALLS.i
>>   GEN     usr/klibc/syscalls/syscalls.nrs
>>   GEN     usr/klibc/syscalls/typesize.c
>>   KLIBCCC usr/klibc/syscalls/typesize.o
>>   OBJCOPY usr/klibc/syscalls/typesize.bin
> [...]
>> etc etc. for ever.
>>
>> On both x86_64 and ppc64.
> 
> me too, on 586
> 
> .config is here: http://oioio.altervista.org/linux/config-2.6.17-mm1

I've uploaded the patch for this to:

http://www.kernel.org/pub/linux/kernel/people/hpa/klibc-2.6.17-mm1-circdep.patch

The klibc tree has additional fixes in it.

	-hpa

2.6.17-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/


- powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
  startup and some later patch is causing a big crash (I didn't bisect that
  one - later).

- ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
  toolchain might be implicated).

- git-sas.patch has been dropped due to build failures.

- git-s390.patch has been dropped due to patching rejects





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




Changes since 2.6.17-rc6-mm2:


 origin.patch
 git-acpi.patch
 git-agpgart.patch
 git-alsa.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-dvb.patch
 git-gfs2.patch
 git-ia64.patch
 git-infiniband.patch
 git-input.patch
 git-jfs.patch
 git-kbuild.patch
 git-klibc.patch
 git-hdrinstall2.patch
 git-libata-all.patch
 git-netdev-all.patch
 git-nfs.patch
 git-ocfs2.patch
 git-powerpc.patch
 git-pcmcia.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch

 git trees

-further-alterations-for-memory-barrier-document.patch
-powernow-k8-crash-workaround.patch
-bugfixes-to-get-i2o-working-again.patch
-fix-possible-oops-in-cs4281-irq-handler.patch
-trivial-videodev2h-patch.patch
-zoran-strncpy-cleanup.patch
-scx200_acb-use-pci-i-o-resource-when-appropriate.patch
-i2c-pca954x-i2c-mux-driver.patch
-i2c-pca954x-fix-initial-access-to-first-mux-switch-port.patch
-ieee1394-video1394-be-quiet.patch
-ieee1394-ohci1394c-function-calls-without.patch
-ieee1394-sbp2-make-tsb42aa9-workaround-specific.patch
-ieee1394-semaphore-to-mutex-conversion.patch
-ieee1394-raw1394-fix-whitespace-after-x86_64.patch
-ieee1394-ieee1394-ohci1394-cycletoolong.patch
-ieee1394-ieee1394-support-for-slow-links-or-slow.patch
-ieee1394-ieee1394-save-ram-by-using-a-single.patch
-ieee1394-sbp2-remove-manipulation-of-inquiry.patch
-ieee1394-sbp2-log-number-of-supported-concurrent.patch
-ieee1394-ieee1394-extend-lowlevel-api-for.patch
-ieee1394-ohci1394-set-address-range-properties.patch
-ieee1394-ohci1394-make-phys_dma-parameter.patch
-ieee1394-sbp2-sbp2-remove-ohci1394-specific.patch
-ieee1394-sbp2-fix-s800-transfers-if-phys_dma-is.patch
-ieee1394-update-feature-removal-of-obsolete.patch
-ieee1394-sbp2-provide-helptext-for.patch
-ieee1394-sbp2-kconfig-fix.patch
-ieee1394-sbp2-use-__attribute__packed-for.patch
-ieee1394-speed-up-of-dma_region_sync_for_cpu.patch
-ieee1394-sbp2-fix-deregistration-of-status-fifo-address-space.patch
-ieee1394-add-preprocessor-constant-for-invalid-csr.patch
-fix-broken-suspend-resume-in-ohci1394-was-acpi-suspend.patch
-ieee1394_core-switch-to-kthread-api.patch
-eth1394-endian-fixes.patch
-ieee1394-hl_irqs_lock-is-taken-in-hardware.patch
-ieee1394-adjust-code-formatting-in.patch
-git-kbuild-modpost-build-fix.patch
-git-klibc-ia64-build-fix.patch
-git-hdrcleanup.patch
-git-hdrcleanup-fixup.patch
-libata-add-missing-data_xfer-for-pata_pdc2027x-and-pdc_adma.patch
-sata_sil24-endian-anotations.patch
-sdhci-truncated-pointer-fix.patch
-git-netdev-all-fixup.patch
-smc911x-Kconfig-fix.patch
-e1000-prevent-statistics-from-getting-garbled-during-reset.patch
-forcedeth-config-ring-sizes.patch
-forcedeth-config-flow-control.patch
-forcedeth-config-phy.patch
-forcedeth-config-wol.patch
-forcedeth-config-csum.patch
-forcedeth-config-statistics.patch
-forcedeth-config-diagnostics.patch
-forcedeth-config-module-parameters.patch
-forcedeth-config-version.patch
-forcedeth-new-device-ids.patch
-ipw2200-locking-fix.patch
-forcedeth-xmit_lock-went-away.patch
-client-side-nfsacl-caching-fix.patch
-nfs-really-return-status-from-decode_recall_args.patch
-gregkh-pci-pci-add-pci_cap_id_vndr.patch
-gregkh-pci-pci-fix-pciehp-compile-issue-when-config_acpi-is-not-enabled.patch
-remove-drivers-scsi-constantscscsi_print_req_sense.patch
-scsi-remove-documentation-scsi-cpqfctxt.patch
-mpt-fusion-driver-initialization-failure-fix.patch
-drivers-scsi-use-array_size-macro.patch
-hptiop-highpoint-rocketraid-3xxx-controller-driver.patch
-remove-the-scsi_request-interface-from-the-gdth-driver.patch
-git-scsi-target-warning-fix.patch
-mm-x86_64-mm-polling-thread-status-fix.patch
-x86_64-setupc-print-cmp-related-boottime-information.patch
-alpha-generic-hweight-build-fix.patch
-add-__iowrite64_copy.patch
-add-__iowrite64_copy-s390-fix.patch
-inotify-split-kernel-api-from-userspace-support.patch
-inotify-add-names-inode-to-event-handler.patch
-inotify-add-interfaces-to-kernel-api.patch
-inotify-allow-watch-removal-from-event-handler.patch
-inotify-update-kernel-documentation.patch
-sound-vxpocket-fix-printk-warning.patch

 Merged into mainline or a subsystem tree

+uml-fix-wall_to_monotonic-initialization.patch
+sparc-build-breakage.patch
+ntfs-critical-bug-fix-affects-mips-and-possibly-others.patch
+selinux-add-hooks-for-key-subsystem.patch
+keys-fix-race-between-two-instantiators-of-a-key.patch
+suspend_console-warning-fix.patch
+myri10ge-build-fix.patch

 to-merge-asap queue.

+git-acpi-pre.patch
+git-acpi-post.patch

 Things to make git-acpi easier to apply.

+git-acpi-fixup.patch

 Fix reject due to git-apci.

+git-acpi-ia64-build-fix.patch

 Fix git-acpi build error
 
+pnpacpi-reject-acpi_producer-resources.patch
+acpi-add-ibm-r60e-laptop-to-proc-idle-blacklist.patch
+acpi-c-states-accounting-of-sleep-states.patch
+acpi-c-states-bm_activity-improvements.patch
+acpi-c-states-only-demote-on-current-bus-mastering-activity.patch

 ACPI patches.

+acpi-sony-add-fn-hotkey-support.patch

 2.6-sony_acpi4.patch feature

+ati-agp-build-fix.patch

 Fix git-agpgart.patch

-git-cpufreq-fixup.patch

 Unneeded

+gregkh-driver-make_class_name-kobj.patch
+gregkh-driver-device-class.patch
+gregkh-driver-driver-core-add-generic-subsystem-link-to-all-devices.patch
+gregkh-driver-device-symlinks-for-classes.patch
+gregkh-driver-driver-core-make-dev_info-and-friends-print-the-bus-name-if-there-is-no-driver.patch
+gregkh-driver-driver-model-add-isa-bus.patch

 driver tree updates

+saa7134-card-lifeview3000-ntsc.patch
+tea575x-tuner-build-fix.patch
+git-dvb-versus-matroxfb.patch
+git-dvb-printk-warning-fix.patch

 Fix git-dvb.patch

+gregkh-i2c-i2c-opencores-cleanup.patch
+gregkh-i2c-i2c-mark-data-const-for-write-block.patch
+gregkh-i2c-i2c-scx200_acb-use-PCI-IO-resource-when-appropriate.patch
+gregkh-i2c-i2c-scx200_acb-mark-scx200_acb_probe-init.patch
+gregkh-i2c-i2c-scx200_acb-documentation-update.patch
+gregkh-i2c-i2c-i801-01-fix-block-transaction-poll-loops.patch
+gregkh-i2c-i2c-i801-02-remove-force_addr-parameter.patch
+gregkh-i2c-i2c-i801-03-remove-pci-function-check.patch
+gregkh-i2c-i2c-i801-04-cleanups.patch
+gregkh-i2c-i2c-i801-05-better-pci-subsystem-integration.patch
+gregkh-i2c-i2c-i801-06-merge-setup-function.patch
+gregkh-i2c-hwmon-kconfig-header-fix.patch
+gregkh-i2c-hwmon-lm70-new-driver.patch
+gregkh-i2c-hwmon-vid-add-core-and-conroe-support.patch
+gregkh-i2c-i2c-i2c-controllers-go-into-right-place-on-sysfs.patch

 I2C tree updates

+i2c-801-64bit-resource-fix.patch

 Fix it.

+git-infiniband-fixup.patch

 Fix reject in git-infiniband.patch

+input-mouse-sermouse-fix-memleak-and-potential-buffer-overflow.patch

 input fix

+revert-sparc-build-breakage.patch

 Make git-klibc.patch easier to apply.

+git-klibc-fixup.patch

 Fix rejects in git-klibc.patch

-git-hdrinstall.patch
+git-hdrinstall2.patch

 Renamed

-revert-sata_sil24-sii3124-sata-driver-endian-problem.patch

 Dropped

+git-libata-all-fixup.patch
+git-libata-all-data_xfer-fixes.patch
+git-libata-all-data_xfer-fixes-fixes.patch
+git-libata-pata_cs5535-is-bust.patch

 Fix git-libata-all.patch

+via-pata-fails-on-some-atapi-drives.patch
+via-pata-fails-on-some-atapi-drives-tidy.patch

 ATA fix

-git-mtd-fixup.patch

 Unneeded

+ni5010-netcard-cleanup.patch

 netdev cleanup

-git-net-git-klibc-fixup.patch

 Unneeded

+netpoll-dont-spin-forever-sending-to-blocked-queues.patch
+netpoll-break-recursive-loop-in-netpoll-rx-path.patch
+irda-add-some-ibm-think-pads.patch
+atm-mpcc-warning-fix.patch

 net fixes

+git-nfs-build-fixes.patch
+nfs-build-fix-99.patch

 Fix git-nfs.patch wreckage

+nfs-remove-nfs_put_link.patch

 nfs cleanup

-git-sas.patch

 Dropped

+serial-add-tsi108-8250-serial-support.patch
+8250_pnp-add-support-for-other-wacom-tablets.patch
+serial-8250-sysrq-deadlock-fix.patch

 Serial things

+gregkh-pci-64bit-resource-c99-changes-for-struct-resource-declarations.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-sound-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-networks-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-pci-core-and-hotplug-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-mtd-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-ide-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-video-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-pcmcia-drivers.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-arch-and-core-code.patch
+gregkh-pci-64bit-resource-fix-up-printks-for-resources-in-misc-drivers.patch
+gregkh-pci-64bit-resource-introduce-resource_size_t-for-the-start-and-end-of-struct-resource.patch
+gregkh-pci-64bit-resource-change-resource-core-to-use-resource_size_t.patch
+gregkh-pci-64bit-resource-change-pci-core-and-arch-code-to-use-resource_size_t.patch
+gregkh-pci-64bit-resource-change-pnp-core-to-use-resource_size_t.patch
+gregkh-pci-64bit-resource-convert-a-few-remaining-drivers-to-use-resource_size_t-where-needed.patch
+gregkh-pci-64bit-resource-finally-enable-64bit-resource-sizes.patch
+gregkh-pci-i386-export-memory-more-than-4g-through-proc-iomem.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-changes-to-generic-pci-code.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-update-documentation-pci_txt.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-make-intel-e1000-driver-legacy-i-o-port-free.patch
-gregkh-pci-pci-legacy-i-o-port-free-driver-make-emulex-lpfc-driver-legacy-i-o-port-free.patch
-gregkh-pci-pci-64-bit-resources-core-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-pci-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-ide-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-media-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-net-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-pcmcia-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-others-changes.patch
-gregkh-pci-pci-64-bit-resources-sound-changes.patch
-gregkh-pci-pci-64-bit-resources-arch-changes.patch
-gregkh-pci-pci-64-bit-resources-arch-powerpc-changes.patch
-gregkh-pci-pci-64-bit-resources-more-drivers-others-changes.patch
-gregkh-pci-pci-64-bit-resources-more-sound-changes.patch
-gregkh-pci-pci-64-bit-resources-drivers-pci-changes-sparc32-fix.patch
-gregkh-pci-pci-64-bit-resource-fixup-pci-resource-dbg-code-to-handle-size-change.patch
-gregkh-pci-pci-64-bit-resource-fix-amba-build-warning.patch
-gregkh-pci-pci-64-bit-resources-fix-pnp-sysfs-interface.patch
-gregkh-pci-pci-64-bit-resources-arch-powerpc-changes-update.patch
-gregkh-pci-pci-64-bit-resource-drivers-mips-changes.patch
-gregkh-pci-kconfigurable-resources-core-changes.patch
-gregkh-pci-kconfigurable-resources-driver-pci-changes.patch
-gregkh-pci-kconfigurable-resources-driver-others-changes.patch
-gregkh-pci-kconfigurable-resources-arch-dependent-changes.patch
-gregkh-pci-kconfigurable-resources-arch-dependent-changes-arch.patch
-gregkh-pci-kconfigurable-resources-arch-dependent-changes-arch-q-z.patch
-gregkh-pci-i386-export-memory-more-than-4g-through-proc-iomem.patch
-gregkh-pci-pci-msi-abstractions-and-support-for-altix.patch
-gregkh-pci-pci-per-platform-ia64_-first-last-_device_vector-definitions.patch
-gregkh-pci-pci-altix-msi-support.patch
-gregkh-pci-pci-error-handling-on-pci-device-resume.patch
+gregkh-pci-pci-hotplug-don-t-use-acpi_os_free.patch
-gregkh-pci-pci-improve-pci-config-space-writeback.patch
-gregkh-pci-pci-reverse-pci-config-space-restore-order.patch
-gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch
-gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch
-gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch
-gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch
-gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
-gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch
-gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch
-gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch
+gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch
+gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch
+gregkh-pci-pci-add-pci_cap_id_vndr.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-changes-to-generic-pci-code.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-update-documentation-pci_txt.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-make-intel-e1000-driver-legacy-i-o-port-free.patch
+gregkh-pci-pci-legacy-i-o-port-free-driver-make-emulex-lpfc-driver-legacy-i-o-port-free.patch
+gregkh-pci-pci-msi-abstractions-and-support-for-altix.patch
+gregkh-pci-pci-per-platform-ia64_-first-last-_device_vector-definitions.patch
+gregkh-pci-pci-altix-msi-support.patch
+gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
+gregkh-pci-pci-fix-to-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
+gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch
+gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch
+gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch
+gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch
+gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch
+gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch
-gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch
+gregkh-pci-pci-fix-memory-leak-in-mmconfig-error-path.patch
+gregkh-pci-pci-bus-parity-status-sysfs-interface.patch
+gregkh-pci-pci-fix-issues-with-extended-conf-space-when-mmconfig-disabled-because-of-e820.patch
+gregkh-pci-pci-nvidia-quirk-to-make-aer-pci-e-extended-capability-visible.patch

 PCI tree changes.  Some of it was merged, I think.
-mm-gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms-fix.patch
+64-bit-resources-lose-some-ifdefs.patch

 Fix it.

+clear-abnormal-poweroff-flag-on-via-southbridges-fix-resume.patch
+clear-abnormal-poweroff-flag-on-via-southbridges-fix-resume-fix.patch

 VIA fix

-git-pcmcia-fixup.patch
-git-pcmcia-fixup-2.patch

 Unneeded

+com20020_cs-more-device-support.patch
+kill-open-coded-offsetof-in-cm4000_csc-zero_dev.patch

 PCMCIA work

-megaraid_sas-switch-fw_outstanding-to-an-atomic_t.patch
-megaraid_sas-add-support-for-zcr-controller.patch
-megaraid_sas-add-support-for-zcr-controller-fix.patch
+megaraid_sas-zcr-with-fix.patch

 Updated patch

+megaraid-dell-cerc-ata100-4ch-support.patch

 megaraid-old device support.

+gregkh-usb-airprime.c-add-kyocera-wireless-kpc650-passport-support.patch
+gregkh-usb-usb-io_edgeport-touch-up.patch
+gregkh-usb-usb-update-usbmon-fix-glued-lines.patch
+gregkh-usb-usb-implement-error-event-in-usbmon.patch
+gregkh-usb-usb-update-usbmontxt.patch
+gregkh-usb-usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers.patch
+gregkh-usb-usb-trivial-debug-message-correction-in-gadget-ether-driver.patch
+gregkh-usb-usb-serial-clean-tty-fields-on-failed-device-open.patch
+gregkh-usb-usb-gadget-serial-fix-a-deadlock-when-closing-the-serial-device.patch
+gregkh-usb-usb-gadget-serial-do-not-save-restore-irq-flags-in-gs_close.patch
+gregkh-usb-usb-gadget-allow-drivers-support-speeds-higher-than-full-speed.patch
+gregkh-usb-usb-gadget-fix-compile-errors.patch
+gregkh-usb-usb-gadget-update-pxa2xx_udc.c-driver-to-fully-support-ixp4xx-platform.patch
+gregkh-usb-usbserial-fixes-wrong-return-values.patch
+gregkh-usb-usb-unusual_devs-entry-for-nokia-n80.patch
+gregkh-usb-usb-whitespace-removal-from-usb-gadget-ether.patch
+gregkh-usb-usb-move-linux-usb_cdc.h-to-linux-usb-cdc.h.patch
+gregkh-usb-usb-move-hardware-specific-linux-usb_-.h-to-linux-usb-.h.patch
+gregkh-usb-usb-move-linux-usb_input.h-to-linux-usb-input.h.patch
+gregkh-usb-usb-endpoint.patch
+gregkh-usb-usb-endpoint-pass-struct-device.patch
+gregkh-usb-usb-endpoint-mess.patch
+gregkh-usb-usb-devio-class-to-device.patch
+gregkh-usb-usb-class-device-to-device.patch
+gregkh-usb-usb-dynamic-usb-class.patch

 USB tree updates

+usb-move-linux-usb_input.h-to-linux-usb-input-fix.patch
+ehci-fix-bogus-alteration-of-a-local-variable.patch
+ipaqc-bugfixes.patch
+ipaqc-timing-parameters.patch
+ipaqc-timing-parameters-fix.patch

 USB things

+x86_64-mm-twofish-cipher---split-out-common-c-code.patch
+x86_64-mm-twofish-cipher---priority-fix.patch
+x86_64-mm-twofish-cipher---i586-assembler.patch
+x86_64-mm-twofish-cipher---x86_64-assembler.patch
+x86_64-mm-unify-cpu-boottime-output.patch

 x86_64 tree udpates

+revert-x86_64-mm-twofish-cipher---x86_64-assembler.patch
+revert-x86_64-mm-twofish-cipher---i586-assembler.patch
+revert-x86_64-mm-twofish-cipher---priority-fix.patch
+revert-x86_64-mm-twofish-cipher---split-out-common-c-code.patch

 Drop most of it again.

+xfs-remove-dir-check-in-xfs_link.patch
+xfs-use-container_of-in-vn_from_inode.patch
+xfs-pass-inode-to-xfs_ioc_space.patch
+xfs-remove-unused-behaviour-lock.patch

 XFS fixlets

-zone-init-check-and-report-unaligned-zone-boundaries.patch
-x86-align-highmem-zone-boundaries-with-numa.patch
-zone-allow-unaligned-zone-boundaries.patch
-zone-allow-unaligned-zone-boundaries-x86-add-zone-alignment-qualifier.patch
+zone-handle-unaligned-zone-boundaries.patch

 Updated patch

+pgdat-allocation-for-new-node-add-export-kswapd-start-func-fix.patch

 Fix pgdat-allocation-for-new-node-add-export-kswapd-start-func.patch

+add-page_mkwrite-vm_operations-method-fix.patch

 Fix add-page_mkwrite-vm_operations-method.patch

+slab-kmalloc-kzalloc-comments-cleanup-and-fix.patch
+kernel-doc-for-mm-filemapc.patch
+delete-unused-definitions-of-kvaddr_to_nid.patch
+printk-should-not-be-called-under-zone-lock.patch

 MM things

-page-migration-simplify-migrate_pages-tweaks.patch

 Foded into page-migration-simplify-migrate_pages.patch

-page-migration-detailed-status-for-moving-of-individual-pages.patch
-page-migration-support-moving-of-individual-pages-fixes.patch

 Folded into page-migration-support-moving-of-individual-pages.patch

-page-migration-support-moving-of-individual-pages-x86-support-fix.patch

 Folded into page-migration-support-moving-of-individual-pages-x86-support.patch

+radix-tree-rcu-lockless-readside.patch
+radix-tree-rcu-lockless-readside-wraning-fix.patch
+radix-tree-rcu-lockless-readside-fix.patch

 radix-tree work.

-zoned-vm-counters-per-zone-counter-functionality.patch
-zoned-vm-counters-per-zone-counter-functionality-tidy.patch
-zoned-vm-counters-per-zone-counter-functionality-fix.patch
-zoned-vm-counters-per-zone-counter-functionality-fix-fix.patch
-zoned-vm-counters-include-per-zone-counters-in-proc-vmstat.patch
-zoned-vm-counters-conversion-of-nr_mapped-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_pagecache-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_pagecache-to-per-zone-counter-fix.patch
-zoned-vm-counters-use-per-zone-counters-to-remove-zone_reclaim_interval.patch
-zoned-vm-counters-add-per-zone-counters-to-zone-node-and-global-vm-statistics.patch
-zoned-vm-counters-conversion-of-nr_slab-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_pagetable-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_writeback-to-per-zone-counter.patch
-zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter.patch
-zoned-vm-counters-remove-unused-get_page_stat-functions.patch
-zoned-vm-counters-conversion-of-nr_bounce-to-per-zone-counter.patch
-zoned-vm-counters-remove-useless-writeback-structure.patch
-zoned-vm-stats-remove-nr_mapped-from-zone-reclaim.patch
-zoned-vm-stats-add-nr_anon.patch
-light-weight-counters-framework.patch
-light-weight-counters-framework-warning-fixes.patch
-light-weight-counters-framework-fix.patch
-light-weight-counters-framework-s390-fix.patch
-light-weight-counters-framework-s390-fix-fix.patch
-light-weight-counters-framework-s390-fix-fix-fix.patch
-light-weight-counters-framework-arm-fix.patch
-light-weight-counters-framework-uml-fix.patch

 Dropped.

+selinux-add-security-hooks-to-getsetaffinity.patch
+selinux-add-security-hook-call-to-mediate-attach_task.patch

 Wire up SELinux hooks.

+frv-__user-infrastructure.patch
+frv-basic-__iomem-annotations.patch
+frv-signal-annotations.patch
+frv-sysctl-__user-annotations.patch
+frv-binfmt_elf_fdpic-__user-annotations.patch
+frv-misc-__user-annotations.patch
+frv-misc-sparse-annotations.patch
+frv-wrong-syscall.patch
+ext2-xip-wont-build-without-mmu.patch
+frv-initrd-is-grossly-broken-on-frv-never-built.patch
+frv-null-noise-removal-in-frv-xchg.patch
+frv-ieee1394-is-borken-on-frv.patch
+frv-add-missing-qualifier-to-memcpy_fromio-prototype.patch
+frv-trivial-cleanups-in-frv_ksymsc.patch
+frv-clean-frv-unistdh.patch

 FRV updates

+i386-use-c-code-for-current_thread_info.patch
+i386-extra-checks-in-show_registers.patch
+via-c7-cpu-flags.patch
+x86-compile-fix-for-asm-i386-alternativesh.patch
+clean-up-and-refactor-i386-sub-architecture-setup.patch

 x86 updates

+move-do_suspend_lowlevel-to-correct-segment.patch

 suspend fix

+m68k-typo-fix.patch
+m68k-trapsc-constraints.patch
+m68k-windfarm-is-powerpc-only-dont-do-it-on-m68k-macs.patch

 m68k updates

+s390-move-var-declarations-behind-ifdef.patch

 s390 fix

+ufs-missed-brelse-and-wrong-baseblk.patch
+ufs-one-way-to-access-super-block.patch
+ufs-fsync-implementation.patch
+ufs-make-fsck-f-happy.patch
+ufs-ubh_ll_rw_block-cleanup.patch

 More ufs fixes

+readahead-backoff-on-i-o-error.patch
+readahead-backoff-on-i-o-error-tweaks.patch
+rcu-documentation-self-limiting-updates-and-call_rcu.patch
+link-error-when-futexes-are-disabled-on-64bit-architectures.patch
+cyclades-cleanup.patch
+cyclades-cleanup-cleanup.patch
+cleanup-char-espc.patch
+autofs4-need-to-invalidate-children-on-tree-mount-expire.patch
+update-contact-information-in-credits.patch
+more-tty-cleanups-in-drivers-char.patch
+another-couple-of-alterations-to-the-memory-barrier-doc.patch
+fuse-use-misc_major.patch
+fuse-no-backgrounding-on-interrupt.patch
+fuse-add-control-filesystem.patch
+fuse-add-control-filesystem-printk-fix.patch
+fuse-add-posix-file-locking-support.patch
+fuse-ensure-flush-reaches-userspace.patch
+fuse-rename-the-interrupted-flag.patch
+fuse-add-request-interruption.patch
+mark-profile-notifier-blocks-__read_mostly.patch
+kernel-doc-warn-on-malformed-function-docs.patch
+ide-floppy-fix-debug-only-syntax-error.patch
+remove-needless-checks-in-fs-9p-vfs_inodec.patch
+kernel-doc-for-lib-bitmapc.patch
+kernel-doc-for-lib-cmdlinec.patch
+kernel-doc-for-lib-crcc.patch
+kthread-update-loopc-to-use-kthread.patch
+kthread-update-loopc-to-use-kthread-fix.patch
+kthread-convert-lock-to-use-kthread.patch
+kthread-convert-smbiod.patch
+kthread-convert-smbiod-tidy.patch
+kthread-convert-s390machc-from-kernel_thread.patch
+initramfs-docs-update.patch
+cciss-disable-device-when-returning-failure.patch
+cciss-request-all-pci-resources.patch
+cciss-announce-cciss%d-devices-with-pci-address-irq-dac-info.patch
+cciss-use-array_size-without-intermediates.patch
+cciss-fix-a-few-spelling-errors.patch
+cciss-remove-parens-around-return-values.patch
+cciss-run-through-lindent.patch
+cciss-tidy-up-product-table-indentation.patch
+i-force-joystick-remove-some-pointless-casts.patch
+affs_fill_super-%s-abuses-2.patch
+kthread-convert-stop_machine-into-a-kthread.patch
+fs-sys_poll-with-timeout-1-bug-fix.patch
+cpu-hotplug-fix-cpu_up_cancel-handling.patch
+add-select-gpio_vr41xx-for-tanbac_tb0229.patch
+#let-even-non-dumpable-tasks-access-proc-self-fd.patch
+#enable-oprofile-on-pentium-d.patch: Andi had issues
+enable-oprofile-on-pentium-d.patch
+implement-at_symlink_follow-flag-for-linkat.patch
+fix-memory-leak-in-rocketport-rp_do_receive.patch
+kernel-doc-dont-use-xml-escapes-in-text-or-man-output.patch
+kernel-doc-use-members-for-struct-fields-consistently.patch
+reed-solomon-fix-kernel-doc-comments.patch
+ktime-hrtimer-fix-kernel-doc-comments.patch
+stop-on-cpu-lost.patch
+stop-on-cpu-lost-tidy.patch
+led-add-led-heartbeat-trigger.patch
+fix-bounds-check-in-vsnprintf-to-allow-for-a-0-size-and.patch
+fix-bounds-check-in-vsnprintf-to-allow-for-a-0-size-and-tidy.patch
+implement-kasprintf.patch
+dmi-cleanup-kernel-doc-add-to-docbook.patch
+kthread-move-kernel-doc-and-put-it-into-docbook.patch
+irda-usb-printk-fix.patch
+autofs4-needs-to-force-fail-return-revalidate.patch

 Misc patches.

+keys-sort-out-key-quota-system.patch
+keys-discard-the-contents-of-a-key-on-revocation.patch
+keys-let-keyctl_chown-change-a-keys-owner.patch
+keys-allocate-key-serial-numbers-randomly.patch
+keys-restrict-contents-of-proc-keys-to-viewable-keys.patch
+keys-add-a-way-to-store-the-appropriate-context-for-newly-created-keys.patch

 Key management API updates

+reiserfs-remove-reiserfs_aio_write.patch
+reiserfs-fix-is_reusable-bitmap-check-to-not-traverse-the-bitmap-info-array.patch
+reiserfs-clean-up-bitmap-block-buffer-head-references.patch
+reiserfs-reorganize-bitmap-loading-functions.patch
+reiserfs-on-demand-bitmap-loading.patch
+reiserfs-on-demand-bitmap-loading-fix.patch
+reiserfs-use-generic_file_open-for-open-checks.patch

 reiser3 updates

+per-task-delay-accounting-taskstats-interface-fix-exit-race-in-per-task-delay-accounting.patch

 per-task delay accounting fix

+add-bcm43xx-hw-rng-support-locking-update.patch

 Fix add-bcm43xx-hw-rng-support.patch

+chardev-gpio-for-scx200-pc-8736x-whitespace.patch
+chardev-gpio-for-scx200-pc-8736x-modernize.patch
+chardev-gpio-for-scx200-pc-8736x-add-platforn_device.patch
+chardev-gpio-for-scx200-pc-8736x-device-minor.patch
+chardev-gpio-for-scx200-pc-8736x-put-gpio_dump.patch
+chardev-gpio-for-scx200-pc-8736x-add-v-command.patch
+chardev-gpio-for-scx200-pc-8736x-refactor-scx200_probe.patch
+chardev-gpio-for-scx200-pc-8736x-add-gpio-ops.patch
+chardev-gpio-for-scx200-pc-8736x-dispatch.patch
+chardev-gpio-for-scx200-pc-8736x-add-empty.patch
+chardev-gpio-for-scx200-pc-8736x-migrate-file-ops.patch
+chardev-gpio-for-scx200-pc-8736x-migrate-gpio_dump.patch
+chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio.patch
+chardev-gpio-for-scx200-pc-8736x-add-platform_device.patch
+chardev-gpio-for-scx200-pc-8736x-use-dev_dbg.patch
+chardev-gpio-for-scx200-pc-8736x-fix-gpio_current.patch
+chardev-gpio-for-scx200-pc-8736x-replace-spinlocks.patch
+chardev-gpio-for-scx200-pc-8736x-display-pin.patch
+chardev-gpio-for-scx200-pc-8736x-add-proper.patch

 GPIO driver framework.

+isdn4linux-gigaset-base-driver-improve-error-recovery.patch
+isdn4linux-gigaset-driver-cleanup.patch
+i4l-gigaset-drivers-add-ioctls-to-compat_ioctlh.patch

 i4l driver updates

-mm-implement-swap-prefetching-fix.patch
-mm-implement-swap-prefetching-sched-batch.patch
-swap-prefetch-fix-lru_cache_add_tail.patch
-swap-prefetch-fix-lru_cache_add_tail-tidy.patch
-mm-swap-prefetch-fix-lowmem-reserve-calc.patch

 Folded into mm-implement-swap-prefetching.patch

-swap_prefetch-conversion-of-nr_mapped-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_slab-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_dirty-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_writeback-to-per-zone-counter.patch
-swap_prefetch-conversion-of-nr_unstable-to-per-zone-counter.patch
-swap_prefetch-remove-unused-get_page_stat-functions.patch
-zoned-vm-stats-nr_slab-is-accurate-fix-comment.patch
-swap_prefetch-zoned-vm-stats-add-nr_anon.patch

 Dropped.

+pi-futex-futex_lock_pi-futex_unlock_pi-support-fix.patch

 Fix pi-futex-futex_lock_pi-futex_unlock_pi-support.patch

+ecryptfs-dont-muck-with-the-existing-nameidata-structures.patch
+ecryptfs-asm-scatterlisth-linux-scatterlisth.patch
+ecryptfs-support-for-larger-maximum-key-size.patch
+ecryptfs-add-codes-for-additional-ciphers.patch
+ecryptfs-unencrypted-key-size-based-on-encrypted-key-size.patch
+ecryptfs-packet-and-key-management-update-for-variable-key-size.patch
+ecryptfs-add-ecryptfs_-prefix-to-mount-options-key-size-parameter.patch
+ecryptfs-set-the-key-size-from-the-default-for-the-mount.patch
+ecryptfs-check-for-weak-keys.patch
+ecryptfs-add-define-values-for-cipher-codes-from-rfc2440-openpgp.patch
+ecryptfs-convert-bits-to-bytes.patch
+ecryptfs-more-elegant-aes-key-size-manipulation.patch
+ecryptfs-more-elegant-aes-key-size-manipulation-tidy.patch
+ecryptfs-more-intelligent-use-of-tfm-objects.patch

 ecryptfs updates

+ipc-namespace-core-unshare-fix.patch
+ipc-namespace-utils-compilation-fix.patch

 Update IPC namespace patches in -mm.

+task-watchers-task-watchers.patch
+task-watchers-task-watchers-tidy.patch
+task-watchers-register-process-events-task-watcher.patch
+task-watchers-refactor-process-events.patch
+task-watchers-make-process-events-configurable-as.patch
+task-watchers-allow-task-watchers-to-block.patch
+task-watchers-register-audit-task-watcher.patch
+task-watchers-register-per-task-delay-accounting.patch
+task-watchers-register-profile-as-a-task-watcher.patch
+task-watchers-add-support-for-per-task-watchers.patch
+task-watchers-add-support-for-per-task-watchers-warning-fix.patch
+task-watchers-register-semundo-task-watcher.patch
+task-watchers-register-per-task-semundo-watcher.patch

 API for registering against task lifecycle events.

+ipc-replace-kmalloc-and-memset-in-get_undo_list-with-kzalloc.patch

 Cleanup

-readahead-backoff-on-i-o-error.patch

 Dropped.

-reiser4-conversion-of-nr_dirty-to-per-zone-counter.patch

 Dropped.

+hpt370-clean-up-dma-timeout-handling.patch
+hpt370-clean-up-dma-timeout-handling-cleanup.patch
+pdc202xx_old-depends-on-config_blk_dev_idedma.patch
+remove-code-that-has-long-been-commented-out-from-pdc20265_old.patch
+enable-cdrom-dma-access-with-pdc20265_old.patch
+ide-fix-revision-comparison-in-ide_in_drive_list.patch

 IDE updates

+fbdev-fix-logo-rotation-if-width-=-height.patch
+macmodes-fix-section-warning.patch
+atyfb-fix-section-warnings.patch

 fbdev updates

-vt-binding-add-sysfs-support.patch

 Dropped.

+vt-binding-add-sysfs-control-to-the-vt-layer.patch
+vt-binding-add-sysfs-control-to-the-vt-layer-fix.patch
+vt-binding-make-vt-binding-a-kconfig-option.patch
+vt-binding-do-not-create-a-device-file-for-class-device.patch
+vt-binding-update-documentation.patch
+vt-binding-make-mdacon-support-binding.patch
+vt-binding-make-newport_con-support-binding.patch
+vt-binding-make-promcon-support-binding.patch
+vt-binding-make-sticon-support-binding.patch

 VT binding updates

+statistics-infrastructure-update-4.patch
+statistics-infrastructure-update-5.patch

 Update statistics patches in -mm.

+genirq-rename-desc-handler-to-desc-chip-terminate_irqs-fix.patch
+genirq-allow-usage-of-no_irq_chip.patch
+genirq-ia64-build-fix.patch

 genirq fixes

+lock-validator-core-provide-lockdep_off-lockdep_on-apis.patch
+lock-validator-core-provide-lockdep_reinit_key-api.patch
+lock-validator-core-print-info-not-bug.patch
+lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type.patch
+lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type-fix.patch
+lock-validator-annotate-ntfs-locking-rules.patch
+lock-validator-s390-stacktrace-interface.patch
+lock-validator-s390-config_frame_pointer-support.patch
+lock-validator-s390-rwsem-semaphore-changes.patch
+lock-validator-early_init_irq_lock_type--console_init.patch
+lock-validator-s390-irqtrace-support.patch
+lock-validator-__local_bh_enable-_local_bh_enable.patch
+lock-validator-s390-use-raw_spinlock-in-mcck-handler.patch
+lock-validator-add-s390-to-supported-options.patch
+lockdep-avoid-false-positive-illegal-lock-usage-message-in-qeth-driver.patch
+lockdep-hack-around-build-errors.patch

 lockdep fixes

-acpi-identify-which-device-is-not-power-manageable-fix.patch

 Folded into acpi-identify-which-device-is-not-power-manageable.patch



All 1738 patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi,

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>
>
> - powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
>   startup and some later patch is causing a big crash (I didn't bisect that
>   one - later).
>
> - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
>   toolchain might be implicated).
>

I have the similar problem here

usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
or directory
usr/klibc/syscalls/typesize.c:5: error: '__u32' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:9: error: expected ')' before 'gid_t'
usr/klibc/syscalls/typesize.c:9: warning: type defaults to 'int' in
declaration of 'type name'
usr/klibc/syscalls/typesize.c:10: error: expected ')' before 'sigset_t'
usr/klibc/syscalls/typesize.c:10: warning: type defaults to 'int' in
declaration of 'type name'
usr/klibc/syscalls/typesize.c:21: error: 'dev_t' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:22: error: 'fd_set' undeclared here (not
in a function)
usr/klibc/syscalls/typesize.c:22: error: expected expression before ')' token
make[4]: *** [usr/klibc/syscalls/typesize.o] Error 1
make[3]: *** [usr/klibc/syscalls] Error 2
make[2]: *** [_usr_klibc] Error 2
make[1]: *** [usr] Error 2
make: *** [_all] Error 2

Linux ltg01-fedora.pl 2.6.17-g25f42b6a #63 SMP PREEMPT Tue Jun 20
14:28:14 CEST 2006 i686 i686 i386 GNU/Linux

Gnu C                  4.1.1
Gnu make               3.80
binutils               2.16.91.0.6
util-linux             2.13-pre7
mount                  2.13-pre7
module-init-tools      3.2.2
e2fsprogs              1.38
jfsutils               1.1.10
reiserfsprogs          3.6.19
xfsprogs               2.7.3
PPP                    2.4.3
Linux C Library        > libc.2.4
Dynamic linker (ldd)   2.4
Procps                 3.2.6
Net-tools              1.60
Kbd                    1.12
Sh-utils               5.96
udev                   084

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Andrew Morton]

On Wed, 21 Jun 2006 13:07:41 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
> >
> > - powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
> >   startup and some later patch is causing a big crash (I didn't bisect that
> >   one - later).
> >
> > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> >   toolchain might be implicated).
> >
> 
> I have the similar problem here
> 
> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> or directory

That one's probably just a parallel kbuild race.  Type `make' again.

Re: 2.6.17-mm1

[Michal Piotrowski]

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> On Wed, 21 Jun 2006 13:07:41 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> > >
> > >
> > > - powerpc is bust (on g5, at least).  git-klibc is causing nash to fail on
> > >   startup and some later patch is causing a big crash (I didn't bisect that
> > >   one - later).
> > >
> > > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> > >   toolchain might be implicated).
> > >
> >
> > I have the similar problem here
> >
> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> > or directory
>
> That one's probably just a parallel kbuild race.  Type `make' again.
>

"make O=/dir" is culprit.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Cedric Le Goater]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Michal Piotrowski wrote:

>> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
>> > or directory
>>
>> That one's probably just a parallel kbuild race.  Type `make' again.
>>
> 
> "make O=/dir" is culprit.
> 
> Regards,
> Michal
> 

That's how i fixed it. Is that the right way to do it ?

Thanks,

C.


[-- Attachment #2: klibc-fix-kbuild-output-issue.patch --]
[-- Type: text/x-patch, Size: 917 bytes --]

From: Cedric Le Goater <clg@fr.ibm.com>
Subject: [KLIBC] fix compile issue when KBUILD_OUTPUT is used

Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>

---
 scripts/Kbuild.klibc |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: 2.6.17-mm1/scripts/Kbuild.klibc
===================================================================
--- 2.6.17-mm1.orig/scripts/Kbuild.klibc
+++ 2.6.17-mm1/scripts/Kbuild.klibc
@@ -85,7 +85,7 @@ KLIBCCPPFLAGS    := -I$(KLIBCINC)/arch/$
 # kernel include paths
 KLIBCKERNELSRC	 ?= $(srctree)/
 KLIBCCPPFLAGS    += -I$(KLIBCKERNELSRC)include		\
-                     $(if $(KBUILD_SRC),-I$(KLIBCKERNELOBJ)include2 -I$(KLIBCKERNELOBJ)include -I$(srctree)/include)    \
+                     $(if $(KBUILD_SRC),-I$(KLIBCKERNELOBJ)include2 -I$(KLIBCKERNELOBJ)include -I$(srctree)/include -I$(srctree)/usr/klibc/syscalls)    \
 		     $(KLIBCARCHINCFLAGS)
 
 # klibc definitions

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi Cedric,

On 21/06/06, Cedric Le Goater <clg@fr.ibm.com> wrote:
> Michal Piotrowski wrote:
>
> >> > usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> >> > or directory
> >>
> >> That one's probably just a parallel kbuild race.  Type `make' again.
> >>
> >
> > "make O=/dir" is culprit.
> >
> > Regards,
> > Michal
> >
>
> That's how i fixed it.

Problem fixed, thanks.

> Is that the right way to do it ?
>
> Thanks,
>
> C.
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Cedric Le Goater wrote:
> Michal Piotrowski wrote:
> 
>>>> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
>>>> or directory
>>> That one's probably just a parallel kbuild race.  Type `make' again.
>>>
>> "make O=/dir" is culprit.
>>
>> Regards,
>> Michal
>>
> 
> That's how i fixed it. Is that the right way to do it ?
> 

Probably not.  I suspect what's needed is the same EXTRA_KLIBCCFLAGS as 
in socketcalls/Kbuild.

	-hpa

[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 424 bytes --]

diff --git a/usr/klibc/syscalls/Kbuild b/usr/klibc/syscalls/Kbuild
index debcd16..e7ae1d2 100644
--- a/usr/klibc/syscalls/Kbuild
+++ b/usr/klibc/syscalls/Kbuild
@@ -28,6 +28,8 @@ clean-files += $(KLIBCINC)/klibc/havesys
 # All the syscall stubs
 clean-files += *.o *.S *.c *.list *.bin
 
+EXTRA_KLIBCCFLAGS := -I$(srctree)/$(src)
+
 quiet_cmd_makelist = LIST    $@
       cmd_makelist = echo '$(filter-out FORCE,$^)' > $@
 

Re: 2.6.17-mm1

[Cedric Le Goater]

H. Peter Anvin wrote:

>> That's how i fixed it. Is that the right way to do it ?
> 
> Probably not.  I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
> in socketcalls/Kbuild.

it works fine.

thanks !

C.

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi Peter,

On 21/06/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Cedric Le Goater wrote:
> > Michal Piotrowski wrote:
> >
> >>>> usr/klibc/syscalls/typesize.c:1:23: error: syscommon.h: No such file
> >>>> or directory
> >>> That one's probably just a parallel kbuild race.  Type `make' again.
> >>>
> >> "make O=/dir" is culprit.
> >>
> >> Regards,
> >> Michal
> >>
> >
> > That's how i fixed it. Is that the right way to do it ?
> >
>
> Probably not.  I suspect what's needed is the same EXTRA_KLIBCCFLAGS as
> in socketcalls/Kbuild.

Thanks for fixing that.

>
>         -hpa
>
>

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Andrew Morton]

On Wed, 21 Jun 2006 03:48:57 -0700
Andrew Morton <akpm@osdl.org> wrote:

> - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
>   toolchain might be implicated).

Actually I did do a full ia64 allmodconfig build on a recent distro.  So
it's "broken on RHAS 2.1".

Re: 2.6.17-mm1

[Christoph Lameter]

On Wed, 21 Jun 2006, Andrew Morton wrote:

> On Wed, 21 Jun 2006 03:48:57 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> > - ia64 doesn't compile for me, due to git-klibc problems (a truly ancient
> >   toolchain might be implicated).
> 
> Actually I did do a full ia64 allmodconfig build on a recent distro.  So
> it's "broken on RHAS 2.1".

Builds fine on SLES9.

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi,

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>

It looks like an ACPI problem.

Setting up standard PCI resources
=============================================
[ INFO: possible recursive locking detected ]
---------------------------------------------
idle/1 is trying to acquire lock:
 (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa

but task is already holding lock:
 (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa

other info that might help us debug this:
1 lock held by idle/1:
 #0:  (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa

stack backtrace:
 [<c0103e89>] show_trace+0xd/0x10
 [<c0104483>] dump_stack+0x19/0x1b
 [<c01395fa>] __lock_acquire+0x7d9/0xa50
 [<c0139a98>] lock_acquire+0x71/0x91
 [<c02f0beb>] _spin_lock_irqsave+0x2c/0x3c
 [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
 [<c0222d95>] acpi_ev_gpe_detect+0x4d/0x10e
 [<c02215c3>] acpi_ev_sci_xrupt_handler+0x15/0x1d
 [<c021c8b1>] acpi_irq+0xe/0x18
 [<c014d36e>] request_irq+0xbe/0x10c
 [<c021cf33>] acpi_os_install_interrupt_handler+0x59/0x87
 [<c02215e7>] acpi_ev_install_sci_handler+0x1c/0x21
 [<c0220d41>] acpi_ev_install_xrupt_handlers+0x9/0x50
 [<c0231772>] acpi_enable_subsystem+0x7d/0x9a
 [<c0416656>] acpi_init+0x3f/0x170
 [<c01003ae>] _stext+0x116/0x26c
 [<c0101005>] kernel_thread_helper+0x5/0xb
ACPI: Interpreter enabled

Here is a dmesg log http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-dmesg
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Franck Bui-Huu]

Andrew,

Andrew Morton wrote:
> 
> 
> All 1738 patches:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list
> 

Is the following patch really needed ?

flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch

"""
The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0.  If we initialise node 0 to start at any other offset we
will incorrectly map pfn's to the wrong struct page *.  The key to the
memory model is the contigious nature of the memory not the location of it.
Relax the requirement for the area to start at 0.
"""

Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
convertions work when node 0 start offset do not start at 0 ?

My physical memory start at 0x20000000. So node 0 starts at an offset
different from 0. I setup ARCH_PFN_OFFSET this way

	#define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)

Until now (2.6.17), it works well, but this patch breaks my machine.

If you need more details about my memory mapping, feel free to ask.

Thanks

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On Thu, 22 Jun 2006, Franck Bui-Huu wrote:

> Andrew,
>
> Andrew Morton wrote:
>>
>>
>> All 1738 patches:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/patch-list
>>
>
> Is the following patch really needed ?
>
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch
>
> """
> The FLATMEM memory model assumes that memory is in one contigious area
> based at pfn 0.  If we initialise node 0 to start at any other offset we
> will incorrectly map pfn's to the wrong struct page *.  The key to the
> memory model is the contigious nature of the memory not the location of it.
> Relax the requirement for the area to start at 0.
> """
>
> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> convertions work when node 0 start offset do not start at 0 ?
>

What happens if you have ARCH_PFN_OFFSET as

#define ARCH_PFN_OFFSET (0UL)

?

What arch is this?

> My physical memory start at 0x20000000. So node 0 starts at an offset
> different from 0. I setup ARCH_PFN_OFFSET this way
>
> 	#define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)
>

If physical memory starts at 0x20000000, why is the PFN not
0x20000000 >> PAGE_SHIFT ?

> Until now (2.6.17), it works well, but this patch breaks my machine.
>
> If you need more details about my memory mapping, feel free to ask.
>
> Thanks
>
> 		Franck
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>
>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
>> convertions work when node 0 start offset do not start at 0 ?
>>
> 
> What happens if you have ARCH_PFN_OFFSET as
> 
> #define ARCH_PFN_OFFSET (0UL)
> 
> ?

It's the default value (see memory_model.h). It means that pfn start
for node 0 is 0, therefore your physical memory address starts at 0.

> 
> What arch is this?
> 

well I'm working on MIPS, but you can take a look at ARM that does the
same thing better...

>> My physical memory start at 0x20000000. So node 0 starts at an offset
>> different from 0. I setup ARCH_PFN_OFFSET this way
>>
>>     #define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)
>>
> 
> If physical memory starts at 0x20000000, why is the PFN not
> 0x20000000 >> PAGE_SHIFT ?
> 

It is a typo... 

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On Thu, 22 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:
>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>>
>>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
>>> convertions work when node 0 start offset do not start at 0 ?
>>>
>>
>> What happens if you have ARCH_PFN_OFFSET as
>>
>> #define ARCH_PFN_OFFSET (0UL)
>>
>> ?
>
> It's the default value (see memory_model.h). It means that pfn start
> for node 0 is 0, therefore your physical memory address starts at 0.
>

I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary 
with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied. 
ARCH_PFN_OFFSET is used as

#define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
                                  ARCH_PFN_OFFSET)

because it knew that the map may not start at PFN 0. With 
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will 
start at PFN 0 even if physical memory does not start until later.

>>
>> What arch is this?
>>
>
> well I'm working on MIPS, but you can take a look at ARM that does the
> same thing better...
>
>>> My physical memory start at 0x20000000. So node 0 starts at an offset
>>> different from 0. I setup ARCH_PFN_OFFSET this way
>>>
>>>     #define ARCH_PFN_OFFSET    (0x20000000 << PAGE_SHIFT)
>>>
>>
>> If physical memory starts at 0x20000000, why is the PFN not
>> 0x20000000 >> PAGE_SHIFT ?
>>
>
> It is a typo...
>

ok

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Russell King]

On Thu, Jun 22, 2006 at 04:54:06PM +0100, Mel Gorman wrote:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >It's the default value (see memory_model.h). It means that pfn start
> >for node 0 is 0, therefore your physical memory address starts at 0.
> 
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary 
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied. 
> ARCH_PFN_OFFSET is used as
> 
> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>                                  ARCH_PFN_OFFSET)
> 
> because it knew that the map may not start at PFN 0. With 
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will 
> start at PFN 0 even if physical memory does not start until later.

Doesn't that result in a massive array of struct pages if your memory
starts a 3GB physical and has 4K pages?  If you have only 32MB in that
scenario, and that was correct, you'd gobble 25MB of that just to
store that array.  Ouch.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: 2.6.17-mm1

[Mel Gorman]

On Thu, 22 Jun 2006, Russell King wrote:

> On Thu, Jun 22, 2006 at 04:54:06PM +0100, Mel Gorman wrote:
>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>>> It's the default value (see memory_model.h). It means that pfn start
>>> for node 0 is 0, therefore your physical memory address starts at 0.
>>
>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>> ARCH_PFN_OFFSET is used as
>>
>> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>>                                  ARCH_PFN_OFFSET)
>>
>> because it knew that the map may not start at PFN 0. With
>> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
>> start at PFN 0 even if physical memory does not start until later.
>
> Doesn't that result in a massive array of struct pages if your memory
> starts a 3GB physical and has 4K pages?

No, I should have been clear. The size of the map remains the same but 
mem_map does not point directly to NODE_DATA(0)->node_mem_map when the PFN 
of node 0 is not 0. Instead mem_map points to

NODE_DATA(0)->node_mem_map - NODE_DATA(0)->node_start_pfn

The relevant bit of code is

 	map = alloc_remap(pgdat->node_id, size);
 	if (!map)
 		map = alloc_bootmem_node(pgdat, size);
 	pgdat->node_mem_map = map + (pgdat->node_start_pfn - start);

 	/*
 	 * With FLATMEM the global mem_map is used.  This is assumed
 	 * to be based at pfn 0 such that 'pfn = page* - mem_map'
 	 * is true. Adjust map relative to node_mem_map to
 	 * maintain this relationship.
 	 */
 	map -= pgdat->node_start_pfn;

and later

 	if (pgdat == NODE_DATA(0))
 		mem_map = map;

So memory is wasted and ARCH_PFN_OFFSET isn't needed in the case where it 
is working around NODE_DATA(0)->node_start_pfn != 0

> If you have only 32MB in that
> scenario, and that was correct, you'd gobble 25MB of that just to
> store that array.  Ouch.
>

It would be a kick in the shins all right if that was the case.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

2006/6/22, Mel Gorman <mel@csn.ul.ie>:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>
> > Mel Gorman wrote:
> >> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>
> >>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>> convertions work when node 0 start offset do not start at 0 ?
> >>>
> >>
> >> What happens if you have ARCH_PFN_OFFSET as
> >>
> >> #define ARCH_PFN_OFFSET (0UL)
> >>
> >> ?
> >
> > It's the default value (see memory_model.h). It means that pfn start
> > for node 0 is 0, therefore your physical memory address starts at 0.
> >
>
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.

yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
has been sent. So your patch seems to be incomplete...

> ARCH_PFN_OFFSET is used as
>
> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>                                   ARCH_PFN_OFFSET)
>
> because it knew that the map may not start at PFN 0. With
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> start at PFN 0 even if physical memory does not start until later.
>

well your approach's trick is on the mem_map address whereas
ARCH_PFN_OFFSET's one is on the computation of the index. Your
solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
because in your case page/pfn conversion is simpler.

Maybe in your patch instead of doing:

        map -= pgdat->node_start_pfn;

you could do:

        map -= ARCH_OFFSET_PFN;

-- 
               Franck

Re: 2.6.17-mm1

[Mel Gorman]

On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> 2006/6/22, Mel Gorman <mel@csn.ul.ie>:
> >On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >
> >> Mel Gorman wrote:
> >>> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>>
> >>>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>>> convertions work when node 0 start offset do not start at 0 ?
> >>>>
> >>>
> >>> What happens if you have ARCH_PFN_OFFSET as
> >>>
> >>> #define ARCH_PFN_OFFSET (0UL)
> >>>
> >>> ?
> >>
> >> It's the default value (see memory_model.h). It means that pfn start
> >> for node 0 is 0, therefore your physical memory address starts at 0.
> >>
> >
> >I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> 
> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> has been sent. So your patch seems to be incomplete...

Difficult to argue with that logic.

> 
> >ARCH_PFN_OFFSET is used as
> >
> >#define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
> >                                  ARCH_PFN_OFFSET)
> >
> >because it knew that the map may not start at PFN 0. With
> >flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> >start at PFN 0 even if physical memory does not start until later.
> >
> 
> well your approach's trick is on the mem_map address whereas
> ARCH_PFN_OFFSET's one is on the computation of the index. Your
> solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
> because in your case page/pfn conversion is simpler.
> 
> Maybe in your patch instead of doing:
> 
>        map -= pgdat->node_start_pfn;
> 
> you could do:
> 
>        map -= ARCH_OFFSET_PFN;
> 

That will assume that ARCH_OFFSET_PFN is always equal to
NODE_DATA(0)->node_start_pfn which may cause other breakage further down
the line. How about something like this? (boot tested on x86 only)


>>> Begin patch

The FLATMEM memory model assumes that memory is
on contiguous area starting from PFN 0.  The patch
flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch relaxed
this assumption by offsetting mem_map from NODE_DATA(0)->node_mem_map
by NODE_DATA(0)->node_start_pfn. However, some architectures are using
ARCH_OFFSET_PFN to do a similar job at a runtime cost which causes the map
to get offset twice.

This patch catches the situation where ARCH_OFFSET_PFN was being used to
workaround NODE_DATA(0)->node_start_pfn != 0 and prints a message letting
the arch maintainer know that ARCH_OFFSET_PFN may be safe to remove.
Once the message appears on no architectures, it may be safe to remove
ARCH_OFFSET_PFN totally.

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h	2006-06-23 10:44:18.000000000 +0100
@@ -28,9 +28,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/mm/page_alloc.c linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm1-clean/mm/page_alloc.c	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c	2006-06-23 10:49:01.000000000 +0100
@@ -2316,7 +2316,22 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		if (ARCH_PFN_OFFSET == 0)
+			map -= pgdat->node_start_pfn;
+		else {
+			/*
+			 * If ARCH_PFN_OFFSET is being used to to workaround
+			 * old assumptions of the FLATMEM memory model, print
+			 * a message so that ARCH_PFN_OFFSET can be safely
+			 * removed. If there are no remaining users of
+			 * ARCH_PFN_OFFSET after this message no longer
+			 * shows up, it'll be safe to remove this else block
+			 */
+			if (ARCH_PFN_OFFSET == pgdat->node_start_pfn)
+				printk("ARCH_PFN_OFFSET not necessary\n");
+
+			map -= ARCH_PFN_OFFSET;
+		}
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>
>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>> has been sent. So your patch seems to be incomplete...
> 
> Difficult to argue with that logic.
> 

sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
solve this before your patch has been sent. So the requirement for
memory to start at pfn 0 is already solved.

Your patch solves the problem in a different way, but it's
incompatible with the current one (ARCH_PFN_OFFSET).

IMHO the question is now, which method is the best one ? If it's yours
the we probably need to get ride of the previous method and add yours
(but don't forget to modify arch such ARM which are currently using
ARCH_PFN_OFFSET).

		Franck

Re: 2.6.17-mm1

[Franck Bui-Huu]

Franck Bui-Huu wrote:
> Mel Gorman wrote:
>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>> has been sent. So your patch seems to be incomplete...
>> Difficult to argue with that logic.
>>
> 
> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> solve this before your patch has been sent. So the requirement for
> memory to start at pfn 0 is already solved.
> 
> Your patch solves the problem in a different way, but it's
> incompatible with the current one (ARCH_PFN_OFFSET).
> 
> IMHO the question is now, which method is the best one ? If it's yours
> the we probably need to get ride of the previous method and add yours
> (but don't forget to modify arch such ARM which are currently using
> ARCH_PFN_OFFSET).
> 

maybe these figures can help to make our choice:

   text    data     bss     dec     hex filename
2226384  223824  110624 2560832  271340 vmlinux-arch-pfn-offset-0
2228488  223824  110624 2562936  271b78 vmlinux-arch-pfn-offset-not-0
2226964  223856  110624 2561444  2715a4 vmlinux-out-of-line-pfn-to-page

Arch is MIPS and I used gcc 3.4.4

So your solution gives the smallest kernel with my config although the win
is only 0.1%. Maybe it would be good to have ARM figures/opinion too.

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> >>>>
> >>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> >> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> >> has been sent. So your patch seems to be incomplete...
> > 
> > Difficult to argue with that logic.
> > 
> 
> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> solve this before your patch has been sent. So the requirement for
> memory to start at pfn 0 is already solved.
> 

In that case, the patch is as simple as you suggested earlier (patch
below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
bit of an obscure #define if you ask me. The obscurity can be lived with of
course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.

> IMHO the question is now, which method is the best one ?

My method should very slightly reduce the size of the kernel and have a
very minor performance improvement. How measurable it is depends on how
often page_to_pfn and pfn_to_page are called.

> the we probably need to get ride of the previous method and add yours
> (but don't forget to modify arch such ARM which are currently using
> ARCH_PFN_OFFSET).
> 

If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm1-clean/include/asm-generic/memory_model.h	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/include/asm-generic/memory_model.h	2006-06-23 10:44:18.000000000 +0100
@@ -28,9 +28,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm1-clean/mm/page_alloc.c linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm1-clean/mm/page_alloc.c	2006-06-23 09:26:15.000000000 +0100
+++ linux-2.6.17-mm1-archpfnfix/mm/page_alloc.c	2006-06-23 14:00:11.000000000 +0100
@@ -2316,7 +2316,7 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		map -= ARCH_PFN_OFFSET;
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
> 
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> 

yes with the patch below it seems useless. But it's also a good way
for all arch to use the same name for defining the start of the
memory.

>> IMHO the question is now, which method is the best one ?
> 
> My method should very slightly reduce the size of the kernel and have a
> very minor performance improvement. How measurable it is depends on how
> often page_to_pfn and pfn_to_page are called.
> 
>> the we probably need to get ride of the previous method and add yours
>> (but don't forget to modify arch such ARM which are currently using
>> ARCH_PFN_OFFSET).
>>
> 
> If we decide to simply hold onto ARCH_PFN_OFFSET, the fix is simply;

here is the patch I'm using, which is mainly yours.

-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0

The FLATMEM memory model assumes that memory is in one contigious area
based at pfn 0. Some archictectures, like ARM, use ARCH_PFN_OFFSET to
relax this requirement. This involves one more operation during
page/pfn conversions.

Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
This results in a slight gain on kernel code size.

---
 include/asm-generic/memory_model.h |    6 +++---
 mm/page_alloc.c                    |   15 +++++++++++----
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
  */
 #if defined(CONFIG_FLATMEM)
 
-#define pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define pfn_to_page(pfn)	(mem_map + (pfn))
+#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
+
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define pfn_to_page(pfn)			\
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..ed6a40f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
 
 static void __init alloc_node_mem_map(struct pglist_data *pgdat)
 {
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+	struct page *map = pgdat->node_mem_map;
+
 	/* Skip empty nodes */
 	if (!pgdat->node_spanned_pages)
 		return;
 
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
 	/* ia64 gets its own node_mem_map, before this, without bootmem */
-	if (!pgdat->node_mem_map) {
+	if (!map) {
 		unsigned long size, start, end;
-		struct page *map;
 
 		/*
 		 * The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
 	 * With no DISCONTIG, the global mem_map is just set as node 0's
 	 */
 	if (pgdat == NODE_DATA(0))
-		mem_map = NODE_DATA(0)->node_mem_map;
+		/*
+		 * mem_map is assumed to be based at pfn 0 such that
+		 * 'pfn = page* - mem_map' is true. Adjust map
+		 * relative to node_mem_map to maintain this
+		 * relationship.
+		 */
+		mem_map = map - ARCH_PFN_OFFSET;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
-- 
1.4.0.g64e8

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
>> Mel Gorman wrote:
>>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
>>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
>>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
>>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
>>>> has been sent. So your patch seems to be incomplete...
>>> Difficult to argue with that logic.
>>>
>> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
>> solve this before your patch has been sent. So the requirement for
>> memory to start at pfn 0 is already solved.
>>
> 
> In that case, the patch is as simple as you suggested earlier (patch
> below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> bit of an obscure #define if you ask me. The obscurity can be lived with of
> course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> 

what do you think about this use of ARCH_PFN_OFFSET ?

diff --git a/mm/bootmem.c b/mm/bootmem.c
index d213fed..fd28eed 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
 	return(free_all_bootmem_core(pgdat));
 }
 
-unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
+unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
 {
 	max_low_pfn = pages;
 	min_low_pfn = start;
-	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
+	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
 }
 
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ed6a40f..43abaeb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
 		 * relative to node_mem_map to maintain this
 		 * relationship.
 		 */
-		mem_map = map - ARCH_PFN_OFFSET;
+		mem_map = map - pgdat->node_start_pfn;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
@@ -2181,8 +2181,7 @@ #endif
 
 void __init free_area_init(unsigned long *zones_size)
 {
-	free_area_init_node(0, NODE_DATA(0), zones_size,
-			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
+	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
 }
 
 #ifdef CONFIG_PROC_FS

Re: 2.6.17-mm1

[Mel Gorman]

On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On (23/06/06 14:22), Franck Bui-Huu didst pronounce:
> >> Mel Gorman wrote:
> >>> On (22/06/06 19:25), Franck Bui-Huu didst pronounce:
> >>>>> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> >>>>> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.
> >>>> yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
> >>>> has been sent. So your patch seems to be incomplete...
> >>> Difficult to argue with that logic.
> >>>
> >> sorry, I was just meaning that ARCH_PFN_OFFSET had been introduced to
> >> solve this before your patch has been sent. So the requirement for
> >> memory to start at pfn 0 is already solved.
> >>
> > 
> > In that case, the patch is as simple as you suggested earlier (patch
> > below). The only downside is that we hold onto ARCH_PFN_OFFSET which is a
> > bit of an obscure #define if you ask me. The obscurity can be lived with of
> > course, but it'd be nice to kick away ARCH_PFN_OFFSET if possible.
> > 
> 
> what do you think about this use of ARCH_PFN_OFFSET ?
> 

I believe that arches calling free_area_init_node() directly, but using
CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
guarantee that pgdat->node_start_pfn will have any relation to
ARCH_PFN_OFFSET. It is why in an earlier patch, I made a check for
ARCH_PFN_OFFSET == pgdat->node_start_pfn and only then printed a message
saying that ARCH_PFN_OFFSET was unnecessary.

> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
>  	return(free_all_bootmem_core(pgdat));
>  }
>  
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
>  {
>  	max_low_pfn = pages;
>  	min_low_pfn = start;
> -	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> +	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
>  }
>  
>  #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ed6a40f..43abaeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
>  		 * relative to node_mem_map to maintain this
>  		 * relationship.
>  		 */
> -		mem_map = map - ARCH_PFN_OFFSET;
> +		mem_map = map - pgdat->node_start_pfn;
>  #endif
>  #endif /* CONFIG_FLAT_NODE_MEM_MAP */
>  }
> @@ -2181,8 +2181,7 @@ #endif
>  
>  void __init free_area_init(unsigned long *zones_size)
>  {
> -	free_area_init_node(0, NODE_DATA(0), zones_size,
> -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> +	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
>  }
>  
>  #ifdef CONFIG_PROC_FS

-- 
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
>> what do you think about this use of ARCH_PFN_OFFSET ?
>>
> 
> I believe that arches calling free_area_init_node() directly, but using
> CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
> guarantee that pgdat->node_start_pfn will have any relation to
> ARCH_PFN_OFFSET. 

I agree we shouldn't make this assumption.

what about this ?

-- >8 --
[PATCH] flatmem: tiny optimisation when memory do not start at 0

The FLATMEM memory model assumes that memory is in one
contigious area based at pfn 0. Some archictectures, like
ARM, use ARCH_PFN_OFFSET to relax this requirement but it
involves one more operation during page/pfn conversion.

Instead this patch modifies the address of mem_map to make
mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
The result is a slight gain on kernel code size.

It also relaxes this requirement in two more places:
	free_area_init(...)
	init_bootmem(...)

---
 include/asm-generic/memory_model.h |    6 +++---
 mm/bootmem.c                       |    4 ++--
 mm/page_alloc.c                    |   18 ++++++++++++------
 3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
index 0cfb086..2faa12f 100644
--- a/include/asm-generic/memory_model.h
+++ b/include/asm-generic/memory_model.h
@@ -34,9 +34,9 @@ #else
  */
 #if defined(CONFIG_FLATMEM)
 
-#define pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define pfn_to_page(pfn)	(mem_map + (pfn))
+#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
+
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define pfn_to_page(pfn)			\
diff --git a/mm/bootmem.c b/mm/bootmem.c
index d213fed..fd28eed 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
 	return(free_all_bootmem_core(pgdat));
 }
 
-unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
+unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
 {
 	max_low_pfn = pages;
 	min_low_pfn = start;
-	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
+	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
 }
 
 #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 253a450..3e97bc3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
 
 static void __init alloc_node_mem_map(struct pglist_data *pgdat)
 {
+#ifdef CONFIG_FLAT_NODE_MEM_MAP
+	struct page *map = pgdat->node_mem_map;
+
 	/* Skip empty nodes */
 	if (!pgdat->node_spanned_pages)
 		return;
 
-#ifdef CONFIG_FLAT_NODE_MEM_MAP
 	/* ia64 gets its own node_mem_map, before this, without bootmem */
-	if (!pgdat->node_mem_map) {
+	if (!map) {
 		unsigned long size, start, end;
-		struct page *map;
 
 		/*
 		 * The zone's endpoints aren't required to be MAX_ORDER
@@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
 	 * With no DISCONTIG, the global mem_map is just set as node 0's
 	 */
 	if (pgdat == NODE_DATA(0))
-		mem_map = NODE_DATA(0)->node_mem_map;
+		/*
+		 * mem_map is assumed to be based at pfn 0 such that
+		 * 'pfn = page* - mem_map' is true. Adjust map
+		 * relative to node_mem_map to maintain this
+		 * relationship.
+		 */
+		mem_map = map - ARCH_PFN_OFFSET;
 #endif
 #endif /* CONFIG_FLAT_NODE_MEM_MAP */
 }
@@ -2174,8 +2181,7 @@ #endif
 
 void __init free_area_init(unsigned long *zones_size)
 {
-	free_area_init_node(0, NODE_DATA(0), zones_size,
-			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
+	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
 }
 
 #ifdef CONFIG_PROC_FS
-- 
1.4.0.g64e8

Re: 2.6.17-mm1

[Mel Gorman]

On Fri, 23 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:
>> On (23/06/06 17:06), Franck Bui-Huu didst pronounce:
>>> what do you think about this use of ARCH_PFN_OFFSET ?
>>>
>>
>> I believe that arches calling free_area_init_node() directly, but using
>> CONFIG_FLAT_NODE_MEM_MAP will have problems with this. There is no
>> guarantee that pgdat->node_start_pfn will have any relation to
>> ARCH_PFN_OFFSET.
>
> I agree we shouldn't make this assumption.
>
> what about this ?
>
> -- >8 --
> [PATCH] flatmem: tiny optimisation when memory do not start at 0
>
> The FLATMEM memory model assumes that memory is in one
> contigious area based at pfn 0. Some archictectures, like
> ARM, use ARCH_PFN_OFFSET to relax this requirement but it
> involves one more operation during page/pfn conversion.
>
> Instead this patch modifies the address of mem_map to make
> mem_map[ARCH_PFN_OFFSET] pointing at NODE_DATA(0)->node_mem_map.
> The result is a slight gain on kernel code size.
>
> It also relaxes this requirement in two more places:
> 	free_area_init(...)
> 	init_bootmem(...)
>
> ---
> include/asm-generic/memory_model.h |    6 +++---
> mm/bootmem.c                       |    4 ++--
> mm/page_alloc.c                    |   18 ++++++++++++------
> 3 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
> index 0cfb086..2faa12f 100644
> --- a/include/asm-generic/memory_model.h
> +++ b/include/asm-generic/memory_model.h
> @@ -34,9 +34,9 @@ #else
>  */
> #if defined(CONFIG_FLATMEM)
>
> -#define pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
> -#define page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
> -				 ARCH_PFN_OFFSET)
> +#define pfn_to_page(pfn)	(mem_map + (pfn))
> +#define page_to_pfn(page)	((unsigned long)((page) - mem_map))
> +
> #elif defined(CONFIG_DISCONTIGMEM)
>
> #define pfn_to_page(pfn)			\
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
> 	return(free_all_bootmem_core(pgdat));
> }
>
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
> {
> 	max_low_pfn = pages;
> 	min_low_pfn = start;
> -	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> +	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
> }
>

Not all arches will use init_bootmem(). Arm for example uses 
init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map, not 
any node attribute. I suspect (but don't know for a fact) that if we try 
and change node attributes with ARCH_PFN_OFFSET, we'll shoot ourselves in 
the foot.

> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 253a450..3e97bc3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2118,15 +2118,16 @@ static void __init free_area_init_core(s
>
> static void __init alloc_node_mem_map(struct pglist_data *pgdat)
> {
> +#ifdef CONFIG_FLAT_NODE_MEM_MAP
> +	struct page *map = pgdat->node_mem_map;
> +
> 	/* Skip empty nodes */
> 	if (!pgdat->node_spanned_pages)
> 		return;
>
> -#ifdef CONFIG_FLAT_NODE_MEM_MAP
> 	/* ia64 gets its own node_mem_map, before this, without bootmem */
> -	if (!pgdat->node_mem_map) {
> +	if (!map) {
> 		unsigned long size, start, end;
> -		struct page *map;
>
> 		/*
> 		 * The zone's endpoints aren't required to be MAX_ORDER
> @@ -2147,7 +2148,13 @@ #ifdef CONFIG_FLATMEM
> 	 * With no DISCONTIG, the global mem_map is just set as node 0's
> 	 */
> 	if (pgdat == NODE_DATA(0))
> -		mem_map = NODE_DATA(0)->node_mem_map;
> +		/*
> +		 * mem_map is assumed to be based at pfn 0 such that
> +		 * 'pfn = page* - mem_map' is true. Adjust map
> +		 * relative to node_mem_map to maintain this
> +		 * relationship.
> +		 */
> +		mem_map = map - ARCH_PFN_OFFSET;

This part is fine.

> #endif
> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
> }
> @@ -2174,8 +2181,7 @@ #endif
>
> void __init free_area_init(unsigned long *zones_size)
> {
> -	free_area_init_node(0, NODE_DATA(0), zones_size,
> -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> +	free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET, NULL);
> }
>

Same comment applies as for init_bootmem(). I can't be sure it's a good 
idea.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Hi Mel

Mel Gorman wrote:
> On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
> 

[snip]

>>
>> -unsigned long __init init_bootmem (unsigned long start, unsigned long
>> pages)
>> +unsigned long __init init_bootmem(unsigned long start, unsigned long
>> pages)
>> {
>>     max_low_pfn = pages;
>>     min_low_pfn = start;
>> -    return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
>> +    return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET,
>> pages);
>> }
>>
> 
> Not all arches will use init_bootmem(). Arm for example uses
> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,

well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
page number that has physical memory. I don't see why we couldn't use
it to correctly initialise the memory system...

If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
kernel will initialise the start of memory to 0 which is boggus. IOW,
we can't use this function without this change (except if your memory
start at 0 of course). And I think that init_bootmem() has been
implemented for systems which have only one node _whatever_ memory
start value...

>> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c

[snip]

>> @@ -2174,8 +2181,7 @@ #endif
>>
>> void __init free_area_init(unsigned long *zones_size)
>> {
>> -    free_area_init_node(0, NODE_DATA(0), zones_size,
>> -            __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>> +    free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET,
>> NULL);
>> }
>>
> 
> Same comment applies as for init_bootmem(). I can't be sure it's a good
> idea.
> 

same comment as for init_bootmem()


		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On Mon, 26 Jun 2006, Franck Bui-Huu wrote:

> Hi Mel
>
> Mel Gorman wrote:
>> On Fri, 23 Jun 2006, Franck Bui-Huu wrote:
>>
>
> [snip]
>
>>>
>>> -unsigned long __init init_bootmem (unsigned long start, unsigned long
>>> pages)
>>> +unsigned long __init init_bootmem(unsigned long start, unsigned long
>>> pages)
>>> {
>>>     max_low_pfn = pages;
>>>     min_low_pfn = start;
>>> -    return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
>>> +    return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET,
>>> pages);
>>> }
>>>
>>
>> Not all arches will use init_bootmem(). Arm for example uses
>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>
> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> page number that has physical memory. I don't see why we couldn't use
> it to correctly initialise the memory system...
>

Architectures will not always have a known fixed start of physical memory. 
On IA64 at least, they initialise memory as if it starts at 0 but on my 
one test machine, the beginning part is always a memory hole. I've seen 
nothing to indicate that this hole will be the same size on all IA64 
machines but I kinda doubt it. Also, arches that use init_bootmem() do not 
necessary use free_area_init().

> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
> kernel will initialise the start of memory to 0 which is boggus.
> IOW,
> we can't use this function without this change (except if your memory
> start at 0 of course). And I think that init_bootmem() has been
> implemented for systems which have only one node _whatever_ memory
> start value...
>

While you may be right, it'll only fix the problem for arches with 
ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I 
guess). But arches using init_bootmem_node or not using free_area_init() 
may still get kicked.

>>> #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>
> [snip]
>
>>> @@ -2174,8 +2181,7 @@ #endif
>>>
>>> void __init free_area_init(unsigned long *zones_size)
>>> {
>>> -    free_area_init_node(0, NODE_DATA(0), zones_size,
>>> -            __pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
>>> +    free_area_init_node(0, NODE_DATA(0), zones_size, ARCH_PFN_OFFSET,
>>> NULL);
>>> }
>>>
>>
>> Same comment applies as for init_bootmem(). I can't be sure it's a good
>> idea.
>>
>
> same comment as for init_bootmem()
>
>
> 		Franck
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> 
> Architectures will not always have a known fixed start of physical
> memory. On IA64 at least, they initialise memory as if it starts at 0
> but on my one test machine, the beginning part is always a memory hole.

in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
change...

> I've seen nothing to indicate that this hole will be the same size on
> all IA64 machines but I kinda doubt it. Also, arches that use
> init_bootmem() do not necessary use free_area_init().
> 

but in that case do they use ARCH_PFN_OFFSET != 0 ? if so that would be
very surprising. That would meand "I have a hole a the start of my mem,
I don't know at compile time where it starts, but I state that my physical
mem start at ARCH_PFN_OFFSET anyways"

>> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
>> kernel will initialise the start of memory to 0 which is boggus.
>> IOW,
>> we can't use this function without this change (except if your memory
>> start at 0 of course). And I think that init_bootmem() has been
>> implemented for systems which have only one node _whatever_ memory
>> start value...
>>
> 
> While you may be right, it'll only fix the problem for arches with
> ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
> guess). But arches using init_bootmem_node or not using free_area_init()
> may still get kicked.
> 

Again in these cases, I doubt that they will setup ARCH_PFN_OFFSET...

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On Mon, 26 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:

>>>> Not all arches will use init_bootmem(). Arm for example uses
>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>>>>
>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
>>> page number that has physical memory. I don't see why we couldn't 
>>> useit to correctly initialise the memory system...
>>
>> Architectures will not always have a known fixed start of physical
>> memory. On IA64 at least, they initialise memory as if it starts at 0
>> but on my one test machine, the beginning part is always a memory hole.
>
> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> change...
>

The change is that ARCH_PFN_OFFSET has a slightly different meaning when 
you alter those two initialisation functions. Currently it is used to 
offset memmap from NODE_DATA(0)->node_start_pfn. By changing 
free_area_init() and init_bootmem(), it changes to altering the value of 
NODE_DATA(0)->node_start_pfn but only when memory is initialised in a 
particular way. I believe it makes ARCH_PFN_OFFSET even more obscure than 
it currently is.

I think we should just fix the problem at hand now for which two simple 
patches have been posted and consider making further changes to 
free_area_init() and init_bootmem() as a separate issue.

>> I've seen nothing to indicate that this hole will be the same size on
>> all IA64 machines but I kinda doubt it. Also, arches that use
>> init_bootmem() do not necessary use free_area_init().
>>
>
> but in that case do they use ARCH_PFN_OFFSET != 0 ?

IA64 do not and I didn't check all arches.

> if so that would be
> very surprising. That would meand "I have a hole a the start of my mem,
> I don't know at compile time where it starts, but I state that my physical
> mem start at ARCH_PFN_OFFSET anyways"
>
>>> If we don't change init_bootmem() to use ARCH_PFN_OFFSET, then the
>>> kernel will initialise the start of memory to 0 which is boggus.
>>> IOW,
>>> we can't use this function without this change (except if your memory
>>> start at 0 of course). And I think that init_bootmem() has been
>>> implemented for systems which have only one node _whatever_ memory
>>> start value...
>>>
>>
>> While you may be right, it'll only fix the problem for arches with
>> ARCH_PFN_OFFSET and using init_bootmem (which is the case of MIPS I
>> guess). But arches using init_bootmem_node or not using free_area_init()
>> may still get kicked.
>>
>
> Again in these cases, I doubt that they will setup ARCH_PFN_OFFSET...
>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> 
>> Mel Gorman wrote:
> 
>>>>> Not all arches will use init_bootmem(). Arm for example uses
>>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
>>>>>
>>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
>>>> page number that has physical memory. I don't see why we couldn't
>>>> useit to correctly initialise the memory system...
>>>
>>> Architectures will not always have a known fixed start of physical
>>> memory. On IA64 at least, they initialise memory as if it starts at 0
>>> but on my one test machine, the beginning part is always a memory hole.
>>
>> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
>> change...
>>
> 
> The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> you alter those two initialisation functions. Currently it is used to
> offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> free_area_init() and init_bootmem(), it changes to altering the value of
> NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> particular way. 

well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
with free_area_init() and init_bootmem() ? If so, there is a bug since
NODE_DATA(0)->node_start_pfn is not setup correctly...

> I think we should just fix the problem at hand now for which two simple
> patches have been posted and consider making further changes to
> free_area_init() and init_bootmem() as a separate issue.
> 

I agree this is a separate issue. We should resolve it in a different thread.
Mind to start a new one that involve people who can shed some light here ?

Thanks

		Franck

Re: 2.6.17-mm1

[Mel Gorman]

On (26/06/06 15:49), Franck Bui-Huu didst pronounce:
> Mel Gorman wrote:
> > On Mon, 26 Jun 2006, Franck Bui-Huu wrote:
> > 
> >> Mel Gorman wrote:
> > 
> >>>>> Not all arches will use init_bootmem(). Arm for example uses
> >>>>> init_bootmem_node(). ARCH_PFN_OFFSET is only meant to affect mem_map,
> >>>>>
> >>>> well, I don't agree here. ARCH_PFN_OFFSET is used to save the first
> >>>> page number that has physical memory. I don't see why we couldn't
> >>>> useit to correctly initialise the memory system...
> >>>
> >>> Architectures will not always have a known fixed start of physical
> >>> memory. On IA64 at least, they initialise memory as if it starts at 0
> >>> but on my one test machine, the beginning part is always a memory hole.
> >>
> >> in that case ARCH_PFN_OFFSET is 0 which is the old behaviour, nothing
> >> change...
> >>
> > 
> > The change is that ARCH_PFN_OFFSET has a slightly different meaning when
> > you alter those two initialisation functions. Currently it is used to
> > offset memmap from NODE_DATA(0)->node_start_pfn. By changing
> > free_area_init() and init_bootmem(), it changes to altering the value of
> > NODE_DATA(0)->node_start_pfn but only when memory is initialised in a
> > particular way. 
> 
> well I don't see your point there. Is ARCH_PFN_OFFSET != 0 supposed to work
> with free_area_init() and init_bootmem() ?

I don't know for sure and for that reason alone, I'd rather not change
the meaning of ARCH_PFN_OFFSET as part of a "fix".

> If so, there is a bug since
> NODE_DATA(0)->node_start_pfn is not setup correctly...
> 
> > I think we should just fix the problem at hand now for which two simple
> > patches have been posted and consider making further changes to
> > free_area_init() and init_bootmem() as a separate issue.
> > 
> 
> I agree this is a separate issue. We should resolve it in a different thread.
> Mind to start a new one that involve people who can shed some light here ?
> 

Lets close this out first and then figure out where to go next.  The following
patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
!= 0 and documents what ARCH_PFN_OFFSET is for.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
--- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h	2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h	2006-06-26 15:22:19.000000000 +0100
@@ -6,6 +6,20 @@
 
 #if defined(CONFIG_FLATMEM)
 
+/*
+ * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
+ * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
+ * represents the first physical page frame in the system. This is not
+ * always the case as an architecture may start physical memory at 3GB
+ * for example. Rather than allocating an empty mem_map to represent
+ * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
+ * NODE_DATA(0)->node_mem_map such that;
+ *
+ * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
+ *
+ * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
+ * depending on how memory is initialised, this is not always the case.
+ */
 #ifndef ARCH_PFN_OFFSET
 #define ARCH_PFN_OFFSET		(0UL)
 #endif
@@ -28,9 +42,8 @@
  */
 #if defined(CONFIG_FLATMEM)
 
-#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
-#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
-				 ARCH_PFN_OFFSET)
+#define __pfn_to_page(pfn)	(mem_map + (pfn))
+#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
 #elif defined(CONFIG_DISCONTIGMEM)
 
 #define __pfn_to_page(pfn)			\
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
--- linux-2.6.17-mm2-clean/mm/page_alloc.c	2006-06-26 11:38:21.000000000 +0100
+++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c	2006-06-26 15:11:29.000000000 +0100
@@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
 		 * is true. Adjust map relative to node_mem_map to
 		 * maintain this relationship.
 		 */
-		map -= pgdat->node_start_pfn;
+		map -= ARCH_PFN_OFFSET;
 	}
 #ifdef CONFIG_FLATMEM
 	/*

-- 
-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Mel Gorman wrote:
> 
> Lets close this out first and then figure out where to go next.  The following
> patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
> != 0 and documents what ARCH_PFN_OFFSET is for.
> 

why not dropping the initial patch, and resubmit the whole thing that
can be called an optimization rather than a fix ?

> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h
> --- linux-2.6.17-mm2-clean/include/asm-generic/memory_model.h	2006-06-26 11:38:21.000000000 +0100
> +++ linux-2.6.17-mm2-archpfnfix/include/asm-generic/memory_model.h	2006-06-26 15:22:19.000000000 +0100
> @@ -6,6 +6,20 @@
>  
>  #if defined(CONFIG_FLATMEM)
>  
> +/*
> + * With FLATMEM, the mem_map on node 0 is used as the global mem_map.
> + * This implicitly assumes that NODE_DATA(0)->node_start_pfn == 0 and
> + * represents the first physical page frame in the system. This is not
> + * always the case as an architecture may start physical memory at 3GB
> + * for example. Rather than allocating an empty mem_map to represent
> + * the non-existent memory, ARCH_PFN_OFFSET is subtracted from
> + * NODE_DATA(0)->node_mem_map such that;
> + *
> + * PFN 0 = mem_map = NODE_DATA(0)->node_mem_map - ARCH_PFN_OFFSET
> + *
> + * One would expect NODE_DATA(0)->node_start_pfn == ARCH_PFN_OFFSET but
> + * depending on how memory is initialised, this is not always the case.
> + */
>  #ifndef ARCH_PFN_OFFSET
>  #define ARCH_PFN_OFFSET		(0UL)
>  #endif
> @@ -28,9 +42,8 @@
>   */
>  #if defined(CONFIG_FLATMEM)
>  
> -#define __pfn_to_page(pfn)	(mem_map + ((pfn) - ARCH_PFN_OFFSET))
> -#define __page_to_pfn(page)	((unsigned long)((page) - mem_map) + \
> -				 ARCH_PFN_OFFSET)
> +#define __pfn_to_page(pfn)	(mem_map + (pfn))
> +#define __page_to_pfn(page)	((unsigned long)((page) - mem_map))
>  #elif defined(CONFIG_DISCONTIGMEM)
>  
>  #define __pfn_to_page(pfn)			\
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-mm2-clean/mm/page_alloc.c linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c
> --- linux-2.6.17-mm2-clean/mm/page_alloc.c	2006-06-26 11:38:21.000000000 +0100
> +++ linux-2.6.17-mm2-archpfnfix/mm/page_alloc.c	2006-06-26 15:11:29.000000000 +0100
> @@ -2103,7 +2103,7 @@ static void __init alloc_node_mem_map(st
>  		 * is true. Adjust map relative to node_mem_map to
>  		 * maintain this relationship.
>  		 */
> -		map -= pgdat->node_start_pfn;
> +		map -= ARCH_PFN_OFFSET;

why not moving this inside the if statement below ?

>  	}
>  #ifdef CONFIG_FLATMEM
>  	/*
> 

Re: 2.6.17-mm1

[Mel Gorman]

On Mon, 26 Jun 2006, Franck Bui-Huu wrote:

> Mel Gorman wrote:
>>
>> Lets close this out first and then figure out where to go next.  The following
>> patch should fix the problem where mem_map is offset twice when ARCH_PFN_OFFSET
>> != 0 and documents what ARCH_PFN_OFFSET is for.
>>
>
> why not dropping the initial patch, and resubmit the whole thing that
> can be called an optimization rather than a fix ?
>

Also works. I note that the patch has been dropped from -mm so I'll 
revisit it after the next -mm release.

> <snipped>

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.17-mm1

[Franck Bui-Huu]

Franck Bui-Huu wrote:
> 
> what do you think about this use of ARCH_PFN_OFFSET ?
> 
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index d213fed..fd28eed 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -377,11 +377,11 @@ unsigned long __init free_all_bootmem_no
>  	return(free_all_bootmem_core(pgdat));
>  }
>  
> -unsigned long __init init_bootmem (unsigned long start, unsigned long pages)
> +unsigned long __init init_bootmem(unsigned long start, unsigned long pages)
>  {
>  	max_low_pfn = pages;
>  	min_low_pfn = start;
> -	return(init_bootmem_core(NODE_DATA(0), start, 0, pages));
> +	return init_bootmem_core(NODE_DATA(0), start, ARCH_PFN_OFFSET, pages);
>  }
>  
>  #ifndef CONFIG_HAVE_ARCH_BOOTMEM_NODE
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index ed6a40f..43abaeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2154,7 +2154,7 @@ #ifdef CONFIG_FLATMEM
>  		 * relative to node_mem_map to maintain this
>  		 * relationship.
>  		 */
> -		mem_map = map - ARCH_PFN_OFFSET;
> +		mem_map = map - pgdat->node_start_pfn;
>  #endif
>  #endif /* CONFIG_FLAT_NODE_MEM_MAP */
>  }
> @@ -2181,8 +2181,7 @@ #endif
>  
>  void __init free_area_init(unsigned long *zones_size)
>  {
> -	free_area_init_node(0, NODE_DATA(0), zones_size,
> -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);

I'm wondering why using "__pa(PAGE_OFFSET) >> PAGE_SHIFT" to compute the start
of memory. That should always result in 0, shouldn't it ?

		Franck

Re: 2.6.17-mm1

[Russell King]

On Fri, Jun 23, 2006 at 05:14:23PM +0200, Franck Bui-Huu wrote:
> Franck Bui-Huu wrote:
> > -	free_area_init_node(0, NODE_DATA(0), zones_size,
> > -			__pa(PAGE_OFFSET) >> PAGE_SHIFT, NULL);
> 
> I'm wondering why using "__pa(PAGE_OFFSET) >> PAGE_SHIFT" to compute the start
> of memory. That should always result in 0, shouldn't it ?

No.  There are platforms where memory starts at about 3GB physical,
so __pa(PAGE_OFFSET) = 0xc0000000, which most definitely isn't zero
when shifted right by PAGE_SHIFT.

The world is not a PC.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: 2.6.17-mm1

[Michal Piotrowski]

Hi,

On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
>

Firefox 2 - a new testing tool for bug hunters.

Jun 23 11:03:48 ltg01-fedora kernel: =======================================
Jun 23 11:03:48 ltg01-fedora kernel: [ INFO: out of order unlock detected. ]
Jun 23 11:03:48 ltg01-fedora kernel: ---------------------------------------
Jun 23 11:03:48 ltg01-fedora kernel: The code is fine but needs lock
validator annotation.
Jun 23 11:03:48 ltg01-fedora kernel: firefox-bin/25734 is trying to
release lock (tasklist_lock) at:
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017b02c>] flush_old_exec+0x12f/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel: but the next lock to release is:
Jun 23 11:03:48 ltg01-fedora kernel:  (&sighand->siglock){++..}, at:
[<c017afab>] flush_old_exec+0xae/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:
Jun 23 11:03:48 ltg01-fedora kernel: other info that might help us debug this:
Jun 23 11:03:48 ltg01-fedora kernel: 2 locks held by firefox-bin/25734:
Jun 23 11:03:48 ltg01-fedora kernel:  #0:  (tasklist_lock){..??}, at:
[<c017afa4>] flush_old_exec+0xa7/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:  #1:  (&sighand->siglock){++..},
at: [<c017afab>] flush_old_exec+0xae/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:
Jun 23 11:03:48 ltg01-fedora kernel: stack backtrace:
Jun 23 11:03:48 ltg01-fedora kernel:  [<c0103e89>] show_trace+0xd/0x10
Jun 23 11:03:48 ltg01-fedora kernel:  [<c0104483>] dump_stack+0x19/0x1b
Jun 23 11:03:48 ltg01-fedora kernel:  [<c0139c52>] lock_release+0x19a/0x371
Jun 23 11:03:48 ltg01-fedora kernel:  [<c02f1148>] _read_unlock+0x16/0x46
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017b02c>] flush_old_exec+0x12f/0xa5f
Jun 23 11:03:48 ltg01-fedora kernel:  [<c019b698>] load_elf_binary+0x4c8/0x15f4
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017a8e1>]
search_binary_handler+0xfc/0x32b
Jun 23 11:03:48 ltg01-fedora kernel:  [<c017c533>] do_execve+0x16c/0x225
Jun 23 11:03:48 ltg01-fedora kernel:  [<c01016e1>] sys_execve+0x3a/0x8b
Jun 23 11:03:48 ltg01-fedora kernel:  [<c02f157d>] sysenter_past_esp+0x56/0x8d

Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-mm1

[Andrew Morton]

On Fri, 23 Jun 2006 14:33:27 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> Hi,
> 
> On 21/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> >
> 
> Firefox 2 - a new testing tool for bug hunters.

Thanks.

> Jun 23 11:03:48 ltg01-fedora kernel: =======================================
> Jun 23 11:03:48 ltg01-fedora kernel: [ INFO: out of order unlock detected. ]
> Jun 23 11:03:48 ltg01-fedora kernel: ---------------------------------------

This test is a bit of a nuisance.

> Jun 23 11:03:48 ltg01-fedora kernel: The code is fine but needs lock
> validator annotation.
> Jun 23 11:03:48 ltg01-fedora kernel: firefox-bin/25734 is trying to
> release lock (tasklist_lock) at:
> Jun 23 11:03:48 ltg01-fedora kernel:  [<c017b02c>] flush_old_exec+0x12f/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel: but the next lock to release is:
> Jun 23 11:03:48 ltg01-fedora kernel:  (&sighand->siglock){++..}, at:
> [<c017afab>] flush_old_exec+0xae/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel:
> Jun 23 11:03:48 ltg01-fedora kernel: other info that might help us debug this:
> Jun 23 11:03:48 ltg01-fedora kernel: 2 locks held by firefox-bin/25734:
> Jun 23 11:03:48 ltg01-fedora kernel:  #0:  (tasklist_lock){..??}, at:
> [<c017afa4>] flush_old_exec+0xa7/0xa5f
> Jun 23 11:03:48 ltg01-fedora kernel:  #1:  (&sighand->siglock){++..},
> at: [<c017afab>] flush_old_exec+0xae/0xa5f

This is de_thread().  It's deliberate.

Re: 2.6.17-mm1

[Eduard Bloch]

#include <hallo.h>
* Andrew Morton [Wed, Jun 21 2006, 03:48:57AM]:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/

Cannot build it. Looks like the build system is looping over:

  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk
  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk
  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk
  GEN     usr/klibc/syscalls/typesize.c
  KLIBCCC usr/klibc/syscalls/typesize.o
  OBJCOPY usr/klibc/syscalls/typesize.bin
  GEN     usr/klibc/syscalls/syscalls.mk

No matter whether executed as user or as root. Setting KBUILD_VERBOSE
does not help much, for the log see http://people.debian.org/~blade/log .

Eduard.

Re: 2.6.17-mm1

[Jiri Slaby]

Eduard Bloch napsal(a):
> #include <hallo.h>
> * Andrew Morton [Wed, Jun 21 2006, 03:48:57AM]:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm1/
> 
> Cannot build it. Looks like the build system is looping over:
> 
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
>   GEN     usr/klibc/syscalls/typesize.c
>   KLIBCCC usr/klibc/syscalls/typesize.o
>   OBJCOPY usr/klibc/syscalls/typesize.bin
>   GEN     usr/klibc/syscalls/syscalls.mk
> 
> No matter whether executed as user or as root. Setting KBUILD_VERBOSE
> does not help much, for the log see http://people.debian.org/~blade/log .

Should be fixed already:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115091547426482&w=2

regards,
-- 
Jiri Slaby         www.fi.muni.cz/~xslaby
\_.-^-._   jirislaby@gmail.com   _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E

Re: 2.6.17-mm1

[Keith Mannthey]

Andrew,
  When I make mrproper to clean the kernel tree with the -mm trees (at
least the last few releases) I end up having to remove
/include/linux/dwarf2-defs.h myself.  This file is generated at build
time but mrproper isn't cleaning it up.   This file is always present
in a tree that has been built but not in the origninal tree so a diff
of the tree picks it up.

Is this expected?

Thanks,
  Keith

Re: 2.6.17-mm1

[Andrew Morton]

On Fri, 23 Jun 2006 13:39:01 -0700
"Keith Mannthey" <kmannth@gmail.com> wrote:

> Andrew,
>   When I make mrproper to clean the kernel tree with the -mm trees (at
> least the last few releases) I end up having to remove
> /include/linux/dwarf2-defs.h myself.  This file is generated at build
> time but mrproper isn't cleaning it up.   This file is always present
> in a tree that has been built but not in the origninal tree so a diff
> of the tree picks it up.
> 
> Is this expected?
> 

No, it's not expected.  That's due to the kgdb patches.

Sam, what should we be doing here?

Thanks.

Re: 2.6.17-mm1

[Sam Ravnborg]

On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> On Fri, 23 Jun 2006 13:39:01 -0700
> "Keith Mannthey" <kmannth@gmail.com> wrote:
> 
> > Andrew,
> >   When I make mrproper to clean the kernel tree with the -mm trees (at
> > least the last few releases) I end up having to remove
> > /include/linux/dwarf2-defs.h myself.  This file is generated at build
> > time but mrproper isn't cleaning it up.   This file is always present
> > in a tree that has been built but not in the origninal tree so a diff
> > of the tree picks it up.
> > 
> > Is this expected?
> > 
> 
> No, it's not expected.  That's due to the kgdb patches.
> 
> Sam, what should we be doing here?

The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
before starting to build the kernel.
So the only same solution would be to move it all to the Kbuild file in
the top-level directory. Then we should also let same Kbuild file take
care of cleaning up.

I noticed that kgdb patches was dropped in -mm this time.
Shall I try to cook up a patch next time you include kgdb?

	Sam

Re: 2.6.17-mm1

[Andrew Morton]

On Sat, 24 Jun 2006 23:27:06 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> > On Fri, 23 Jun 2006 13:39:01 -0700
> > "Keith Mannthey" <kmannth@gmail.com> wrote:
> > 
> > > Andrew,
> > >   When I make mrproper to clean the kernel tree with the -mm trees (at
> > > least the last few releases) I end up having to remove
> > > /include/linux/dwarf2-defs.h myself.  This file is generated at build
> > > time but mrproper isn't cleaning it up.   This file is always present
> > > in a tree that has been built but not in the origninal tree so a diff
> > > of the tree picks it up.
> > > 
> > > Is this expected?
> > > 
> > 
> > No, it's not expected.  That's due to the kgdb patches.
> > 
> > Sam, what should we be doing here?
> 
> The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
> before starting to build the kernel.
> So the only same solution would be to move it all to the Kbuild file in
> the top-level directory. Then we should also let same Kbuild file take
> care of cleaning up.
> 
> I noticed that kgdb patches was dropped in -mm this time.
> Shall I try to cook up a patch next time you include kgdb?
> 

I wouldn't bother, really - we have bigger fish to fry.

I cc'ed Tom, who might care to take a look at it sometime.

Re: 2.6.17-mm1

[Tom Rini]

On Sat, Jun 24, 2006 at 02:53:05PM -0700, Andrew Morton wrote:
> On Sat, 24 Jun 2006 23:27:06 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > On Fri, Jun 23, 2006 at 02:32:05PM -0700, Andrew Morton wrote:
> > > On Fri, 23 Jun 2006 13:39:01 -0700
> > > "Keith Mannthey" <kmannth@gmail.com> wrote:
> > > 
> > > > Andrew,
> > > >   When I make mrproper to clean the kernel tree with the -mm trees (at
> > > > least the last few releases) I end up having to remove
> > > > /include/linux/dwarf2-defs.h myself.  This file is generated at build
> > > > time but mrproper isn't cleaning it up.   This file is always present
> > > > in a tree that has been built but not in the origninal tree so a diff
> > > > of the tree picks it up.
> > > > 
> > > > Is this expected?
> > > > 
> > > 
> > > No, it's not expected.  That's due to the kgdb patches.
> > > 
> > > Sam, what should we be doing here?
> > 
> > The dwarf2-defs.h file is similar to the asm-offsets.h file. We need it
> > before starting to build the kernel.
> > So the only same solution would be to move it all to the Kbuild file in
> > the top-level directory. Then we should also let same Kbuild file take
> > care of cleaning up.
> > 
> > I noticed that kgdb patches was dropped in -mm this time.
> > Shall I try to cook up a patch next time you include kgdb?
> > 
> 
> I wouldn't bother, really - we have bigger fish to fry.

Just got back from a holiday, catching up on things now.

I _thought_ this had been fixed, but it may have been after Andrew
grabbed the patches last, I'll double check soon.

-- 
Tom Rini