The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
and will soon be available at
git://zen-kernel.org/kernel/mmotm.git
It contains the following patches against 2.6.35-rc1:
origin.patch
rtc-s3c-initialize-driver-data-before-using-it.patch
rtc-s3c-initialize-s3c_rtc_cpu_type-before-using-it.patch
fs-compat_rw_copy_check_uvector-add-missing-compat_ptr-call.patch
ramoops-add-has_iomem-dependency.patch
frv-invoke-oom-killer-from-page-fault.patch
m32r-invoke-oom-killer-from-page-fault.patch
mn10300-invoke-oom-killer-from-page-fault.patch
xtensa-invoke-oom-killer-from-page-fault.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
include-linux-fsh-complete-hexification-of-fmode_-constants.patch
vmware-balloon-clamp-number-of-collected-non-balloonable-pages.patch
flat-split-the-stack-data-alignments.patch
flat-fix-unmap-len-in-load-error-path.patch
revert-fb_defio-fix-for-non-dirty-ptes.patch
fb_defio-redo-fix-for-non-dirty-ptes.patch
sys_personality-change-sys_personality-to-accept-unsigned-int-instead-of-u_long.patch
arch-um-fix-kunmap_atomic-call-in-skas-uaccessc.patch
fbdev-fix-frame-buffer-devices-menu.patch
lib-add-s390-to-atomic64_dec_if_positive-archs.patch
cgroup-alloc_css_id-increments-hierarchy-depth.patch
kernel-fix-bug_on-checks-for-cpu-notifier-callbacks-direct-call.patch
vmscan-fix-do_try_to_free_pages-return-value-when-priority==0-reclaim-failure.patch
omap-remove-bug_on-for-disabled-interrupts.patch
block-bd_start_claiming-fix-module-refcount.patch
block-bd_start_claiming-cleanup.patch
cpufreq-revert-remove-rwsem-lock-from-cpufreq_gov_stop-call-second-call-site.patch
gconfig-fix-build-failure-on-fedora-13.patch
sched-prevent-compiler-from-optimising-sched_avg_update-loop.patch
vfs-dont-hold-s_umount-over-close_bdev_exclusive-call.patch
x86-i8259-only-register-sysdev-for-real-pic.patch
acerhdf-add-new-bios-versions.patch
dell-studio-1555-eject-key-does-not-work-small-patch-to-fix-included.patch
timer-add-on-stack-deferrable-timer-interfaces.patch
intel_menlow-fix-memory-leaks-in-error-path.patch
intel_menlow-fix-memory-leaks-in-error-path-fix.patch
x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent.patch
x86-rwsem-stay-on-fast-path-when-count0-in-__up_write.patch
x86-rwsem-minor-cleanups.patch
compal-laptop-added-jhl90-battery-hwmon-interface.patch
compal-laptop-uses-hwmon-interfaces-depends-on-hwmon.patch
avr32-invoke-oom-killer-from-page-fault.patch
fs-btrfs-use-memdup_user.patch
fs-btrfs-use-err_cast.patch
cifs-provide-user-with-a-hint-when-name-resolution-fails.patch
drivers-dma-eliminate-a-null-pointer-dereference.patch
dib3000mc-reduce-large-stack-usage-fix.patch
drivers-media-use-memdup_user.patch
drivers-media-video-pvrusb2-add-missing-mutex_unlock.patch
drivers-video-omap2-displays-add-missing-mutex_unlock.patch
hpet-factor-timer-allocate-from-open.patch
posix_timer-move-copy_to_usercreated_timer_id-down-in-timer_create.patch
arch-ia64-kvm-add-missing-spin_unlock.patch
input-remove-references-to-obsolete-config_spruce.patch
checkkconfigsymbolssh-kconfig-symbols-sometimes-have-lowercase-letters.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
drivers-ide-use-memdup_user.patch
drivers-mfd-kzalloc-doesnt-return-err_ptr.patch
mtd-sst25l-check-for-null-consistently.patch
score-fix-dereference-of-null-pointer-in-local_flush_tlb_page.patch
fs-ubifs-use-err_cast.patch
3x59x-fix-pci-resource-management.patch
btusb-patch-add_apple_macbookpro62.patch
fs-ocfs2-dlm-add-missing-spin_unlock.patch
altera_uart-simplify-altera_uart_console_putc-checkpatch-fixes.patch
serial-fix-missing-bit-coverage-of-async_flags.patch
serial-general-fixes-in-the-serial_rs485-structure.patch
altera_uart-proper-section-for-altera_uart_remove.patch
drivers-s390-net-use-memdup_user.patch
percpu-online-cpu-before-memory-failed-in-pcpu_alloc_pages.patch
percpu-fix-list_head-init-bug-in-__percpu_counter_init.patch
scsi-add-__init-__exit-macros-to-ibmvstgtc.patch
drivers-scsi-fnic-fnic_scsic-clean-up.patch
drivers-scsi-lpfc-lpfc_vportc-fix-read-buffer-overflow.patch
osst-fix-read-buffer-overflow.patch
gdth-unmap-ccb_phys-when-scsi_add_host-fails-in-gdth_eisa_probe_one.patch
drivers-scsi-libsas-use-sam_good.patch
ncr5380-bit-mr_dma_mode-set-twice-in-ncr5380_transfer_dma.patch
drivers-scsi-remove-unnecessary-null-test.patch
drivers-message-move-dereference-after-null-test.patch
mpt-fusion-convert-to-seq_file.patch
g_ncr5380-remove-misleading-pnp-error-message.patch
g_ncr5380-fix-broken-mmio-compilation.patch
dc395x-decrease-iteration-for-tag_number-of-max_command-in-start_scsi.patch
drivers-scsi-correct-the-size-argument-to-kmalloc.patch
scsi-remove-superfluous-null-pointer-check-from-scsi_kill_request.patch
scsi-sdc-quiet-all-sparse-noise.patch
lpfc-positive-error-return-into-negative.patch
drivers-scsi-qla2xxx-qla_osc-fix-continuation-line-formats.patch
scsi-bfa-correct-onstack-wait_queue_head-declaration.patch
drivers-scsi-chc-dont-use-vprintk-as-macro.patch
bfa-wrong-fcport-h2i-message-tested-in-bfa_fcport_isr.patch
scsi-use-__ux-types-for-headers-exported-to-user-space.patch
scsi-fix-pmcraid-build-errors.patch
scsi-fix-be2iscsi-build.patch
scsi-fix-bnx2i-build-errors.patch
scsi-remove-private-bit-macros.patch
drivers-scsi-use-memdup_user.patch
drivers-block-use-memdup_user.patch
cciss-enqueue-and-submit-io.patch
cciss-clean-up-interrupt-handler.patch
cciss-check-for-msi-in-interrupt_not_for_us.patch
cciss-make-interrupt-access-methods-return-type-bool.patch
cciss-add-performant-mode-support-for-stars-sirius.patch
cciss-new-controller-support-and-bump-driver-version.patch
arch-sparc-kernel-eliminate-what-looks-like-a-null-pointer-dereference.patch
drivers-staging-dream-camera-use-memdup_user.patch
drivers-staging-vme-bridges-add-missing-unlocks.patch
drivers-staging-eliminate-a-null-pointer-dereference.patch
drivers-usb-gadget-use-memdup_user.patch
drivers-usb-serial-eliminate-a-null-pointer-dereference.patch
cdc-acm-fix-resource-reclaim-in-error-path-of-acm_probe.patch
virtio_9ph-include-linux-typesh.patch
vfs-improve-comment-describing-fget_light.patch
vfs-o_-bit-numbers-uniqueness-check.patch
vfs-introduce-fmode_neg_offset-for-allowing-negative-f_pos.patch
vfs-clarify-that-nonseekable_open-will-never-fail.patch
vfs-use-kmalloc-to-allocate-fdmem-if-possible.patch
padata-add-parenthesis-in-max_seq_nr-macro.patch
modpost-support-objects-with-more-than-64k-sections.patch
mm.patch
mm-use-memdup_user.patch
mm-use-err_cast.patch
mm-provide-init_mm-mm_context-initializer.patch
tmpfs-quick-token-library-to-allow-scalable-retrieval-of-tokens-from-token-jar.patch
tmpfs-quick-token-library-to-allow-scalable-retrieval-of-tokens-from-token-jar-fix.patch
tmpfs-make-tmpfs-scalable-with-caches-for-free-blocks.patch
hugetlb-call-mmu-notifiers-on-hugepage-cow.patch
kmap_atomic-make-kunmap_atomic-harder-to-misuse.patch
mm-vmap-area-cache.patch
mm-vmap-area-cache-fix.patch
define-madv_hugepage.patch
mm-rename-anon_vma_lock-to-vma_lock_anon_vma.patch
mm-change-direct-call-of-spin_lockanon_vma-lock-to-inline-function.patch
mm-track-the-root-oldest-anon_vma.patch
mm-track-the-root-oldest-anon_vma-fix.patch
mm-always-lock-the-root-oldest-anon_vma.patch
mm-extend-ksm-refcounts-to-the-anon_vma-root.patch
buffer_head-remove-redundant-test-from-wait_on_buffer.patch
buffer_head-remove-redundant-test-from-wait_on_buffer-fix.patch
wait_on_buffer-remove-the-buffer_locked-test.patch
ummunotify-userspace-support-for-mmu-notifications-v2.patch
keys-propagate-error-code-instead-of-returning-einval.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
alpha-add-performance-monitor-interrupt-counter.patch
alpha-add-wrperfmonh-header-file-to-aid-use-of-wrperfmon-palcall.patch
alpha-implement-hw-performance-events-on-the-ev67-and-later-cpus.patch
asm-generic-ioh-add-big-endian-versions-of-ioreadwrite1632.patch
include-linux-compiler-gcch-use-__same_type-in-__must_be_array.patch
misc-rohm-bh1780gli-ambient-light-sensor-driver.patch
sys_personality-remove-the-bogus-checks-in-sys_personality-__set_personality-path.patch
char-add-warn_on-in-misc_deregister.patch
s390-remove-warn_on-for-misc_deregister-failures.patch
checkpatch-refactor-allowed-asm-includes-and-add-memoryh.patch
rwsem-fully-separate-code-pathes-to-wake-writers-vs-readers.patch
rwsem-lighter-active-count-checks-when-waking-up-readers.patch
rwsem-let-rwsem_waiting_bias-represent-any-number-of-waiting-threads.patch
rwsem-wake-queued-readers-when-writer-blocks-on-active-read-lock.patch
rwsem-smaller-wrappers-around-rwsem_down_failed_common.patch
drivers-message-i2o-exec-osmc-add-missing-mutex_unlock.patch
autofs4-remove-unneeded-null-check-in-try_to_fill_dentry.patch
nuc900-rtc-change-the-waiting-for-device-ready-implement.patch
drivers-rtc-rtc-pcf8563c-remove-unused-struct.patch
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
fusion-fix-kernel-doc-warnings.patch
timerc-fix-kernel-doc-warning.patch
mtd-nand_base-fix-kernel-doc-warnings-typos.patch
drivers-char-n_gsmc-add-missing-spin_unlock_irqrestore.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
delayacct-align-to-8-byte-boundary-on-64-bit-systems.patch
edac-add-wissing-pieces-from-mpc85xx-fsl_soc_booke.patch
ssb-add-dma_dev-to-ssb_device-structure.patch
b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
ssb-remove-the-ssb-dma-api.patch
aio-always-reinitialize-iocb-ki_run_list-at-the-end-of-aio_run_iocb.patch
kfifo-kfifo_is_fullempty-should-return-bools-not-ints.patch
kfifo-fix-kfifo-miss-use-of-nozamic.patch
kfifo-add-the-new-generic-kfifo-api.patch
kfifo-replace-the-old-non-generic-api.patch
kfifo-add-example-files-to-the-kernel-sample-directory.patch
kfifo-add-example-files-to-the-kernel-sample-directory-checkpatch-fixes.patch
lib-decompress_bunzip2c-fix-checkstack-warning.patch
time-kill-off-config_generic_time.patch
vfs-add-super-operation-writeback_inodes.patch
vfs-take-2add-set_page_dirty_notag.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-remove_from_page_cache-fix.patch
reiser4-export-find_get_pages.patch
reiser4.patch
reiser4-writeback_inodes-implementation.patch
reiser4-writeback_inodes-implementation-fix.patch
reiser4-fixup-checkin-checkout-jnodes-for-entd.patch
reiser4-fixups.patch
reiser4-broke.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
mutex-subsystem-synchro-test-module-add-missing-header-file.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
getblk-handle-2tb-devices.patch
On Thu, 03 Jun 2010 16:36:51 -0700
[email protected] wrote:
> The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
>
> and will soon be available at
>
> git://zen-kernel.org/kernel/mmotm.git
>
> It contains the following patches against 2.6.35-rc1:
(snip)
> ssb-add-dma_dev-to-ssb_device-structure.patch
> b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> ssb-remove-the-ssb-dma-api.patch
Is there any reason why the above patches are still in -mm (i.e. not
merged in the previous merge window)?
I got an ACK on the first patch to ssb core from the ssb maintainer,
ACKs on the second and third to b43legacy and b43 from the maintainer.
http://marc.info/?t=126621151900002&r=1&w=2
Thanks,
On Fri, 4 Jun 2010 10:14:27 +0900 FUJITA Tomonori <[email protected]> wrote:
> On Thu, 03 Jun 2010 16:36:51 -0700
> [email protected] wrote:
>
> > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
> >
> > and will soon be available at
> >
> > git://zen-kernel.org/kernel/mmotm.git
> >
> > It contains the following patches against 2.6.35-rc1:
>
> (snip)
>
> > ssb-add-dma_dev-to-ssb_device-structure.patch
> > b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> > b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> > b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> > ssb-remove-the-ssb-dma-api.patch
>
> Is there any reason why the above patches are still in -mm (i.e. not
> merged in the previous merge window)?
Two lines earlier:
# propagate these:
is akpm shorthand for "send these through maintainers".
I prefer to go that way if the patch isn't urgent, just to get a bit
more attention and review. If the patch has a maintainer ack already
then I'll often merge it directly.
> I got an ACK on the first patch to ssb core from the ssb maintainer,
> ACKs on the second and third to b43legacy and b43 from the maintainer.
>
> http://marc.info/?t=126621151900002&r=1&w=2
And none of the above patches were sent to me with acked-by:s, and
nobody sent new acked-by:s, so I didn't know this!
I guess John is the conduit for all five of the above so I'll send them
to him now and he might decide to squeak them into 2.6.35.
But before I do that, please send me an email telling me who acked each
patch and I'll update that info.
Thanks.
On Fri, Jun 4, 2010 at 7:36 AM, <[email protected]> wrote:
> The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
>
Hi, intel_idle build fails:
drivers/idle/intel_idle.c: In function ‘intel_idle’:
drivers/idle/intel_idle.c:234: error: too few arguments to function ‘trace_power
_start’
make[2]: *** [drivers/idle/intel_idle.o] Error 1
make[1]: *** [drivers/idle] Error 2
make[1]: *** Waiting for unfinished jobs....
--
Regards
dave
On Fri, 4 Jun 2010 09:41:58 +0800 Dave Young <[email protected]> wrote:
> On Fri, Jun 4, 2010 at 7:36 AM, <[email protected]> wrote:
> > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
> >
> > __ http://userweb.kernel.org/~akpm/mmotm/
> >
>
> Hi, intel_idle build fails:
>
> drivers/idle/intel_idle.c: In function ___intel_idle___:
> drivers/idle/intel_idle.c:234: error: too few arguments to function ___trace_power
> _start___
> make[2]: *** [drivers/idle/intel_idle.o] Error 1
> make[1]: *** [drivers/idle] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
Caused by
x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent.patch
which changed trace_power_start().
drivers/idle/intel_idle.c wasn't there when Thomas wrote that patch.
this, I guess:
--- a/drivers/idle/intel_idle.c~x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent-fix
+++ a/drivers/idle/intel_idle.c
@@ -231,7 +231,7 @@ static int intel_idle(struct cpuidle_dev
stop_critical_timings();
#ifndef MODULE
- trace_power_start(POWER_CSTATE, (eax >> 4) + 1);
+ trace_power_start(POWER_CSTATE, (eax >> 4) + 1, cpu);
#endif
if (!need_resched()) {
_
it's a bit odd that all trace_power_start() callers just pass in
smp_processor_id(). Why not do it within trace_power_start() itself?
On Fri, 4 Jun 2010 09:41:58 +0800 Dave Young <[email protected]> wrote:
> On Fri, Jun 4, 2010 at 7:36 AM, <[email protected]> wrote:
> > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
> >
> > __ http://userweb.kernel.org/~akpm/mmotm/
> >
>
> Hi, intel_idle build fails:
>
> drivers/idle/intel_idle.c: In function ___intel_idle___:
> drivers/idle/intel_idle.c:234: error: too few arguments to function ___trace_power
> _start___
> make[2]: *** [drivers/idle/intel_idle.o] Error 1
> make[1]: *** [drivers/idle] Error 2
> make[1]: *** Waiting for unfinished jobs....
Oh, and why didn't my x86_64 allmodconfig build catch this?
allmodconfig is for compile coverage testing (IMO) and someone isn't
being covered. Someone needs thwapping!
#ifndef MODULE
trace_power_start(POWER_CSTATE, (eax >> 4) + 1);
#endif
Len: thwap.
On Fri, Jun 4, 2010 at 9:54 AM, Andrew Morton <[email protected]> wrote:
> On Fri, 4 Jun 2010 09:41:58 +0800 Dave Young <[email protected]> wrote:
>
>> On Fri, Jun 4, 2010 at 7:36 AM, <[email protected]> wrote:
>> > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
>> >
>> > __ http://userweb.kernel.org/~akpm/mmotm/
>> >
>>
>> Hi, intel_idle build fails:
>>
>> drivers/idle/intel_idle.c: In function ___intel_idle___:
>> drivers/idle/intel_idle.c:234: error: too few arguments to function ___trace_power
>> _start___
>> make[2]: *** [drivers/idle/intel_idle.o] Error 1
>> make[1]: *** [drivers/idle] Error 2
>> make[1]: *** Waiting for unfinished jobs....
>>
>
> Caused by
> x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent.patch
> which changed trace_power_start().
>
> drivers/idle/intel_idle.c wasn't there when Thomas wrote that patch.
>
> this, I guess:
>
> --- a/drivers/idle/intel_idle.c~x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent-fix
> +++ a/drivers/idle/intel_idle.c
> @@ -231,7 +231,7 @@ static int intel_idle(struct cpuidle_dev
>
> stop_critical_timings();
> #ifndef MODULE
> - trace_power_start(POWER_CSTATE, (eax >> 4) + 1);
> + trace_power_start(POWER_CSTATE, (eax >> 4) + 1, cpu);
> #endif
> if (!need_resched()) {
>
With one more param "cpu", fails with "too many arguments":
CC drivers/idle/intel_idle.o
drivers/idle/intel_idle.c: In function ‘intel_idle’:
drivers/idle/intel_idle.c:234: error: too many arguments to function
‘trace_power_start’
make[2]: *** [drivers/idle/intel_idle.o] Error 1
make[1]: *** [drivers/idle] Error 2
make[1]: *** Waiting for unfinished jobs....
> _
>
>
> it's a bit odd that all trace_power_start() callers just pass in
> smp_processor_id(). Why not do it within trace_power_start() itself?
>
>
>
--
Regards
dave
On Fri, 4 Jun 2010 10:02:57 +0800 Dave Young <[email protected]> wrote:
> On Fri, Jun 4, 2010 at 9:54 AM, Andrew Morton <[email protected]> wrote:
> > On Fri, 4 Jun 2010 09:41:58 +0800 Dave Young <[email protected]> wrote:
> >
> >> On Fri, Jun 4, 2010 at 7:36 AM, __<[email protected]> wrote:
> >> > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
> >> >
> >> > __ http://userweb.kernel.org/~akpm/mmotm/
> >> >
> >>
> >> Hi, intel_idle build fails:
> >>
> >> drivers/idle/intel_idle.c: In function ___intel_idle___:
> >> drivers/idle/intel_idle.c:234: error: too few arguments to function ___trace_power
> >> _start___
> >> make[2]: *** [drivers/idle/intel_idle.o] Error 1
> >> make[1]: *** [drivers/idle] Error 2
> >> make[1]: *** Waiting for unfinished jobs....
> >>
> >
> > Caused by
> > x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent.patch
> > which changed trace_power_start().
> >
> > drivers/idle/intel_idle.c wasn't there when Thomas wrote that patch.
> >
> > this, I guess:
> >
> > --- a/drivers/idle/intel_idle.c~x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent-fix
> > +++ a/drivers/idle/intel_idle.c
> > @@ -231,7 +231,7 @@ static int intel_idle(struct cpuidle_dev
> >
> > __ __ __ __stop_critical_timings();
> > __#ifndef MODULE
> > - __ __ __ trace_power_start(POWER_CSTATE, (eax >> 4) + 1);
> > + __ __ __ trace_power_start(POWER_CSTATE, (eax >> 4) + 1, cpu);
> > __#endif
> > __ __ __ __if (!need_resched()) {
> >
>
> With one more param "cpu", fails with "too many arguments":
>
> CC drivers/idle/intel_idle.o
> drivers/idle/intel_idle.c: In function ___intel_idle___:
> drivers/idle/intel_idle.c:234: error: too many arguments to function
> ___trace_power_start___
> make[2]: *** [drivers/idle/intel_idle.o] Error 1
> make[1]: *** [drivers/idle] Error 2
> make[1]: *** Waiting for unfinished jobs....
hm, It Works For Me. I suspect you applied my patch to mainline, not
to -mm.
On Fri, Jun 4, 2010 at 10:10 AM, Andrew Morton
<[email protected]> wrote:
> On Fri, 4 Jun 2010 10:02:57 +0800 Dave Young <[email protected]> wrote:
>
>> On Fri, Jun 4, 2010 at 9:54 AM, Andrew Morton <[email protected]> wrote:
>> > On Fri, 4 Jun 2010 09:41:58 +0800 Dave Young <[email protected]> wrote:
>> >
>> >> On Fri, Jun 4, 2010 at 7:36 AM, __<[email protected]> wrote:
>> >> > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
>> >> >
>> >> > __ http://userweb.kernel.org/~akpm/mmotm/
>> >> >
>> >>
>> >> Hi, intel_idle build fails:
>> >>
>> >> drivers/idle/intel_idle.c: In function ___intel_idle___:
>> >> drivers/idle/intel_idle.c:234: error: too few arguments to function ___trace_power
>> >> _start___
>> >> make[2]: *** [drivers/idle/intel_idle.o] Error 1
>> >> make[1]: *** [drivers/idle] Error 2
>> >> make[1]: *** Waiting for unfinished jobs....
>> >>
>> >
>> > Caused by
>> > x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent.patch
>> > which changed trace_power_start().
>> >
>> > drivers/idle/intel_idle.c wasn't there when Thomas wrote that patch.
>> >
>> > this, I guess:
>> >
>> > --- a/drivers/idle/intel_idle.c~x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent-fix
>> > +++ a/drivers/idle/intel_idle.c
>> > @@ -231,7 +231,7 @@ static int intel_idle(struct cpuidle_dev
>> >
>> > __ __ __ __stop_critical_timings();
>> > __#ifndef MODULE
>> > - __ __ __ trace_power_start(POWER_CSTATE, (eax >> 4) + 1);
>> > + __ __ __ trace_power_start(POWER_CSTATE, (eax >> 4) + 1, cpu);
>> > __#endif
>> > __ __ __ __if (!need_resched()) {
>> >
>>
>> With one more param "cpu", fails with "too many arguments":
>>
>> CC drivers/idle/intel_idle.o
>> drivers/idle/intel_idle.c: In function ___intel_idle___:
>> drivers/idle/intel_idle.c:234: error: too many arguments to function
>> ___trace_power_start___
>> make[2]: *** [drivers/idle/intel_idle.o] Error 1
>> make[1]: *** [drivers/idle] Error 2
>> make[1]: *** Waiting for unfinished jobs....
>
> hm, It Works For Me. I suspect you applied my patch to mainline, not
> to -mm.
>
oops, you are right, I applied to different tree.
Tested, it works
--
Regards
dave
On Thu, 3 Jun 2010 18:34:10 -0700
Andrew Morton <[email protected]> wrote:
> On Fri, 4 Jun 2010 10:14:27 +0900 FUJITA Tomonori <[email protected]> wrote:
>
> > On Thu, 03 Jun 2010 16:36:51 -0700
> > [email protected] wrote:
> >
> > > The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> > >
> > > and will soon be available at
> > >
> > > git://zen-kernel.org/kernel/mmotm.git
> > >
> > > It contains the following patches against 2.6.35-rc1:
> >
> > (snip)
> >
> > > ssb-add-dma_dev-to-ssb_device-structure.patch
> > > b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> > > b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> > > b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
> > > ssb-remove-the-ssb-dma-api.patch
> >
> > Is there any reason why the above patches are still in -mm (i.e. not
> > merged in the previous merge window)?
>
> Two lines earlier:
>
> # propagate these:
>
> is akpm shorthand for "send these through maintainers".
>
> I prefer to go that way if the patch isn't urgent, just to get a bit
> more attention and review. If the patch has a maintainer ack already
> then I'll often merge it directly.
>
> > I got an ACK on the first patch to ssb core from the ssb maintainer,
> > ACKs on the second and third to b43legacy and b43 from the maintainer.
> >
> > http://marc.info/?t=126621151900002&r=1&w=2
>
> And none of the above patches were sent to me with acked-by:s, and
> nobody sent new acked-by:s, so I didn't know this!
Oh, sorry.
> I guess John is the conduit for all five of the above so I'll send them
> to him now and he might decide to squeak them into 2.6.35.
Thanks. They aren't urgent. 2.6.26 is fine.
> But before I do that, please send me an email telling me who acked each
> patch and I'll update that info.
The first version included the first, second, third, and forth
patches' changes:
http://marc.info/?l=linux-netdev&m=126621140418564&w=2
Michael Buesch <[email protected]> acked:
http://marc.info/?l=linux-kernel&m=126623288409638&w=2
David S. Miller <[email protected]> also acked:
http://marc.info/?l=linux-netdev&m=126621509421648&w=2
Larry Finger <[email protected]> acked the changes to
b43legacy and b43 (the second and third patches now):
http://marc.info/?l=linux-kernel&m=126634755930224&w=2
Thanks,
On Thu, 03 Jun 2010 16:36:51 PDT, [email protected] said:
> The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
Not strictly a -mm problemn, but I just noticed it.
In drivers/idle/Kconfig, we see:
Cpuidle Driver for Intel Processors (INTEL_IDLE) [N/m/y/?] (NEW) ?
CONFIG_INTEL_IDLE:
Enable intel_idle, a cpuidle driver that includes knowledge of
native Intel hardware idle features. The acpi_idle driver
can be configured at the same time, in order to handle
processors intel_idle does not support.
I think we wanted a s/acpi_idle/processor_idle/ there?
On 06/04/2010 04:16 AM, FUJITA Tomonori wrote:
> On Thu, 3 Jun 2010 18:34:10 -0700
> Andrew Morton<[email protected]> wrote:
>
>> On Fri, 4 Jun 2010 10:14:27 +0900 FUJITA Tomonori<[email protected]> wrote:
>>
>>> On Thu, 03 Jun 2010 16:36:51 -0700
>>> [email protected] wrote:
>>>
>>>> The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
>>>>
>>>> http://userweb.kernel.org/~akpm/mmotm/
>>>>
>>>> and will soon be available at
>>>>
>>>> git://zen-kernel.org/kernel/mmotm.git
>>>>
>>>> It contains the following patches against 2.6.35-rc1:
>>>
>>> (snip)
>>>
>>>> ssb-add-dma_dev-to-ssb_device-structure.patch
>>>> b43legacy-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
>>>> b43-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
>>>> b44-replace-the-ssb_dma-api-with-the-generic-dma-api.patch
>>>> ssb-remove-the-ssb-dma-api.patch
>>>
>>> Is there any reason why the above patches are still in -mm (i.e. not
>>> merged in the previous merge window)?
>>
>> Two lines earlier:
>>
>> # propagate these:
>>
>> is akpm shorthand for "send these through maintainers".
>>
>> I prefer to go that way if the patch isn't urgent, just to get a bit
>> more attention and review. If the patch has a maintainer ack already
>> then I'll often merge it directly.
>>
>>> I got an ACK on the first patch to ssb core from the ssb maintainer,
>>> ACKs on the second and third to b43legacy and b43 from the maintainer.
>>>
>>> http://marc.info/?t=126621151900002&r=1&w=2
>>
>> And none of the above patches were sent to me with acked-by:s, and
>> nobody sent new acked-by:s, so I didn't know this!
>
> Oh, sorry.
>
>> I guess John is the conduit for all five of the above so I'll send them
>> to him now and he might decide to squeak them into 2.6.35.
>
> Thanks. They aren't urgent. 2.6.26 is fine.
>
>
>> But before I do that, please send me an email telling me who acked each
>> patch and I'll update that info.
>
> The first version included the first, second, third, and forth
> patches' changes:
> http://marc.info/?l=linux-netdev&m=126621140418564&w=2
>
> Michael Buesch<[email protected]> acked:
> http://marc.info/?l=linux-kernel&m=126623288409638&w=2
>
> David S. Miller<[email protected]> also acked:
> http://marc.info/?l=linux-netdev&m=126621509421648&w=2
>
> Larry Finger<[email protected]> acked the changes to
> b43legacy and b43 (the second and third patches now):
> http://marc.info/?l=linux-kernel&m=126634755930224&w=2
I'm a bit nervous, however, whether these patches are tested on all
platforms that ssb supports. Especially embedded.
However, there is not a huge problem if a breakage is introduced into
the mainline kernel here. We hardly use mainline for embedded anyway.
Some patches are basically always needed.
So from my point of view it is OK to merge these patches, if they are
tested on i386, x86/64. The rest may be sorted out later in the rc cycle
(or even -stable, for embedded).
--
Greetings Michael.
From: Randy Dunlap <[email protected]>
Fix build for CONFIG_PROC_FS not enabled; fixes this build error:
drivers/block/cciss.c:3422: error: implicit declaration of function 'next_command'
Looks like the next_command() function was added at a bad location
in cciss-add-performant-mode-support-for-stars-sirius.patch.
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Mike Miller <[email protected]>
---
drivers/block/cciss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- mmotm-2010-0603-1636.orig/drivers/block/cciss.c
+++ mmotm-2010-0603-1636/drivers/block/cciss.c
@@ -372,8 +372,6 @@ static const char *raid_label[] = { "0",
};
#define RAID_UNKNOWN (sizeof(raid_label) / sizeof(raid_label[0])-1)
-#ifdef CONFIG_PROC_FS
-
static inline u32 next_command(ctlr_info_t *h)
{
u32 a;
@@ -396,6 +394,8 @@ static inline u32 next_command(ctlr_info
return a;
}
+#ifdef CONFIG_PROC_FS
+
/*
* Report information about this controller.
*/
> -----Original Message-----
> From: Randy Dunlap [mailto:[email protected]]
> Sent: Friday, June 04, 2010 11:42 AM
> To: [email protected]
> Cc: [email protected]; Miller, Mike (OS Dev)
> Subject: [PATCH -mmotm] cciss: fix build for CONFIG_PROC_FS=n
>
> From: Randy Dunlap <[email protected]>
>
> Fix build for CONFIG_PROC_FS not enabled; fixes this build error:
> drivers/block/cciss.c:3422: error: implicit declaration of
> function 'next_command'
>
> Looks like the next_command() function was added at a bad
> location in cciss-add-performant-mode-support-for-stars-sirius.patch.
>
> Signed-off-by: Randy Dunlap <[email protected]>
Thanks, Randy. But I'm working on that plus a couple other miscues.
-- mikem
> Cc: Mike Miller <[email protected]>
> ---
> drivers/block/cciss.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- mmotm-2010-0603-1636.orig/drivers/block/cciss.c
> +++ mmotm-2010-0603-1636/drivers/block/cciss.c
> @@ -372,8 +372,6 @@ static const char *raid_label[] = { "0",
> }; #define RAID_UNKNOWN (sizeof(raid_label) /
> sizeof(raid_label[0])-1)
>
> -#ifdef CONFIG_PROC_FS
> -
> static inline u32 next_command(ctlr_info_t *h) {
> u32 a;
> @@ -396,6 +394,8 @@ static inline u32 next_command(ctlr_info
> return a;
> }
>
> +#ifdef CONFIG_PROC_FS
> +
> /*
> * Report information about this controller.
> */
> -
Hi Andrew,
On Thu, 03 Jun 2010 16:36:51 -0700 [email protected] wrote:
>
> The mm-of-the-moment snapshot 2010-06-03-16-36 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
I have added the mmotm tree to our build system. The results are at
http://kisskb.ellerman.id.au/kisskb/branch/14/ . Let me know if you
would like any more configs built (you can see a complete list by looking
at http://kisskb.ellerman.id.au/kisskb/matrix/).
I will attempt to add each mmotm as it is released. The results may take
a day to be produced depending on how busy our build machines are.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/