2006-12-15 06:59:19

by Andrew Morton

[permalink] [raw]
Subject: 2.6.20-rc1-mm1


Temporarily at

http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/

Will appear later at

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



- Added the avr32 devel tree as git-avr32.patch (Haavard Skinnemoen)

- Don't enable locking API self-tests on powerpc - it explodes in a
spectacular fashion.




Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.

echo "subscribe mm-commits" | mail [email protected]

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at

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

But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.

- Semi-daily snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.



Changes since 2.6.19-mm1:

origin.patch
git-acpi.patch
git-alsa.patch
git-avr32.patch
git-cpufreq.patch
git-drm.patch
git-dvb.patch
git-gfs2-nmw.patch
git-ieee1394.patch
git-infiniband.patch
git-libata-all.patch
git-lxdialog.patch
git-mmc.patch
git-mmc-fixup.patch
git-mtd.patch
git-ubi.patch
git-netdev-all.patch
git-ioat.patch
git-ocfs2.patch
git-pcmcia.patch
git-chelsio.patch
git-selinux.patch
git-pciseg.patch
git-s390.patch
git-sh.patch
git-sas.patch
git-sparc64.patch
git-qla3xxx.patch
git-wireless.patch
git-gccbug.patch

git trees.

-x86-smp-export-smp_num_siblings-for-oprofile.patch
-tty-export-get_current_tty.patch
-ieee80211softmac-fix-errors-related-to-the-work_struct-changes.patch
-kvm-add-missing-include.patch
-kvm-put-kvm-in-a-new-virtualization-menu.patch
-kvm-clean-up-amd-svm-debug-registers-load-and-unload.patch
-kvm-replace-__x86_64__-with-config_x86_64.patch
-fix-more-workqueue-build-breakage-tps65010.patch
-another-build-fix-header-rearrangements-osk.patch
-uml-fix-net_kern-workqueue-abuse.patch
-isdn-gigaset-fix-possible-missing-wakeup.patch
-i2o_exec_exit-and-i2o_driver_exit-should-not-be-__exit.patch
-cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
-gregkh-driver-modules-state.patch
-gregkh-driver-driver-core-delete-virtual-directory-on-class_unregister.patch
-gregkh-driver-debugfs-inotify-create-mkdir-support.patch
-gregkh-driver-debugfs-coding-style-fixes.patch
-gregkh-driver-debugfs-file-directory-creation-error-handling.patch
-gregkh-driver-debugfs-more-file-directory-creation-error-handling.patch
-gregkh-driver-debugfs-file-directory-removal-fix.patch
-gregkh-driver-driver-core-platform_driver_probe-can-save-codespace-save-codespace.patch
-gregkh-driver-driver-core-make-platform_device_add_data-accept-a-const-pointer.patch
-gregkh-driver-driver-core-deprecate-pm_legacy-default-it-to-n.patch
-drm-fix-return-value-check.patch
-drm-handle-pci_enable_device-failure.patch
-jdelvare-i2c-i2c-documentation-typos.patch
-jdelvare-i2c-i2c-update-i2c-id-list.patch
-jdelvare-i2c-i2c-delete-ite-bus-driver.patch
-jdelvare-i2c-i2c-pnx-new-driver.patch
-jdelvare-i2c-i2c-ibm_iic-add_request_release_mem_region.patch
-jdelvare-i2c-i2c-nforce2-cleanup.patch
-jdelvare-i2c-i2c-lockdep-handle-recursive-locking.patch
-jdelvare-i2c-i2c-at91-new-bus-driver.patch
-jdelvare-i2c-i2c-dev-make-I2C_FUNCS-ioctl-faster.patch
-jdelvare-i2c-i2c-remove-extraneous-whitespace.patch
-jdelvare-i2c-i2c-core-use-__ATTR.patch
-jdelvare-i2c-i2c-i801-documentation-update.patch
-jdelvare-i2c-i2c-fix-broken-ds1337-initialization.patch
-jdelvare-i2c-i2c-versatile-new-arm-bus-driver.patch
-jdelvare-i2c-i2c-discard-del-bus-wrappers.patch
-jdelvare-i2c-i2c-i801-enable-PEC-on-ICH6.patch
-jdelvare-i2c-i2c-dev-fix-return-value-check.patch
-jdelvare-i2c-i2c-dev-merge-kfree.patch
-jdelvare-i2c-i2c-omap-prescaler-formula.patch
-jdelvare-hwmon-hwmon-f71805f-add-fanctl-1-prepare.patch
-jdelvare-hwmon-hwmon-f71805f-add-fanctl-2-manual-mode.patch
-jdelvare-hwmon-hwmon-f71805f-add-fanctl-3-pwm-freq.patch
-jdelvare-hwmon-hwmon-f71805f-add-fanctl-4-pwm-mode.patch
-jdelvare-hwmon-hwmon-f71805f-add-fanctl-5-speed-mode.patch
-jdelvare-hwmon-hwmon-f71805f-add-fanctl-6-documentation.patch
-jdelvare-hwmon-hwmon-pc87360-set-vrm-using-hwmon-vid-routine.patch
-jdelvare-hwmon-hwmon-hdaps-dmi-detection-data-to-data-section.patch
-jdelvare-hwmon-hwmon-hdaps-BIOS-note.patch
-jdelvare-hwmon-hwmon-it87-drop-smbus-interface-support.patch
-jdelvare-hwmon-hwmon-pc87427-new-driver.patch
-jdelvare-hwmon-hwmon-f71805f-add-f71872f-support.patch
-jdelvare-hwmon-hwmon-f71805f-always-create-all-fans.patch
-jdelvare-hwmon-hwmon-f71805f-fix-address-decoding.patch
-jdelvare-hwmon-hwmon-rudolf-marek-changed-email-address.patch
-jdelvare-hwmon-hwmon-w83793-new-driver.patch
-jdelvare-hwmon-hwmon-w83793-documentation.patch
-jdelvare-hwmon-hwmon-ams-new-driver.patch
-jdelvare-hwmon-hwmon-ams-maintainers.patch
-kconfig-new-function-bool-conf_get_changedvoid.patch
-kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
-kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
-kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
-ata_piix-ide-mode-sata-patch-for-intel-ich9.patch
-pata_it8213-add-new-driver-for-the-it8213-card.patch
-mmc-fix-prev-state-2-=-task_running-problem-on-sd-mmc-card-removal.patch
-git-mtd-build-fix.patch
-zd1211rw-call-ieee80211_rx-in-tasklet.patch
-ieee80211softmac-fix-mutex_lock-at-exit-of-ieee80211_softmac_get_genie.patch
-x86_64-make-the-numa-hash-function-nodemap-allocation.patch
-x86_64-make-the-numa-hash-function-nodemap-allocation-fix.patch
-cleanup-slab-headers--api-to-allow-easy-addition-of-new-slab.patch
-more-slabh-cleanups.patch
-cpuset-rework-cpuset_zone_allowed-api.patch
-slab-use-a-multiply-instead-of-a-divide-in-obj_to_index.patch
-slab-use-a-multiply-instead-of-a-divide-in-obj_to_index-tweaks.patch
-pm-fix-freezing-of-stopped-tasks.patch
-pm-fix-smp-races-in-the-freezer.patch
-touch_atime-cleanup.patch
-relative-atime.patch
-ocfs2-relative-atime-support.patch
-ocfs2-relative-atime-support-tweaks.patch
-optimize-o_direct-on-block-device-v3.patch
-optimize-o_direct-on-block-device-v3-tweak.patch
-debug-add-sysrq_always_enabled-boot-option.patch
-lockdep-filter-off-by-default.patch
-lockdep-improve-verbose-messages.patch
-lockdep-improve-lockdep_reset.patch
-lockdep-clean-up-very_verbose-define.patch
-lockdep-use-chain-hash-on-config_debug_lockdep-too.patch
-lockdep-print-irq-trace-info-on-asserts.patch
-lockdep-fix-possible-races-while-disabling-lock-debugging.patch
-lockdep-fix-possible-races-while-disabling-lock-debugging-fix.patch
-use-activate_mm-in-fs-aiocuse_mm.patch
-fix-numerous-kcalloc-calls-convert-to-kzalloc.patch
-tty-remove-useless-memory-barrier.patch
-config_computone-should-depend-on-isaeisapci.patch
-appldata_mem-dependes-on-vm-counters.patch
-uml-problems-with-linux-ioh.patch
-missing-includes-in-hilkbd.patch
-hci-endianness-annotations.patch
-lockd-endianness-annotations-rebased.patch
-rtc-fix-error-case.patch
-rtc-driver-init-adjustment.patch
-tty_ioc-balance-tty_ldisc_ref.patch
-knfsd-nfsd4-remove-a-dprink-from-nfsd4_lock.patch
-knfsd-svcrpc-fix-gss-krb5i-memory-leak.patch
-knfsd-nfsd4-clarify-units-of-compound_slack_space.patch
-knfsd-nfsd-make-exp_rootfh-handle-exp_parent-errors.patch
-knfsd-nfsd-simplify-exp_pseudoroot.patch
-knfsd-nfsd4-handling-more-nfsd_cross_mnt-errors-in-nfsd4-readdir.patch
-knfsd-nfsd-dont-drop-silently-on-upcall-deferral.patch
-knfsd-svcrpc-remove-another-silent-drop-from-deferral-code.patch
-knfsd-nfsd4-pass-saved-and-current-fh-together-into-nfsd4-operations.patch
-knfsd-nfsd4-remove-spurious-replay_owner-check.patch
-knfsd-nfsd4-move-replay_owner-to-cstate.patch
-knfsd-nfsd4-dont-inline-nfsd4-compound-op-functions.patch
-knfsd-nfsd4-make-verify-and-nverify-wrappers.patch
-knfsd-nfsd4-reorganize-compound-ops.patch
-knfsd-nfsd4-simplify-migration-op-check.patch
-knfsd-nfsd4-simplify-filehandle-check.patch
-knfsd-dont-ignore-kstrdup-failure-in-rpc-caches.patch
-knfsd-fix-up-some-bit-rot-in-exp_export.patch
-ide-hpt3xxn-clocking-fixes.patch
-ide-fix-hpt37x-timing-tables.patch
-ide-optimize-hpt37x-timing-tables.patch
-ide-fix-hpt3xx-hotswap-support.patch
-ide-fix-the-case-of-multiple-hpt3xx-chips-present.patch
-ide-hpt3xx-fix-pci-clock-detection.patch
-ide-hpt3xx-fix-pci-clock-detection-fix-2.patch
-getting-rid-of-all-casts-of-kalloc-calls.patch

Merged into mainline or a subsystem tree.

+infiniband-work-around-gcc-bug-on-sparc64.patch
+kvm-add-valid_vcpu-helper.patch
+kvm-amd-svm-handle-msr_star-in-32-bit-mode.patch
+kvm-amd-svm-save-and-restore-the-floating-point-unit.patch
+config_vm_event_counter-comment-decrustify.patch
+conditionally-check-expected_preempt_count-in-__resched_legal.patch
+fix-for-shmem_truncate_range-bug_on.patch
+rtc-warning-fix.patch
+slab-fix-kmem_ptr_validate-prototype.patch
+fix-kernel-doc-warnings-in-2620-rc1.patch
+make-kernel-printkcignore_loglevel_setup-static.patch
+fs-sysv-proper-prototypes-for-2-functions.patch
+fix-swapped-parameters-in-mm-vmscanc.patch
+add-cscope-generated-files-to-gitignore.patch
+sched-remove-__cpuinitdata-anotation-to-cpu_isolated_map.patch
+fix-vm_events_fold_cpu-build-breakage.patch
+fix-vm_events_fold_cpu-build-breakage-fix.patch
+build-compileh-earlier.patch
+workstruct-add-assign_bits-to-give-an-atomic-bitops-safe-assignment.patch
+workstruct-use-bitops-safe-direct-assignment.patch
+connector-some-fixes-for-ia64-unaligned-access-errors.patch

2.6.20 queue

-revert-generic_file_buffered_write-handle-zero-length-iovec-segments.patch
-revert-generic_file_buffered_write-deadlock-on-vectored-write.patch
-generic_file_buffered_write-cleanup.patch
-mm-only-mm-debug-write-deadlocks.patch
-mm-fix-pagecache-write-deadlocks.patch
-mm-fix-pagecache-write-deadlocks-comment.patch
-mm-fix-pagecache-write-deadlocks-xip.patch
-mm-fix-pagecache-write-deadlocks-mm-pagecache-write-deadlocks-efault-fix.patch
-mm-fix-pagecache-write-deadlocks-zerolength-fix.patch
-mm-fix-pagecache-write-deadlocks-stale-holes-fix.patch
-fs-prepare_write-fixes.patch
-fs-prepare_write-fixes-fuse-fix.patch
-fs-prepare_write-fixes-jffs-fix.patch
-fs-prepare_write-fixes-fat-fix.patch
-fs-fix-cont-vs-deadlock-patches.patch

Dropped (again).

+git-acpi-cpufreq-fixup.patch

Fix git-acpi.patch

+acpi-make-code-static.patch
+acpi-dock-send-a-uevent-to-indicate-a-device-change.patch
+asus_acpi-add-support-for-asus-z81sp.patch

ACPI things

-git-alsa-fixup.patch

Unneeded

+git-alsa-more-borkage.patch

ALSA fix

+agp-fix-detection-of-aperture-size-versus-gtt-size-on-g965.patch

AGP fix

+arm-systemh-build-fix.patch

Fix ARM build

-git-cpufreq-prep.patch
-git-cpufreq-fixup.patch

Unneeded

+gregkh-driver-uio-documentation.patch
+gregkh-driver-uio-irq.patch

driver tree updates

+kobject-kobject_uevent-returns-manageable-value.patch
+proper-prototype-for-drivers-base-initcdriver_init.patch
+kref-refcnt-and-false-positives.patch

