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
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
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.
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.
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
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
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
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
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 */
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
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.
* 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:
*/
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
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);;
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;
}
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;
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);
> 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.
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
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."
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);
> > 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
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
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
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
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
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
> > > 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
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
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?
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
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?
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
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.
* 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
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
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
* 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);
}
/*
--- 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
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)
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
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)
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;
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
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/
>
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;
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
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;
> _
>
>
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
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
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
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