driver core fixes and updates

+kthread-api-conversion-for-dvb_frontend-and-av7110.patch
+usbvision-possible-cleanups.patch

DVB things

+infiniband-fix-for-gregkh-depredations.patch

Disable some new infiniband drivers due to their not knowing about
gregkh-driver-network-device.patch.

-git-input-vs-git-alsa.patch

Renamed.

-git-libata-all-fixup.patch

Unneeded

+sata_nv-fix-kfree-ordering-in-remove.patch
+libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch
+pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch

sata/pata things

+driver-for-silan-sc92031-netdev-fix-more.patch

Fix driver-for-silan-sc92031-netdev.patch some more.

+remove-the-broken-skmc-driver.patch

Remove net driver

-spidernet-rx-locking.patch
-spidernet-refactor-rx-refill.patch
+spidernet-remove-rxramfull-tasklet.patch
+spidernet-cleanup-un-needed-api.patch
-spidernet-merge-error-branches.patch
-spidernet-turn-rx-irq-back-on.patch

spidernet update

+ep93xx-some-minor-cleanups-to-the-ep93xx-eth-driver.patch
+problem-phy-probe-not-working-properly-for-ibm_emac-ppc4xx.patch

netdev fixes

+pci-disable-multithreaded-probing.patch

Disable multithreaded-probing. I have enough problems.

-kbuild-make-fusion-mpt-selectable-from-device-drivers.patch

Dropped.

+funsoft-is-bust-on-sparc.patch

Disable funsoft on sparc due to dud patch in the USB queue.

+input-usb-supporting-more-keys-from-the-hut-consumer-page.patch
+usblp-add-serial-number-to-device-id.patch

USB things.

-x86_64-mm-i386-add-idle-notifier.patch
+x86_64-mm-defconfig-update.patch
+x86_64-mm-i386-defconfig-update.patch
+x86_64-mm-copy-user-nocache.patch
+x86_64-mm-amd-tsc-sync.patch
+x86_64-mm-make-the-numa-hash-function-nodemap-allocation.patch
+x86_64-mm-fix-aout-warning.patch

x86_64 tree updates

+revert-x86_64-mm-copy-user-nocache.patch

Toss out old patch from x86_64 tree

+add-memcpy_uncached_read.patch
+add-memcpy_uncached_read-fix.patch
+add-memcpy_uncached_read-tidy.patch
+ib-ipath-use-memcpy_uncached_read-in-rdma-interrupt.patch

Add in the updated version

+get-rid-of-arch_have_xtime_lock.patch
+x86_64-improved-iommu-documentation.patch
+x86_64-do-not-always-end-the-stack-trace-with-ulong_max.patch
+arch-i386-kernel-e820c-should-include-asm-setuph.patch

x86 updates

+lumpy-reclaim-v2.patch
+lumpy-reclaim-v2-page_to_pfn-fix.patch
+lumpy-reclaim-v2-tidy.patch

Teach page reclaim to perform a short physical scan to try to generate free
higher-order pages. Needs work.

+nfs-fix-nr_file_dirty-underflow.patch
+nfs-fix-nr_file_dirty-underflow-tidy.patch

Fix invlaidate_inode_pages2() again.

+alpha-increase-percpu_enough_room.patch

Alpha fix

+vmscanc-account-for-memory-already-freed-in-seeking-to.patch

swsusp fix

+m32r-build-fix-for-processors-without-isa_dsp_level2.patch
+m32r-fix-do_page_fault-and-update_mmu_cache.patch
+m32r-update-defconfig-files-for-v2619.patch
+m32r-fix-kernel-entry-address-of-vmlinux.patch
+m32r-cosmetic-updates-and-trivial-fixes.patch

m32r udpate

+m68k-work-around-binutils-tokenizer-change.patch
+m68k-trivial-build-fixes.patch

m68k update

+ecryptfs-public-key-transport-mechanism-fix.patch

Fix ecryptfs-public-key-transport-mechanism.patch

+vt-refactor-console-sak-processing.patch
+sysctl_ms_jiffies-fix-oldlen-semantics.patch
+remove-include-linux-byteorder-pdp_endianh.patch
+9p-use-kthread_stop-instead-of-sending-a-sigkill.patch
+count_vm_events-warning-fix.patch
+parse-boot-parameter-error.patch
+toshiba-tc86c001-ide-driver-take-2.patch
+char-tty-delete-wake_up_interruptible-after-tty_wakeup.patch
+edac-fix-in-e752x-mc-driver.patch
+edac-add-memory-scrubbing-controls-api-to-core.patch
+edac-add-fully-buffered-dimm-apis-to-core.patch
+disable-init-initramfsc-updated.patch
+disable-init-initramfsc-architectures.patch
+usr-gen_init_cpioc-support-for-hard-links.patch
+ioc3-ioc4-pci-mem-space-resources.patch
+char-isicom-remove-tty_hangwakeup-bottomhalves.patch
+procfs-fix-race-between-proc_readdir-and-remove_proc_entry.patch
+procfs-fix-race-between-proc_readdir-and-remove_proc_entry-fix.patch

Misc.

+tty-make-__proc_set_tty-static.patch
+tty-clarify-disassociate_ctty.patch
+tty-fix-the-locking-for-signal-session-in-disassociate_ctty.patch
+signal-use-kill_pgrp-not-kill_pg-in-the-sunos-compatibility-code.patch
+signal-rewrite-kill_something_info-so-it-uses-newer-helpers.patch
+pid-make-session_of_pgrp-use-struct-pid-instead-of-pid_t.patch
+pid-use-struct-pid-for-talking-about-process-groups-in-exitc.patch
+pid-replace-is_orphaned_pgrp-with-is_current_pgrp_orphaned.patch
+tty-update-the-tty-layer-to-work-with-struct-pid.patch
+pid-replace-do-while_each_task_pid-with-do-while_each_pid_task.patch
+pid-remove-now-unused-do_each_task_pid-and-while_each_task_pid.patch
+pid-remove-the-now-unused-kill_pg-kill_pg_info-and-__kill_pg_info.patch

rework tty pid handling.

+gtod-uninline-jiffiesh.patch
+gtod-fix-multiple-conversion-bugs-in-msecs_to_jiffies.patch
+gtod-fix-timeout-overflow.patch
+gtod-persistent-clock-support-core.patch
+gtod-persistent-clock-support-i386.patch
+dynticks-uninline-irq_enter.patch
+dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie.patch
+hrtimers-namespace-and-enum-cleanup.patch
+hrtimers-clean-up-locking.patch
+hrtimers-add-state-tracking.patch
+hrtimers-clean-up-callback-tracking.patch
+hrtimers-move-and-add-documentation.patch
+acpi-include-fix.patch
+acpi-keep-track-of-timer-broadcast.patch
+acpi-add-state-propagation-for-dynamic-broadcasting.patch
+acpi-cleanups-allow-early-access-to-pmtimer.patch
+i386-apic-clean-up-the-apic-code.patch
+clockevents-core.patch
+clockevents-i386-drivers.patch
+clockevents-i386-hpet-driver.patch
+i386-apic-rework-and-fix-local-apic-calibration.patch
+high-res-timers-core.patch
+high-res-timers-core-do-itimer-rearming-in-process-context.patch
+high-res-timers-allow-tsc-clocksource-if-pmtimer-present.patch
+dynticks-core.patch
+dynticks-add-nohz-stats-to-proc-stat.patch
+dynticks-i386-support-idle-handler-callbacks.patch
+dynticks-i386-prepare-nmi-watchdog.patch
+high-res-timers-dynticks-i386-support-enable-in-kconfig.patch
+debugging-feature-add-proc-timer_stat.patch
+debugging-feature-proc-timer_list.patch

Refreshed, refactored dynticks/hrtimer queue.

+hpet-avoid-warning-message-livelock.patch

hpet fix

+drivers-isdn-pcbit-proper-prototypes.patch

isdn cleanup

+knfsd-sunrpc-update-internal-api-separate-pmap-register-and-temp-sockets.patch
+knfsd-sunrpc-allow-creating-an-rpc-service-without-registering-with-portmapper.patch
+knfsd-sunrpc-cache-remote-peers-address-in-svc_sock.patch
+knfsd-sunrpc-use-sockaddr_storage-to-store-address-in-svc_deferred_req.patch
+knfsd-sunrpc-add-a-function-to-format-the-address-in-an-svc_rqst-for-printing.patch

A partial nfsd update. Eight patches were dropped due to bustage.

+reiser4-fix-write_extent-1.patch

Part of reiser4-fix-write_extent.patch

+fbdev-driver-for-s3-trio-virge.patch
+remove-broken-video-drivers-v4.patch
+tgafb-switch-to-framebuffer_alloc.patch
+tgafb-fix-copying-overlapping-areas.patch
+tgafb-support-the-directcolor-visual.patch
+tgafb-fix-the-mode-register-setting.patch
+tgafb-module-support-fixes.patch
+tgafb-sync-on-green-support-fixes.patch
+tgafb-fix-the-pci-id-table.patch

fbdev updates

-md-change-lifetime-rules-for-md-devices.patch
-md-close-a-race-between-destroying-and-recreating-an-md-device.patch
-md-allow-mddevs-to-live-a-bit-longer-to-avoid-a-loop-with-udev.patch

Dropped.

+slim-debug-output-slm_set_taskperm-remove-horrible-error-handling-code.patch

Fix slim-debug-output.patch




All 693 patches:

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



2006-12-15 14:46:32

by Jiri Slaby

[permalink] [raw]
Subject: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]

Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>
> Will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/

The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png

ATA port is not connected, only 2 SATA disks on my
# lspci -vvxs 02:01.0
02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
TX2plus) (rev 02)
Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 8000 [size=128]
Region 2: I/O ports at 8400 [size=256]
Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at fb000000 (32-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at 50000000 [disabled] [size=32K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12

2.6.19-rc6-mm2 is OK (2.6.19-mm1 untested and won't be)

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

2006-12-15 19:24:38

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]

On Fri, 15 Dec 2006 15:45:55 +0059
Jiri Slaby <[email protected]> wrote:

> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
> >
> > Will appear later at
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>
> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>
> ATA port is not connected, only 2 SATA disks on my
> # lspci -vvxs 02:01.0
> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
> TX2plus) (rev 02)
> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: I/O ports at 8000 [size=128]
> Region 2: I/O ports at 8400 [size=256]
> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
> Region 4: Memory at fb000000 (32-bit, non-prefetchable) [size=128K]
> [virtual] Expansion ROM at 50000000 [disabled] [size=32K]
> Capabilities: [60] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>

Presumably

void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;

gave us a null pointer.

Something like this:

diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
--- a/drivers/ata/sata_promise.c~a
+++ a/drivers/ata/sata_promise.c
@@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
unsigned int tmp;

+ if (!mmio) {
+ rc = -EDOM;
+ goto out_kfree;
+ }
tmp = readl(mmio + 0x014);
tmp = (tmp & ~3) | 1; /* set bits 1:0 = 0:1 */
writel(tmp, mmio + 0x014);
_

should perhaps let you wobble to a state where you can get us the full
dmesg output, please.

Actually, that should already be possible simply using netconsole.

2006-12-15 21:02:09

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

On Fri, 15 Dec 2006 21:39:36 +0100
Damien Wyart <[email protected]> wrote:

> With this new kernel, I notice two messages I do not have with
> 2.6.19-rc6-mm2 :
>
> Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling barriers,trial barrier write failed
> Dec 15 20:00:47 brouette kernel: Filesystem "sda5": Disabling barriers,trial barrier write failed
>
> Nothing changed in the config between the two, and going back to
> 2.6.19-rc6-mm2 do not give the messages.

I don't think anything has changed in this area in XFS. I'd expect that
something got broken in sata, ata_piix or the block core which caused the
"trial barrier write" to start failing. Various cc's hopefully added.

> Also, I got panics when unmounting reiser4 filesystems with
> 2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4
> being broken in 2.6.19-mm1 (even if it is not listed in notes for
> 2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did
> not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now.
> For the moment, I mainly wanted to report the xfs messages which seems
> a bit suspect.

The reiser4 failure is unexpected. Could you please see if you can capture
a trae, let the people at [email protected] know?

Thanks.

2006-12-15 21:06:22

by Damien Wyart

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

With this new kernel, I notice two messages I do not have with
2.6.19-rc6-mm2 :

Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling barriers,trial barrier write failed
Dec 15 20:00:47 brouette kernel: Filesystem "sda5": Disabling barriers,trial barrier write failed

Nothing changed in the config between the two, and going back to
2.6.19-rc6-mm2 do not give the messages.

Also, I got panics when unmounting reiser4 filesystems with
2.6.20-rc1-mm1 but I guess this is related to your waring about reiser4
being broken in 2.6.19-mm1 (even if it is not listed in notes for
2.6.20-rc1-mm1)... I attach dmesg and config, but the reiser4 panics did
not get logged and I am not able to reboot on 2.6.20-rc1-mm1 right now.
For the moment, I mainly wanted to report the xfs messages which seems
a bit suspect.

--
Damien Wyart


Attachments:
(No filename) (832.00 B)
dmesg (31.94 kB)
config (38.83 kB)
Download all attachments

2006-12-15 22:48:46

by Jiri Slaby

[permalink] [raw]
Subject: Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]

Andrew Morton wrote:
> On Fri, 15 Dec 2006 15:45:55 +0059
> Jiri Slaby <[email protected]> wrote:
>
>> Andrew Morton wrote:
>>> Temporarily at
>>>
>>> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>>>
>>> Will appear later at
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
>> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>>
>> ATA port is not connected, only 2 SATA disks on my
>> # lspci -vvxs 02:01.0
>> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
>> TX2plus) (rev 02)
>> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: I/O ports at 8000 [size=128]
>> Region 2: I/O ports at 8400 [size=256]
>> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
>> Region 4: Memory at fb000000 (32-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at 50000000 [disabled] [size=32K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
>> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
>> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
>> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>>
>
> Presumably
>
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
>
> gave us a null pointer.
>
> Something like this:
>
> diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
> --- a/drivers/ata/sata_promise.c~a
> +++ a/drivers/ata/sata_promise.c
> @@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
> unsigned int tmp;
>
> + if (!mmio) {
> + rc = -EDOM;
> + goto out_kfree;
> + }
> tmp = readl(mmio + 0x014);
> tmp = (tmp & ~3) | 1; /* set bits 1:0 = 0:1 */
> writel(tmp, mmio + 0x014);
> _
>
> should perhaps let you wobble to a state where you can get us the full
> dmesg output, please.
>
> Actually, that should already be possible simply using netconsole.

I set it up and here it comes:
[ 6.779351] ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 21 (level, low) -> IRQ 19
[ 6.779483] sata_promise PATA port found
[ 6.779584] ata3: SATA max UDMA/133 cmd 0xF8816200 ctl 0xF8816238 bmdma 0x0
irq 19
[ 6.779708] ata4: SATA max UDMA/133 cmd 0xF8816280 ctl 0xF88162B8 bmdma 0x0
irq 19
[ 6.779831] BUG: unable to handle kernel NULL pointer dereference at virtual
address 00000014
[ 6.779958] printing eip:
[ 6.780020] c02753b9
[ 6.780080] *pde = 00000000
[ 6.780142] Oops: 0000 [#1]
[ 6.780202] SMP
[ 6.780328] last sysfs file:
[ 6.780389] Modules linked in:
[ 6.780488] CPU: 1
[ 6.780488] EIP: 0060:[<c02753b9>] Not tainted VLI
[ 6.780490] EFLAGS: 00010202 (2.6.20-rc1-mm1 #203)
[ 6.780680] EIP is at pdc_port_start+0x82/0xb0
[ 6.780742] eax: 00000001 ebx: f7e3d9a0 ecx: 00000000 edx: 00000000
[ 6.780808] esi: f7dcc2e8 edi: 00000000 ebp: c193fe3c esp: c193fe24
[ 6.780873] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
[ 6.780938] Process swapper (pid: 1, ti=c193e000 task=c1923a90 task.ti=c193e000)
[ 6.781004] Stack: 000000d0 c1a59a80 c1adcc48 f7ea4000 f88162b8 f7dcc2e8
c193fe90 c026c724
[ 6.781398] 00000078 00000004 00000053 c043d998 f8816280 f88162b8
00000000 00000013
[ 6.781789] f7ea4000 f7d91b00 f8816280 c1adcc48 00000013 c1adcc00
00000002 c01de64f
[ 6.782180] Call Trace:
[ 6.782298] [<c0103f1b>] show_trace_log_lvl+0x1a/0x30
[ 6.782396] [<c0103fd6>] show_stack_log_lvl+0xa5/0xca
[ 6.782494] [<c01041ce>] show_registers+0x1d3/0x2b8
[ 6.782591] [<c01043d4>] die+0x121/0x243
[ 6.782690] [<c01193b0>] do_page_fault+0x2b8/0x5e8
[ 6.782788] [<c0389e74>] error_code+0x7c/0x84
[ 6.782885] [<c026c724>] ata_device_add+0x1b1/0x516
[ 6.782983] [<c027568e>] pdc_ata_init_one+0x2a7/0x3e9
[ 6.783081] [<c01e057e>] pci_device_probe+0x44/0x5f
[ 6.783180] [<c02432a2>] driver_probe_device+0x75/0x12c
[ 6.783279] [<c0243470>] __driver_attach+0x8c/0x8e
[ 6.783376] [<c02428b3>] bus_for_each_dev+0x44/0x62
[ 6.783476] [<c0243161>] driver_attach+0x19/0x1b
[ 6.783574] [<c0242ba7>] bus_add_driver+0x6a/0x188
[ 6.783671] [<c02436c9>] driver_register+0x54/0x84
[ 6.783768] [<c01e06e0>] __pci_register_driver+0x45/0x73
[ 6.783865] [<c0520f34>] pdc_ata_init+0xf/0x1b
[ 6.783967] [<c01004b6>] init+0x10d/0x310
[ 6.784063] [<c0103bbf>] kernel_thread_helper+0x7/0x18
[ 6.784160] =======================
[ 6.784224] Code: 00 8b 45 f0 e8 ca 25 e9 ff 89 03 85 c0 74 32 89 9e 54 20 00
00 8b 45 ec f6 00 01 74 b6 89 f0 e8 99 1b ff ff 85 c0 74 ab 8b 56 64 <8b> 42 14
83 e0 fc 83 c8 01 89 42 14 89 f8 83 c4 0c 5b 5e 5f 5d
[ 6.786508] EIP: [<c02753b9>] pdc_port_start+0x82/0xb0 SS:ESP 0068:c193fe24
[ 6.786641] <0>Kernel panic - not syncing: Attempted to kill init!
[ 6.787970]

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

2006-12-15 23:26:17

by Jiri Slaby

[permalink] [raw]
Subject: WARNING (1) at .../arch/i386/mm/highmem.c:49 [Was: 2.6.20-rc1-mm1]

Andrew Morton wrote:
> Temporarily at
>
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>
> Will appear later at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/

Ok, after fixing sata_promise, I got this 7 times:
[ 30.957539] WARNING (1) at /home/l/latest/xxx/arch/i386/mm/highmem.c:49
kmap_atomic()
[ 30.957642] [<c0103f1b>] show_trace_log_lvl+0x1a/0x30
[ 30.957748] [<c01045d5>] show_trace+0x12/0x14
[ 30.957846] [<c010465c>] dump_stack+0x16/0x18
[ 30.957944] [<c011a20b>] kmap_atomic+0x1f8/0x20d
[ 30.958041] [<c01b1921>] ntfs_end_buffer_async_read+0x191/0x2ed
[ 30.958142] [<c0182f3a>] end_bio_bh_io_sync+0x26/0x3f
[ 30.958241] [<c01849d4>] bio_endio+0x37/0x62
[ 30.958338] [<c01cc500>] __end_that_request_first+0x224/0x445
[ 30.958441] [<c01cc729>] end_that_request_chunk+0x8/0xa
[ 30.958541] [<c025fe3a>] scsi_end_request+0x1f/0xc6
[ 30.958640] [<c02600c8>] scsi_io_completion+0x1a1/0x336
[ 30.958738] [<c026578d>] sd_rw_intr+0x23/0x1ab
[ 30.958835] [<c025c38d>] scsi_finish_command+0x42/0x47
[ 30.958935] [<c02607f8>] scsi_softirq_done+0x64/0xca
[ 30.959032] [<c01ce2c9>] blk_done_softirq+0x54/0x62
[ 30.959132] [<c0126a25>] __do_softirq+0x75/0xde
[ 30.959229] [<c0126ac9>] do_softirq+0x3b/0x3d
[ 30.959326] [<c0126d5e>] irq_exit+0x3b/0x3e
[ 30.959423] [<c0105746>] do_IRQ+0x45/0x7f
[ 30.959540] [<c010397f>] common_interrupt+0x23/0x28
[ 30.959713] [<c010138b>] cpu_idle+0x7c/0xba
[ 30.959809] [<c01006dc>] rest_init+0x23/0x37
[ 30.959951] [<c050a7df>] start_kernel+0x337/0x3e8
[ 30.960090] [<00000000>] 0x0

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

2006-12-15 23:56:26

by Jiri Slaby

[permalink] [raw]
Subject: Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]

Mikael Pettersson wrote:
> Applying the trivial patch below on top of 2.6.20-rc1-mm1 should

Yup, Jeff fwd me this yet and it works.

thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

2006-12-15 23:59:46

by Mikael Pettersson

[permalink] [raw]
Subject: Re: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]

On Fri, 15 Dec 2006 11:24:12 -0800, Andrew Morton wrote:
>On Fri, 15 Dec 2006 15:45:55 +0059
>Jiri Slaby <[email protected]> wrote:
>
>> Andrew Morton wrote:
>> > Temporarily at
>> >
>> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>> >
>> > Will appear later at
>> >
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>>
>> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
>> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>>
>> ATA port is not connected, only 2 SATA disks on my
>> # lspci -vvxs 02:01.0
>> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
>> TX2plus) (rev 02)
>> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR-
>> Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
>> Interrupt: pin A routed to IRQ 19
>> Region 0: I/O ports at 8000 [size=128]
>> Region 2: I/O ports at 8400 [size=256]
>> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
>> Region 4: Memory at fb000000 (32-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at 50000000 [disabled] [size=32K]
>> Capabilities: [60] Power Management version 2
>> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
>> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
>> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
>> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>>
>
>Presumably
>
> void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
>
>gave us a null pointer.

Yes, it does look like pdc_port_start() is invoked with scr_addr
being zero for the port.

The -mm patch kit includes the Promise 2037x PATA support patch,
via libata-all. That patch is incomplete and actually breaks 2057x
chips: it leaves the SATA flag set for all ports on 2057x, which
makes sata_scr_valid() erroneously return true for the PATA port,
and that breaks many things including pdc_port_start().

Applying the trivial patch below on top of 2.6.20-rc1-mm1 should
fix the oops and even make the PATA port work on the 2057x.
With this patch -mm1's sata_promise.c will match what I've been
using recently to access both SATA and PATA devices on 2057x.

/Mikael

diff -rupN linux-2.6.20-rc1-mm1/drivers/ata/sata_promise.c linux-2.6.20-rc1-mm1.sata_promise-2057x-pata-fix/drivers/ata/sata_promise.c
--- linux-2.6.20-rc1-mm1/drivers/ata/sata_promise.c 2006-12-15 23:33:17.000000000 +0100
+++ linux-2.6.20-rc1-mm1.sata_promise-2057x-pata-fix/drivers/ata/sata_promise.c 2006-12-15 23:58:09.000000000 +0100
@@ -213,7 +213,7 @@ static const struct ata_port_info pdc_po
/* board_2057x */
{
.sht = &pdc_ata_sht,
- .flags = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
+ .flags = PDC_COMMON_FLAGS /* | ATA_FLAG_SATA */,
.pio_mask = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask = 0x7f, /* udma0-6 ; FIXME */

2006-12-16 00:04:42

by Adrian Bunk

[permalink] [raw]
Subject: 2.6.20-rc1-mm1: unused sysrq_timer_list_show()

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +debugging-feature-proc-timer_list.patch
>
> Refreshed, refactored dynticks/hrtimer queue.
>...

I'd assume sysrq_timer_list_show() wasn't intended to be unused?

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2006-12-16 00:17:08

by Andrew Morton

[permalink] [raw]
Subject: Re: WARNING (1) at .../arch/i386/mm/highmem.c:49 [Was: 2.6.20-rc1-mm1]

On Sat, 16 Dec 2006 00:25:43 +0059
Jiri Slaby <[email protected]> wrote:

> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
> >
> > Will appear later at
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>
> Ok, after fixing sata_promise, I got this 7 times:
> [ 30.957539] WARNING (1) at /home/l/latest/xxx/arch/i386/mm/highmem.c:49
> kmap_atomic()
> [ 30.957642] [<c0103f1b>] show_trace_log_lvl+0x1a/0x30
> [ 30.957748] [<c01045d5>] show_trace+0x12/0x14
> [ 30.957846] [<c010465c>] dump_stack+0x16/0x18
> [ 30.957944] [<c011a20b>] kmap_atomic+0x1f8/0x20d
> [ 30.958041] [<c01b1921>] ntfs_end_buffer_async_read+0x191/0x2ed
> [ 30.958142] [<c0182f3a>] end_bio_bh_io_sync+0x26/0x3f
> [ 30.958241] [<c01849d4>] bio_endio+0x37/0x62
> [ 30.958338] [<c01cc500>] __end_that_request_first+0x224/0x445
> [ 30.958441] [<c01cc729>] end_that_request_chunk+0x8/0xa
> [ 30.958541] [<c025fe3a>] scsi_end_request+0x1f/0xc6
> [ 30.958640] [<c02600c8>] scsi_io_completion+0x1a1/0x336
> [ 30.958738] [<c026578d>] sd_rw_intr+0x23/0x1ab
> [ 30.958835] [<c025c38d>] scsi_finish_command+0x42/0x47
> [ 30.958935] [<c02607f8>] scsi_softirq_done+0x64/0xca
> [ 30.959032] [<c01ce2c9>] blk_done_softirq+0x54/0x62
> [ 30.959132] [<c0126a25>] __do_softirq+0x75/0xde
> [ 30.959229] [<c0126ac9>] do_softirq+0x3b/0x3d
> [ 30.959326] [<c0126d5e>] irq_exit+0x3b/0x3e
> [ 30.959423] [<c0105746>] do_IRQ+0x45/0x7f
> [ 30.959540] [<c010397f>] common_interrupt+0x23/0x28
> [ 30.959713] [<c010138b>] cpu_idle+0x7c/0xba
> [ 30.959809] [<c01006dc>] rest_init+0x23/0x37
> [ 30.959951] [<c050a7df>] start_kernel+0x337/0x3e8

bah, that's a false positive. I'll teach kmap_atomic-debugging.patch about
KM_BIO_SRC_IRQ and KM_BIO_DST_IRQ, thanks.

2006-12-16 07:59:11

by Ingo Molnar

[permalink] [raw]
Subject: [patch] debugging feature: SysRq-Q to print timers


* Adrian Bunk <[email protected]> wrote:

> On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-mm1:
> >...
> > +debugging-feature-proc-timer_list.patch
> >
> > Refreshed, refactored dynticks/hrtimer queue.
> >...
>
> I'd assume sysrq_timer_list_show() wasn't intended to be unused?

correct, there's a sysrq side of it, but i forgot to send the patch to
Andrew. Find it below.

Ingo

----------------->
Subject: [patch] debugging feature: SysRq-Q to print timers
From: Ingo Molnar <[email protected]>

add SysRq-Q to print pending timers and other timer info.

Signed-off-by: Ingo Molnar <[email protected]>
---
drivers/char/sysrq.c | 14 +++++++++++++-
include/linux/hrtimer.h | 3 +++
2 files changed, 16 insertions(+), 1 deletion(-)

Index: linux/drivers/char/sysrq.c
===================================================================
--- linux.orig/drivers/char/sysrq.c
+++ linux/drivers/char/sysrq.c
@@ -36,6 +36,7 @@
#include <linux/workqueue.h>
#include <linux/kexec.h>
#include <linux/irq.h>
+#include <linux/hrtimer.h>

#include <asm/ptrace.h>
#include <asm/irq_regs.h>
@@ -159,6 +160,17 @@ static struct sysrq_key_op sysrq_sync_op
.enable_mask = SYSRQ_ENABLE_SYNC,
};

+static void sysrq_handle_show_timers(int key, struct tty_struct *tty)
+{
+ sysrq_timer_list_show();
+}
+
+static struct sysrq_key_op sysrq_show_timers_op = {
+ .handler = sysrq_handle_show_timers,
+ .help_msg = "show-all-timers(Q)",
+ .action_msg = "Show Pending Timers",
+};
+
static void sysrq_handle_mountro(int key, struct tty_struct *tty)
{
emergency_remount();
@@ -339,7 +351,7 @@ static struct sysrq_key_op *sysrq_key_ta
/* This will often be registered as 'Off' at init time */
NULL, /* o */
&sysrq_showregs_op, /* p */
- NULL, /* q */
+ &sysrq_show_timers_op, /* q */
&sysrq_unraw_op, /* r */
&sysrq_sync_op, /* s */
&sysrq_showstate_op, /* t */
Index: linux/include/linux/hrtimer.h
===================================================================
--- linux.orig/include/linux/hrtimer.h
+++ linux/include/linux/hrtimer.h
@@ -364,6 +364,9 @@ static inline void show_no_hz_stats(stru
/* Bootup initialization: */
extern void __init hrtimers_init(void);

+/* Show pending timers: */
+extern void sysrq_timer_list_show(void);
+
/*
* Timer-statistics info:
*/

2006-12-16 13:20:17

by Jan Dittmer

[permalink] [raw]
Subject: (Cross) compiling fails on first try (was Re: 2.6.20-rc1-mm1)

Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc,
sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs.
2.6.20-rc1 is also affected.


# make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um defconfig
<cut>
# make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um
GEN /tmp/tmp.abUIc11429/out/um/Makefile
scripts/kconfig/conf -s arch/um/Kconfig
MKDIR /tmp/tmp.abUIc11429/out/um/arch/um/include
SYMLINK arch/um/include/kern_constants.h
SYMLINK include/asm-um/arch
SYMLINK arch/um/include/sysdep
SYMLINK arch/um/os
SYMLINK include/asm-um/archparam.h
SYMLINK include/asm-um/system.h
SYMLINK include/asm-um/sigcontext.h
SYMLINK include/asm-um/processor.h
SYMLINK include/asm-um/ptrace.h
SYMLINK include/asm-um/module.h
SYMLINK include/asm-um/vm-flags.h
SYMLINK include/asm-um/elf.h
SYMLINK include/asm-um/host_ldt.h
CHK arch/um/include/uml-config.h
UPD arch/um/include/uml-config.h
CC arch/um/sys-x86_64/user-offsets.s
CHK arch/um/include/user_constants.h
UPD arch/um/include/user_constants.h
Using /tmp/x as source for kernel
GEN /tmp/tmp.abUIc11429/out/um/Makefile
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/linux/compile.h
UPD include/linux/compile.h
CHK include/linux/utsrelease.h
"2.6.20-rc1-mm1cat:include/config/kernel.release:Nosuchfileordirectory" exceeds 64 characters
make[1]: *** [include/linux/utsrelease.h] Error 1
make: *** [_all] Error 2

# make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um
SYMLINK arch/um/include/kern_constants.h
SYMLINK arch/um/include/sysdep
make[2]: `arch/um/sys-x86_64/user-offsets.s' is up to date.
Using /tmp/x as source for kernel
GEN /tmp/tmp.abUIc11429/out/um/Makefile
CHK include/linux/version.h
CHK include/linux/compile.h
CHK include/linux/utsrelease.h
UPD include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-um
CC arch/um/kernel/asm-offsets.s
GEN include/asm-um/asm-offsets.h
CC scripts/mod/empty.o
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/kallsyms
HOSTCC scripts/bin2c
CC init/main.o
CC init/version.o
CC init/do_mounts.o
LD init/mounts.o
CC init/noinitramfs.o


Thanks,

Jan

2006-12-16 13:56:52

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] drivers/ide/pci/tc86c001.c: make a function static

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +toshiba-tc86c001-ide-driver-take-2.patch
>...
> Misc.
>...

This patch makes the needlessly global init_hwif_tc86c001() static.

Signed-off-by: Adrian Bunk <[email protected]>

---

BTW:
I'm not sure whether it'd be a good idea to include such a driver for
the legacy IDE subsystem without a libata based driver for the same
hardware.

--- linux-2.6.20-rc1-mm1/drivers/ide/pci/tc86c001.c.old 2006-12-15 21:58:44.000000000 +0100
+++ linux-2.6.20-rc1-mm1/drivers/ide/pci/tc86c001.c 2006-12-15 21:58:54.000000000 +0100
@@ -204,7 +204,7 @@
return 0;
}

-void __devinit init_hwif_tc86c001(ide_hwif_t *hwif)
+static void __devinit init_hwif_tc86c001(ide_hwif_t *hwif)
{
unsigned long sc_base = pci_resource_start(hwif->pci_dev, 5);
u16 scr1 = hwif->INW(sc_base + 0x00);;

2006-12-16 13:56:56

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] make uio_irq_handler() static

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +gregkh-driver-uio-irq.patch
>
> driver tree updates
>...

This patch makes the needlessly global uio_irq_handler() static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.20-rc1-mm1/drivers/uio/uio_irq.c.old 2006-12-15 22:23:23.000000000 +0100
+++ linux-2.6.20-rc1-mm1/drivers/uio/uio_irq.c 2006-12-15 22:33:40.000000000 +0100
@@ -22,7 +22,7 @@

static struct uio_device *uio_irq_idev;

-irqreturn_t uio_irq_handler(int irq, void *dev_id)
+static irqreturn_t uio_irq_handler(int irq, void *dev_id)
{
return IRQ_HANDLED;
}

2006-12-16 13:57:26

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] mm/vmscan.c: make a function static

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +lumpy-reclaim-v2.patch
>...
> Teach page reclaim to perform a short physical scan to try to generate free
> higher-order pages. Needs work.
>...

This patch makes the needlessly global __isolate_lru_page() static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.20-rc1-mm1/mm/vmscan.c.old 2006-12-15 23:37:18.000000000 +0100
+++ linux-2.6.20-rc1-mm1/mm/vmscan.c 2006-12-16 00:36:00.000000000 +0100
@@ -616,7 +616,7 @@
*
* returns 0 on success, -ve errno on failure.
*/
-int __isolate_lru_page(struct page *page, int active)
+static int __isolate_lru_page(struct page *page, int active)
{
int ret = -EINVAL;


2006-12-16 13:57:31

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] drivers/video/{s3fb,svgalib}.c: possible cleanups

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.19-mm1:
>...
> +fbdev-driver-for-s3-trio-virge.patch
>...
> fbdev updates
>...

This patch contains the following possible cleanups:
- CodingStyle:
- opening braces of functions at the beginning of the next line
- C99 struct initializers
- make the following needlessly global functions static:
- s3fb.c: s3fb_settile()
- s3fb.c: s3fb_tilecopy()
- s3fb.c: s3fb_tilefill()
- s3fb.c: s3fb_tileblit()
- s3fb.c: s3fb_tilecursor()
- s3fb.c: s3fb_init()
- svgalib.c: svga_regset_size()
- #if 0 the following unused global functions:
- svga_wseq_multi()
- svga_dump_var()

Signed-off-by: Adrian Bunk <[email protected]>

---

drivers/video/s3fb.c | 29 +++++++++++++++++------------
drivers/video/svgalib.c | 11 +++++------
include/linux/svga.h | 4 ----
3 files changed, 22 insertions(+), 22 deletions(-)

--- linux-2.6.20-rc1-mm1/drivers/video/s3fb.c.old 2006-12-15 22:47:49.000000000 +0100
+++ linux-2.6.20-rc1-mm1/drivers/video/s3fb.c 2006-12-15 22:51:26.000000000 +0100
@@ -161,7 +161,8 @@

/* Set font in text (tileblit) mode */

-void s3fb_settile(struct fb_info *info, struct fb_tilemap *map) {
+static void s3fb_settile(struct fb_info *info, struct fb_tilemap *map)
+{
const u8 *font = map->data;
u8* fb = (u8 *) info->screen_base;
int i, c;
@@ -185,7 +186,8 @@

/* Copy area in text (tileblit) mode */

-void s3fb_tilecopy(struct fb_info *info, struct fb_tilearea *area) {
+static void s3fb_tilecopy(struct fb_info *info, struct fb_tilearea *area)
+{
int dx, dy;
// int colstride = 4;
int colstride = 2;
@@ -222,7 +224,8 @@

/* Fill area in text (tileblit) mode */

-void s3fb_tilefill(struct fb_info *info, struct fb_tilerect *rect) {
+static void s3fb_tilefill(struct fb_info *info, struct fb_tilerect *rect)
+{
int dx, dy;
// int colstride = 8;
int colstride = 4;
@@ -244,7 +247,8 @@

/* Write text in text (tileblit) mode */

-void s3fb_tileblit(struct fb_info *info, struct fb_tileblit *blit) {
+static void s3fb_tileblit(struct fb_info *info, struct fb_tileblit *blit)
+{
int dx, dy, i;
// int colstride = 8;
int colstride = 4;
@@ -270,7 +274,8 @@

/* Set cursor in text (tileblit) mode */

-void s3fb_tilecursor(struct fb_info *info, struct fb_tilecursor *cursor) {
+static void s3fb_tilecursor(struct fb_info *info, struct fb_tilecursor *cursor)
+{
u8 cs = 0x0d;
u8 ce = 0x0e;
u16 pos = cursor->sx + (info->var.xoffset / 8)
@@ -1183,12 +1188,12 @@
MODULE_DEVICE_TABLE(pci, s3_devices);

static struct pci_driver s3fb_pci_driver = {
- name:"s3fb",
- id_table:s3_devices,
- probe:s3_pci_probe,
- remove:__devexit_p(s3_pci_remove),
-// suspend:s3_pci_suspend,
-// resume:s3_pci_resume,
+ .name = "s3fb",
+ .id_table = s3_devices,
+ .probe = s3_pci_probe,
+ .remove = __devexit_p(s3_pci_remove),
+// .suspend = s3_pci_suspend,
+// .resume = s3_pci_resume,
};

/* Parse user speficied options */
@@ -1228,7 +1233,7 @@

/* Driver Initialisation */

-int __init s3fb_init(void)
+static int __init s3fb_init(void)
{

#ifndef MODULE
--- linux-2.6.20-rc1-mm1/include/linux/svga.h.old 2006-12-15 22:52:12.000000000 +0100
+++ linux-2.6.20-rc1-mm1/include/linux/svga.h 2006-12-15 22:53:05.000000000 +0100
@@ -91,8 +91,6 @@


void svga_wcrt_multi(const struct vga_regset *regset, u32 value);
-void svga_wseq_multi(const struct vga_regset *regset, u32 value);
-unsigned int svga_regset_size(const struct vga_regset *regset);

void svga_set_default_gfx_regs(void);
void svga_set_default_atc_regs(void);
@@ -100,8 +98,6 @@
void svga_set_default_crt_regs(void);
void svga_set_textmode_vga_regs(void);

-void svga_dump_var(struct fb_var_screeninfo *var, int node);
-
int svga_compute_pll(const struct svga_pll *pll, u32 f_wanted, u16 *m, u16 *n, u16 *r, int node);
int svga_check_timings(const struct svga_timing_regs *tm, struct fb_var_screeninfo *var, int node);
void svga_set_timings(const struct svga_timing_regs *tm, struct fb_var_screeninfo *var, u32 hmul, u32 hdiv, u32 vmul, u32 vdiv, int node);
--- linux-2.6.20-rc1-mm1/drivers/video/svgalib.c.old 2006-12-15 22:54:31.000000000 +0100
+++ linux-2.6.20-rc1-mm1/drivers/video/svgalib.c 2006-12-15 22:54:56.000000000 +0100
@@ -42,8 +42,8 @@
}
}

+#if 0
/* Write a sequence register value spread across multiple registers */
-
void svga_wseq_multi(const struct vga_regset *regset, u32 value) {

u8 regval, bitval, bitnum;
@@ -62,8 +62,9 @@
regset ++;
}
}
+#endif /* 0 */

-unsigned int svga_regset_size(const struct vga_regset *regset)
+static unsigned int svga_regset_size(const struct vga_regset *regset)
{
u8 count = 0;

@@ -163,6 +164,7 @@
vga_w(NULL, VGA_ATT_W, 0x20);
}

+#if 0
void svga_dump_var(struct fb_var_screeninfo *var, int node)
{
pr_debug("fb%d: var.vmode : 0x%X\n", node, var->vmode);
@@ -180,6 +182,7 @@
pr_debug("fb%d: var.sync : 0x%X\n", node, var->sync);
pr_debug("fb%d: var.pixclock : %d\n\n", node, var->pixclock);
}
+#endif /* 0 */

/* ------------------------------------------------------------------------- */

@@ -433,9 +436,7 @@
}


-EXPORT_SYMBOL(svga_wseq_multi);
EXPORT_SYMBOL(svga_wcrt_multi);
-EXPORT_SYMBOL(svga_regset_size);

EXPORT_SYMBOL(svga_set_default_gfx_regs);
EXPORT_SYMBOL(svga_set_default_atc_regs);
@@ -443,8 +444,6 @@
EXPORT_SYMBOL(svga_set_default_crt_regs);
EXPORT_SYMBOL(svga_set_textmode_vga_regs);

-EXPORT_SYMBOL(svga_dump_var);
-
EXPORT_SYMBOL(svga_compute_pll);
EXPORT_SYMBOL(svga_check_timings);
EXPORT_SYMBOL(svga_set_timings);

2006-12-16 14:14:43

by Alan

[permalink] [raw]
Subject: Re: [-mm patch] drivers/ide/pci/tc86c001.c: make a function static

> I'm not sure whether it'd be a good idea to include such a driver for
> the legacy IDE subsystem without a libata based driver for the same
> hardware.

It would be nice to have a libata driver but having the hardware
supported is far better than no support at all.

2006-12-16 17:41:29

by Randy Dunlap

[permalink] [raw]
Subject: Re: [-mm patch] drivers/video/{s3fb,svgalib}.c: possible cleanups

On Sat, 16 Dec 2006 14:56:57 +0100 Adrian Bunk wrote:

> This patch contains the following possible cleanups:
> - CodingStyle:
> - opening braces of functions at the beginning of the next line
> - C99 struct initializers

I don't see anything about struct initializers in CodingStyle,
but I would say that it's a good candidate for addition.

---
~Randy

2006-12-16 18:37:28

by Ondrej Zajicek

[permalink] [raw]
Subject: Re: [-mm patch] drivers/video/{s3fb,svgalib}.c: possible cleanups

On Sat, Dec 16, 2006 at 02:56:57PM +0100, Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - CodingStyle:
> - opening braces of functions at the beginning of the next line
> - C99 struct initializers
> - make the following needlessly global functions static:
> - s3fb.c: s3fb_settile()
> - s3fb.c: s3fb_tilecopy()
> - s3fb.c: s3fb_tilefill()
> - s3fb.c: s3fb_tileblit()
> - s3fb.c: s3fb_tilecursor()
> - s3fb.c: s3fb_init()
> - svgalib.c: svga_regset_size()
> - #if 0 the following unused global functions:
> - svga_wseq_multi()
> - svga_dump_var()
>
> Signed-off-by: Adrian Bunk <[email protected]>

Acked-by: Ondrej Zajicek <[email protected]>

--
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: [email protected], jabber: [email protected])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

2006-12-16 19:31:48

by Frederik Deweerdt

[permalink] [raw]
Subject: [-mm patch] noinitramfs cleanup

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>
> +disable-init-initramfsc-updated.patch


Jean-Paul,

The following patch silences the following compile time warning introduced
by the disable-init-initramfsc-updated patch:

CC init/noinitramfs.o
init/noinitramfs.c:42: warning : initialization from incompatible pointer type

In addition, I've cleaned up the headers and added some error handling.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[email protected]>

diff --git a/init/noinitramfs.c b/init/noinitramfs.c
index 01f88c3..f4c1a3a 100644
--- a/init/noinitramfs.c
+++ b/init/noinitramfs.c
@@ -18,25 +18,35 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
#include <linux/init.h>
-#include <linux/fs.h>
-#include <linux/slab.h>
-#include <linux/types.h>
-#include <linux/fcntl.h>
-#include <linux/delay.h>
-#include <linux/string.h>
+#include <linux/stat.h>
+#include <linux/kdev_t.h>
#include <linux/syscalls.h>

/*
* Create a simple rootfs that is similar to the default initramfs
*/
-static void __init default_rootfs(void)
+static int __init default_rootfs(void)
{
- int mkdir_err = sys_mkdir("/dev", 0755);
- int err = sys_mknod((const char __user *) "/dev/console",
- S_IFCHR | S_IRUSR | S_IWUSR,
- new_encode_dev(MKDEV(5, 1)));
- if (err == -EROFS)
- printk("Warning: Failed to create a rootfs\n");
- mkdir_err = sys_mkdir("/root", 0700);
+ int err;
+
+ err = sys_mkdir("/dev", 0755);
+ if (err < 0)
+ goto out;
+
+ err = sys_mknod((const char __user *) "/dev/console",
+ S_IFCHR | S_IRUSR | S_IWUSR,
+ new_encode_dev(MKDEV(5, 1)));
+ if (err < 0)
+ goto out;
+
+ err = sys_mkdir("/root", 0700);
+ if (err < 0)
+ goto out;
+
+ return 0;
+
+out:
+ printk(KERN_WARNING "Failed to create a rootfs\n");
+ return err;
}
rootfs_initcall(default_rootfs);

2006-12-17 11:07:17

by Damien Wyart

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

> > Also, I got panics when unmounting reiser4 filesystems with
> > 2.6.20-rc1-mm1 but I guess this is related to your waring about
> > reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
> > notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
> > reiser4 panics did not get logged and I am not able to reboot on
> > 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report
> > the xfs messages which seems a bit suspect.

> The reiser4 failure is unexpected. Could you please see if you can
> capture a trace, let the people at [email protected] know?

Ok, I've handwritten the messages, here they are :

reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597)
write log failed (-5)

[ got 2 copies of them because I have 2 reiser4 fs)

I got them mainly when I try to reboot or halt the machine, and the
process doesn't finish, the computer gets stuck after the reiser4
messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2.

--
Damien Wyart

2006-12-17 18:07:19

by Sergei Shtylyov

[permalink] [raw]
Subject: Re: [-mm patch] drivers/ide/pci/tc86c001.c: make a function static

Hello.

Adrian Bunk wrote:

>>+toshiba-tc86c001-ide-driver-take-2.patch

> This patch makes the needlessly global init_hwif_tc86c001() static.

Duh, I hoped tha this driver may get into 2.6.20-rc1 and finally
overlooked this. Sigh, uou won't believe how much time this driver rewrite
spent in an unfinished state in my internal tree... :-/

> Signed-off-by: Adrian Bunk <[email protected]>
>
> ---
>
> BTW:
> I'm not sure whether it'd be a good idea to include such a driver for
> the legacy IDE subsystem without a libata based driver for the same
> hardware.

Well, I'd agree with Alan here. Don't expect me to convert this to libata
in the foreseeable future... I'd like to join the folks hacking on libata but
this certainly won't happen soon (if at all)...

WBR, Sergei

2006-12-17 20:51:07

by Sergei Shtylyov

[permalink] [raw]
Subject: Re: [-mm patch] drivers/ide/pci/tc86c001.c: make a function static

Hello.

Adrian Bunk wrote:

> This patch makes the needlessly global init_hwif_tc86c001() static.

> Signed-off-by: Adrian Bunk <[email protected]>

If this patch hasn't been accepted by Andrew yet, could you add another
fixlet: init_chipset_tc86c001() should've been __devinit. If not or it's
already accepted, I'll post the patchlet myself later...

WBR, Sergei

2006-12-18 07:42:40

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

On Fri, Dec 15 2006, Andrew Morton wrote:
> On Fri, 15 Dec 2006 21:39:36 +0100
> Damien Wyart <[email protected]> wrote:
>
> > With this new kernel, I notice two messages I do not have with
> > 2.6.19-rc6-mm2 :
> >
> > Dec 15 20:00:47 brouette kernel: Filesystem "sdb9": Disabling barriers,trial barrier write failed
> > Dec 15 20:00:47 brouette kernel: Filesystem "sda5": Disabling barriers,trial barrier write failed
> >
> > Nothing changed in the config between the two, and going back to
> > 2.6.19-rc6-mm2 do not give the messages.
>
> I don't think anything has changed in this area in XFS. I'd expect that
> something got broken in sata, ata_piix or the block core which caused the
> "trial barrier write" to start failing. Various cc's hopefully added.

There hasn't been any barrier changes lately (or block layer handling of
such), so I don't think it's in that area. I'll do some barrier testing
today to verify that things work for me.

--
Jens Axboe

2006-12-18 09:00:19

by Laurent Riffard

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

Le 17.12.2006 12:07, Damien Wyart a ?crit :
>>> Also, I got panics when unmounting reiser4 filesystems with
>>> 2.6.20-rc1-mm1 but I guess this is related to your waring about
>>> reiser4 being broken in 2.6.19-mm1 (even if it is not listed in
>>> notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the
>>> reiser4 panics did not get logged and I am not able to reboot on
>>> 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report
>>> the xfs messages which seems a bit suspect.
>
>> The reiser4 failure is unexpected. Could you please see if you can
>> capture a trace, let the people at [email protected] know?
>
> Ok, I've handwritten the messages, here they are :
>
> reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597)
> write log failed (-5)
>
> [ got 2 copies of them because I have 2 reiser4 fs)
>
> I got them mainly when I try to reboot or halt the machine, and the
> process doesn't finish, the computer gets stuck after the reiser4
> messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2.
>

fix-sense-key-medium-error-processing-and-retry.patch seems to be the culprit.

Reverting it fix those reiser4 panics for me. Damien, could you confirm please ?

~~
laurent

2006-12-18 13:39:49

by Frederik Deweerdt

[permalink] [raw]
Subject: [-mm patch] kill pxa2xx Kconfig warning

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
> git-alsa.patch
Hi,

The following patch silences the following Kconfig warning:
scripts/kconfig/conf -s arch/i386/Kconfig
sound/soc/pxa/Kconfig:18:warning: 'select' used by config symbol 'SND_PXA2XX_SOC_AC97' refer to undefined symbol 'SND_AC97_BUS'

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[email protected]>


diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index a07598c..579e1c8 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -15,7 +15,7 @@ config SND_PXA2XX_AC97

config SND_PXA2XX_SOC_AC97
tristate
- select SND_AC97_BUS
+ select AC97_BUS
select SND_SOC_AC97_BUS

config SND_PXA2XX_SOC_I2S

2006-12-18 18:35:32

by Damien Wyart

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

> > > The reiser4 failure is unexpected. Could you please see if you can
> > > capture a trace, let the people at [email protected] know?

> > Ok, I've handwritten the messages, here they are :

> > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom
> > (fs/reiser4/txmngr.c:1087) (zam-597)
> > write log failed (-5)

> > [ got 2 copies of them because I have 2 reiser4 fs)

> > I got them mainly when I try to reboot or halt the machine, and the
> > process doesn't finish, the computer gets stuck after the reiser4
> > messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2.

* Laurent Riffard <[email protected]> [2006-12-18 09:03]:
> fix-sense-key-medium-error-processing-and-retry.patch seems to be the
> culprit.

> Reverting it fix those reiser4 panics for me. Damien, could you confirm
> please ?

Yes, this fixes it too on my side. Thanks for this tracking !

--
Damien Wyart

Subject: Re: 2.6.20-rc1-mm1

On 12/15/06, Andrew Morton <[email protected]> wrote:

> +toshiba-tc86c001-ide-driver-take-2.patch

Acked-by: Bartlomiej Zolnierkiewicz <[email protected]>

IMO this can be merged for 2.6.20 as it is new driver
(which is clean, tested and acked by Alan already)

> All 693 patches:

hpt3xx-rework-rate-filtering.patch
HPT3xx: rework rate filtering

ACK

hpt3xx-rework-rate-filtering-tidy.patch
hpt3xx-rework-rate-filtering-tidy

ACK

hpt3xx-print-the-real-chip-name-at-startup.patch
HPT3xx: print the real chip name at startup

ACK

hpt3xx-switch-to-using-pci_get_slot.patch
HPT3xx: switch to using pci_get_slot()

ACK

hpt3xx-cache-channels-mcr-address.patch
[PATCH] HPT3xx: cache channel's MCR address

ACK

hpt3x7-merge-speedproc-handlers.patch
HPT3x7: merge speedproc handlers

ACK

hpt370-clean-up-dma-timeout-handling.patch
HPT370: clean up DMA timeout handling

ACK

hpt3xx-init-code-rewrite.patch
HPT3xx: init code rewrite

ACK

piix-fix-82371mx-enablebits.patch
PIIX: fix 82371MX enablebits

ACK, thought I haven't compared wrt datasheet yet

piix-remove-check-for-broken-mw-dma-mode-0.patch
PIIX: remove check for broken MW DMA mode 0

ACK, 100% correct and non-intrusive cleanup

piix-slc90e66-pio-mode-fallback-fix.patch
PIIX/SLC90E66: PIO mode fallback fix

ACK, this is an important bugfix

pdc202xx_new-remove-useless-code.patch
pdc202xx_new: remove useless code

ACK, nice cleanup

pdc202xx_-remove-check_in_drive_lists-abomination.patch
pdc202xx_*: remove check_in_drive_lists() abomination

ACK, ditto

I think that all above patches from Sergei should be merged now as they
are either bugfixes or not-intrusive cleanups and got more than enough
exposure in -mm (since 2.6.17-mm).

jmicron-warning-fix.patch

Wouldn't it be neater to add BUG() instead? Seems to fix warning
for me and documents nicely that this case cannot happen.

Thanks,
Bart

2006-12-18 23:34:32

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch] debugging feature: SysRq-Q to print timers

On Sat, 16 Dec 2006 08:56:58 +0100
Ingo Molnar <[email protected]> wrote:

> ----------------->
> Subject: [patch] debugging feature: SysRq-Q to print timers
> From: Ingo Molnar <[email protected]>
>
> add SysRq-Q to print pending timers and other timer info.

I must say that I've never needed this feature or /proc/timer-list, and I
don't recall ever having seen anyone request it, nor get themselves into a
situation where they needed it.

Do we really need to include this?

2006-12-18 23:47:03

by Dave Jones

[permalink] [raw]
Subject: Re: [patch] debugging feature: SysRq-Q to print timers

On Mon, Dec 18, 2006 at 03:31:03PM -0800, Andrew Morton wrote:
> On Sat, 16 Dec 2006 08:56:58 +0100
> Ingo Molnar <[email protected]> wrote:
>
> > ----------------->
> > Subject: [patch] debugging feature: SysRq-Q to print timers
> > From: Ingo Molnar <[email protected]>
> >
> > add SysRq-Q to print pending timers and other timer info.
>
> I must say that I've never needed this feature or /proc/timer-list, and I
> don't recall ever having seen anyone request it, nor get themselves into a
> situation where they needed it.

/proc/timer-list is useful for profiling applications doing excessive wakeups.
With the move towards being tickless, this is more important than ever,
and giving users the right tools to find these problems themselves is important.

Dave

--
http://www.codemonkey.org.uk

2006-12-19 00:00:51

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch] debugging feature: SysRq-Q to print timers

On Mon, 18 Dec 2006 18:45:49 -0500
Dave Jones <[email protected]> wrote:

> On Mon, Dec 18, 2006 at 03:31:03PM -0800, Andrew Morton wrote:
> > On Sat, 16 Dec 2006 08:56:58 +0100
> > Ingo Molnar <[email protected]> wrote:
> >
> > > ----------------->
> > > Subject: [patch] debugging feature: SysRq-Q to print timers
> > > From: Ingo Molnar <[email protected]>
> > >
> > > add SysRq-Q to print pending timers and other timer info.
> >
> > I must say that I've never needed this feature or /proc/timer-list, and I
> > don't recall ever having seen anyone request it, nor get themselves into a
> > situation where they needed it.
>
> /proc/timer-list is useful for profiling applications doing excessive wakeups.
> With the move towards being tickless, this is more important than ever,
> and giving users the right tools to find these problems themselves is important.
>

oic. Nobody ever tells me squat. <updates changelog>

Your explanation doesn't explain why we need this info in a sysrq
triggerable form.

And what about /proc/timer-stat?


2006-12-19 00:28:00

by Randy Dunlap

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:

Got this on booting up on x86_64 test box.
Didn't happen on next boot.


BUG: scheduling while atomic: hald-addon-stor/0x20000000/3300

Call Trace:
[<ffffffff8020ac30>] show_trace+0x34/0x47
[<ffffffff8020ac55>] dump_stack+0x12/0x17
[<ffffffff8050c2dd>] __sched_text_start+0x5d/0x7ba
[<ffffffff8022b3f0>] __cond_resched+0x1c/0x44
[<ffffffff8050cb4d>] cond_resched+0x29/0x30
[<ffffffff8050e7aa>] __reacquire_kernel_lock+0x26/0x44
[<ffffffff8050cae6>] thread_return+0xac/0xea
[<ffffffff8022b3f0>] __cond_resched+0x1c/0x44
[<ffffffff8050cb4d>] cond_resched+0x29/0x30
[<ffffffff8050cb83>] wait_for_completion+0x17/0xd2
[<ffffffff80337a19>] blk_execute_rq+0x98/0xb8
[<ffffffff80413e7b>] scsi_execute+0xd4/0xf1
[<ffffffff80413f51>] scsi_execute_req+0xb9/0xde
[<ffffffff80413faf>] scsi_test_unit_ready+0x39/0x75
[<ffffffff804443cd>] sd_media_changed+0x40/0x87
[<ffffffff8029cde0>] check_disk_change+0x1f/0x76
[<ffffffff8044417e>] sd_open+0x80/0x113
[<ffffffff8029d4c4>] do_open+0x9f/0x2a7
[<ffffffff8029d8bc>] blkdev_open+0x2e/0x5d
[<ffffffff8027afeb>] __dentry_open+0xd9/0x1a7
[<ffffffff8027b16a>] do_filp_open+0x2a/0x38
[<ffffffff8027b1bc>] do_sys_open+0x44/0xc8
[<ffffffff8020956e>] system_call+0x7e/0x83
[<00002b6c5bb34580>]

---
~Randy
kconfig: http://oss.oracle.com/~rdunlap/configs/config-2620-rc1mm1
full log: http://oss.oracle.com/~rdunlap/logs/2620-rc1mm1.out

2006-12-19 00:42:25

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

On Mon, 18 Dec 2006 16:29:02 -0800
Randy Dunlap <[email protected]> wrote:

> On Thu, 14 Dec 2006 22:59:13 -0800 Andrew Morton wrote:
>
> Got this on booting up on x86_64 test box.
> Didn't happen on next boot.
>
>
> BUG: scheduling while atomic: hald-addon-stor/0x20000000/3300
>
> Call Trace:
> [<ffffffff8020ac30>] show_trace+0x34/0x47
> [<ffffffff8020ac55>] dump_stack+0x12/0x17
> [<ffffffff8050c2dd>] __sched_text_start+0x5d/0x7ba
> [<ffffffff8022b3f0>] __cond_resched+0x1c/0x44
> [<ffffffff8050cb4d>] cond_resched+0x29/0x30
> [<ffffffff8050e7aa>] __reacquire_kernel_lock+0x26/0x44
> [<ffffffff8050cae6>] thread_return+0xac/0xea
> [<ffffffff8022b3f0>] __cond_resched+0x1c/0x44
> [<ffffffff8050cb4d>] cond_resched+0x29/0x30
> [<ffffffff8050cb83>] wait_for_completion+0x17/0xd2
> [<ffffffff80337a19>] blk_execute_rq+0x98/0xb8
> [<ffffffff80413e7b>] scsi_execute+0xd4/0xf1
> [<ffffffff80413f51>] scsi_execute_req+0xb9/0xde
> [<ffffffff80413faf>] scsi_test_unit_ready+0x39/0x75
> [<ffffffff804443cd>] sd_media_changed+0x40/0x87
> [<ffffffff8029cde0>] check_disk_change+0x1f/0x76
> [<ffffffff8044417e>] sd_open+0x80/0x113
> [<ffffffff8029d4c4>] do_open+0x9f/0x2a7
> [<ffffffff8029d8bc>] blkdev_open+0x2e/0x5d
> [<ffffffff8027afeb>] __dentry_open+0xd9/0x1a7
> [<ffffffff8027b16a>] do_filp_open+0x2a/0x38
> [<ffffffff8027b1bc>] do_sys_open+0x44/0xc8
> [<ffffffff8020956e>] system_call+0x7e/0x83

Bit 29 of current->preempt_count got set. I don't think there's any way in
which that can happen normally. So probably some hardware or software
error reached out and flipped that bit.

2006-12-19 12:04:43

by Ingo Molnar

[permalink] [raw]
Subject: Re: [patch] debugging feature: SysRq-Q to print timers


* Andrew Morton <[email protected]> wrote:

> > /proc/timer-list is useful for profiling applications doing
> > excessive wakeups. With the move towards being tickless, this is
> > more important than ever, and giving users the right tools to find
> > these problems themselves is important.
> >
>
> oic. Nobody ever tells me squat. <updates changelog>
>
> Your explanation doesn't explain why we need this info in a sysrq
> triggerable form.
>
> And what about /proc/timer-stat?

/proc/timer_stats does timer profiling. You start it via:

echo 1 > /proc/timer_stats

and then the profile info gathers into /proc/timer_stats. Useful way to
look at it is:

sort -n /proc/timer_stats

for example:

Timer Stats Version: v0.1
1, 0 swapper page_writeback_init (wb_timer_fn)
1, 1898 modprobe neigh_table_init_no_netlink (neigh_periodic_timer)
1, 1 init schedule_timeout (process_timeout)
1, 1 swapper neigh_table_init_no_netlink (neigh_periodic_timer)
1, 2700 hald-addon-stor do_nanosleep (hrtimer_wakeup)
1, 6 softirq-timer/0 __netdev_watchdog_up (dev_watchdog)
2, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
2, 1 swapper queue_delayed_work_on (delayed_work_timer_fn)
2, 480 IRQ 218 e1000_intr_msi (e1000_watchdog)
3, 2652 yum-updatesd schedule_timeout (process_timeout)
4, 2472 pcscd do_nanosleep (hrtimer_wakeup)
4, 7824 sshd sk_reset_timer (tcp_write_timer)
13, 428 insmod usb_hcd_poll_rh_status (rh_timer_func)
13, 428 insmod usb_hcd_poll_rh_status (rh_timer_func)
13, 437 insmod usb_hcd_submit_urb (rh_timer_func)
19, 21 softirq-net-rx/ sk_reset_timer (tcp_delack_timer)
164, 1868 kondemand/0 queue_delayed_work_on (delayed_work_timer_fn)
164, 1869 kondemand/1 queue_delayed_work_on (delayed_work_timer_fn)
282, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
321, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick)
335, 0 swapper hrtimer_restart_sched_tick (hrtimer_sched_tick)
408, 0 swapper hrtimer_restart_sched_tick (hrtimer_sched_tick)
1755 total events, 585.534 events/sec

this shows us that the kondemand kernel threads are causing 90% of the
timeout events on this system.

/proc/timer_list shows all currently pending timers, and all the state
of the hardware timers. That is a bit different from timer_stat but
still very useful: it gives us a snapshot into the current state of the
(hr)timer subsystem. I needed it to debug a couple of high-res timers
subsystem bugs. The SysRq trigger was useful for things like timer
related boot hangs. (It's also useful to catch excessive waiters during
bootup.)

Ingo

2006-12-19 18:38:05

by Tilman Schmidt

[permalink] [raw]
Subject: BUG: NMI Watchdog detected LOCKUP (was: 2.6.20-rc1-mm1)

I tried kernel 2.6.20-rc1-mm1 with the "tickless" option on my P3/933
but it has now for the second time in a row caused a system freeze
as soon as I left the system idle for a couple of hours. The second
time I was warned and switched to a text console before I left the
system, and was able to collect this BUG message (copied manually,
beware of typos):

BUG: NMI Watchdog detected LOCKUP on CPU0, eip c021cf4d, registers:
Modules linked in: xt_pkttype ipt_LOG xt_limit usbserial snd_rtctimer snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device thermal processor fan button battery ac af_packet bas_gigaset gigaset isdn slhc crc_ccitt ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 uhci_hcd ipv6 nls_iso8859_1 nls_cp437 vfat fat nsl_utf8 ntfs dm_mod
CPU: 0
EIP: 0060:[<c021cf4d>] Not tainted VLI
EFLAGS: 00200082 (2.6.20-rc1-mm1-noinitrd #0)
EIP is at __rb_rotate_right+0x1/0x54
eax: dea0c77c ebx: dea0c77c ecx: dae0c77c edx: c04beb8c
esi: dea0c77c edi: dea0c77c ebp: deaf3d74 esp: deaf3d54
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process X (pid: 3255, ti=deaf2000 task=c14deb00 task.ti=deaf2000)
Stack: deaf3d74 c021d049 c04beb8c 00000000 00000000 dea0c77c de8d5f3e 00000995
deaf3d98 c012d15b 00000001 c04beb84 dea0c780 dea0c77c de8d5f3e 00000995
c04beb84 deaf3dc4 c012d9b4 c012d323 dea0c77c 00200096 00000000 dea0c77c
Call Trace:
[<c021d049>] rb_insert_color+0x55/0xbe
[<c012d15b>] enqueue_hrtimer+0x10a/0x116
[<c012d9b4>] hrtimer_start+0x78/0x93
[<c0123453>] get_signal_to_deliver+0xf3/0x74e
[<c01026ee>] do_notify_resume+0x93/0x655
[<c0102ef5>] work_notifysig+0x13/0x1a
[<b7f5f410>] 0xb7f5f410
=======================
Code: 39 d0 74 22 8b 4a 08 85 c9 74 0d 8b 41 04 85 c0 74 14 89 c1 eb f5 89 c2 8b 02 83 e0 fc 74 05 3b 50 08 74 f2 89 c1 5d 89 c8 c3 55 <89> e5 57 89 d7 56 53 89 c3 8b 50 08 8b 30 8b 4a 04 83 e6 fc 85

Config file available upon request. (The system won't boot right now,
it wants a manual fsck first.) Bisecting this promises to take about
8 hours per iteration if I add up the wait for the hang, the fsck
afterwards and the time this system needs for compiling a kernel, so
I'll wait for you to tell me if it's really necessary. ;-)

HTH
Tilman

2006-12-19 18:48:48

by Thomas Gleixner

[permalink] [raw]
Subject: Re: BUG: NMI Watchdog detected LOCKUP (was: 2.6.20-rc1-mm1)

On Thu, 2006-12-14 at 22:59 -0800, Tilman Schmidt wrote:
> [<c021d049>] rb_insert_color+0x55/0xbe
> [<c012d15b>] enqueue_hrtimer+0x10a/0x116
> [<c012d9b4>] hrtimer_start+0x78/0x93
> [<c0123453>] get_signal_to_deliver+0xf3/0x74e
> [<c01026ee>] do_notify_resume+0x93/0x655
> [<c0102ef5>] work_notifysig+0x13/0x1a
> [<b7f5f410>] 0xb7f5f410

Not really helpful.

> Config file available upon request. (The system won't boot right now,
> it wants a manual fsck first.) Bisecting this promises to take about
> 8 hours per iteration if I add up the wait for the hang, the fsck
> afterwards and the time this system needs for compiling a kernel, so
> I'll wait for you to tell me if it's really necessary. ;-)

Can you send me the config file please and the boot log of the machine ?

tglx


2006-12-19 19:59:07

by Ingo Molnar

[permalink] [raw]
Subject: [patch] hrtimers: add state tracking, fix


* Tilman Schmidt <[email protected]> wrote:

> I tried kernel 2.6.20-rc1-mm1 with the "tickless" option on my P3/933
> but it has now for the second time in a row caused a system freeze as
> soon as I left the system idle for a couple of hours. The second time
> I was warned and switched to a text console before I left the system,
> and was able to collect this BUG message (copied manually, beware of
> typos):
>
> EFLAGS: 00200082 (2.6.20-rc1-mm1-noinitrd #0)
> EIP is at __rb_rotate_right+0x1/0x54
[...]
> Call Trace:
> [<c021d049>] rb_insert_color+0x55/0xbe
> [<c012d15b>] enqueue_hrtimer+0x10a/0x116
> [<c012d9b4>] hrtimer_start+0x78/0x93

thanks for the report - this made me review the hrtimer state engine
logic, and bingo, it indeed has a nasty typo! Could you try the fix
below, does it fix your problem? It might explain the crash you are
seeing, because the typo means we'd ignore HRTIMER_STATE_PENDING state
(which is rare but possible).

Ingo

-------------------------->
Subject: [patch] hrtimers: add state tracking, fix
From: Ingo Molnar <[email protected]>

fix bug in hrtimer_is_queued(), introduced by a cleanup during
the recent refactoring.

Signed-off-by: Ingo Molnar <[email protected]>
---
kernel/hrtimer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/kernel/hrtimer.c
===================================================================
--- linux.orig/kernel/hrtimer.c
+++ linux/kernel/hrtimer.c
@@ -157,7 +157,7 @@ static void hrtimer_get_softirq_time(str
static inline int hrtimer_is_queued(struct hrtimer *timer)
{
return timer->state &
- (HRTIMER_STATE_ENQUEUED || HRTIMER_STATE_PENDING);
+ (HRTIMER_STATE_ENQUEUED | HRTIMER_STATE_PENDING);
}

/*

2006-12-19 23:36:10

by Luben Tuikov

[permalink] [raw]
Subject: Re: 2.6.20-rc1-mm1

--- Damien Wyart <[email protected]> wrote:
> > > > The reiser4 failure is unexpected. Could you please see if you can
> > > > capture a trace, let the people at [email protected] know?
>
> > > Ok, I've handwritten the messages, here they are :
>
> > > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom
> > > (fs/reiser4/txmngr.c:1087) (zam-597)
> > > write log failed (-5)
>
> > > [ got 2 copies of them because I have 2 reiser4 fs)
>
> > > I got them mainly when I try to reboot or halt the machine, and the
> > > process doesn't finish, the computer gets stuck after the reiser4
> > > messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2.
>
> * Laurent Riffard <[email protected]> [2006-12-18 09:03]:
> > fix-sense-key-medium-error-processing-and-retry.patch seems to be the
> > culprit.
>
> > Reverting it fix those reiser4 panics for me. Damien, could you confirm
> > please ?
>
> Yes, this fixes it too on my side. Thanks for this tracking !

I had a bug in my dev tree which got picked up by the patch
when I diffed against master:

- scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
+ scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL)
return;

As james explained, the other chunk of the patch is still good.

Luben

2006-12-20 01:34:41

by Tilman Schmidt

[permalink] [raw]
Subject: Re: [patch] hrtimers: add state tracking, fix

Am 19.12.2006 20:56 schrieb Ingo Molnar:
> thanks for the report - this made me review the hrtimer state engine
> logic, and bingo, it indeed has a nasty typo! Could you try the fix
> below, does it fix your problem? It might explain the crash you are
> seeing, because the typo means we'd ignore HRTIMER_STATE_PENDING state
> (which is rare but possible).

Ok, the machine has been running for a couple of hours with that patch
and so far hasn't frozen again. I'll watch it some more but it looks
like your patch did indeed fix my problem.

Thanks
Tilman

> -------------------------->
> Subject: [patch] hrtimers: add state tracking, fix
> From: Ingo Molnar <[email protected]>
>
> fix bug in hrtimer_is_queued(), introduced by a cleanup during
> the recent refactoring.
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> kernel/hrtimer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux/kernel/hrtimer.c
> ===================================================================
> --- linux.orig/kernel/hrtimer.c
> +++ linux/kernel/hrtimer.c
> @@ -157,7 +157,7 @@ static void hrtimer_get_softirq_time(str
> static inline int hrtimer_is_queued(struct hrtimer *timer)
> {
> return timer->state &
> - (HRTIMER_STATE_ENQUEUED || HRTIMER_STATE_PENDING);
> + (HRTIMER_STATE_ENQUEUED | HRTIMER_STATE_PENDING);
> }
>
> /*

--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)


Attachments:
signature.asc (253.00 B)
OpenPGP digital signature

2006-12-20 06:10:28

by Greg KH

[permalink] [raw]
Subject: Re: [-mm patch] make uio_irq_handler() static

On Sat, Dec 16, 2006 at 02:56:54PM +0100, Adrian Bunk wrote:
> On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.19-mm1:
> >...
> > +gregkh-driver-uio-irq.patch
> >
> > driver tree updates
> >...
>
> This patch makes the needlessly global uio_irq_handler() static.
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> --- linux-2.6.20-rc1-mm1/drivers/uio/uio_irq.c.old 2006-12-15 22:23:23.000000000 +0100
> +++ linux-2.6.20-rc1-mm1/drivers/uio/uio_irq.c 2006-12-15 22:33:40.000000000 +0100
> @@ -22,7 +22,7 @@
>
> static struct uio_device *uio_irq_idev;
>
> -irqreturn_t uio_irq_handler(int irq, void *dev_id)
> +static irqreturn_t uio_irq_handler(int irq, void *dev_id)
> {
> return IRQ_HANDLED;
> }

Thanks, I've applied this to my tree.

greg k-h

2006-12-20 20:01:27

by Tilman Schmidt

[permalink] [raw]
Subject: Re: [patch] hrtimers: add state tracking, fix

Am 19.12.2006 20:56 schrieb Ingo Molnar:
> Could you try the fix below, does it fix your problem?

The system has been running for a whole day now without freezing,
convincing me that your patch does indeed fix my problem.

> -------------------------->
> Subject: [patch] hrtimers: add state tracking, fix
> From: Ingo Molnar <[email protected]>
>
> fix bug in hrtimer_is_queued(), introduced by a cleanup during
> the recent refactoring.
>
> Signed-off-by: Ingo Molnar <[email protected]>

Acked-by: Tilman Schmidt <[email protected]>

> ---
> kernel/hrtimer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux/kernel/hrtimer.c
> ===================================================================
> --- linux.orig/kernel/hrtimer.c
> +++ linux/kernel/hrtimer.c
> @@ -157,7 +157,7 @@ static void hrtimer_get_softirq_time(str
> static inline int hrtimer_is_queued(struct hrtimer *timer)
> {
> return timer->state &
> - (HRTIMER_STATE_ENQUEUED || HRTIMER_STATE_PENDING);
> + (HRTIMER_STATE_ENQUEUED | HRTIMER_STATE_PENDING);
> }
>
> /*

Thanks again
Tilman

--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)


Attachments:
signature.asc (253.00 B)
OpenPGP digital signature

2006-12-21 18:36:54

by Frederik Deweerdt

[permalink] [raw]
Subject: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>
Hi all,

Following the i386 pda patches, it's not possible to set gs or fs value
from gdb anymore. The following patch restores the old behaviour of
getting and setting thread.gs of thread.fs respectively.
Here's a gdb session *before* the patch:
(gdb) info reg
[...]
fs 0x33 51
gs 0x33 51
(gdb) set $fs=0xffff
(gdb) info reg
[...]
fs 0x33 51
gs 0x33 51
(gdb) set $gs=0xffffffff
(gdb) info reg
[...]
fs 0xffff 65535
gs 0x33 51

Another one *after* the patch:
(gdb) info reg
[...]
fs 0xd8 216
gs 0x33 51
(gdb) set $fs=0xffff
(gdb) info reg
[...]
fs 0xffff 65535
gs 0x33 51
(gdb) set $gs=0xffff
(gdb) info reg
[...]
fs 0xffff 65535
gs 0xffff 65535

Andrew, this goes on top of ptrace-fix-efl_offset-value-according-to-i386-pda-changes.patch
sent by Jeremy yesterday.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[email protected]>

diff --git a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
index a803a49..7af494e 100644
--- a/arch/i386/kernel/ptrace.c
+++ b/arch/i386/kernel/ptrace.c
@@ -94,9 +94,13 @@ static int putreg(struct task_struct *child,
return -EIO;
child->thread.fs = value;
return 0;
+ case GS:
+ if (value && (value & 3) != 3)
+ return -EIO;
+ child->thread.gs = value;
+ return 0;
case DS:
case ES:
- case GS:
if (value && (value & 3) != 3)
return -EIO;
value &= 0xffff;
@@ -124,12 +128,14 @@ static unsigned long getreg(struct task_struct *child,
unsigned long retval = ~0UL;

switch (regno >> 2) {
+ case FS:
+ retval = child->thread.fs;
+ break;
case GS:
retval = child->thread.gs;
break;
case DS:
case ES:
- case FS:
case SS:
case CS:
retval = 0xffff;

2006-12-21 19:22:10

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

Frederik Deweerdt wrote:
> Following the i386 pda patches, it's not possible to set gs or fs value
> from gdb anymore. The following patch restores the old behaviour of
> getting and setting thread.gs of thread.fs respectively.
> Here's a gdb session *before* the patch:
> (gdb) info reg
> [...]
> fs 0x33 51
> gs 0x33 51
> (gdb) set $fs=0xffff
> (gdb) info reg
> [...]
> fs 0x33 51
> gs 0x33 51
> (gdb) set $gs=0xffffffff
> (gdb) info reg
> [...]
> fs 0xffff 65535
> gs 0x33 51
>
> Another one *after* the patch:
> (gdb) info reg
> [...]
> fs 0xd8 216
>

This doesn't look right. This is the kernel's %fs, not usermode's
(which should be 0).

> gs 0x33 51
> (gdb) set $fs=0xffff
> (gdb) info reg
> [...]
> fs 0xffff 65535
> gs 0x33 51
> (gdb) set $gs=0xffff
> (gdb) info reg
> [...]
> fs 0xffff 65535
> gs 0xffff 65535
>
Hm. This shouldn't be possible since this is a bad selector, but I
guess ptrace/gdb doesn't really know that. If you run the target (even
single step it), these should revert to 0.

> Andrew, this goes on top of ptrace-fix-efl_offset-value-according-to-i386-pda-changes.patch
> sent by Jeremy yesterday.
>

Don't think this is quite right yet. Assuming the %gs->%fs patch has
been applied, then the target %fs should be on its stack, and target %gs
will be in thread.gs. I'm not sure that thread.fs has any use, but I'd
want to double check vm86 to be sure.

J

2006-12-21 20:54:49

by Frederik Deweerdt

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

On Thu, Dec 21, 2006 at 11:22:05AM -0800, Jeremy Fitzhardinge wrote:
> Frederik Deweerdt wrote:
> > Following the i386 pda patches, it's not possible to set gs or fs value
> > from gdb anymore. The following patch restores the old behaviour of
> > getting and setting thread.gs of thread.fs respectively.
> > Here's a gdb session *before* the patch:
> > (gdb) info reg
> > [...]
> > fs 0x33 51
> > gs 0x33 51
> > (gdb) set $fs=0xffff
> > (gdb) info reg
> > [...]
> > fs 0x33 51
> > gs 0x33 51
> > (gdb) set $gs=0xffffffff
> > (gdb) info reg
> > [...]
> > fs 0xffff 65535
> > gs 0x33 51
> >
> > Another one *after* the patch:
> > (gdb) info reg
> > [...]
> > fs 0xd8 216
> >
>
> This doesn't look right. This is the kernel's %fs, not usermode's
> (which should be 0).
>
Right, I missed that.
> > gs 0x33 51
> > (gdb) set $fs=0xffff
> > (gdb) info reg
> > [...]
> > fs 0xffff 65535
> > gs 0x33 51
> > (gdb) set $gs=0xffff
> > (gdb) info reg
> > [...]
> > fs 0xffff 65535
> > gs 0xffff 65535
> >
> Hm. This shouldn't be possible since this is a bad selector, but I
> guess ptrace/gdb doesn't really know that. If you run the target (even
> single step it), these should revert to 0.
I does, my point there is just that in that case gdb would stick the
0xffff value in the right place, which it doesn't without the patch.
>
> > Andrew, this goes on top of ptrace-fix-efl_offset-value-according-to-i386-pda-changes.patch
> > sent by Jeremy yesterday.
> >
>
> Don't think this is quite right yet. Assuming the %gs->%fs patch has
> been applied, then the target %fs should be on its stack, and target %gs
> will be in thread.gs. I'm not sure that thread.fs has any use, but I'd
> want to double check vm86 to be sure.
I'm not sure what you mean by the '%gs->%fs patch'. Do you refer to
convert-i386-pda-code-to-use-%fs-fixes.patch
which is in -mm1?
Or is there another one I might have missed? For the record, I'm running
-mm1 + the efl_offset patch.

Regards,
Frederik
>
> J
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2006-12-21 22:01:28

by Frederik Deweerdt

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

On Thu, Dec 21, 2006 at 11:22:05AM -0800, Jeremy Fitzhardinge wrote:
> Frederik Deweerdt wrote:
> > Following the i386 pda patches, it's not possible to set gs or fs value
> > from gdb anymore. The following patch restores the old behaviour of
> > getting and setting thread.gs of thread.fs respectively.
> > Here's a gdb session *before* the patch:
> > (gdb) info reg
> > [...]
> > fs 0x33 51
> > gs 0x33 51
> > (gdb) set $fs=0xffff
> > (gdb) info reg
> > [...]
> > fs 0x33 51
> > gs 0x33 51
> > (gdb) set $gs=0xffffffff
> > (gdb) info reg
> > [...]
> > fs 0xffff 65535
> > gs 0x33 51
> >
> > Another one *after* the patch:
> > (gdb) info reg
> > [...]
> > fs 0xd8 216
> >
>
> This doesn't look right. This is the kernel's %fs, not usermode's
> (which should be 0).
>
> > gs 0x33 51
> > (gdb) set $fs=0xffff
> > (gdb) info reg
> > [...]
> > fs 0xffff 65535
> > gs 0x33 51
> > (gdb) set $gs=0xffff
> > (gdb) info reg
> > [...]
> > fs 0xffff 65535
> > gs 0xffff 65535
> >
> Hm. This shouldn't be possible since this is a bad selector, but I
> guess ptrace/gdb doesn't really know that. If you run the target (even
> single step it), these should revert to 0.
>
Here's a third session that looks better:

(gdb) info reg
[...]
fs 0x0 0
gs 0x33 51
(gdb) set $fs=0xffff
(gdb) info reg
[...]
fs 0xffff 65535
gs 0x33 51
(gdb) set $gs=0xffff
(gdb) info reg
[...]
fs 0xffff 65535
gs 0xffff 65535
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Cannot find user-level thread for LWP 10751: generic error
(gdb) set $gs=0x33
(gdb) set $fs=0
(gdb) n
Single stepping until exit from function main,
which has no line number information.
0x08048c05 in __i686.get_pc_thunk.bx ()
(gdb) info reg
[...]
fs 0x0 0
gs 0x33 51

This is a -mm1 kernel + your efl_offset fix + the attached patch.
So the problem came from putreg still saving %gs to the stack where
there's no slot for it, whereas getreg got things right.

Regards,
Frederik

Signed-off-by: Frederik Deweerdt <[email protected]>


diff --git a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
index a803a49..d8f44db 100644
--- a/arch/i386/kernel/ptrace.c
+++ b/arch/i386/kernel/ptrace.c
@@ -89,14 +89,14 @@ static int putreg(struct task_struct *child,
unsigned long regno, unsigned long value)
{
switch (regno >> 2) {
- case FS:
+ case GS:
if (value && (value & 3) != 3)
return -EIO;
- child->thread.fs = value;
+ child->thread.gs = value;
return 0;
case DS:
case ES:
- case GS:
+ case FS:
if (value && (value & 3) != 3)
return -EIO;
value &= 0xffff;

2006-12-22 02:01:00

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

Frederik Deweerdt wrote:
> This is a -mm1 kernel + your efl_offset fix + the attached patch.
> So the problem came from putreg still saving %gs to the stack where
> there's no slot for it, whereas getreg got things right.
>

That patch looks good, but I think it is already effectively in Andrew's
queue, because I noticed some problems in there when I reviewed the
convert-to-%fs patch.

J

2006-12-22 06:08:09

by Frederik Deweerdt

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

On Thu, Dec 21, 2006 at 06:11:08PM -0800, Andrew Morton wrote:
> On Thu, 21 Dec 2006 18:00:49 -0800
> Jeremy Fitzhardinge <[email protected]> wrote:
>
> > Frederik Deweerdt wrote:
> > > This is a -mm1 kernel + your efl_offset fix + the attached patch.
> > > So the problem came from putreg still saving %gs to the stack where
> > > there's no slot for it, whereas getreg got things right.
> > >
> >
> > That patch looks good, but I think it is already effectively in Andrew's
> > queue, because I noticed some problems in there when I reviewed the
> > convert-to-%fs patch.
> >
>
> The below is what I have queued for urgent mainlining to address these
> problems.
>
> Is it sufficient?
>
No, it's not. The patch below fixes the place where we get eflags, this
triggered the "BUG while gdb'ing" reports.
The one I sent was to fix a problem that only I reported, AFAIK: when
you use gdb/ptrace to modify %fs, the value gets written in the wrong
place (see gdb sessions). So, unless you have another patch fixing the
way putreg() writes %fs, the patch[1] I sent should also be queued for
mainline.

Regards,
Frederik

[1] http://lkml.org/lkml/2006/12/21/267
>
>
>
> From: Jeremy Fitzhardinge <[email protected]>
>
> The PDA patches introduced a bug in ptrace: it reads eflags from the wrong
> place on the target's stack, but writes it back to the correct place. The
> result is a corrupted eflags, which is most visible when it turns interrupts
> off unexpectedly.
>
> This patch fixes this by making the ptrace code a little less fragile. It
> changes [gs]et_stack_long to take a straightforward byte offset into struct
> pt_regs, rather than requiring all callers to do a sizeof(struct pt_regs)
> offset adjustment. This means that the eflag's offset (EFL_OFFSET) on the
> target stack can be simply computed with offsetof().
>
> Signed-off-by: Jeremy Fitzhardinge <[email protected]>
> Cc: Frederik Deweerdt <[email protected]>
> Cc: Andi Kleen <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> arch/i386/kernel/ptrace.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff -puN arch/i386/kernel/ptrace.c~ptrace-fix-efl_offset-value-according-to-i386-pda-changes arch/i386/kernel/ptrace.c
> --- a/arch/i386/kernel/ptrace.c~ptrace-fix-efl_offset-value-according-to-i386-pda-changes
> +++ a/arch/i386/kernel/ptrace.c
> @@ -45,7 +45,7 @@
> /*
> * Offset of eflags on child stack..
> */
> -#define EFL_OFFSET ((EFL-2)*4-sizeof(struct pt_regs))
> +#define EFL_OFFSET offsetof(struct pt_regs, eflags)
>
> static inline struct pt_regs *get_child_regs(struct task_struct *task)
> {
> @@ -54,24 +54,24 @@ static inline struct pt_regs *get_child_
> }
>
> /*
> - * this routine will get a word off of the processes privileged stack.
> - * the offset is how far from the base addr as stored in the TSS.
> - * this routine assumes that all the privileged stacks are in our
> + * This routine will get a word off of the processes privileged stack.
> + * the offset is bytes into the pt_regs structure on the stack.
> + * This routine assumes that all the privileged stacks are in our
> * data space.
> */
> static inline int get_stack_long(struct task_struct *task, int offset)
> {
> unsigned char *stack;
>
> - stack = (unsigned char *)task->thread.esp0;
> + stack = (unsigned char *)task->thread.esp0 - sizeof(struct pt_regs);
> stack += offset;
> return (*((int *)stack));
> }
>
> /*
> - * this routine will put a word on the processes privileged stack.
> - * the offset is how far from the base addr as stored in the TSS.
> - * this routine assumes that all the privileged stacks are in our
> + * This routine will put a word on the processes privileged stack.
> + * the offset is bytes into the pt_regs structure on the stack.
> + * This routine assumes that all the privileged stacks are in our
> * data space.
> */
> static inline int put_stack_long(struct task_struct *task, int offset,
> @@ -79,7 +79,7 @@ static inline int put_stack_long(struct
> {
> unsigned char * stack;
>
> - stack = (unsigned char *) task->thread.esp0;
> + stack = (unsigned char *)task->thread.esp0 - sizeof(struct pt_regs);
> stack += offset;
> *(unsigned long *) stack = data;
> return 0;
> @@ -114,7 +114,7 @@ static int putreg(struct task_struct *ch
> }
> if (regno > ES*4)
> regno -= 1*4;
> - put_stack_long(child, regno - sizeof(struct pt_regs), value);
> + put_stack_long(child, regno, value);
> return 0;
> }
>
> @@ -137,7 +137,6 @@ static unsigned long getreg(struct task_
> default:
> if (regno > ES*4)
> regno -= 1*4;
> - regno = regno - sizeof(struct pt_regs);
> retval &= get_stack_long(child, regno);
> }
> return retval;
> _
>
>

2006-12-22 06:52:22

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

Andrew Morton wrote:
> The below is what I have queued for urgent mainlining to address these
> problems.
>
> Is it sufficient?
>

It is sufficient to fix the serious eflags-clobbering bug, but it
doesn't fix the read-and-modify correctness problem Frederik found.

J

2006-12-22 06:55:39

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

Frederik Deweerdt wrote:
> On Thu, Dec 21, 2006 at 11:22:05AM -0800, Jeremy Fitzhardinge wrote:
>
>> Frederik Deweerdt wrote:
>>
>>> Following the i386 pda patches, it's not possible to set gs or fs value
>>> from gdb anymore. The following patch restores the old behaviour of
>>> getting and setting thread.gs of thread.fs respectively.
>>> Here's a gdb session *before* the patch:
>>> (gdb) info reg
>>> [...]
>>> fs 0x33 51
>>> gs 0x33 51
>>> (gdb) set $fs=0xffff
>>> (gdb) info reg
>>> [...]
>>> fs 0x33 51
>>> gs 0x33 51
>>> (gdb) set $gs=0xffffffff
>>> (gdb) info reg
>>> [...]
>>> fs 0xffff 65535
>>> gs 0x33 51
>>>
>>> Another one *after* the patch:
>>> (gdb) info reg
>>> [...]
>>> fs 0xd8 216
>>>
>>>
>> This doesn't look right. This is the kernel's %fs, not usermode's
>> (which should be 0).
>>
>>
>>> gs 0x33 51
>>> (gdb) set $fs=0xffff
>>> (gdb) info reg
>>> [...]
>>> fs 0xffff 65535
>>> gs 0x33 51
>>> (gdb) set $gs=0xffff
>>> (gdb) info reg
>>> [...]
>>> fs 0xffff 65535
>>> gs 0xffff 65535
>>>
>>>
>> Hm. This shouldn't be possible since this is a bad selector, but I
>> guess ptrace/gdb doesn't really know that. If you run the target (even
>> single step it), these should revert to 0.
>>
>>
> Here's a third session that looks better:
>
> (gdb) info reg
> [...]
> fs 0x0 0
> gs 0x33 51
> (gdb) set $fs=0xffff
> (gdb) info reg
> [...]
> fs 0xffff 65535
> gs 0x33 51
> (gdb) set $gs=0xffff
> (gdb) info reg
> [...]
> fs 0xffff 65535
> gs 0xffff 65535
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> Cannot find user-level thread for LWP 10751: generic error
> (gdb) set $gs=0x33
> (gdb) set $fs=0
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> 0x08048c05 in __i686.get_pc_thunk.bx ()
> (gdb) info reg
> [...]
> fs 0x0 0
> gs 0x33 51
>
> This is a -mm1 kernel + your efl_offset fix + the attached patch.
> So the problem came from putreg still saving %gs to the stack where
> there's no slot for it, whereas getreg got things right.
>
> Regards,
> Frederik
>
> Signed-off-by: Frederik Deweerdt <[email protected]>
>
>
> diff --git a/arch/i386/kernel/ptrace.c b/arch/i386/kernel/ptrace.c
> index a803a49..d8f44db 100644
> --- a/arch/i386/kernel/ptrace.c
> +++ b/arch/i386/kernel/ptrace.c
> @@ -89,14 +89,14 @@ static int putreg(struct task_struct *child,
> unsigned long regno, unsigned long value)
> {
> switch (regno >> 2) {
> - case FS:
> + case GS:
> if (value && (value & 3) != 3)
> return -EIO;
> - child->thread.fs = value;
> + child->thread.gs = value;
> return 0;
> case DS:
> case ES:
> - case GS:
> + case FS:
> if (value && (value & 3) != 3)
> return -EIO;
> value &= 0xffff;
>

This patch is good. convert-i386-pda-code-to-use-%fs-fixes.patch
touched this same code, but it didn't actually fix the problem.

J

2006-12-22 07:00:53

by Jeremy Fitzhardinge

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

Andrew Morton wrote:
> OK, but you're using -mm, yes? And -mm has (the rather irritating)
> convert-i386-pda-code-to-use-%fs.patch in it.
>
> So perhaps your fix is a -mm-only thing?
>

Yes, I think that's true.


J

2006-12-22 08:07:26

by Frederik Deweerdt

[permalink] [raw]
Subject: Re: [-mm patch] ptrace: make {put,get}reg work again for gs and fs

On Thu, Dec 21, 2006 at 10:54:14PM -0800, Andrew Morton wrote:
> On Fri, 22 Dec 2006 06:06:18 +0000
> Frederik Deweerdt <[email protected]> wrote:
>
> > On Thu, Dec 21, 2006 at 06:11:08PM -0800, Andrew Morton wrote:
> > > On Thu, 21 Dec 2006 18:00:49 -0800
> > > Jeremy Fitzhardinge <[email protected]> wrote:
> > >
> > > > Frederik Deweerdt wrote:
> > > > > This is a -mm1 kernel + your efl_offset fix + the attached patch.
> > > > > So the problem came from putreg still saving %gs to the stack where
> > > > > there's no slot for it, whereas getreg got things right.
> > > > >
> > > >
> > > > That patch looks good, but I think it is already effectively in Andrew's
> > > > queue, because I noticed some problems in there when I reviewed the
> > > > convert-to-%fs patch.
> > > >
> > >
> > > The below is what I have queued for urgent mainlining to address these
> > > problems.
> > >
> > > Is it sufficient?
> > >
> > No, it's not. The patch below fixes the place where we get eflags, this
> > triggered the "BUG while gdb'ing" reports.
> > The one I sent was to fix a problem that only I reported, AFAIK: when
> > you use gdb/ptrace to modify %fs, the value gets written in the wrong
> > place (see gdb sessions). So, unless you have another patch fixing the
> > way putreg() writes %fs, the patch[1] I sent should also be queued for
> > mainline.
>
> OK, but you're using -mm, yes? And -mm has (the rather irritating)
> convert-i386-pda-code-to-use-%fs.patch in it.
>
> So perhaps your fix is a -mm-only thing?
>
It is sorry, I mixed things up. BTW, your mails don't seem to make it to
the lkml (see http://lkml.org/lkml/2006/12/22/10)

Regards,
Frederik