* 2.6.25-mm1
@ 2008-04-18 8:47 Andrew Morton
2008-04-18 11:26 ` [PATCH] 2.6.25-mm1 - Build Failure with PWRficient onchip memory controller driver Kamalesh Babulal
` (10 more replies)
0 siblings, 11 replies; 109+ messages in thread
From: Andrew Morton @ 2008-04-18 8:47 UTC (permalink / raw)
To: linux-kernel
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
- git-xfs is undropped because I finally got around to fixing its clashes
with git-vfs.
- git-arm-master, git-sparc64 and perhaps others are dropped because they
don't generate a clean pull. They might be empty - I didn't check.
- git-kvm remains dropped due to clashes with git-s390 and perhaps git-x86.
- git-selinux is newly dropped due to memory corruption regressions.
- git-nfs is (perhaps permanently) dropped because its content is also in
git-nfsd.
- git-drm remains reverted due to build failures
- Tomorrow I'll do the -mm merge plans email and I'll dump a couple hundred
patches on tree maintainers (these have about a 15% yay-he-merged-it rate).
Then I'm travelling for a poorly-timed week. I return late in the merge
window to find out if any of these patches still apply.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug 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.
- Occasional 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. These probably are at least compilable.
- More-than-daily -mm snapshots may be found at
http://userweb.kernel.org/~akpm/mmotm/. These are almost certainly not
compileable.
Changes since 2.6.25-rc8-mm2:
git-acpi.patch
git-x86.patch
git-kgdb-light.patch
git-alsa-tiwai.patch
git-agpgart.patch
git-arm.patch
git-avr32.patch
git-cifs.patch
git-cpufreq.patch
git-powerpc.patch
git-drm.patch
git-dvb.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-dlm.patch
git-hid.patch
git-hrt.patch
git-ia64.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-jfs.patch
git-leds.patch
git-libata-all.patch
git-async-tx.patch
git-mips.patch
git-mmc.patch
git-mtd.patch
git-ubi.patch
git-udf.patch
git-net.patch
git-battery.patch
git-nfsd.patch
git-ocfs2.patch
git-security-testing.patch
git-s390.patch
git-sched.patch
git-sh.patch
git-scsi-misc.patch
git-block.patch
git-unionfs.patch
git-v9fs.patch
git-vfs.patch
git-watchdog.patch
git-xfs.patch
git-cryptodev.patch
git-xtensa.patch
git-pekka.patch
git-semaphore.patch
git trees
-cgroups-include-hierarchy-ids-in-proc-pid-cgroup.patch
-rtc-rtc-s35390ac-needs-the-bitreverse-library.patch
-eventfd-kaio-integration-fix.patch
-i2c-fix-platform-driver-hotplug-coldplug.patch
-spi-fix-platform-driver-hotplug-coldplug.patch
-usb-gadget-fix-platform-driver-hotplug-coldplug.patch
-usb-host-fix-platform-driver-hotplug-coldplug.patch
-watchdog-fix-platform-driver-hotplug-coldplug.patch
-rtc-fix-platform-driver-hotplug-coldplug.patch
-cciss-error-implicit-declaration-of-function-sg_init_table.patch
-hfs-fix-unlink-of-links.patch
-md-close-a-livelock-window-in-handle_parity_checks5.patch
-pnp-increase-number-of-devices-supported-per-protocol.patch
-signalfd-fix-for-incorrect-si_queue-user-data-reporting.patch
-lzo-fix-typo-in-decompresor.patch
-generic_file_splice_read-fix-lockups.patch
-acpi-unneccessary-to-scan-the-pci-bus-already-scanned.patch
-git-acpi-revert-suspend-wakeup-code-in-c.patch
-revert-include-asm-x86-i387h-checkpatch-cleanups-formatting-only.patch
-git-x86-revert-x86-fpu-lazy-allocation-of-fpu-area-v5.patch
-git-x86-revert-x86-fpu-split-fpu-state-from-task-struct-v5.patch
-x86_64-do-not-reserve-ramdisk-two-times.patch
-git-alsa-tiwai-hda_codec-fix-locking.patch
-usb-audio-fix-another-dallas-quirk.patch
-usb-audio-make-quirk-handling-more-readable-and-fix-commented-out-code.patch
-es1968-fix-jitter-on-some-maestro-cards.patch
-es1968-fix-jitter-on-some-maestro-cards-checkpatch-fixes.patch
-sound-pci-rme9652-hdspmc-stop-inlining-largish-static-functions.patch
-lmb-add-lmb_alloc_nid.patch
-pm-remove-destroy_suspended_device.patch
-sysfs-refill-attribute-buffer-when-reading-from-offset-0.patch
-pm-introduce-new-top-level-suspend-and-hibernation-callbacks-rev-7.patch
-pm-introduce-new-top-level-suspend-and-hibernation-callbacks-rev-7-fix.patch
-pm-new-suspend-and-hibernation-callbacks-for-platform-bus-type-rev-3.patch
-pm-new-suspend-and-hibernation-callbacks-for-pci-bus-type-rev-3.patch
-pm-new-suspend-and-hibernation-callbacks-for-pci-bus-type-rev-3-fix.patch
-v4l-common-replace-remaining-__function__-occurences.patch
-v4l-dvb-replace-remaining-__function__-occurences.patch
-v4l-video-replace-remaining-__function__-occurences.patch
-jdelvare-i2c-i2c-ibm_iic-fast-mode-parm-desc-fixup.patch
-jdelvare-i2c-i2c-davinci-01-fix-lost-interrupt.patch
-jdelvare-i2c-i2c-tiny-usb-new-vid-pid-pair.patch
-maple-add-driver-for-sega-dreamcast-controller.patch
-input-put-ledstate-in-the-keyboard-notifier.patch
-aiptekc-add-support-for-genius-g-pen-560-tablet.patch
-ps-2-serio-driver-for-avr32-devices.patch
-input-replace-remaining-__function__-occurrences.patch
-git-libata-all-unbork-drivers-ata-sata_sx4c.patch
-ide-mm-remove-include-linux-hdsmart-h.patch
-ide-mm-ide-remove-cds-field-from-ide_hwif_t.patch
-ide-mm-scc_pata-add-in-out-put_data-methods.patch
-ide-mm-au1xxx-ide-add-in-out-put_data-methods.patch
-ide-mm-ide-h8300-add-in-out-put_data-methods.patch
-ehea-fix-dlpar-memory-add-support.patch
-gregkh-pci-pci-arm-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-cris-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-frv-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-mips-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-mn10300-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-parisc-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-sh-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-v850-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch
-gregkh-pci-pci-xtensa-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-arm-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-cris-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-frv-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-mips-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-mn10300-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-parisc-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-ppc-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-sh-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-v850-use-generic-pci_enable_resources.patch
-revert-gregkh-pci-pci-xtensa-use-generic-pci_enable_resources.patch
-pci-hotplug-fix-leaks-in-ibm-hot-plug-controller-driver-ibmphp_init_devno.patch
-sh-arch-sh-kernel-traps_32c-needs-asm-fpuh.patch
-sh-export-empty_zero_page.patch
-aacraid-fix-unchecked-down_interruptible.patch
-cfq-iosched-do-not-leak-ioc_data-across-iosched-switches.patch
-gregkh-usb-usb-replace-remaining-__function__-occurrences.patch
-gregkh-usb-usb-remove-unnecessary-type-casting-of-urb-context.patch
-usb-serial-fix-regression-in-visor-palm-os-module-for-kernels-=-2624.patch
-xfs-replace-remaining-__function__-occurrences.patch
-xfs-replace-__inline-with-inline.patch
-acpi-bus-check-once-more-for-an-empty-list-after-locking-it.patch
-acpi-thermal-trip-points-increased-to-12.patch
-forcedeth-mac-address-fix.patch
-smc91x-driver-fix-bug-print-warning-only-in-interrupt-mode.patch
-sc92031-sysfs-link-missing.patch
-usb-fix-interface-deregistration-during-unbind-operations.patch
-frv-handle-update_mmu_cache-being-called-when-current-mm-is-null.patch
-frv-move-stack_top_max-up.patch
-frv-add-support-for-emulation-of-userspace-atomic-ops.patch
-frv-make-nommu-mode-work-with-base-addresses-other-than-0xc0000000.patch
-frv-dont-make-smp_r-w-mb-interpolate-membar-when-config_smp=n.patch
-usb-serial-more-fixes-and-groundwork-for-tty-changes.patch
-proc-switch-proc-driver-ray_cs-ray_cs-to-seq_file-interface.patch
-proc-switch-proc-driver-radio-typhoon-to-seq_file-interface.patch
-documentation-patch-tags-one-more-time.patch
Merged into mainline or a subsystem tree.
-revert-x86-fix-call-to-set_cyc2ns_scale-from-time_cpufreq_notifier.patch
Dropped
+mm-fix-possible-off-by-one-in-walk_pte_range.patch
+dz-test-after-postfix-decrement-fails-in-dz_console_putchar.patch
+disable-the-memory-controller-by-default-v3.patch
+disable-the-memory-controller-by-default-v3-fix.patch
+cgroup-fix-a-race-condition-in-manipulating-tsk-cg_list.patch
+rtc-pcf8583-build-fix.patch
+memcgroup-check-and-initialize-page-cgroup-in-memmap_init_zone.patch
2.6.25 queue. Whoops. These are tagged for 2.6.25.1.
+hotplug-memory-make-online_page-common.patch
+hotplug-memory-make-online_page-common-fix.patch
memory-hotplug work.
+aio-io_getevents-should-return-if-io_destroy-is-invoked.patch
AIO fix.
+acpi-video-balcklist-fujitsu-lifebook-s6410.patch
ACPI fix
+miscacpibacklight-compal-laptop-extras-add-entry-to-maintainers.patch
+miscacpibacklight-compal-laptop-extras-use-bitmask-not-hex.patch
+miscacpibacklight-compal-laptop-extras-add-support-for-new-laptops.patch
+acpi-check-a-return-value-correctly-in-acpi_power_get_context.patch
Update miscacpibacklight-compal-laptop-extras-3rd-try.patch
+thinkpad-acpi-fix-possible-null-pointer-dereference.patch
thinkpad driver fix
+x86_64-restore-mask_bits-in-msi-shutdown.patch
+x86-ptrace-pebs-support.patch
+x86-ptrace-pebs-support-warning-fix.patch
+arch-x86-video-fbdevc-add-module_license.patch
x86 fixes
+git-arm-fix.patch
Fix build in git-arm.patch
+agk-dm-dm-table-improve-unplug-performance.patch
+agk-dm-dm-table-drop-void-suspend_targets-return.patch
+agk-dm-dm-table-remove-unused-dm_create_error_table.patch
+agk-dm-dm-raid1-use-timer.patch
device mapper tree updates
+macintosh-windfarm-fix-platform-driver-hotplug-coldplug.patch
mac driver fix
+gregkh-driver-uio-hold-a-reference-to-the-device-s-owner-while-the-device-is-open.patch
+gregkh-driver-pm-remove-destroy_suspended_device.patch
+gregkh-driver-sysfs-refill-attribute-buffer-when-reading-from-offset-0.patch
+gregkh-driver-sysfs-add-sys-dev-char-block-to-lookup-sysfs-path-by-major-minor.patch
+gregkh-driver-pm-introduce-new-top-level-suspend-and-hibernation-callbacks.patch
+gregkh-driver-pm-new-suspend-and-hibernation-callbacks-for-platform-bus-type.patch
+gregkh-driver-pm-new-suspend-and-hibernation-callbacks-for-pci-bus-type.patch
DRiver tree updates
+s2ram-warn-when-interrupts-should-be-disabled-but-are-not.patch
PM debugging
+sysfs-provide-a-clue-about-the-effects-of-config_usb_device_class=y.patch
Make a sysfs warning which shouldn't be coming out look less puzzling.
+revert-git-drm.patch
Revert it via patch so I notice when it gets updated.
+git-dvb-kconfig-fix.patch
git-dvb build fix
+jdelvare-i2c-i2c-bfin-twi-04-driver-description.patch
+jdelvare-i2c-i2c-fix-platform-driver-hotplug-coldplug.patch
I2C tree updates
+input-fix-platform-driver-hotplug-coldplug.patch
Fix hotplugging in input drivers
+ata-ide-fix-platform-driver-hotplug-coldplug.patch
Fix hotplugging
+ide-mm-scc_pata-c-do-setup-itself-instead-of-ide_setup_pci_device.patch
+ide-mm-ide-make-ide_pci_check_iomem-actually-work.patch
+ide-mm-scc_pata-ide_find_port.patch
+ide-mm-ide-remove-cds-field-from-ide_hwif_t-take-2.patch
+ide-mm-ide-add-struct-ide_dma_ops-take-3.patch
+ide-mm-ide-add-struct-ide_io_ports-take-2.patch
+ide-mm-scc_pata-add-in-out-put_data-methods-take-2.patch
+ide-mm-au1xxx-ide-add-in-out-put_data-methods-take-2.patch
+ide-mm-ide-h8300-add-in-out-put_data-methods-take-2.patch
+ide-mm-ide-always-use-outbsync-method-for-executing-commands.patch
+ide-mm-ide-floppy-tape-scsi-400ns-delay-is-required-after-executing-the-command.patch
+ide-mm-ide-add-ide_execute_pkt_cmd-helper.patch
+ide-mm-ide-factor-out-debugging-code-from-ide_tf_load.patch
+ide-mm-ide-move-ide_tf_load-read-to-ide-iops-c.patch
+ide-mm-ide-add-tf_load-and-tf_read-methods.patch
+ide-mm-ide-cris-add-tf_load-read-methods.patch
+ide-mm-ide-h8300-add-tf_load-read-methods.patch
+ide-mm-scc_pata-add-tf_load-read-methods.patch
+ide-mm-ns87415-add-tf_read-method.patch
+ide-mm-ide-use-ide-io-helpers-directly-in-ide_tf_load-read.patch
+ide-mm-ide-remove-inw-and-outw-methods.patch
+ide-mm-ide-add-ide_pad_transfer-helper.patch
+ide-mm-ide-skip-vlb-sync-if-host-uses-mmio.patch
+ide-mm-scc_pata-add-dma_host_set-and-dma_start-methods.patch
+ide-mm-ide-remove-dma_vendor1-3-fields-from-ide_hwif_t.patch
+ide-mm-ide-remove-dma_prdtable-field-from-ide_hwif_t.patch
+ide-mm-remove-the-broken-etrax_ide-driver.patch
IDE tree updates
+mtd-maps-fix-platform-driver-hotplug-coldplug.patch
+mtd-nand-fix-platform-driver-hotplug-coldplug.patch
Fix hotplugging
+drivers-atm-use-time_before-time_before_eq-etc.patch
+drivers-net-appletalk-use-time_before-time_before_eq-etc.patch
net cleanups
ehea-fix-dlpar-memory-add-support-fix.patch
This got stranded because Jeff merged the base patch but didn't merge my
fix to it.
+net-drivers-fix-platform-driver-hotplug-coldplug.patch
+net-drivers-fix-platform-driver-hotplug-coldplug-sgiseeq-fix.patch
+smc911x-test-after-postfix-decrement-fails-in-smc911x_resetdrop_pkt.patch
+smc911x-test-after-postfix-decrement-fails-in-smc911x_resetdrop_pkt-checkpatch-fixes.patch
net driver things
+blackfin-add-include-boot-gitignore-files.patch
blackfin fix
+nfs-fix-potential-null-pointer-dereference-v2.patch
+nfs-lsm-make-nfsv4-set-lsm-mount-options.patch
nfs fixes
+gregkh-pci-pci-x86-use-generic-pci_enable_resources.patch
+gregkh-pci-pci-parisc-use-generic-pci_enable_resources.patch
+gregkh-pci-pci-hotplug-fix-leaks-in-ibm-hot-plug-controller-driver-ibmphp_init_devno.patch
+gregkh-pci-pci-hotplug-fakephp-return-success-not-enodev-when-bus-rescan-is-triggered.patch
PCI tree updates
-pci-hotplug-introduce-pci_slot-fix.patch
-pci-hotplug-introduce-pci_slot-fix-fix.patch
-pci-hotplug-introduce-pci_slot-fix-2.patch
-pci-hotplug-introduce-pci_slot-fix-99.patch
-pci-hotplug-introduce-pci_slot-fix-3.patch
Folded into pci-hotplug-introduce-pci_slot.patch
-pci-hotplug-acpi-pci-slot-detection-driver-fix.patch
-drivers-acpi-pci_slotc-fix-build-with-config_dmi=n.patch
Folded into pci-hotplug-acpi-pci-slot-detection-driver.patch
+rcu-add-call_rcu_sched.patch
+rcu-add-memory-barriers-and-comments-to-rcu_check_callbacks.patch
+rcu-add-rcu_barrier_sched-and-rcu_barrier_bh.patch
+rcu-add-call_rcu_sched-and-friends-to-rcutorture.patch
+rcu-1q08-rcu-doc-update-add-call_rcu_sched.patch
RCU updates
+scsi-fix-platform-driver-hotplug-coldplug.patch
+scsi-fix-platform-driver-hotplug-coldplug-sgiwd93-fix.patch
Fix hotplugging
+mpt-remove-unused-struct-mpt_proc_entry_t.patch
+drivers-scsi-use-time_before-time_before_eq-etc.patch
scsi driver cleanups
-kconfig-cleanup-block-kconfigiosched-help-descriptions.patch
Dropped due to rejects (I think)
+gregkh-usb-usb-cp2101-add-new-device-ids.patch
+gregkh-usb-usb-fix-memory-leak-in-mon_stat_release.patch
+gregkh-usb-checkpatch-usb_free_urb-can-take-null.patch
+gregkh-usb-usb-serial-sierra-add-new-dev-group.patch
+gregkh-usb-usb-ohci-fix-bug-in-controller-resume.patch
+gregkh-usb-usb-convert-away-from-urb-status-in-xpad-driver.patch
+gregkh-usb-usb-root-hubs-don-t-lie-about-their-number-of-tts.patch
+gregkh-usb-usb-clarify-usage-of-hcd-suspend-resume-methods.patch
+gregkh-usb-usb-ohci-host-controller-resumes-leave-root-hub-suspended.patch
+gregkh-usb-usb-replace-remaining-__pretty_function__-occurrences.patch
+gregkh-usb-usb-rework-sysfs-removal-of-interface-files.patch
+gregkh-usb-usb-gadget-section-fixes.patch
+gregkh-usb-usb-dummy-hcd-use-dynamic-allocation-for-platform_devices.patch
+gregkh-usb-usb-at91_udc-can-prefetch-data.patch
+gregkh-usb-usb-ehci-shutdown-refactored.patch
+gregkh-usb-usb-oti6858-fix-tcflsh-ioctl-handling.patch
+gregkh-usb-usb-r8a66597-hcd-fix-interrupt-transfer-interval.patch
+gregkh-usb-usb-r8a66597-hcd-fix-usb-device-connection-timing.patch
+gregkh-usb-usb-r8a66597-hcd-add-support-for-sh7366-usb-host.patch
+gregkh-usb-usb-add-extension-of-anchor-api-usb_unlink_anchored_urbs.patch
+gregkh-usb-usb-remove-superfluous-depends-on-usb_serial-from-kconfig.patch
+gregkh-usb-usb-update-comments-about-usb-driver-s-header.patch
+gregkh-usb-usb-log-an-error-message-when-usb-enumeration-fails.patch
+gregkh-usb-usb-ehci-qh-qtd-cleanup-comments.patch
+gregkh-usb-usb-add-documentation-about-usb_anchor.patch
+gregkh-usb-usb-optionc-correct-dtr-behaviour.patch
+gregkh-usb-usb-serial-remove-unneeded-number-endpoints-settings.patch
+gregkh-usb-usb-serial-remove-endpoints-setting-checks-from-core-and-header.patch
+gregkh-usb-usb-g_file_storage-ignore-bulk-out-data-after-invalid-cbw.patch
+gregkh-usb-usb-hcds-use-the-do_remote_wakeup-flag.patch
+gregkh-usb-usb-ohci-turn-off-rd-when-remote-wakeup-is-disabled.patch
+gregkh-usb-usb-don-t-explicitly-reenable-root-hub-status-interrupts.patch
+gregkh-usb-usb-add-documentation-about-callbacks.patch
+gregkh-usb-usb-cdc-acm-signedness-fix.patch
+gregkh-usb-usb-ehci-qh_completions-cleanup-and-bugfix.patch
+gregkh-usb-usb-replace-remaining-__function__-occurrences.patch
+gregkh-usb-usb-serial-more-fixes-and-groundwork-for-tty-changes.patch
+gregkh-usb-usb-remove-unnecessary-type-casting-of-urb-context.patch
+gregkh-usb-wusb-add-the-wireless-usb-stack-to-linux.patch
+gregkh-usb-wusb-add-whc-rc-radio-control-driver.patch
+gregkh-usb-wusb-add-hwa-rc-radio-controller-driver.patch
+gregkh-usb-wusb-add-uwb-core-for-wimedia-link-protocol.patch
+gregkh-usb-wusb-add-the-i1480-driver.patch
+gregkh-usb-wusb-add-the-usb-wireless-core-code.patch
+gregkh-usb-wusb-add-the-usb-wusb-cbaf-driver.patch
+gregkh-usb-wusb-add-the-usb-wireless-core-host-controller-helper-driver.patch
+gregkh-usb-wusb-add-hwa-hc-wireless-host-controller-driver.patch
USB tree updates
+fix-gregkh-usb-usb-ohci-host-controller-resumes-leave-root-hub-suspended.patch
+fix-gregkh-usb-wusb-add-the-wireless-usb-stack-to-linux.patch
+fix-gregkh-usb-usb-hcds-use-the-do_remote_wakeup-flag.patch
+uwb-seems-to-need-pci.patch
Fix it.
+git-xfs-fixups.patch
Repair git-xfs
+aes-x86_64-asm-implementation-optimization.patch
Make Intel crypto faster than AMD crypto ;)
-git-semaphore-vs-git-x86.patch
Dropped
+input-replace-remaining-__function__-occurrences.patch
cleanups
+pageflags-standardize-comment-inclusion-in-asm-offsetsh-and-fix-mips.patch
+pageflags-get-rid-of-flags_reserved-sparc64-fix.patch
Update the page-flags patches in -mm.
+mempolicy-use-mpol_f_local-to-indicate-preferred-local-policy-fix.patch
Fix mempolicy-use-mpol_f_local-to-indicate-preferred-local-policy.patch
+mm-page_allocc-remove-hand-coded-get_order.patch
+mm-fix-broken-gfp_zone-with-__gfp_thisnode.patch
+mm-fix-misleading-__gfp_repeat-related-comments.patch
+page-allcoator-smarter-retry-of-costly-order-allocations.patch
+page-allocator-explicitly-retry-hugepage-allocations.patch
MM work
+uml-make-a-function-static.patch
+uml-remove-a-useless-function.patch
+uml-make-three-functions-static.patch
+uml-make-several-things-static.patch
+arch-um-os-linux-sys-i386-task_sizec-improve-a-bit.patch
+uml-clean-up-arch-um-drivers-ubd_kernc.patch
UML updates
+update-checkpatchpl-to-version-018.patch
checkpatch update
+smbh-uses-struct-timespec-but-didnt-include-linux-timeh.patch
smb.h fixlet.
+utimensat-non-conformances-and-fixes.patch
+utimensat-non-conformances-and-fixes-checkpatch-fixes.patch
utimes fixes (awaiting input from Ulrich)
+serial-use-time_before-time_before_eq-etc.patch
+atmel_serial-remove-duplicated-macro-definition.patch
Serial updates
+capifs-fix-memory-leak-on-remount.patch
i4l fix
+ecryptfs-introduce-device-handle-for-userspace-daemon-communications.patch
+ecryptfs-integrate-ecryptfs-device-handle-into-the-module.patch
+ecryptfs-integrate-ecryptfs-device-handle-into-the-module-printk-fixes.patch
+ecryptfs-make-key-module-subsystem-respect-namespaces.patch
+ecryptfs-make-key-module-subsystem-respect-namespaces-fix-refs-to-pid-and-user_ns.patch
+ecryptfs-make-key-module-subsystem-respect-namespaces-fix-refs-to-pid-and-user_ns-fix.patch
ecryptfs updates
+rtc-add-the-support-for-alarm-time-relative-to-current-time-in-sysfs.patch
+drivers-char-rtcc-use-time_before-time_before_eq-etc.patch
RTC updates
+x86-geode-add-virtual-systems-architecture-detection.patch
+gxfb-lxfb-use-vsa-definitions-when-fetching-framebuffer-size.patch
+gxfb-lxfb-detect-framebuffer-size-using-an-msr-if-vsa2-isnt-available.patch
+olpc-gxfb-lxfb-add-dcon-panel-modes-to-framebuffer-drivers.patch
+olpc-gxfb-lxfb-add-dcon-panel-modes-to-framebuffer-drivers-section-fix.patch
geode/olpc things
+drivers-video-uvesafbc-fix-error-path-memory-leak.patch
+fb-convert-proc-fb-to-seq_file-interface.patch
+fb-convert-proc-fb-to-seq_file-interface-checkpatch-fixes.patch
+fbdev-intelfb-add-support-for-the-intel-integrated-graphics-controller-965g-965gm.patch
+drivers-video-w100fbc-avoid-a-couple-of-error-path-null-derefs.patch
+x86-olpc-add-one-laptop-per-child-architecture-support.patch
+x86-olpc-add-one-laptop-per-child-architecture-support-fix.patch
+x86-olpc-add-one-laptop-per-child-architecture-support-fix-2.patch
fbdev updates
+raid-remove-leading-tab-on-printk-messages.patch
+raid-remove-trailing-space-from-printk-line.patch
+drivers-md-use-time_before-time_before_eq-etc.patch
+drivers-md-use-time_before-time_before_eq-etc-checkpatch-fixes.patch
MD udpates
+ext2-retry-block-allocation-if-new-blocks-are-allocated-from-system-zone.patch
+ext2-retry-block-allocation-if-new-blocks-are-allocated-from-system-zone-comment-typo.patch
ext3 fix
+ext3-retry-block-allocation-if-new-blocks-are-allocated-from-system-zone.patch
+ext3-retry-block-allocation-if-new-blocks-are-allocated-from-system-zone-comment-typo.patch
+ext3-fix-mount-messages-when-quota-disabled.patch
ext3 fixes
+cgroup-api-files-rename-read-write_uint-methods-to-read_write_u64-fix.patch
Fix cgroup-api-files-rename-read-write_uint-methods-to-read_write_u64.patch
+cgroups-add-an-owner-to-the-mm_struct.patch
cgroups work.
+use-vmalloc-for-mem_cgroup-allocation-v3.patch
+use-vmalloc-for-mem_cgroup-allocation-v3-simplification.patch
memcg work
+ptrace_signal-subroutine.patch
ptrace cleanup
+ext4-fix-mount-messages-when-quota-disabled.patch
ext4 fix
+ipc-sysvsem-implement-sys_unshareclone_sysvsem.patch
+ipc-sysvsem-force-unshareclone_sysvsem-when-clone_newipc.patch
+ipc-sysvsem-refuse-cloneclone_sysvsemclone_newipc.patch
+ipc-sysvsem-refuse-cloneclone_sysvsemclone_newipc-cleanup.patch
ipc/namespace work
+ipmi-remove-write_proc-code.patch
ipmi cleanup
+drivers-char-ds1286c-use-time_before-time_before_eq-etc.patch
char driver cleanup
+s390-tty-prepare-for-put_char-to-return-success-fail.patch
+serial-m68k-put_char-returns.patch
+usb-gadget-switch-to-put_char-returning-int.patch
+amiserial-switch-put-char-to-return-success-fail.patch
+char-switch-gs-cyclades-and-esp-to-return-int-for-put_char.patch
+mxser-switch-to-put_char-being-int.patch
+pcmcia-serial-to-int-put_char-method.patch
+riscom-rocket-switch-to-int-put_char-method.patch
+serial167-switch-to-int-put_char-method.patch
+specialix-switch-to-int-put_char-method.patch
+synclink-series-switch-to-int-put_char-method.patch
+consoles-switch-to-int-put_char-method.patch
+isdn-switch-to-int-put_char-method.patch
+pty-prepare-for-tty-ops-changes.patch
+pc300-update-to-tty_set_operations.patch
+serial-switch-the-serial-core-to-int-put_char-methods.patch
+isicom-bring-into-coding-style.patch
+isicom-bring-into-coding-style-fix.patch
+tty-the-big-operations-rework.patch
+tty-the-big-operations-rework-fix-2.patch
+tty-the-big-operations-rework-isicom-fix.patch
+tty-the-big-operations-rework-simserial-fix.patch
+strip-fix-up-strip-for-the-new-order.patch
+tty-the-big-operations-rework-vs-git-kgdb-light.patch
+tty-the-big-operations-rework-vs-kgdb-2.patch
+tty-the-big-operations-rework-broke-wan.patch
+tty-fix-routine-name-in-ptmx_open.patch
+devpts-propagate-error-code-from-devpts_pty_new.patch
+devpts-factor-out-pty-index-allocation.patch
+devpts-factor-out-pty-index-allocation-fix.patch
TTY driver work.
+proc-convert-proc-tty-ldiscs-to-seq_file-interface.patch
+proc-introduce-proc_create_data-to-setup-de-data.patch
+nfsd-use-proc_create-to-setup-de-proc_fops.patch
+nfs-use-proc_create-to-setup-de-proc_fops.patch
+afs-use-non-racy-method-for-proc-entries-creation.patch
+ext4-use-non-racy-method-for-proc-entries-creation.patch
+reiserfs-use-non-racy-method-for-proc-entries-creation.patch
+jbd2-use-non-racy-method-for-proc-entries-creation.patch
+sysvipc-use-non-racy-method-for-proc-entries-creation.patch
+mm-use-non-racy-method-for-proc-swaps-creation.patch
+sound-use-non-racy-method-for-proc-driver-snd-page-alloc-creation.patch
+zorro-use-non-racy-method-for-proc-entries-creation.patch
+samples-use-non-racy-method-for-proc-marker-example-creation.patch
+scsi-use-non-racy-method-for-proc-entries-creation.patch
+usb-use-non-racy-method-for-proc-entries-creation.patch
+s390-use-non-racy-method-for-proc-entries-creation.patch
+arm-use-non-racy-method-for-proc-davinci_clocks-creation.patch
+avr32-proc-use-non-racy-method-for-proc-tlb-creation.patch
+cris-use-non-racy-method-for-proc-system_profile-creation.patch
+ia64-use-non-racy-method-for-proc-entries-creation.patch
+parisc-use-non-racy-method-for-proc-pcxl_dma-creation.patch
+powerpc-use-non-racy-method-for-proc-entries-creation.patch
+acpi-use-non-racy-method-for-proc-entries-creation.patch
+netdev-use-non-racy-method-for-proc-entries-creation.patch
+isdn-use-non-racy-method-for-proc-entries-creation.patch
+kernel-use-non-racy-method-for-proc-entries-creation.patch
+parisc-use-non-racy-method-for-proc-entries-creation.patch
+drivers-use-non-racy-method-for-proc-entries-creation.patch
+drivers-use-non-racy-method-for-proc-entries-creation-2.patch
procfs work
+kernel-add-common-infrastructure-for-unaligned-access.patch
+kernel-move-arches-to-use-common-unaligned-access.patch
+drivers-block-use-get_unaligned_-helpers.patch
+hid-core-use-get_unaligned_-helpers.patch
+char-use-get_unaligned_-helpers.patch
+input-use-get_unaligned_-helpers.patch
+mmc-use-get-put_unaligned_-helpers.patch
+net-use-get-put_unaligned_-helpers.patch
+wireless-use-get-put_unaligned_-helpers.patch
+pcmcia-use-get-put_unaligned_-helpers.patch
+usb-use-get-put_unaligned_-helpers.patch
+video-use-get-put_unaligned_-helpers.patch
+fat-use-get-put_unaligned_-helpers.patch
+hfsplus-use-get-put_unaligned_-helpers.patch
+isofs-use-get-put_unaligned_-helpers.patch
+ncpfs-use-get-put_unaligned_-helpers.patch
+ncpfs-use-get-put_unaligned_-helpers-checkpatch-fixes.patch
unaligned access cleanups
+omap_rng-minor-updates.patch
rng updates
+relayfs-support-larger-relay-buffer-take-3.patch
+relayfs-support-larger-relay-buffer-take-3-cleanup.patch
relatfs update
+aio-remove-misleading-comment-from-ioctx_lookup.patch
AIO cleanup
+add-kbuildh-that-contains-common-definitions-for-kbuild-users.patch
+x86-use-kbuildh.patch
+mips-use-kbuildh-instead-of-macros-in-asm-offsetsc.patch
+alpha-use-kbuildh-instead-of-macros-in-asm-offsetsc.patch
+ia64-use-kbuildh-macros-instead-of-defining-macros-in-asm-offsetsc.patch
+arm-use-kbuildh-instead-of-macros-in-asm-offsetsc.patch
+xtensa-use-kbuildh-macros-instead-of-defining-them-in-asm-offsetsc.patch
+sparc-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+avr32-use-kbuildh-macros-instead-of-defining-macros-in-asm-offsetsc.patch
+blackfin-use-kbuildh-instead-of-defining-macros-in-asm-macrosc.patch
+frv-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+h8300-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+m68k-m68kmmu-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+mn10300-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+parisc-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+ppc-powerpc-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+s390-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+s390-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc-update.patch
+sh-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
+v850-use-kbuildh-instead-of-defining-macros-in-asm-offsetsc.patch
cleanups to asm-offsets.c
+proc-use-non-racy-method-for-proc-page_owner-creation-page_owner.patch
procfs cleanup
6045 commits in 1878 patch files
All patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
^ permalink raw reply [flat|nested] 109+ messages in thread
* [PATCH] 2.6.25-mm1 - Build Failure with PWRficient onchip memory controller driver
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
@ 2008-04-18 11:26 ` Kamalesh Babulal
2008-04-18 13:02 ` StackProtector Oopses - Re: 2.6.25-mm1 Reuben Farrelly
` (9 subsequent siblings)
10 siblings, 0 replies; 109+ messages in thread
From: Kamalesh Babulal @ 2008-04-18 11:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, apw
Hi Andrew,
The 2.6.25-mm1 kernel allyesconfig build fails on the powerpc
drivers/edac/pasemi_edac.c: In function ‘pasemi_edac_init’:
drivers/edac/pasemi_edac.c:288: error: implicit declaration of function ‘opstate_init’
drivers/edac/pasemi_edac.c: In function ‘__check_edac_op_state’:
drivers/edac/pasemi_edac.c:304: error: ‘edac_op_state’ undeclared (first use in this function)
drivers/edac/pasemi_edac.c:304: error: (Each undeclared identifier is reported only once
drivers/edac/pasemi_edac.c:304: error: for each function it appears in.)
drivers/edac/pasemi_edac.c: At top level:
drivers/edac/pasemi_edac.c:304: error: ‘edac_op_state’ undeclared here (not in a function)
make[2]: *** [drivers/edac/pasemi_edac.o] Error 1
make[1]: *** [drivers/edac] Error 2
make: *** [drivers] Error 2
I have only build tested the patch.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
---
--- linux-2.6.25/drivers/edac/pasemi_edac.c 2008-04-18 16:18:27.000000000 +0530
+++ linux-2.6.25/drivers/edac/~pasemi_edac.c 2008-04-18 16:18:36.000000000 +0530
@@ -26,6 +26,7 @@
#include <linux/pci.h>
#include <linux/pci_ids.h>
#include <linux/slab.h>
+#include <linux/edac.h>
#include "edac_core.h"
#define MODULE_NAME "pasemi_edac"
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply [flat|nested] 109+ messages in thread
* StackProtector Oopses - Re: 2.6.25-mm1
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
2008-04-18 11:26 ` [PATCH] 2.6.25-mm1 - Build Failure with PWRficient onchip memory controller driver Kamalesh Babulal
@ 2008-04-18 13:02 ` Reuben Farrelly
2008-04-18 13:36 ` Ingo Molnar
2008-04-18 16:40 ` 2.6.25-mm1 (build error: driver core) Randy Dunlap
` (8 subsequent siblings)
10 siblings, 1 reply; 109+ messages in thread
From: Reuben Farrelly @ 2008-04-18 13:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Ingo Molnar
On 18/04/2008 6:47 PM, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
The GCC stackprotector option is a no-go for me, and causes 100% repeatable
fatal oopses on boot with my x86_64 box.
This is not new to 2.6.25-mm1 - but was also present in 2.6.24-rc8-mm2
(2.6.24-rc8-mm1 was good, but this option didn't exist then).
It seems that enabling the stackprotector option:
tornado boot # diff -u config-2.6.25-mm1 config-2.6.25-mm1.old
--- config-2.6.25-mm1 2008-04-18 22:40:15.000000000 +1000
+++ config-2.6.25-mm1.old 2008-04-18 20:09:38.000000000 +1000
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-mm1
-# Fri Apr 18 22:25:04 2008
+# Fri Apr 18 19:57:17 2008
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
@@ -256,7 +256,8 @@
CONFIG_X86_PAT=y
# CONFIG_EFI is not set
CONFIG_SECCOMP=y
-# CONFIG_CC_STACKPROTECTOR is not set
+CONFIG_CC_STACKPROTECTOR_ALL=y
+CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
is enough to prevent my system booting, viz:
input: Belkin Components Belkin OmniView KVM Switch as
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.0/input/input2
input: USB HID v1.00 Keyboard [Belkin Components Belkin OmniView KVM Switch] on
usb-0000:00:1d.1-1.1
input: Belkin Components Belkin OmniView KVM Switch as
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.1/3-1.1:1.1/input/input3
input: USB HID v1.00 Mouse [Belkin Components Belkin OmniView KVM Switch] on
usb-0000:00:1d.1-1.1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
NET: Registered protocol family 17
Testing -fstack-protector-all feature
------------[ cut here ]------------
WARNING: at ™š:-2145164734 0x0()
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #1
Call Trace:
[<ffffffff802362a9>] warn_on_slowpath+0x67/0x98
[<ffffffff802f31da>] ? proc_register+0x104/0x1b0
[<ffffffff80237e2a>] ? printk+0x79/0x94
[<ffffffff804f1d05>] ? register_netdevice_notifier+0xed/0x1c9
[<ffffffff8023da80>] ? insert_resource+0x3c/0x117
[<ffffffff8023630d>] ? __stack_chk_test+0x33/0x7b
[<ffffffff80740ff0>] ? kernel_init+0x16d/0x30d
[<ffffffff8020c7b8>] ? child_rip+0xa/0x12
[<ffffffff80740e83>] ? kernel_init+0x0/0x30d
[<ffffffff8020c7ae>] ? child_rip+0x0/0x12
---[ end trace 8d584356702633c0 ]---
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<0000000000000000>]
PGD 0
Oops: 0010 [1] SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Tainted: G W 2.6.25-mm1 #1
RIP: 0010:[<0000000000000000>] [<0000000000000000>]
RSP: 0000:ffff8100bf05de88 EFLAGS: 00010296
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000200
RBP: ffff8100bf05de90 R08: 0000000000000000 R09: ffff8100000bcce0
R10: 0720072007200720 R11: 0720072007200720 R12: 0000000000000000
R13: ffffffff80787530 R14: 0000000000000000 R15: ffffffff8067fd3c
FS: 0000000000000000(0000) GS:ffffffff80721000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff8100bf05c000, task ffff8100bf060000)
Stack: 0000000000000000 ffff8100bf05deb0 ffffffff8023630d 0000000000000000
0000000090e2a955 ffff8100bf05df40 ffffffff80740ff0 aa55aa0000000000
aa55aa55aa55aa55 0000000000000003 55aa55aa55aa55aa 55aa55aa55aa55aa
Call Trace:
[<ffffffff8023630d>] __stack_chk_test+0x33/0x7b
[<ffffffff80740ff0>] kernel_init+0x16d/0x30d
[<ffffffff8020c7b8>] child_rip+0xa/0x12
[<ffffffff80740e83>] ? kernel_init+0x0/0x30d
[<ffffffff8020c7ae>] ? child_rip+0x0/0x12
Code: Bad RIP value.
RIP [<0000000000000000>]
RSP <ffff8100bf05de88>
CR2: 0000000000000000
---[ end trace 8d584356702633c0 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D W 2.6.25-mm1 #1
Call Trace:
[<ffffffff80236716>] panic+0xb2/0x187
[<ffffffff802547c7>] ? blocking_notifier_call_chain+0x24/0x42
[<ffffffff8023a5b7>] do_exit+0x772/0x7eb
[<ffffffff8020cd1f>] oops_end+0x9a/0x9f
[<ffffffff80224349>] do_page_fault+0x61d/0x7c4
[<ffffffff802f31da>] ? proc_register+0x104/0x1b0
[<ffffffff805a51f9>] error_exit+0x0/0x51
[<ffffffff8023630d>] ? __stack_chk_test+0x33/0x7b
[<ffffffff80740ff0>] ? kernel_init+0x16d/0x30d
[<ffffffff8020c7b8>] ? child_rip+0xa/0x12
[<ffffffff80740e83>] ? kernel_init+0x0/0x30d
[<ffffffff8020c7ae>] ? child_rip+0x0/0x12
Rebooting in 30 seconds..
----------
gcc version 4.2.3 (Gentoo 4.2.3 p1.0)
I have put the config and full dmesg of 2.6.25-mm1 both working and not working,
up at http://www.reub.net/files/kernel/2.6.25-mm1/
It is the exact same oops with 2.6.24-rc8-mm1.
Reuben
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-18 13:02 ` StackProtector Oopses - Re: 2.6.25-mm1 Reuben Farrelly
@ 2008-04-18 13:36 ` Ingo Molnar
2008-04-18 13:51 ` Arjan van de Ven
2008-04-18 14:49 ` Reuben Farrelly
0 siblings, 2 replies; 109+ messages in thread
From: Ingo Molnar @ 2008-04-18 13:36 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: Andrew Morton, linux-kernel, Arjan van de Ven
* Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
> is enough to prevent my system booting, viz:
hm, does it boot up fine with the attached patch and stackprotector
enabled? It appears that your system got to the self-test so
stackprotector is working mostly - it's just that the self-test went
wrong.
Ingo
----------------->
Subject: x86: disable stackprotector selftest
From: Ingo Molnar <mingo@elte.hu>
Date: Fri Apr 18 15:21:49 CEST 2008
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/panic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-x86.q/kernel/panic.c
===================================================================
--- linux-x86.q.orig/kernel/panic.c
+++ linux-x86.q/kernel/panic.c
@@ -394,5 +394,5 @@ void __stack_chk_fail(void)
}
EXPORT_SYMBOL(__stack_chk_fail);
-late_initcall(__stack_chk_test);
+/* late_initcall(__stack_chk_test); */
#endif
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-18 13:36 ` Ingo Molnar
@ 2008-04-18 13:51 ` Arjan van de Ven
2008-04-18 14:41 ` Reuben Farrelly
2008-04-18 14:49 ` Reuben Farrelly
1 sibling, 1 reply; 109+ messages in thread
From: Arjan van de Ven @ 2008-04-18 13:51 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Reuben Farrelly, Andrew Morton, linux-kernel
On Fri, 18 Apr 2008 15:36:45 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
>
> > is enough to prevent my system booting, viz:
>
> hm, does it boot up fine with the attached patch and stackprotector
> enabled? It appears that your system got to the self-test so
> stackprotector is working mostly - it's just that the self-test went
> wrong.
>
yes it'll be interesting to see if this is due to the test triggering or due to
something else.
Reuben:
I assume your gcc is pretty vanilla and doesn't have weird patches in this area?
Can you do a (with the test enabled in the config/code) do a
make kernel/panic.s
and send me that file? (this allows me to see what code your gcc generated for the test)
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-18 13:51 ` Arjan van de Ven
@ 2008-04-18 14:41 ` Reuben Farrelly
0 siblings, 0 replies; 109+ messages in thread
From: Reuben Farrelly @ 2008-04-18 14:41 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Ingo Molnar, Andrew Morton, linux-kernel
On 18/04/2008 11:51 PM, Arjan van de Ven wrote:
> On Fri, 18 Apr 2008 15:36:45 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
>
>> * Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
>>
>>> is enough to prevent my system booting, viz:
>> hm, does it boot up fine with the attached patch and stackprotector
>> enabled? It appears that your system got to the self-test so
>> stackprotector is working mostly - it's just that the self-test went
>> wrong.
>>
>
> yes it'll be interesting to see if this is due to the test triggering or due to
> something else.
>
> Reuben:
> I assume your gcc is pretty vanilla and doesn't have weird patches in this area?
I think so. Well, put it this way... I haven't made any changes to it, this is
the standard/current gcc that has been in Gentoo Portage for the last while.
> Can you do a (with the test enabled in the config/code) do a
> make kernel/panic.s
> and send me that file? (this allows me to see what code your gcc generated
for the test)
Done - posted up in the web directory along with the other files (saves the
possible grief of MUA mangling).
I'm about to reboot to try Ingo's test also.
Reuben
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-18 13:36 ` Ingo Molnar
2008-04-18 13:51 ` Arjan van de Ven
@ 2008-04-18 14:49 ` Reuben Farrelly
2008-04-21 15:06 ` Ingo Molnar
1 sibling, 1 reply; 109+ messages in thread
From: Reuben Farrelly @ 2008-04-18 14:49 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Andrew Morton, linux-kernel, Arjan van de Ven
On 18/04/2008 11:36 PM, Ingo Molnar wrote:
> * Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
>
>> is enough to prevent my system booting, viz:
>
> hm, does it boot up fine with the attached patch and stackprotector
> enabled? It appears that your system got to the self-test so
> stackprotector is working mostly - it's just that the self-test went
> wrong.
It boots up fine with that patch below and:
tornado boot # grep STACKPROTECT /boot/config-2.6.25-mm1-wip
CONFIG_CC_STACKPROTECTOR_ALL=y
CONFIG_CC_STACKPROTECTOR=y
In fact I'm running with it applied right now and it all seems good so far, so I
guess that's confirmation that it is just the test itself which is problematic?
Reuben
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (build error: driver core)
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
2008-04-18 11:26 ` [PATCH] 2.6.25-mm1 - Build Failure with PWRficient onchip memory controller driver Kamalesh Babulal
2008-04-18 13:02 ` StackProtector Oopses - Re: 2.6.25-mm1 Reuben Farrelly
@ 2008-04-18 16:40 ` Randy Dunlap
2008-04-18 16:56 ` Greg KH
2008-04-18 16:45 ` 2.6.25-mm1 (build error: trace selftest) Randy Dunlap
` (7 subsequent siblings)
10 siblings, 1 reply; 109+ messages in thread
From: Randy Dunlap @ 2008-04-18 16:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, gregkh
On Fri, 18 Apr 2008 01:47:57 -0700 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
with CONFIG_BLOCK=n:
linux-2.6.25-mm1/drivers/base/core.c: In function 'device_to_dev_kobj':
linux-2.6.25-mm1/drivers/base/core.c:768: error: 'block_class' undeclared (first use in this function)
make[3]: *** [drivers/base/core.o] Error 1
---
~Randy
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (build error: trace selftest)
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (2 preceding siblings ...)
2008-04-18 16:40 ` 2.6.25-mm1 (build error: driver core) Randy Dunlap
@ 2008-04-18 16:45 ` Randy Dunlap
2008-04-18 20:14 ` 2.6.25-mm1 Valdis.Kletnieks
` (6 subsequent siblings)
10 siblings, 0 replies; 109+ messages in thread
From: Randy Dunlap @ 2008-04-18 16:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, mingo
On Fri, 18 Apr 2008 01:47:57 -0700 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
with CONFIG_RT_MUTEXES=N:
In file included from linux-2.6.25-mm1/kernel/trace/trace.c:2432:
linux-2.6.25-mm1/kernel/trace/trace_selftest.c: In function 'trace_wakeup_test_thread':
linux-2.6.25-mm1/kernel/trace/trace_selftest.c:413: error: implicit declaration of function 'rt_mutex_setprio'
make[3]: *** [kernel/trace/trace.o] Error 1
---
~Randy
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (build error: driver core)
2008-04-18 16:40 ` 2.6.25-mm1 (build error: driver core) Randy Dunlap
@ 2008-04-18 16:56 ` Greg KH
2008-04-18 18:38 ` Dan Williams
0 siblings, 1 reply; 109+ messages in thread
From: Greg KH @ 2008-04-18 16:56 UTC (permalink / raw)
To: Randy Dunlap, Dan Williams; +Cc: Andrew Morton, linux-kernel
On Fri, Apr 18, 2008 at 09:40:41AM -0700, Randy Dunlap wrote:
> On Fri, 18 Apr 2008 01:47:57 -0700 Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
>
> with CONFIG_BLOCK=n:
>
> linux-2.6.25-mm1/drivers/base/core.c: In function 'device_to_dev_kobj':
> linux-2.6.25-mm1/drivers/base/core.c:768: error: 'block_class' undeclared (first use in this function)
> make[3]: *** [drivers/base/core.o] Error 1
Ah, more fun caused by Dan's /sys/dev/... patch.
Dan, this is causing a lot of problems, I'm going to drop it for now
until the build and run-time errors get resolved.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (build error: driver core)
2008-04-18 16:56 ` Greg KH
@ 2008-04-18 18:38 ` Dan Williams
0 siblings, 0 replies; 109+ messages in thread
From: Dan Williams @ 2008-04-18 18:38 UTC (permalink / raw)
To: Greg KH; +Cc: Randy Dunlap, Andrew Morton, linux-kernel
On Fri, Apr 18, 2008 at 9:56 AM, Greg KH <greg@kroah.com> wrote:
> On Fri, Apr 18, 2008 at 09:40:41AM -0700, Randy Dunlap wrote:
> > On Fri, 18 Apr 2008 01:47:57 -0700 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> >
> > with CONFIG_BLOCK=n:
> >
> > linux-2.6.25-mm1/drivers/base/core.c: In function 'device_to_dev_kobj':
> > linux-2.6.25-mm1/drivers/base/core.c:768: error: 'block_class' undeclared (first use in this function)
> > make[3]: *** [drivers/base/core.o] Error 1
>
> Ah, more fun caused by Dan's /sys/dev/... patch.
>
> Dan, this is causing a lot of problems, I'm going to drop it for now
> until the build and run-time errors get resolved.
>
Ok, I'll have an updated version with Kay's duplicate-entry fix and a
resolution for CONFIG_BLOCK=n shortly...
> thanks,
>
> greg k-h
>
Regards,
Dan
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (3 preceding siblings ...)
2008-04-18 16:45 ` 2.6.25-mm1 (build error: trace selftest) Randy Dunlap
@ 2008-04-18 20:14 ` Valdis.Kletnieks
2008-04-18 23:09 ` 2.6.25-mm1: orphaned files after build Alexey Dobriyan
` (5 subsequent siblings)
10 siblings, 0 replies; 109+ messages in thread
From: Valdis.Kletnieks @ 2008-04-18 20:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3221 bytes --]
On Fri, 18 Apr 2008 01:47:57 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
I may have reported this same one previously against an earlier -mm, or somebody
did, or something... ;)
x86_64 kernel, Core2 Duo T7200, Dell Latitude D820 laptop...
[ 0.060388] ACPI: Core revision 20080321
[ 0.070079] ------------[ cut here ]------------
[ 0.070082] WARNING: at arch/x86/kernel/genapic_64.c:86 read_apic_id+0x41/0x7c()
[ 0.070085] Modules linked in:
[ 0.070089] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #1
[ 0.070091]
[ 0.070092] Call Trace:
[ 0.070099] [<ffffffff8023c702>] warn_on_slowpath+0x67/0xb7
[ 0.070105] [<ffffffff805d096e>] ? _spin_lock+0x25/0x54
[ 0.070111] [<ffffffff8021e399>] ? __cpus_weight+0x4b/0x68
[ 0.070114] [<ffffffff802245c1>] read_apic_id+0x41/0x7c
[ 0.070119] [<ffffffff807a0ded>] verify_local_APIC+0xb4/0x177
[ 0.070123] [<ffffffff805d4153>] ? sub_preempt_count+0x44/0x6e
[ 0.070126] [<ffffffff8079faf4>] native_smp_prepare_cpus+0x238/0x36a
[ 0.070129] [<ffffffff805d4153>] ? sub_preempt_count+0x44/0x6e
[ 0.070134] [<ffffffff80794712>] kernel_init+0x69/0x2a1
[ 0.070137] [<ffffffff805d0d42>] ? _spin_unlock_irq+0x43/0x62
[ 0.070143] [<ffffffff802366b7>] ? finish_task_switch+0x3e/0xb4
[ 0.070147] [<ffffffff8020d6e8>] child_rip+0xa/0x12
[ 0.070150] [<ffffffff8020cdd0>] ? restore_args+0x0/0x30
[ 0.070154] [<ffffffff807946a9>] ? kernel_init+0x0/0x2a1
[ 0.070157] [<ffffffff8020d6de>] ? child_rip+0x0/0x12
[ 0.070159]
[ 0.070166] ---[ end trace a7919e7f17c0a725 ]---
[ 0.070169] ------------[ cut here ]------------
[ 0.070171] WARNING: at arch/x86/kernel/genapic_64.c:86 read_apic_id+0x41/0x7c()
[ 0.070174] Modules linked in:
[ 0.070177] Pid: 1, comm: swapper Tainted: G W 2.6.25-mm1 #1
[ 0.070179]
[ 0.070179] Call Trace:
[ 0.070182] [<ffffffff8023c702>] warn_on_slowpath+0x67/0xb7
[ 0.070186] [<ffffffff805d096e>] ? _spin_lock+0x25/0x54
[ 0.070189] [<ffffffff8021e399>] ? __cpus_weight+0x4b/0x68
[ 0.070192] [<ffffffff802245c1>] read_apic_id+0x41/0x7c
[ 0.070195] [<ffffffff807a0e1f>] verify_local_APIC+0xe6/0x177
[ 0.070199] [<ffffffff805d4153>] ? sub_preempt_count+0x44/0x6e
[ 0.070202] [<ffffffff8079faf4>] native_smp_prepare_cpus+0x238/0x36a
[ 0.070205] [<ffffffff805d4153>] ? sub_preempt_count+0x44/0x6e
[ 0.070209] [<ffffffff80794712>] kernel_init+0x69/0x2a1
[ 0.070212] [<ffffffff805d0d42>] ? _spin_unlock_irq+0x43/0x62
[ 0.070215] [<ffffffff802366b7>] ? finish_task_switch+0x3e/0xb4
[ 0.070218] [<ffffffff8020d6e8>] child_rip+0xa/0x12
[ 0.070221] [<ffffffff8020cdd0>] ? restore_args+0x0/0x30
[ 0.070225] [<ffffffff807946a9>] ? kernel_init+0x0/0x2a1
[ 0.070228] [<ffffffff8020d6de>] ? child_rip+0x0/0x12
[ 0.070230]
[ 0.070231] ---[ end trace a7919e7f17c0a725 ]---
[ 0.081710] CPU0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz stepping 06
Other than that, it's lived for an hour without barfing yet, but I won't
have a chance to kick the tires and try stupid sysadmin tricks like I usually
do until Sunday-ish... Have a good weekend...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 109+ messages in thread
* 2.6.25-mm1: orphaned files after build
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (4 preceding siblings ...)
2008-04-18 20:14 ` 2.6.25-mm1 Valdis.Kletnieks
@ 2008-04-18 23:09 ` Alexey Dobriyan
2008-04-19 2:13 ` 2.6.25-mm1 Joseph Fannin
` (4 subsequent siblings)
10 siblings, 0 replies; 109+ messages in thread
From: Alexey Dobriyan @ 2008-04-18 23:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, sam
At least the following files aren't removed by "make mrproper":
Module.markers
arch/x86/kernel/acpi/realmode/wakeup.lds
crypto/.tmp_aes_generic.ver
fs/.tmp_buffer.ver
kernel/time/.tmp_timekeeping.ver
Noticed by "git-ls-files -o".
*.ver , I think, remain after abruptdly terminated build.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (5 preceding siblings ...)
2008-04-18 23:09 ` 2.6.25-mm1: orphaned files after build Alexey Dobriyan
@ 2008-04-19 2:13 ` Joseph Fannin
2008-04-19 3:02 ` 2.6.25-mm1 Andrew Morton
2008-04-19 2:25 ` 2.6.25-mm1 Joseph Fannin
` (3 subsequent siblings)
10 siblings, 1 reply; 109+ messages in thread
From: Joseph Fannin @ 2008-04-19 2:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
least, since that's the earliest -mm I've built in a while. I don't
get the same in mainline.
No idea who to CC: I've sat on this report long enough.
I'm going to send a few different reports in separate mails, so I'll
put my dmesg and .config up on a server:
http://home.columbus.rr.com/jfannin3/dmesg.txt
http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
[ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
[ 451.915731] ------------[ cut here ]------------
[ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
[ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
[ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
[ 451.929271] [<c0130fa9>] warn_on_slowpath+0x59/0x80
[ 451.929500] [<c0132400>] ? vprintk+0x2f0/0x4a0
[ 451.929723] [<c0356adc>] ? _spin_unlock+0x2c/0x50
[ 451.929918] [<c01c6a7a>] ? ifind+0x4a/0xa0
[ 451.930126] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
[ 451.930334] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
[ 451.930534] [<c01325d0>] ? printk+0x20/0x30
[ 451.930727] [<c01fcc45>] sysfs_add_one+0x85/0xe0
[ 451.930900] [<c01fd89e>] create_dir+0x4e/0xb0
[ 451.931064] [<c01fd930>] sysfs_create_dir+0x30/0x50
[ 451.931291] [<c0356adc>] ? _spin_unlock+0x2c/0x50
[ 451.931485] [<c023dac6>] kobject_add_internal+0xb6/0x190
[ 451.931656] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
[ 451.931857] [<c023dc8a>] kobject_add_varg+0x5a/0x60
[ 451.932022] [<c023e12f>] kobject_init_and_add+0x2f/0x40
[ 451.932188] [<c02a3e44>] bus_add_driver+0x94/0x250
[ 451.932364] [<c02a5062>] driver_register+0x42/0xf0
[ 451.932533] [<c02a6c56>] platform_driver_register+0x66/0x70
[ 451.932702] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
[ 451.932877] [<c015e137>] sys_init_module+0x87/0x1a0
[ 451.933043] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
[ 451.933246] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 451.933453] [<c0104077>] sysenter_past_esp+0x78/0xc5
[ 451.933636] =======================
[ 451.933744] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 451.933905] kobject_add_internal failed for pcspkr with -EEXIST, don't try to register things with the same name in the same directory.
[ 451.934130] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
[ 451.934269] [<c023db53>] kobject_add_internal+0x143/0x190
[ 451.934439] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
[ 451.934641] [<c023dc8a>] kobject_add_varg+0x5a/0x60
[ 451.934805] [<c023e12f>] kobject_init_and_add+0x2f/0x40
[ 451.934969] [<c02a3e44>] bus_add_driver+0x94/0x250
[ 451.979314] [<c02a5062>] driver_register+0x42/0xf0
[ 451.979535] [<c02a6c56>] platform_driver_register+0x66/0x70
[ 451.979709] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
[ 451.979888] [<c015e137>] sys_init_module+0x87/0x1a0
[ 451.980060] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
[ 451.980264] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 451.980479] [<c0104077>] sysenter_past_esp+0x78/0xc5
[ 451.980660] =======================
Anyone?
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (6 preceding siblings ...)
2008-04-19 2:13 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-19 2:25 ` Joseph Fannin
2008-04-19 3:08 ` 2.6.25-mm1 Andrew Morton
2008-04-19 3:10 ` 2.6.25-mm1 Joseph Fannin
` (2 subsequent siblings)
10 siblings, 1 reply; 109+ messages in thread
From: Joseph Fannin @ 2008-04-19 2:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
I've been seeing the following backtrace since (I think)
2.6.25-rc8-mm2.
I'm sending multiple reports vs. 2.6.25-mm1, so I'm putting the dmesg
and .config on a server:
http://home.columbus.rr.com/jfannin3/dmesg.txt
http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
[ 842.795144] hm, dftrace overflow: 265 changes (0 total) in 428 usecs
[ 842.795182] ------------[ cut here ]------------
[ 842.795192] WARNING: at kernel/trace/ftrace.c:658 ftraced+0x1a4/0x1b0()
[ 842.795200] Modules linked in: af_packet rfcomm l2cap bluetooth ppdev ipv6 cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave video output wmi pci_slot container dock sbs sbshcbattery iptable_filter ip_tables x_tables ext2 ac lp loop snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
[ 842.795470] Pid: 13, comm: ftraced Tainted: G W 2.6.25-mm1 #7
[ 842.795497] [<c0130fa9>] warn_on_slowpath+0x59/0x80
[ 842.795541] [<c013244f>] ? vprintk+0x33f/0x4a0
[ 842.795589] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
[ 842.795622] [<c0354eb0>] ? __mutex_lock_common+0x2b0/0x3c0
[ 842.795667] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
[ 842.795688] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
[ 842.795709] [<c017e4d0>] ? __ftrace_update_code+0x0/0x110
[ 842.795730] [<c017e9f0>] ? ftraced+0x0/0x1b0
[ 842.795746] [<c01325d0>] ? printk+0x20/0x30
[ 842.795764] [<c017e9f0>] ? ftraced+0x0/0x1b0
[ 842.795780] [<c017eb94>] ftraced+0x1a4/0x1b0
[ 842.795807] [<c0146527>] kthread+0x47/0x80
[ 842.795836] [<c01464e0>] ? kthread+0x0/0x80
[ 842.795855] [<c0104d9b>] kernel_thread_helper+0x7/0x10
[ 842.795890] =======================
[ 842.795899] ---[ end trace 4eaa2a86a8e2da22 ]---
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 2:13 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-19 3:02 ` Andrew Morton
2008-04-19 4:14 ` 2.6.25-mm1 Dmitry Torokhov
0 siblings, 1 reply; 109+ messages in thread
From: Andrew Morton @ 2008-04-19 3:02 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linux-kernel, Greg KH, Kay Sievers, Dmitry Torokhov
On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
>
> I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
> least, since that's the earliest -mm I've built in a while. I don't
> get the same in mainline.
>
> No idea who to CC:
I have a few ideas.
> I've sat on this report long enough.
Thanks for the report.
> I'm going to send a few different reports in separate mails, so I'll
> put my dmesg and .config up on a server:
>
> http://home.columbus.rr.com/jfannin3/dmesg.txt
> http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
>
> [ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
> [ 451.915731] ------------[ cut here ]------------
> [ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
> [ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
> [ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
> [ 451.929271] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> [ 451.929500] [<c0132400>] ? vprintk+0x2f0/0x4a0
> [ 451.929723] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> [ 451.929918] [<c01c6a7a>] ? ifind+0x4a/0xa0
> [ 451.930126] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> [ 451.930334] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
> [ 451.930534] [<c01325d0>] ? printk+0x20/0x30
> [ 451.930727] [<c01fcc45>] sysfs_add_one+0x85/0xe0
> [ 451.930900] [<c01fd89e>] create_dir+0x4e/0xb0
> [ 451.931064] [<c01fd930>] sysfs_create_dir+0x30/0x50
> [ 451.931291] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> [ 451.931485] [<c023dac6>] kobject_add_internal+0xb6/0x190
> [ 451.931656] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
> [ 451.931857] [<c023dc8a>] kobject_add_varg+0x5a/0x60
> [ 451.932022] [<c023e12f>] kobject_init_and_add+0x2f/0x40
> [ 451.932188] [<c02a3e44>] bus_add_driver+0x94/0x250
> [ 451.932364] [<c02a5062>] driver_register+0x42/0xf0
> [ 451.932533] [<c02a6c56>] platform_driver_register+0x66/0x70
> [ 451.932702] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
> [ 451.932877] [<c015e137>] sys_init_module+0x87/0x1a0
> [ 451.933043] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> [ 451.933246] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> [ 451.933453] [<c0104077>] sysenter_past_esp+0x78/0xc5
Yes, there have been lots of these lately. I expect some of them _will_ go
into mainline and they'll then slowly get weeded out.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 2:25 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-19 3:08 ` Andrew Morton
0 siblings, 0 replies; 109+ messages in thread
From: Andrew Morton @ 2008-04-19 3:08 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linux-kernel, Steven Rostedt, Ingo Molnar
On Fri, 18 Apr 2008 22:25:59 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
>
> I've been seeing the following backtrace since (I think)
> 2.6.25-rc8-mm2.
>
> I'm sending multiple reports vs. 2.6.25-mm1, so I'm putting the dmesg
> and .config on a server:
>
> http://home.columbus.rr.com/jfannin3/dmesg.txt
> http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
Thanks.
> [ 400.781246] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
I don't think I've seen that one before.
> [ 406.935080] sysfs: duplicate filename '189:0' can not be created
Seen plenty of them - I think Greg today dropped the offending patch(es).
[ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
Yup. Maybe the above droppage will make this go away, I'm not sure.
> [ 842.795144] hm, dftrace overflow: 265 changes (0 total) in 428 usecs
> [ 842.795182] ------------[ cut here ]------------
> [ 842.795192] WARNING: at kernel/trace/ftrace.c:658 ftraced+0x1a4/0x1b0()
> [ 842.795200] Modules linked in: af_packet rfcomm l2cap bluetooth ppdev ipv6 cpufreq_conservative cpufreq_stats cpufreq_userspace cpufreq_powersave video output wmi pci_slot container dock sbs sbshcbattery iptable_filter ip_tables x_tables ext2 ac lp loop snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
> [ 842.795470] Pid: 13, comm: ftraced Tainted: G W 2.6.25-mm1 #7
> [ 842.795497] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> [ 842.795541] [<c013244f>] ? vprintk+0x33f/0x4a0
> [ 842.795589] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> [ 842.795622] [<c0354eb0>] ? __mutex_lock_common+0x2b0/0x3c0
> [ 842.795667] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> [ 842.795688] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
> [ 842.795709] [<c017e4d0>] ? __ftrace_update_code+0x0/0x110
> [ 842.795730] [<c017e9f0>] ? ftraced+0x0/0x1b0
> [ 842.795746] [<c01325d0>] ? printk+0x20/0x30
> [ 842.795764] [<c017e9f0>] ? ftraced+0x0/0x1b0
> [ 842.795780] [<c017eb94>] ftraced+0x1a4/0x1b0
> [ 842.795807] [<c0146527>] kthread+0x47/0x80
> [ 842.795836] [<c01464e0>] ? kthread+0x0/0x80
> [ 842.795855] [<c0104d9b>] kernel_thread_helper+0x7/0x10
> [ 842.795890] =======================
> [ 842.795899] ---[ end trace 4eaa2a86a8e2da22 ]---
I haven't seen that one before.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (7 preceding siblings ...)
2008-04-19 2:25 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-19 3:10 ` Joseph Fannin
2008-04-19 3:29 ` 2.6.25-mm1 Andrew Morton
2008-04-20 11:29 ` internal compiler error: SIGSEGV [Was: 2.6.25-mm1] Jiri Slaby
2008-04-21 8:31 ` Jiri Slaby
10 siblings, 1 reply; 109+ messages in thread
From: Joseph Fannin @ 2008-04-19 3:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
"[ 0.160375] NET: Registered protocol family 16"
The hang lasts about five minutes, and then boot continues. Just
after that, a backtrace is printed; I don't know if it's related. The
backtrace will follow.
This does not occur in mainline. It seems it might be related to OLPC
support -- I enabled all those options -- but that's not good
behavior, and I see no warning of thus in the help.
I'm sending a number or reports against 2.6.25-mm1, so I've put my
dmesg and .config on a server:
http://home.columbus.rr.com/jfannin3/dmesg.txt
http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
[ 0.160375] NET: Registered protocol family 16
[ 400.782683] ------------[ cut here ]------------
[ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
[ 400.783022] Modules linked in:
[ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
[ 400.783300] [<c0130fa9>] warn_on_slowpath+0x59/0x80
[ 400.783480] [<c0106c2e>] ? profile_pc+0x3e/0x50
[ 400.783682] [<c01374ee>] ? irq_exit+0x4e/0xa0
[ 400.783879] [<c0115aec>] ? smp_apic_timer_interrupt+0x5c/0x90
[ 400.784087] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 400.784298] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
[ 400.784506] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 400.784706] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
[ 400.784906] [<c011d0e6>] ? page_is_ram+0xa6/0xd0
[ 400.785059] [<c011d4ed>] __ioremap_caller+0x27d/0x2e0
[ 400.785221] [<c03569d8>] ? _spin_unlock_irqrestore+0x48/0x80
[ 400.785421] [<c017f4cd>] ? ftrace_record_ip+0x7d/0x250
[ 400.785621] [<c0474801>] ? olpc_init+0x31/0x140
[ 400.785817] [<c011d59f>] ioremap_nocache+0x1f/0x30
[ 400.785976] [<c0474801>] ? olpc_init+0x31/0x140
[ 400.786165] [<c0474801>] olpc_init+0x31/0x140
[ 400.786318] [<c0464992>] kernel_init+0x142/0x2d0
[ 400.786479] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
[ 400.786680] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
[ 400.786879] [<c0464850>] ? kernel_init+0x0/0x2d0
[ 400.787069] [<c0464850>] ? kernel_init+0x0/0x2d0
[ 400.787260] [<c0104d9b>] kernel_thread_helper+0x7/0x10
[ 400.787422] =======================
[ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 3:10 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-19 3:29 ` Andrew Morton
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
2008-04-19 18:21 ` 2.6.25-mm1 Arjan van de Ven
0 siblings, 2 replies; 109+ messages in thread
From: Andrew Morton @ 2008-04-19 3:29 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linux-kernel, Andres Salomon, Ingo Molnar
On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
>
> New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
>
> "[ 0.160375] NET: Registered protocol family 16"
>
> The hang lasts about five minutes, and then boot continues.
Please add initcall_debug to the kernel boot command line - that should
narrow it down.
> Just
> after that, a backtrace is printed; I don't know if it's related. The
> backtrace will follow.
>
> This does not occur in mainline. It seems it might be related to OLPC
> support -- I enabled all those options -- but that's not good
> behavior, and I see no warning of thus in the help.
>
> I'm sending a number or reports against 2.6.25-mm1, so I've put my
> dmesg and .config on a server:
>
> http://home.columbus.rr.com/jfannin3/dmesg.txt
> http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
>
> [ 0.160375] NET: Registered protocol family 16
> [ 400.782683] ------------[ cut here ]------------
> [ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
> [ 400.783022] Modules linked in:
> [ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
> [ 400.783300] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> [ 400.783480] [<c0106c2e>] ? profile_pc+0x3e/0x50
> [ 400.783682] [<c01374ee>] ? irq_exit+0x4e/0xa0
> [ 400.783879] [<c0115aec>] ? smp_apic_timer_interrupt+0x5c/0x90
> [ 400.784087] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> [ 400.784298] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> [ 400.784506] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> [ 400.784706] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> [ 400.784906] [<c011d0e6>] ? page_is_ram+0xa6/0xd0
> [ 400.785059] [<c011d4ed>] __ioremap_caller+0x27d/0x2e0
> [ 400.785221] [<c03569d8>] ? _spin_unlock_irqrestore+0x48/0x80
> [ 400.785421] [<c017f4cd>] ? ftrace_record_ip+0x7d/0x250
> [ 400.785621] [<c0474801>] ? olpc_init+0x31/0x140
> [ 400.785817] [<c011d59f>] ioremap_nocache+0x1f/0x30
> [ 400.785976] [<c0474801>] ? olpc_init+0x31/0x140
> [ 400.786165] [<c0474801>] olpc_init+0x31/0x140
> [ 400.786318] [<c0464992>] kernel_init+0x142/0x2d0
> [ 400.786479] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> [ 400.786680] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> [ 400.786879] [<c0464850>] ? kernel_init+0x0/0x2d0
> [ 400.787069] [<c0464850>] ? kernel_init+0x0/0x2d0
> [ 400.787260] [<c0104d9b>] kernel_thread_helper+0x7/0x10
> [ 400.787422] =======================
> [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---
<looks at this again>
That's
WARN_ON_ONCE(is_ram);
the changelog for the patch which added that warning is information-free
and there's no code comment explaining what went wrong, which makes things
rather harder than they ought to be.
Yes it's due to the new OLPC code. olpc_init() has
romsig = ioremap(0xffffffc0, 16);
which we probably just shouldn't do this at all unless we're running on the
OLPC hardware. But we need to do this to find out if we're running on the OLPC
hardware! Perhaps the warning should just be removed.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 3:02 ` 2.6.25-mm1 Andrew Morton
@ 2008-04-19 4:14 ` Dmitry Torokhov
2008-04-19 4:29 ` 2.6.25-mm1 Andrew Morton
0 siblings, 1 reply; 109+ messages in thread
From: Dmitry Torokhov @ 2008-04-19 4:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: Joseph Fannin, linux-kernel, Greg KH, Kay Sievers
On Fri, Apr 18, 2008 at 08:02:37PM -0700, Andrew Morton wrote:
> On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
>
> > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> >
> > I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
> > least, since that's the earliest -mm I've built in a while. I don't
> > get the same in mainline.
> >
> > No idea who to CC:
>
> I have a few ideas.
>
> > I've sat on this report long enough.
>
> Thanks for the report.
>
> > I'm going to send a few different reports in separate mails, so I'll
> > put my dmesg and .config up on a server:
> >
> > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> >
> > [ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
> > [ 451.915731] ------------[ cut here ]------------
> > [ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
> > [ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
> > [ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
> > [ 451.929271] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > [ 451.929500] [<c0132400>] ? vprintk+0x2f0/0x4a0
> > [ 451.929723] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > [ 451.929918] [<c01c6a7a>] ? ifind+0x4a/0xa0
> > [ 451.930126] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > [ 451.930334] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
> > [ 451.930534] [<c01325d0>] ? printk+0x20/0x30
> > [ 451.930727] [<c01fcc45>] sysfs_add_one+0x85/0xe0
> > [ 451.930900] [<c01fd89e>] create_dir+0x4e/0xb0
> > [ 451.931064] [<c01fd930>] sysfs_create_dir+0x30/0x50
> > [ 451.931291] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > [ 451.931485] [<c023dac6>] kobject_add_internal+0xb6/0x190
> > [ 451.931656] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
> > [ 451.931857] [<c023dc8a>] kobject_add_varg+0x5a/0x60
> > [ 451.932022] [<c023e12f>] kobject_init_and_add+0x2f/0x40
> > [ 451.932188] [<c02a3e44>] bus_add_driver+0x94/0x250
> > [ 451.932364] [<c02a5062>] driver_register+0x42/0xf0
> > [ 451.932533] [<c02a6c56>] platform_driver_register+0x66/0x70
> > [ 451.932702] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
> > [ 451.932877] [<c015e137>] sys_init_module+0x87/0x1a0
> > [ 451.933043] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > [ 451.933246] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > [ 451.933453] [<c0104077>] sysenter_past_esp+0x78/0xc5
>
> Yes, there have been lots of these lately. I expect some of them _will_ go
> into mainline and they'll then slowly get weeded out.
>
It looks like it is coming from snd_pcsp module from alsa tree.
Cool things there:
+#ifdef CONFIG_DEBUG_PAGEALLOC
+ /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets
alert */
+ printk(KERN_WARNING
+ "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
+ "You have to disable it if you want to use the PC-Speaker
"
+ "driver.\n"
+ "Unless it is disabled, enjoy the horrible, distorted "
+ "and crackling noise.\n");
+#endif
--
Dmitry
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 4:14 ` 2.6.25-mm1 Dmitry Torokhov
@ 2008-04-19 4:29 ` Andrew Morton
2008-04-19 6:33 ` 2.6.25-mm1 Joseph Fannin
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Andrew Morton @ 2008-04-19 4:29 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Joseph Fannin, linux-kernel, Greg KH, Kay Sievers, Takashi Iwai
On Sat, 19 Apr 2008 00:14:29 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Fri, Apr 18, 2008 at 08:02:37PM -0700, Andrew Morton wrote:
> > On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> >
> > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> > >
> > > I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
> > > least, since that's the earliest -mm I've built in a while. I don't
> > > get the same in mainline.
> > >
> > > No idea who to CC:
> >
> > I have a few ideas.
> >
> > > I've sat on this report long enough.
> >
> > Thanks for the report.
> >
> > > I'm going to send a few different reports in separate mails, so I'll
> > > put my dmesg and .config up on a server:
> > >
> > > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> > >
> > > [ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
> > > [ 451.915731] ------------[ cut here ]------------
> > > [ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
> > > [ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
> > > [ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
> > > [ 451.929271] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > > [ 451.929500] [<c0132400>] ? vprintk+0x2f0/0x4a0
> > > [ 451.929723] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > > [ 451.929918] [<c01c6a7a>] ? ifind+0x4a/0xa0
> > > [ 451.930126] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > > [ 451.930334] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
> > > [ 451.930534] [<c01325d0>] ? printk+0x20/0x30
> > > [ 451.930727] [<c01fcc45>] sysfs_add_one+0x85/0xe0
> > > [ 451.930900] [<c01fd89e>] create_dir+0x4e/0xb0
> > > [ 451.931064] [<c01fd930>] sysfs_create_dir+0x30/0x50
> > > [ 451.931291] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > > [ 451.931485] [<c023dac6>] kobject_add_internal+0xb6/0x190
> > > [ 451.931656] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
> > > [ 451.931857] [<c023dc8a>] kobject_add_varg+0x5a/0x60
> > > [ 451.932022] [<c023e12f>] kobject_init_and_add+0x2f/0x40
> > > [ 451.932188] [<c02a3e44>] bus_add_driver+0x94/0x250
> > > [ 451.932364] [<c02a5062>] driver_register+0x42/0xf0
> > > [ 451.932533] [<c02a6c56>] platform_driver_register+0x66/0x70
> > > [ 451.932702] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
> > > [ 451.932877] [<c015e137>] sys_init_module+0x87/0x1a0
> > > [ 451.933043] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > > [ 451.933246] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > [ 451.933453] [<c0104077>] sysenter_past_esp+0x78/0xc5
> >
> > Yes, there have been lots of these lately. I expect some of them _will_ go
> > into mainline and they'll then slowly get weeded out.
> >
>
> It looks like it is coming from snd_pcsp module from alsa tree.
Ah, OK. More cc's.
>
> Cool things there:
>
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> + /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets
> alert */
> + printk(KERN_WARNING
> + "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
> + "You have to disable it if you want to use the PC-Speaker
> "
> + "driver.\n"
> + "Unless it is disabled, enjoy the horrible, distorted "
> + "and crackling noise.\n");
> +#endif
heh.
CONFIG_DEBUG_PAGEALLOC is a very heavy consumer of CPU cycles. I'm not
surprised that it would whack what I presume to be a very latency-sensitive
driver.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 4:29 ` 2.6.25-mm1 Andrew Morton
@ 2008-04-19 6:33 ` Joseph Fannin
2008-04-21 11:07 ` 2.6.25-mm1 Takashi Iwai
2008-04-21 14:06 ` 2.6.25-mm1 Takashi Iwai
2 siblings, 0 replies; 109+ messages in thread
From: Joseph Fannin @ 2008-04-19 6:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Dmitry Torokhov, linux-kernel, Greg KH, Kay Sievers, Takashi Iwai
On Fri, 2008-04-18 at 21:29 -0700, Andrew Morton wrote:
> On Sat, 19 Apr 2008 00:14:29 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> > On Fri, Apr 18, 2008 at 08:02:37PM -0700, Andrew Morton wrote:
> > > On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> > >
> > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> > > >
> > > > I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
> > > > least, since that's the earliest -mm I've built in a while. I don't
> > > > get the same in mainline.
> > > >
> > > > No idea who to CC:
> > >
> > > I have a few ideas.
> > >
> > > > I've sat on this report long enough.
> > >
> > > Thanks for the report.
> > >
> > > > I'm going to send a few different reports in separate mails, so I'll
> > > > put my dmesg and .config up on a server:
> > > >
> > > > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > > > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> > > >
> > > > [ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
> > > > [ 451.915731] ------------[ cut here ]------------
> > > > [ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
> > > > [ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
> > > > [ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
> > > > [ 451.929271] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > > > [ 451.929500] [<c0132400>] ? vprintk+0x2f0/0x4a0
> > > > [ 451.929723] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > > > [ 451.929918] [<c01c6a7a>] ? ifind+0x4a/0xa0
> > > > [ 451.930126] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > > > [ 451.930334] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
> > > > [ 451.930534] [<c01325d0>] ? printk+0x20/0x30
> > > > [ 451.930727] [<c01fcc45>] sysfs_add_one+0x85/0xe0
> > > > [ 451.930900] [<c01fd89e>] create_dir+0x4e/0xb0
> > > > [ 451.931064] [<c01fd930>] sysfs_create_dir+0x30/0x50
> > > > [ 451.931291] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > > > [ 451.931485] [<c023dac6>] kobject_add_internal+0xb6/0x190
> > > > [ 451.931656] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
> > > > [ 451.931857] [<c023dc8a>] kobject_add_varg+0x5a/0x60
> > > > [ 451.932022] [<c023e12f>] kobject_init_and_add+0x2f/0x40
> > > > [ 451.932188] [<c02a3e44>] bus_add_driver+0x94/0x250
> > > > [ 451.932364] [<c02a5062>] driver_register+0x42/0xf0
> > > > [ 451.932533] [<c02a6c56>] platform_driver_register+0x66/0x70
> > > > [ 451.932702] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
> > > > [ 451.932877] [<c015e137>] sys_init_module+0x87/0x1a0
> > > > [ 451.933043] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > > > [ 451.933246] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > > [ 451.933453] [<c0104077>] sysenter_past_esp+0x78/0xc5
> > >
> > > Yes, there have been lots of these lately. I expect some of them _will_ go
> > > into mainline and they'll then slowly get weeded out.
> > >
> >
> > It looks like it is coming from snd_pcsp module from alsa tree.
>
> Ah, OK. More cc's.
>
> >
> > Cool things there:
> >
> > +#ifdef CONFIG_DEBUG_PAGEALLOC
> > + /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets
> > alert */
> > + printk(KERN_WARNING
> > + "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
> > + "You have to disable it if you want to use the PC-Speaker
> > "
> > + "driver.\n"
> > + "Unless it is disabled, enjoy the horrible, distorted "
> > + "and crackling noise.\n");
> > +#endif
>
> heh.
>
> CONFIG_DEBUG_PAGEALLOC is a very heavy consumer of CPU cycles. I'm not
> surprised that it would whack what I presume to be a very latency-sensitive
> driver.
Um...
[jhf@Susa ~]$ uname -a
Linux Susa 2.6.25-mm1 #7 SMP PREEMPT Fri Apr 18 17:05:14 EDT 2008 i686
GNU/Linux
[jhf@Susa ~]$ zgrep PAGEALLOC /proc/config.gz
# CONFIG_DEBUG_PAGEALLOC is not set
[jhf@Susa ~]$
I thought that might have snuck in as =y, but it didn't.
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 3:29 ` 2.6.25-mm1 Andrew Morton
@ 2008-04-19 13:25 ` Andres Salomon
2008-04-19 17:38 ` 2.6.25-mm1 Andrew Morton
` (2 more replies)
2008-04-19 18:21 ` 2.6.25-mm1 Arjan van de Ven
1 sibling, 3 replies; 109+ messages in thread
From: Andres Salomon @ 2008-04-19 13:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Joseph Fannin, linux-kernel, Ingo Molnar, jordan.crouse
On Fri, 18 Apr 2008 20:29:25 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
>
> > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> >
> > New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
> >
> > "[ 0.160375] NET: Registered protocol family 16"
> >
> > The hang lasts about five minutes, and then boot continues.
>
> Please add initcall_debug to the kernel boot command line - that should
> narrow it down.
>
> > Just
> > after that, a backtrace is printed; I don't know if it's related. The
> > backtrace will follow.
> >
> > This does not occur in mainline. It seems it might be related to OLPC
> > support -- I enabled all those options -- but that's not good
> > behavior, and I see no warning of thus in the help.
> >
> > I'm sending a number or reports against 2.6.25-mm1, so I've put my
> > dmesg and .config on a server:
> >
> > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> >
> > [ 0.160375] NET: Registered protocol family 16
> > [ 400.782683] ------------[ cut here ]------------
> > [ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
> > [ 400.783022] Modules linked in:
> > [ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
> > [ 400.783300] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > [ 400.783480] [<c0106c2e>] ? profile_pc+0x3e/0x50
> > [ 400.783682] [<c01374ee>] ? irq_exit+0x4e/0xa0
> > [ 400.783879] [<c0115aec>] ? smp_apic_timer_interrupt+0x5c/0x90
> > [ 400.784087] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > [ 400.784298] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> > [ 400.784506] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > [ 400.784706] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> > [ 400.784906] [<c011d0e6>] ? page_is_ram+0xa6/0xd0
> > [ 400.785059] [<c011d4ed>] __ioremap_caller+0x27d/0x2e0
> > [ 400.785221] [<c03569d8>] ? _spin_unlock_irqrestore+0x48/0x80
> > [ 400.785421] [<c017f4cd>] ? ftrace_record_ip+0x7d/0x250
> > [ 400.785621] [<c0474801>] ? olpc_init+0x31/0x140
> > [ 400.785817] [<c011d59f>] ioremap_nocache+0x1f/0x30
> > [ 400.785976] [<c0474801>] ? olpc_init+0x31/0x140
> > [ 400.786165] [<c0474801>] olpc_init+0x31/0x140
> > [ 400.786318] [<c0464992>] kernel_init+0x142/0x2d0
> > [ 400.786479] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> > [ 400.786680] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> > [ 400.786879] [<c0464850>] ? kernel_init+0x0/0x2d0
> > [ 400.787069] [<c0464850>] ? kernel_init+0x0/0x2d0
> > [ 400.787260] [<c0104d9b>] kernel_thread_helper+0x7/0x10
> > [ 400.787422] =======================
> > [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---
>
> <looks at this again>
>
> That's
>
> WARN_ON_ONCE(is_ram);
>
> the changelog for the patch which added that warning is information-free
> and there's no code comment explaining what went wrong, which makes things
> rather harder than they ought to be.
>
> Yes it's due to the new OLPC code. olpc_init() has
>
> romsig = ioremap(0xffffffc0, 16);
>
> which we probably just shouldn't do this at all unless we're running on the
> OLPC hardware. But we need to do this to find out if we're running on the OLPC
> hardware! Perhaps the warning should just be removed.
Hm. We could either protect that code with an:
if (!is_geode())
return;
Or I could add the OpenFirmware patches which would allow us to get
rid of this code, and instead check for the existence of OFW using
that.
The former is quick and easy; the latter is (imo) nicer, so long as
people don't have problems w/ the OFW code. :)
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
@ 2008-04-19 17:38 ` Andrew Morton
2008-04-19 17:50 ` 2.6.25-mm1 Andres Salomon
2008-04-19 17:39 ` [PATCH 1/2] OLPC: Add support for calling into Open Firmware Andres Salomon
2008-04-19 17:39 ` [PATCH 2/2] OLPC: drop pre-OpenFirmware workarounds Andres Salomon
2 siblings, 1 reply; 109+ messages in thread
From: Andrew Morton @ 2008-04-19 17:38 UTC (permalink / raw)
To: Andres Salomon; +Cc: jfannin, linux-kernel, mingo, jordan.crouse
> On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@queued.net> wrote:
> On Fri, 18 Apr 2008 20:29:25 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> >
> > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> > >
> > > New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
> > >
> > > "[ 0.160375] NET: Registered protocol family 16"
> > >
> > > The hang lasts about five minutes, and then boot continues.
> >
> > Please add initcall_debug to the kernel boot command line - that should
> > narrow it down.
> >
> > > Just
> > > after that, a backtrace is printed; I don't know if it's related. The
> > > backtrace will follow.
> > >
> > > This does not occur in mainline. It seems it might be related to OLPC
> > > support -- I enabled all those options -- but that's not good
> > > behavior, and I see no warning of thus in the help.
> > >
> > > I'm sending a number or reports against 2.6.25-mm1, so I've put my
> > > dmesg and .config on a server:
> > >
> > > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> > >
> > > [ 0.160375] NET: Registered protocol family 16
> > > [ 400.782683] ------------[ cut here ]------------
> > > [ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
> > > [ 400.783022] Modules linked in:
> > > [ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
> > > [ 400.783300] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > > [ 400.783480] [<c0106c2e>] ? profile_pc+0x3e/0x50
> > > [ 400.783682] [<c01374ee>] ? irq_exit+0x4e/0xa0
> > > [ 400.783879] [<c0115aec>] ? smp_apic_timer_interrupt+0x5c/0x90
> > > [ 400.784087] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > [ 400.784298] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> > > [ 400.784506] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > [ 400.784706] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> > > [ 400.784906] [<c011d0e6>] ? page_is_ram+0xa6/0xd0
> > > [ 400.785059] [<c011d4ed>] __ioremap_caller+0x27d/0x2e0
> > > [ 400.785221] [<c03569d8>] ? _spin_unlock_irqrestore+0x48/0x80
> > > [ 400.785421] [<c017f4cd>] ? ftrace_record_ip+0x7d/0x250
> > > [ 400.785621] [<c0474801>] ? olpc_init+0x31/0x140
> > > [ 400.785817] [<c011d59f>] ioremap_nocache+0x1f/0x30
> > > [ 400.785976] [<c0474801>] ? olpc_init+0x31/0x140
> > > [ 400.786165] [<c0474801>] olpc_init+0x31/0x140
> > > [ 400.786318] [<c0464992>] kernel_init+0x142/0x2d0
> > > [ 400.786479] [<c01552cd>] ? trace_hardirqs_on_caller+0xcd/0x150
> > > [ 400.786680] [<c010416c>] ? restore_nocheck_notrace+0x0/0xe
> > > [ 400.786879] [<c0464850>] ? kernel_init+0x0/0x2d0
> > > [ 400.787069] [<c0464850>] ? kernel_init+0x0/0x2d0
> > > [ 400.787260] [<c0104d9b>] kernel_thread_helper+0x7/0x10
> > > [ 400.787422] =======================
> > > [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---
> >
> > <looks at this again>
> >
> > That's
> >
> > WARN_ON_ONCE(is_ram);
> >
> > the changelog for the patch which added that warning is information-free
> > and there's no code comment explaining what went wrong, which makes things
> > rather harder than they ought to be.
> >
> > Yes it's due to the new OLPC code. olpc_init() has
> >
> > romsig = ioremap(0xffffffc0, 16);
> >
> > which we probably just shouldn't do this at all unless we're running on the
> > OLPC hardware. But we need to do this to find out if we're running on the OLPC
> > hardware! Perhaps the warning should just be removed.
>
> Hm. We could either protect that code with an:
>
> if (!is_geode())
> return;
>
> Or I could add the OpenFirmware patches which would allow us to get
> rid of this code, and instead check for the existence of OFW using
> that.
>
> The former is quick and easy; the latter is (imo) nicer, so long as
> people don't have problems w/ the OFW code. :)
>
Do both ;)
The quick-n-easy version sounds suitable for now.
^ permalink raw reply [flat|nested] 109+ messages in thread
* [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
2008-04-19 17:38 ` 2.6.25-mm1 Andrew Morton
@ 2008-04-19 17:39 ` Andres Salomon
2008-04-20 10:34 ` Yinghai Lu
2008-04-19 17:39 ` [PATCH 2/2] OLPC: drop pre-OpenFirmware workarounds Andres Salomon
2 siblings, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-19 17:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Joseph Fannin, linux-kernel, Ingo Molnar, jordan.crouse, Mitch Bradley
This adds 32-bit support for calling into OFW from the kernel. It's useful
for querying the firmware for misc hardware information, fetching the device
tree, etc.
There's potentially no reason why other platforms couldn't use this, but
currently OLPC is the main user of it.
This work was originally done by Mitch Bradley.
Signed-off-by: Andres Salomon <dilinger@debian.org>
---
arch/x86/Kconfig | 8 +++++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/head_32.S | 27 ++++++++++++++++
arch/x86/kernel/ofw.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
include/asm-x86/ofw.h | 50 ++++++++++++++++++++++++++++++
include/asm-x86/setup.h | 1 +
6 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/kernel/ofw.c
create mode 100644 include/asm-x86/ofw.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 3b9089b..ce56105 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -661,6 +661,14 @@ config I8K
Say Y if you intend to run this kernel on a Dell Inspiron 8000.
Say N otherwise.
+config OPEN_FIRMWARE
+ bool "Support for Open Firmware"
+ default y if OLPC
+ ---help---
+ This option adds support for the implementation of Open Firmware
+ that is used on the OLPC XO laptop.
+ If unsure, say N here.
+
config X86_REBOOTFIXUPS
def_bool n
prompt "Enable X86 board specific fixups for reboot"
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 9575754..d33600e 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_$(BITS).o
obj-$(CONFIG_X86_MPPARSE) += mpparse_$(BITS).o
obj-$(CONFIG_X86_LOCAL_APIC) += apic_$(BITS).o nmi_$(BITS).o
obj-$(CONFIG_X86_IO_APIC) += io_apic_$(BITS).o
+obj-$(CONFIG_OPEN_FIRMWARE) += ofw.o
obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 74d87ea..c9d2d00 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -132,6 +132,33 @@ ENTRY(startup_32)
movsl
1:
+#ifdef CONFIG_OPEN_FIRMWARE
+/*
+ * If Open Firmware booted us, save the OFW client interface callback address
+ * and preserve the OFW page mappings by priming the kernel's new page
+ * directory area with a copy of the OFW page directory. That lets OFW stay
+ * resident in high memory (high in both the virtual and physical spaces)
+ * for at least long enough to copy out the device tree.
+ */
+ movl $pa(boot_params + OFW_INFO_OFFSET), %ebp
+ cmpl $0x2057464F, (%ebp) /* Magic number "OFW " */
+ jne 4f
+
+ mov 0x8(%ebp), %eax /* Save callback address */
+ mov %eax, pa(call_firmware)
+
+ /* Copy the OFW pdir into swapper_pg_dir */
+ movl %esi, %edx /* save %esi */
+ movl $pa(swapper_pg_dir), %edi
+ movl %cr3, %esi /* Source is current pg_dir base address */
+ movl $1024, %ecx /* Number of page directory entries */
+ rep
+ movsl
+ movl %edx, %esi /* restore %esi */
+4:
+
+#endif
+
#ifdef CONFIG_PARAVIRT
/* This is can only trip for a broken bootloader... */
cmpw $0x207, pa(boot_params + BP_version)
diff --git a/arch/x86/kernel/ofw.c b/arch/x86/kernel/ofw.c
new file mode 100644
index 0000000..14036aa
--- /dev/null
+++ b/arch/x86/kernel/ofw.c
@@ -0,0 +1,75 @@
+/*
+ * Open Firmware client interface for 32-bit systems.
+ *
+ * Copyright © 2007 Mitch Bradley <wmb@firmworks.com>
+ * Copyright © 2007-2008 Andres Salomon <dilinger@debian.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/module.h>
+#include <asm/ofw.h>
+
+/*
+ * This code is intended to be portable to any 32-bit Open Firmware
+ * implementation with a standard client interface that can be
+ * called when Linux is running.
+ *
+ * The return value from ofw() in all cases is 0 if the attempt to call the
+ * function succeeded. The return value is from the Linux function only; any
+ * results from OFW are returned via output argument pointers.
+ */
+
+#define MAXARGS 20
+
+int (*call_firmware)(int *);
+static DEFINE_SPINLOCK(prom_lock);
+
+int ofw(const char *name, int nr_args, int nr_results, ...)
+{
+ unsigned long flags;
+ va_list args;
+ int argarray[MAXARGS+3];
+ int retval;
+ int *intp;
+ int i;
+
+ if (!call_firmware)
+ return -ENODEV;
+
+ if ((nr_args + nr_results) > MAXARGS)
+ return -EIO; /* spit out an error? */
+
+ /* Stuff the arguments into argarray */
+ argarray[0] = (int) name;
+ argarray[1] = nr_args;
+ argarray[2] = nr_results;
+
+ va_start(args, nr_results);
+ for (i = 3; nr_args; i++) {
+ argarray[i] = va_arg(args, int);
+ nr_args--;
+ }
+
+ /* Call into Open Firmware */
+ spin_lock_irqsave(&prom_lock, flags);
+ retval = call_firmware(argarray);
+ spin_unlock_irqrestore(&prom_lock, flags);
+
+ if (retval == 0) {
+ while (nr_results) {
+ intp = va_arg(args, int *);
+ *intp = argarray[i++];
+ nr_results--;
+ }
+ }
+
+ va_end(args);
+ return retval;
+}
+EXPORT_SYMBOL_GPL(ofw);
diff --git a/include/asm-x86/ofw.h b/include/asm-x86/ofw.h
new file mode 100644
index 0000000..7d064f8
--- /dev/null
+++ b/include/asm-x86/ofw.h
@@ -0,0 +1,50 @@
+/*
+ * Definitions for Open Firmware client interface on 32-bit system.
+ * OF Cell size is 4. Integer properties are encoded big endian,
+ * as with all OF implementations.
+ */
+#ifndef _OFW_H
+#define _OFW_H
+#ifdef __KERNEL__
+
+extern int ofw(const char *name, int nr_args, int nr_results, ...);
+
+typedef uint32_t ofw_phandle;
+typedef uint32_t ofw_ihandle;
+
+/*
+ * Here are call templates for standard OFW client services:
+ *
+ * ofw("test", 1, 1, namestr, &missing);
+ * ofw("peer", 1, 1, phandle, &sibling_phandle);
+ * ofw("child", 1, 1, phandle, &child_phandle);
+ * ofw("parent", 1, 1, phandle, &parent_phandle);
+ * ofw("instance_to_package", 1, 1, ihandle, &phandle);
+ * ofw("getproplen", 2, 1, phandle, namestr, &proplen);
+ * ofw("getprop", 4, 1, phandle, namestr, bufaddr, buflen, &size);
+ * ofw("nextprop", 3, 1, phandle, previousstr, bufaddr, &flag);
+ * ofw("setprop", 4, 1, phandle, namestr, bufaddr, len, &size);
+ * ofw("canon", 3, 1, devspecstr, bufaddr, buflen, &length);
+ * ofw("finddevice", 1, 1, devspecstr, &phandle);
+ * ofw("instance-to-path", 3, 1, ihandle, bufaddr, buflen, &length);
+ * ofw("package-to-path", 3, 1, phandle, bufaddr, buflen, &length);
+ * ofw("call_method", numin, numout, in0, in1, ..., &out0, &out1, ...);
+ * ofw("open", 1, 1, devspecstr, &ihandle);
+ * ofw("close", 1, 0, ihandle);
+ * ofw("read", 3, 1, ihandle, addr, len, &actual);
+ * ofw("write", 3, 1, ihandle, addr, len, &actual);
+ * ofw("seek", 3, 1, ihandle, pos_hi, pos_lo, &status);
+ * ofw("claim", 3, 1, virtaddr, size, align, &baseaddr);
+ * ofw("release", 2, 0, virtaddr, size);
+ * ofw("boot", 1, 0, bootspecstr);
+ * ofw("enter", 0, 0);
+ * ofw("exit", 0, 0);
+ * ofw("chain", 5, 0, virtaddr, size, entryaddr, argsaddr, len);
+ * ofw("interpret", numin+1, numout+1, cmdstr, in0, ..., &catchres, &out0, ...)
+ * ofw("set-callback", 1, 1, newfuncaddr, &oldfuncaddr);
+ * ofw("set-symbol-lookup", 2, 0, symtovaladdr, valtosymaddr);
+ * ofw("milliseconds", 0, 1, &ms);
+ */
+
+#endif
+#endif
diff --git a/include/asm-x86/setup.h b/include/asm-x86/setup.h
index 071e054..8e2b674 100644
--- a/include/asm-x86/setup.h
+++ b/include/asm-x86/setup.h
@@ -28,6 +28,7 @@ char *machine_specific_memory_setup(void);
#define OLD_CL_MAGIC 0xA33F
#define OLD_CL_ADDRESS 0x020 /* Relative to real mode data */
#define NEW_CL_POINTER 0x228 /* Relative to real mode data */
+#define OFW_INFO_OFFSET 0xb0 /* Relative to real mode data */
#ifndef __ASSEMBLY__
#include <asm/bootparam.h>
--
1.5.4.4
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply related [flat|nested] 109+ messages in thread
* [PATCH 2/2] OLPC: drop pre-OpenFirmware workarounds
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
2008-04-19 17:38 ` 2.6.25-mm1 Andrew Morton
2008-04-19 17:39 ` [PATCH 1/2] OLPC: Add support for calling into Open Firmware Andres Salomon
@ 2008-04-19 17:39 ` Andres Salomon
2 siblings, 0 replies; 109+ messages in thread
From: Andres Salomon @ 2008-04-19 17:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Joseph Fannin, linux-kernel, Ingo Molnar, jordan.crouse, Mitch Bradley
Prior to including OFW kernel support, we had to work around the lack of
OFW. Once OFW support is added, we can switch to using it. This cleans
up some pre-OFW model detection and OFW signature detection.
Note: this should be a bit nicer to non-OLPC hardware.
Signed-off-by: Andres Salomon <dilinger@debian.org>
---
arch/x86/kernel/olpc.c | 43 +++++++++++++++++++++++++++++--------------
1 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/olpc.c b/arch/x86/kernel/olpc.c
index 11670be..3a05683 100644
--- a/arch/x86/kernel/olpc.c
+++ b/arch/x86/kernel/olpc.c
@@ -190,11 +190,11 @@ EXPORT_SYMBOL_GPL(olpc_ec_cmd);
static void __init platform_detect(void)
{
size_t propsize;
- u32 rev;
+ uint32_t rev;
if (ofw("getprop", 4, 1, NULL, "board-revision-int", &rev, 4,
&propsize) || propsize != 4) {
- printk(KERN_ERR "ofw: getprop call failed!\n");
+ printk(KERN_ERR "olpc: ofw getprop call failed!\n");
rev = 0;
}
olpc_platform_info.boardrev = be32_to_cpu(rev);
@@ -207,26 +207,43 @@ static void __init platform_detect(void)
}
#endif
-static int __init olpc_init(void)
+static int __init ofw_detect(void)
{
- unsigned char *romsig;
+ size_t propsize;
+ char romsig[20];
+ ofw_phandle phandle;
- spin_lock_init(&ec_lock);
+ /* Fetch /openprom/model */
+ if (ofw("finddevice", 1, 1, "/openprom", &phandle) || phandle == ~0)
+ return -ENODEV;
- romsig = ioremap(0xffffffc0, 16);
- if (!romsig)
- return 0;
+ if (ofw("getprop", 4, 1, phandle, "model", &romsig, sizeof(romsig),
+ &propsize) || propsize < 7)
+ return -ENODEV;
+ /* String should look something like "CL1 Q2D08 Q2D" */
if (strncmp(romsig, "CL1 Q", 7))
- goto unmap;
+ return -ENODEV;
if (strncmp(romsig+6, romsig+13, 3)) {
- printk(KERN_INFO "OLPC BIOS signature looks invalid. "
+ printk(KERN_INFO "olpc: BIOS signature looks invalid. "
"Assuming not OLPC\n");
- goto unmap;
+ return -ENODEV;
}
- printk(KERN_INFO "OLPC board with OpenFirmware %.16s\n", romsig);
+ /* Looks like we have OLPC's OFW */
olpc_platform_info.flags |= OLPC_F_PRESENT;
+ printk(KERN_INFO "olpc: board with OpenFirmware %.16s\n", romsig);
+
+ return 0;
+}
+
+static int __init olpc_init(void)
+{
+ spin_lock_init(&ec_lock);
+
+ /* ensure OFW is available */
+ if (ofw_detect())
+ return 0;
/* get the platform revision */
platform_detect();
@@ -248,8 +265,6 @@ static int __init olpc_init(void)
olpc_platform_info.boardrev >> 4,
olpc_platform_info.ecver);
-unmap:
- iounmap(romsig);
return 0;
}
--
1.5.4.4
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply related [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 17:38 ` 2.6.25-mm1 Andrew Morton
@ 2008-04-19 17:50 ` Andres Salomon
2008-04-21 14:56 ` 2.6.25-mm1 Jordan Crouse
0 siblings, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-19 17:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: jfannin, linux-kernel, mingo, jordan.crouse
On Sat, 19 Apr 2008 10:38:33 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@queued.net> wrote:
> > On Fri, 18 Apr 2008 20:29:25 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> > >
> > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
[...]
> > >
> > > which we probably just shouldn't do this at all unless we're running on the
> > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
> > > hardware! Perhaps the warning should just be removed.
> >
> > Hm. We could either protect that code with an:
> >
> > if (!is_geode())
> > return;
> >
> > Or I could add the OpenFirmware patches which would allow us to get
> > rid of this code, and instead check for the existence of OFW using
> > that.
> >
> > The former is quick and easy; the latter is (imo) nicer, so long as
> > people don't have problems w/ the OFW code. :)
> >
>
> Do both ;)
>
> The quick-n-easy version sounds suitable for now.
Heh, I already had sent the nicer version. If people have some fundamental
problem w/ it, I can send the quick-n-easy version.
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 3:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
@ 2008-04-19 18:21 ` Arjan van de Ven
1 sibling, 0 replies; 109+ messages in thread
From: Arjan van de Ven @ 2008-04-19 18:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: Joseph Fannin, linux-kernel, Andres Salomon, Ingo Molnar
On Fri, 18 Apr 2008 20:29:25 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> That's
>
> WARN_ON_ONCE(is_ram);
>
> the changelog for the patch which added that warning is
> information-free
it got added with a full changelog, then temporary removed and then added back ;(
> and there's no code comment explaining what went
> wrong, which makes things rather harder than they ought to be.
>
> Yes it's due to the new OLPC code. olpc_init() has
>
> romsig = ioremap(0xffffffc0, 16);
>
> which we probably just shouldn't do this at all unless we're running
> on the OLPC hardware. But we need to do this to find out if we're
> running on the OLPC hardware! Perhaps the warning should just be
> removed. --
calling ioremap() on something which COULD be ram is... REALLY nasty.
The kernel has to mark that page uncached, for all users and mappings of that memory.
A second hard case then is to find out when the last ioremap() user has
released that memory (since there's several cases where different parts of the same
4K page can be ioremapped) before it can map it cached again. The good news is that
until this olpc patch got in, there were no users of this capability....
Instead of outright forbidding it though we added a warn_on to find out if the
assumption of no users was correct...
seems it caught some new code which is trying to do this here.
this code should probably be a lot more careful and check that
1) there is no actual kernel memory or something else at this region
(what if there's some other device there? this code could blow up)
2) the machine won't tripple fault or otherwise throw tantrums if
this hardcoded value is accessed (not automatic on x86!!)
3) it only runs if there's a really high degree of confidence that this really is
an OLPC device.
or maybe
4) get this address from some other table or system provided resource
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-19 17:39 ` [PATCH 1/2] OLPC: Add support for calling into Open Firmware Andres Salomon
@ 2008-04-20 10:34 ` Yinghai Lu
2008-04-20 12:07 ` H. Peter Anvin
2008-04-21 3:09 ` Mitch Bradley
0 siblings, 2 replies; 109+ messages in thread
From: Yinghai Lu @ 2008-04-20 10:34 UTC (permalink / raw)
To: Andres Salomon, H. Peter Anvin, Eric W. Biederman, Ingo Molnar
Cc: Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse, Mitch Bradley
On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon <dilinger@queued.net> wrote:
>
> This adds 32-bit support for calling into OFW from the kernel. It's useful
> for querying the firmware for misc hardware information, fetching the device
> tree, etc.
>
> There's potentially no reason why other platforms couldn't use this, but
> currently OLPC is the main user of it.
>
> This work was originally done by Mitch Bradley.
>
> Signed-off-by: Andres Salomon <dilinger@debian.org>
> ---
> arch/x86/Kconfig | 8 +++++
> arch/x86/kernel/Makefile | 1 +
> arch/x86/kernel/head_32.S | 27 ++++++++++++++++
> arch/x86/kernel/ofw.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
> include/asm-x86/ofw.h | 50 ++++++++++++++++++++++++++++++
> include/asm-x86/setup.h | 1 +
> 6 files changed, 162 insertions(+), 0 deletions(-)
> create mode 100644 arch/x86/kernel/ofw.c
> create mode 100644 include/asm-x86/ofw.h
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3b9089b..ce56105 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -661,6 +661,14 @@ config I8K
> Say Y if you intend to run this kernel on a Dell Inspiron 8000.
> Say N otherwise.
>
> +config OPEN_FIRMWARE
> + bool "Support for Open Firmware"
> + default y if OLPC
> + ---help---
> + This option adds support for the implementation of Open Firmware
> + that is used on the OLPC XO laptop.
> + If unsure, say N here.
> +
> config X86_REBOOTFIXUPS
> def_bool n
> prompt "Enable X86 board specific fixups for reboot"
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 9575754..d33600e 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_$(BITS).o
> obj-$(CONFIG_X86_MPPARSE) += mpparse_$(BITS).o
> obj-$(CONFIG_X86_LOCAL_APIC) += apic_$(BITS).o nmi_$(BITS).o
> obj-$(CONFIG_X86_IO_APIC) += io_apic_$(BITS).o
> +obj-$(CONFIG_OPEN_FIRMWARE) += ofw.o
> obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
> obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
> obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
> index 74d87ea..c9d2d00 100644
> --- a/arch/x86/kernel/head_32.S
> +++ b/arch/x86/kernel/head_32.S
> @@ -132,6 +132,33 @@ ENTRY(startup_32)
> movsl
> 1:
>
> +#ifdef CONFIG_OPEN_FIRMWARE
> +/*
> + * If Open Firmware booted us, save the OFW client interface callback address
> + * and preserve the OFW page mappings by priming the kernel's new page
> + * directory area with a copy of the OFW page directory. That lets OFW stay
> + * resident in high memory (high in both the virtual and physical spaces)
> + * for at least long enough to copy out the device tree.
> + */
> + movl $pa(boot_params + OFW_INFO_OFFSET), %ebp
> + cmpl $0x2057464F, (%ebp) /* Magic number "OFW " */
> + jne 4f
> +
> + mov 0x8(%ebp), %eax /* Save callback address */
> + mov %eax, pa(call_firmware)
> +
> + /* Copy the OFW pdir into swapper_pg_dir */
> + movl %esi, %edx /* save %esi */
> + movl $pa(swapper_pg_dir), %edi
> + movl %cr3, %esi /* Source is current pg_dir base address */
> + movl $1024, %ecx /* Number of page directory entries */
> + rep
> + movsl
> + movl %edx, %esi /* restore %esi */
> +4:
> +
> +#endif
> +
> #ifdef CONFIG_PARAVIRT
> /* This is can only trip for a broken bootloader... */
> cmpw $0x207, pa(boot_params + BP_version)
> diff --git a/arch/x86/kernel/ofw.c b/arch/x86/kernel/ofw.c
> new file mode 100644
> index 0000000..14036aa
> --- /dev/null
> +++ b/arch/x86/kernel/ofw.c
> @@ -0,0 +1,75 @@
> +/*
> + * Open Firmware client interface for 32-bit systems.
> + *
> + * Copyright (c) 2007 Mitch Bradley <wmb@firmworks.com>
> + * Copyright (c) 2007-2008 Andres Salomon <dilinger@debian.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/spinlock.h>
> +#include <linux/module.h>
> +#include <asm/ofw.h>
> +
> +/*
> + * This code is intended to be portable to any 32-bit Open Firmware
> + * implementation with a standard client interface that can be
> + * called when Linux is running.
how about changing to ofw_32.c?
YH
^ permalink raw reply [flat|nested] 109+ messages in thread
* internal compiler error: SIGSEGV [Was: 2.6.25-mm1]
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (8 preceding siblings ...)
2008-04-19 3:10 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-20 11:29 ` Jiri Slaby
2008-04-21 8:31 ` Jiri Slaby
10 siblings, 0 replies; 109+ messages in thread
From: Jiri Slaby @ 2008-04-20 11:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Ingo Molnar, linux-mm
On 04/18/2008 10:47 AM, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
Hi, I'm not sure by what was this caused.
LANG=en strace -fo strace_gcc.txt gcc -Wp,-MD,drivers/usb/class/.usblp.o.d
-nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.3/include -D__KERNEL__
-Iinclude -Iinclude2 -I/home/l/latest/xxx/include -include
include/linux/autoconf.h -I/home/l/latest/xxx/drivers/usb/class
-Idrivers/usb/class -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2
-fno-stack-protector -m64 -march=core2 -mno-red-zone -mcmodel=kernel
-funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-I/home/l/latest/xxx/include/asm-x86/mach-default -Iinclude/asm-x86/mach-default
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g
-Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(usblp)" -D"KBUILD_MODNAME=KBUILD_STR(usblp)"
/home/l/latest/xxx/drivers/usb/class/usblp.c -S -o usblp.s
/home/l/latest/xxx/drivers/usb/class/usblp.c: In function 'usblp_submit_read':
/home/l/latest/xxx/drivers/usb/class/usblp.c:977: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.opensuse.org/> for instructions.
strace_gcc.txt:
http://www.fi.muni.cz/~xslaby/sklad/strace_gcc.txt
preprocessor output available here:
http://www.fi.muni.cz/~xslaby/sklad/usblp.E
Reboot fixed it. It happened after few suspend/resume cycles. The preproc output
differs in no way from after the reboot. Now, the strace looks like:
5341 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f362e004000
5341 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f362df04000
5341 brk(0x1964000) = 0x1964000
5341 brk(0x194c000) = 0x194c000
5341 brk(0x196d000) = 0x196d000
5341 brk(0x195a000) = 0x195a000
5341 mmap(NULL, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f362dee1000
5341 munmap(0x7f362dee1000, 143360) = 0
5341 brk(0x1981000) = 0x1981000
5341 brk(0x196b000) = 0x196b000
5341 brk(0x1966000) = 0x1966000
5341 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x7f362defc000
5341 brk(0x1988000) = 0x1988000
at that sigsegv place.
Some kind of random-brk gcc (gcc-4.3-30) non-readiness?
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 10:34 ` Yinghai Lu
@ 2008-04-20 12:07 ` H. Peter Anvin
2008-04-20 17:59 ` Andres Salomon
2008-04-21 3:09 ` Mitch Bradley
1 sibling, 1 reply; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-20 12:07 UTC (permalink / raw)
To: Yinghai Lu
Cc: Andres Salomon, Eric W. Biederman, Ingo Molnar, Andrew Morton,
Joseph Fannin, linux-kernel, jordan.crouse, Mitch Bradley
Yinghai Lu wrote:
> On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon <dilinger@queued.net> wrote:
>> This adds 32-bit support for calling into OFW from the kernel. It's useful
>> for querying the firmware for misc hardware information, fetching the device
>> tree, etc.
>>
>> There's potentially no reason why other platforms couldn't use this, but
>> currently OLPC is the main user of it.
>>
>> This work was originally done by Mitch Bradley.
>>
Hm. This interface seems more than a bit ad hoc. In particular, I
*really* don't like the swapper_pg_dir hack.
"There must be a better way."
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 12:07 ` H. Peter Anvin
@ 2008-04-20 17:59 ` Andres Salomon
2008-04-20 18:42 ` Mitch Bradley
2008-04-20 19:13 ` [PATCH 1/2] " H. Peter Anvin
0 siblings, 2 replies; 109+ messages in thread
From: Andres Salomon @ 2008-04-20 17:59 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Yinghai Lu, Eric W. Biederman, Ingo Molnar, Andrew Morton,
Joseph Fannin, linux-kernel, jordan.crouse, Mitch Bradley
On Sun, 20 Apr 2008 08:07:55 -0400
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Yinghai Lu wrote:
> > On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon <dilinger@queued.net> wrote:
> >> This adds 32-bit support for calling into OFW from the kernel. It's useful
> >> for querying the firmware for misc hardware information, fetching the device
> >> tree, etc.
> >>
> >> There's potentially no reason why other platforms couldn't use this, but
> >> currently OLPC is the main user of it.
> >>
> >> This work was originally done by Mitch Bradley.
> >>
>
> Hm. This interface seems more than a bit ad hoc. In particular, I
> *really* don't like the swapper_pg_dir hack.
>
> "There must be a better way."
>
> -hpa
I'm certainly open to suggestions.. Otherwise, I'll poke around and
see if I can come up w/ something.
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 17:59 ` Andres Salomon
@ 2008-04-20 18:42 ` Mitch Bradley
2008-04-20 19:12 ` H. Peter Anvin
2008-04-20 19:13 ` [PATCH 1/2] " H. Peter Anvin
1 sibling, 1 reply; 109+ messages in thread
From: Mitch Bradley @ 2008-04-20 18:42 UTC (permalink / raw)
To: Andres Salomon
Cc: H. Peter Anvin, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Andres Salomon wrote:
> On Sun, 20 Apr 2008 08:07:55 -0400
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>
>> Yinghai Lu wrote:
>>
>>> On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon <dilinger@queued.net> wrote:
>>>
>>>> This adds 32-bit support for calling into OFW from the kernel. It's useful
>>>> for querying the firmware for misc hardware information, fetching the device
>>>> tree, etc.
>>>>
>>>> There's potentially no reason why other platforms couldn't use this, but
>>>> currently OLPC is the main user of it.
>>>>
>>>> This work was originally done by Mitch Bradley.
>>>>
>>>>
>> Hm. This interface seems more than a bit ad hoc. In particular, I
>> *really* don't like the swapper_pg_dir hack.
>>
>> "There must be a better way."
>>
>> -hpa
>>
>
> I'm certainly open to suggestions.. Otherwise, I'll poke around and
> see if I can come up w/ something.
>
The x86 architecture doesn't make this problem easy.
The conventional solution is to have the BIOS operate in real mode.
When the kernel calls into the BIOS, it has to do a grotesque dance that
involves jumping through a chain of several segments of different
flavors, thus gradually shutting down the multi-tiered address
translation mechanism. Then, if the BIOS is actually operating in
protected mode (which is necessary if it is larger than 64K, as all
modern BIOSes are), it has to perform the inverse process, do the
requested work, then go back into real mode to return to the kernel.
The net result is that a "call" into the BIOS involves:
a) Copying the arguments to a real-mode register shadow array
b) Saving all the registers - general ones and a few special ones too
c) Far call to a linear-mapped code segment with an execution address in
the first 1M of memory
d) Switching to a different stack
e) Turning off page translation
f) Switching from protected mode to real mode (or in some cases, V86
mode instead, which requires an additional Task State Segment dance to
set the IO permission mask)
g) Switching to a real-mode interrupt descriptor table
h) Executing an INT instruction
I) Performing the inverse of a - g inside the BIOS
j) Doing the requested work
K) Performing a - g again to get back into real mode
l) Executing an "iret" instruction
M) Performing the inverse of a-g to return to normal operation
The machinery that you need to do all that is predictably complex -
extra segment descriptors that are set up just-so, several little code
fragments that must be at special addresses in the first meg, additional
stacks, a real-mode interrupt table at a fixed address, and several data
save arrays. That machinery has to be in assembly language, spanning
several different instruction set modes.
Compared to that, I think that sharing one or two page directory entries
at the very top of the virtual address space is pretty clean and
simple. With that sharing, the BIOS call is just an ordinary subroutine
call. (The setup code copies the entire page directory, but only a
couple of entries are actually needed. The reason for copying the whole
thing is because it is rather more work to determine the exact number of
entries necessary, compared to copying everything and then letting Linux
replace the ones it uses.)
Every other solution that I know of requires some sort of heroic dance,
either from the OS or from the BIOS or (usually) both.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 18:42 ` Mitch Bradley
@ 2008-04-20 19:12 ` H. Peter Anvin
2008-04-21 3:39 ` Mitch Bradley
0 siblings, 1 reply; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-20 19:12 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Mitch Bradley wrote:
>
> The x86 architecture doesn't make this problem easy.
>
[long rant about the x86 architecture]
It would be more useful if you described the actual defined entry
conditions from OpenFirmware look like, including if they are
well-defined for all OF implementations or only for OLPC.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 17:59 ` Andres Salomon
2008-04-20 18:42 ` Mitch Bradley
@ 2008-04-20 19:13 ` H. Peter Anvin
1 sibling, 0 replies; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-20 19:13 UTC (permalink / raw)
To: Andres Salomon
Cc: Yinghai Lu, Eric W. Biederman, Ingo Molnar, Andrew Morton,
Joseph Fannin, linux-kernel, jordan.crouse, Mitch Bradley
Andres Salomon wrote:
>
> I'm certainly open to suggestions.. Otherwise, I'll poke around and
> see if I can come up w/ something.
>
It pretty much depends on what the invariants look like. The
normal/clean way of doing this kind of thing is via a fixmap entry
and/or ioremap.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 10:34 ` Yinghai Lu
2008-04-20 12:07 ` H. Peter Anvin
@ 2008-04-21 3:09 ` Mitch Bradley
2008-04-21 3:15 ` Yinghai Lu
1 sibling, 1 reply; 109+ messages in thread
From: Mitch Bradley @ 2008-04-21 3:09 UTC (permalink / raw)
To: Yinghai Lu
Cc: Andres Salomon, H. Peter Anvin, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Yinghai Lu wrote:
> On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon <dilinger@queued.net> wrote:
>
>> This adds 32-bit support for calling into OFW from the kernel. It's useful
>> for querying the firmware for misc hardware information, fetching the device
>> tree, etc.
>>
>> There's potentially no reason why other platforms couldn't use this, but
>> currently OLPC is the main user of it.
>>
>> This work was originally done by Mitch Bradley.
>>
>> Signed-off-by: Andres Salomon <dilinger@debian.org>
>> ---
>> arch/x86/Kconfig | 8 +++++
>> arch/x86/kernel/Makefile | 1 +
>> arch/x86/kernel/head_32.S | 27 ++++++++++++++++
>> arch/x86/kernel/ofw.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
>> include/asm-x86/ofw.h | 50 ++++++++++++++++++++++++++++++
>> include/asm-x86/setup.h | 1 +
>> 6 files changed, 162 insertions(+), 0 deletions(-)
>> create mode 100644 arch/x86/kernel/ofw.c
>> create mode 100644 include/asm-x86/ofw.h
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 3b9089b..ce56105 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -661,6 +661,14 @@ config I8K
>> Say Y if you intend to run this kernel on a Dell Inspiron 8000.
>> Say N otherwise.
>>
>> +config OPEN_FIRMWARE
>> + bool "Support for Open Firmware"
>> + default y if OLPC
>> + ---help---
>> + This option adds support for the implementation of Open Firmware
>> + that is used on the OLPC XO laptop.
>> + If unsure, say N here.
>> +
>> config X86_REBOOTFIXUPS
>> def_bool n
>> prompt "Enable X86 board specific fixups for reboot"
>> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
>> index 9575754..d33600e 100644
>> --- a/arch/x86/kernel/Makefile
>> +++ b/arch/x86/kernel/Makefile
>> @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_$(BITS).o
>> obj-$(CONFIG_X86_MPPARSE) += mpparse_$(BITS).o
>> obj-$(CONFIG_X86_LOCAL_APIC) += apic_$(BITS).o nmi_$(BITS).o
>> obj-$(CONFIG_X86_IO_APIC) += io_apic_$(BITS).o
>> +obj-$(CONFIG_OPEN_FIRMWARE) += ofw.o
>> obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
>> obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
>> obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
>> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
>> index 74d87ea..c9d2d00 100644
>> --- a/arch/x86/kernel/head_32.S
>> +++ b/arch/x86/kernel/head_32.S
>> @@ -132,6 +132,33 @@ ENTRY(startup_32)
>> movsl
>> 1:
>>
>> +#ifdef CONFIG_OPEN_FIRMWARE
>> +/*
>> + * If Open Firmware booted us, save the OFW client interface callback address
>> + * and preserve the OFW page mappings by priming the kernel's new page
>> + * directory area with a copy of the OFW page directory. That lets OFW stay
>> + * resident in high memory (high in both the virtual and physical spaces)
>> + * for at least long enough to copy out the device tree.
>> + */
>> + movl $pa(boot_params + OFW_INFO_OFFSET), %ebp
>> + cmpl $0x2057464F, (%ebp) /* Magic number "OFW " */
>> + jne 4f
>> +
>> + mov 0x8(%ebp), %eax /* Save callback address */
>> + mov %eax, pa(call_firmware)
>> +
>> + /* Copy the OFW pdir into swapper_pg_dir */
>> + movl %esi, %edx /* save %esi */
>> + movl $pa(swapper_pg_dir), %edi
>> + movl %cr3, %esi /* Source is current pg_dir base address */
>> + movl $1024, %ecx /* Number of page directory entries */
>> + rep
>> + movsl
>> + movl %edx, %esi /* restore %esi */
>> +4:
>> +
>> +#endif
>> +
>> #ifdef CONFIG_PARAVIRT
>> /* This is can only trip for a broken bootloader... */
>> cmpw $0x207, pa(boot_params + BP_version)
>> diff --git a/arch/x86/kernel/ofw.c b/arch/x86/kernel/ofw.c
>> new file mode 100644
>> index 0000000..14036aa
>> --- /dev/null
>> +++ b/arch/x86/kernel/ofw.c
>> @@ -0,0 +1,75 @@
>> +/*
>> + * Open Firmware client interface for 32-bit systems.
>> + *
>> + * Copyright (c) 2007 Mitch Bradley <wmb@firmworks.com>
>> + * Copyright (c) 2007-2008 Andres Salomon <dilinger@debian.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/module.h>
>> +#include <asm/ofw.h>
>> +
>> +/*
>> + * This code is intended to be portable to any 32-bit Open Firmware
>> + * implementation with a standard client interface that can be
>> + * called when Linux is running.
>>
>
> how about changing to ofw_32.c?
>
> YH
>
Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"?
That seems like a good idea to me.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 3:09 ` Mitch Bradley
@ 2008-04-21 3:15 ` Yinghai Lu
2008-04-21 4:05 ` Mitch Bradley
0 siblings, 1 reply; 109+ messages in thread
From: Yinghai Lu @ 2008-04-21 3:15 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, H. Peter Anvin, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>
>
>
> Yinghai Lu wrote:
>
> >
> > how about changing to ofw_32.c?
> >
> > YH
> >
> >
>
> Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"? That
> seems like a good idea to me.
Yes.
BTW, why olpc need OFW runtime service?
why not just put the info in in ram with some signiture, so
kernel/util just need to loot at the table if needed?
YH
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-20 19:12 ` H. Peter Anvin
@ 2008-04-21 3:39 ` Mitch Bradley
2008-04-21 4:54 ` Yinghai Lu
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Mitch Bradley @ 2008-04-21 3:39 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andres Salomon, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
H. Peter Anvin wrote:
> Mitch Bradley wrote:
>>
>> The x86 architecture doesn't make this problem easy.
>>
>
> [long rant about the x86 architecture]
>
> It would be more useful if you described the actual defined entry
> conditions from OpenFirmware look like, including if they are
> well-defined for all OF implementations or only for OLPC.
>
> -hpa
Fair enough...
To get the second subquestion out of the way: At the present time, on
the x86 architecture, "all OF implementations" and "OLPC" are
effectively the same. I am unaware of any other x86 OFW deployments in
current use. There have been some in the past, on bespoke systems such
as Network Appliance servers and at least one settop box, but those have
fallen by the wayside as those companies have shifted over to commodity
PC hardware. The current market status quo is that x86 boards are
primarily designed for Windows, and thus must run legacy BIOS, with some
recent migration to EFI, neither of which are open source in the strong
sense. While I would like to see more OFW penetration into the larger
x86 market, I don't really expect it. x86 motherboard manufacturing is
becoming more and more difficult as signal speeds increase, leading to a
decline in the number of manufacturers. The existing manufacturers
depend on Windows for sales volume and their internal procedures and
working knowledge are based on legacy BIOS.
Once upon a time, we had an OFW "binding" document that stipulated the
interface conditions, with the intention of making that "standard"
across all OFW-on-x86 systems. However, by the time OLPC came around,
there were no other systems to consider, so I felt free to make some
changes in the interface. I ended up choosing an ABI that resulted in a
simple (in the sense of not much code, and no complex state transitions)
interface with 2.6 Linux kernels.
The interface defined below is not inherently OLPC-specific - it would
be suitable for any ia32 system that used OFW. (At a higher level, the
set of OFW callback functions is architecture-neutral; in this message I
am focusing on the very low-level details of the ia32 ABI)
The system conditions for the OFW to Linux kernel transition are as follows:
a) OFW can load the Linux kernel from either bzimage format or ELF
format (either uncompressed or zlib-compressed.) If the kernel is in
ELF format with symbols, OFW can do symbolic kernel debugging. Further
discussion will focus on bzimage format, as that is what OLPC uses and
is also the "greased path" for kernel builds.
b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if
any, at 0x800000.
c) OFW runs in 32-bit protected mode with paging enabled. There are two
reasons for this. First, it lets OFW locate itself at the top of both
physical memory space and virtual address space, the only places that
are truly "out of the way". It also lets Linux call back into OFW with
a minimum of bother (similarly helping with the OFW-debugs-Linux scenario).
d) OFW itself lives at the top of the virtual address space, just below
the ROM. (The ROM is mapped virtual=physical for convenience) OFW
uses RAM allocated from the top of physical memory, mapped at the
aforementioned high virtual addresses. One page directory entry - the
next to last one - is used for that RAM mapping and also for mapping
additional miscellaneous I/O devices. The 8MB frame buffer requires 2
additional PDEs, just below. When Linux takes over the display, OFW no
longer needs the frame buffer mapping, but it is convenient to preserve
that mapping temporarily while using OFW as a debugger.
e) Low memory - everything except the ~1Meg that OFW lives in - is
mapped virtual=physical.
f) The code, data, and stack segment descriptors are all for 32-bit 4GB
linear segments. (For debugging convenience, OFW initially uses the
same segment numbers as the Linux kernel, but that is not an ABI
requirement - callbacks into OFW will work from any 32-bit segments that
encompass the kernel and OFW virtual address space.)
g) OFW sets up a boot parameter block at 0x90000, with the format as
defined in include/asm-x86/bootparam.h . The block includes the
cmdline, memory layout information, screen info, and address/length of
the ramdisk.
h) OFW also includes in the boot parameter block an additional
information block at OFW_INFO_OFFSET. That info block contains:
"OFW " - 4-byte signature string ('O' at byte offset 0, etc)
__u32 version - 1
__u32 callback - (actually a 32-bit function pointer) address of
callback function
__u32 idt - address of OFW's interrupt descriptor table, in case
Linux wants to preserve the breakpoint vector
i) OFW transfers control to the bzimage with the processor in the
following state:
* interrupts masked off at the interrupt controller and in the flags
register
* 32-bit protected mode, CS=0x60, DS=ES=FS=GS=SS=0x68
* ebx=ecx=edx=ebp=edi=0
* eax = &callback_function
* esi = 0x90000 (boot parameter block)
* esp = 0x90000 (short-lived initial stack starts below boot
parameter block)
* eip = 0x100000 (entry address of bzimage)
* paging enabled, with V=P mapping of physical memory and one high
pde for OFW, as in (d) and (e) above
j) Linux must save the following information during early startup:
1) The callback function address - either from the initial value of
eax or from the OFW info block.
2) The the next-to-last page directory entry - just the pointer to the
page table. The page table itself lives in OFW's reserved memory.
k) When calling back into OFW, Linux must:
1) Establish a page directory that contains OFW's PDE (saved in j2
above) and that maps the client interface argument array, including any
buffer pointers.
2) Call callback_function with the address of the argument array in
eax. (Ordinary 32-bit near call).
For all of the OLPC kernel's current callbacks into OFW, the
requirements (j2) and (k1) are easily satisfied by "priming"
swapper_pg_dir with the contents of the current page directory (as
pointed to by the CR3 register).
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 3:15 ` Yinghai Lu
@ 2008-04-21 4:05 ` Mitch Bradley
2008-04-21 4:26 ` David Miller
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Mitch Bradley @ 2008-04-21 4:05 UTC (permalink / raw)
To: Yinghai Lu
Cc: Andres Salomon, H. Peter Anvin, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Yinghai Lu wrote:
> On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>
>>
>> Yinghai Lu wrote:
>>
>>
>>> how about changing to ofw_32.c?
>>>
>>> YH
>>>
>>>
>>>
>> Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"? That
>> seems like a good idea to me.
>>
>
> Yes.
>
> BTW, why olpc need OFW runtime service?
> why not just put the info in in ram with some signiture, so
> kernel/util just need to loot at the table if needed?
>
In SPARC land, at least on SunOS and Solaris, it was very convenient for
debugging to interrupt the OS with Stop-A and use OFW to inspect the
system state. That was especially handy for live crash analysis. Dumps
are useful as far as they go, but they often fail to capture detailed
I/O device state.
I was hoping to do that on x86 too. So far we (OLPC) haven't
implemented a sysrq hook to enter OFW, but I haven't given up hope yet.
It doesn't cost much to leave OFW around, but once you decide to eject
it, you can't easily get it back.
Apple made the early decision to eject OFW and just keep a device tree
table. That decision was probably due to several factors, including the
rather lame state of Apple's first OFW implementation and the complexity
of their OS startup process at the time (which included "trampolining"
to a 68000 emulator to run their legacy code). Once they went down that
path, the die was cast, and the PowerPC community got used to the "OFW
ends up as just a table" idea.
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 4:05 ` Mitch Bradley
@ 2008-04-21 4:26 ` David Miller
2008-04-21 4:50 ` Yinghai Lu
2008-04-21 14:24 ` Andres Salomon
2 siblings, 0 replies; 109+ messages in thread
From: David Miller @ 2008-04-21 4:26 UTC (permalink / raw)
To: wmb
Cc: yhlu.kernel, dilinger, hpa, ebiederm, mingo, akpm, jfannin,
linux-kernel, jordan.crouse
From: Mitch Bradley <wmb@firmworks.com>
Date: Sun, 20 Apr 2008 18:05:26 -1000
> In SPARC land, at least on SunOS and Solaris, it was very convenient for
> debugging to interrupt the OS with Stop-A and use OFW to inspect the
> system state. That was especially handy for live crash analysis. Dumps
> are useful as far as they go, but they often fail to capture detailed
> I/O device state.
In most current SPARC systems, OFW is not usable and is completely
forgotten right after bootup in order to accomodate LDOMs and CPU
hotplug.
It's a better idea, anyways, to develop more pervasive and usable
in-kernel debugger facilities. Then it doesn't matter if you have
"cool" firmware or not. :-)
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 4:05 ` Mitch Bradley
2008-04-21 4:26 ` David Miller
@ 2008-04-21 4:50 ` Yinghai Lu
2008-04-21 8:03 ` Mitch Bradley
2008-04-21 14:24 ` Andres Salomon
2 siblings, 1 reply; 109+ messages in thread
From: Yinghai Lu @ 2008-04-21 4:50 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, H. Peter Anvin, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
On Sun, Apr 20, 2008 at 9:05 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>
>
>
> Yinghai Lu wrote:
>
> > On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> >
> >
> > >
> > > Yinghai Lu wrote:
> > >
> > >
> > >
> > > > how about changing to ofw_32.c?
> > > >
> > > > YH
> > > >
> > > >
> > > >
> > > >
> > > Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"?
> That
> > > seems like a good idea to me.
> > >
> > >
> >
> > Yes.
> >
> > BTW, why olpc need OFW runtime service?
> > why not just put the info in in ram with some signiture, so
> > kernel/util just need to loot at the table if needed?
> >
> >
>
> In SPARC land, at least on SunOS and Solaris, it was very convenient for
> debugging to interrupt the OS with Stop-A and use OFW to inspect the system
> state. That was especially handy for live crash analysis. Dumps are useful
> as far as they go, but they often fail to capture detailed I/O device state.
>
> I was hoping to do that on x86 too. So far we (OLPC) haven't implemented a
> sysrq hook to enter OFW, but I haven't given up hope yet. It doesn't cost
> much to leave OFW around, but once you decide to eject it, you can't easily
> get it back.
geode is using SMI to simulate the pci conf space, wonder that could be problem.
later you have 64 runtime service for 64 platform like UEFI?
YH
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 3:39 ` Mitch Bradley
@ 2008-04-21 4:54 ` Yinghai Lu
2008-04-21 8:22 ` Mitch Bradley
2008-04-21 11:36 ` H. Peter Anvin
2008-04-21 15:05 ` Jordan Crouse
2 siblings, 1 reply; 109+ messages in thread
From: Yinghai Lu @ 2008-04-21 4:54 UTC (permalink / raw)
To: Mitch Bradley
Cc: H. Peter Anvin, Andres Salomon, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
On Sun, Apr 20, 2008 at 8:39 PM, Mitch Bradley <wmb@firmworks.com> wrote:
>
> H. Peter Anvin wrote:
>
> > Mitch Bradley wrote:
> >
> > >
> > > The x86 architecture doesn't make this problem easy.
> > >
> > >
> >
> > [long rant about the x86 architecture]
> >
> > It would be more useful if you described the actual defined entry
> conditions from OpenFirmware look like, including if they are well-defined
> for all OF implementations or only for OLPC.
> >
> > -hpa
> >
>
> Fair enough...
>
> To get the second subquestion out of the way: At the present time, on the
> x86 architecture, "all OF implementations" and "OLPC" are effectively the
> same. I am unaware of any other x86 OFW deployments in current use. There
> have been some in the past, on bespoke systems such as Network Appliance
> servers and at least one settop box, but those have fallen by the wayside as
> those companies have shifted over to commodity PC hardware. The current
> market status quo is that x86 boards are primarily designed for Windows, and
> thus must run legacy BIOS, with some recent migration to EFI, neither of
> which are open source in the strong sense. While I would like to see more
> OFW penetration into the larger x86 market, I don't really expect it. x86
> motherboard manufacturing is becoming more and more difficult as signal
> speeds increase, leading to a decline in the number of manufacturers. The
> existing manufacturers depend on Windows for sales volume and their internal
> procedures and working knowledge are based on legacy BIOS.
>
> Once upon a time, we had an OFW "binding" document that stipulated the
> interface conditions, with the intention of making that "standard" across
> all OFW-on-x86 systems. However, by the time OLPC came around, there were
> no other systems to consider, so I felt free to make some changes in the
> interface. I ended up choosing an ABI that resulted in a simple (in the
> sense of not much code, and no complex state transitions) interface with 2.6
> Linux kernels.
>
> The interface defined below is not inherently OLPC-specific - it would be
> suitable for any ia32 system that used OFW. (At a higher level, the set of
> OFW callback functions is architecture-neutral; in this message I am
> focusing on the very low-level details of the ia32 ABI)
>
> The system conditions for the OFW to Linux kernel transition are as
> follows:
>
> a) OFW can load the Linux kernel from either bzimage format or ELF format
> (either uncompressed or zlib-compressed.) If the kernel is in ELF format
> with symbols, OFW can do symbolic kernel debugging. Further discussion will
> focus on bzimage format, as that is what OLPC uses and is also the "greased
> path" for kernel builds.
>
> b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if any,
> at 0x800000.
so you are assuming that your uncompressed vmlinux only use less 8M space?
you are supposed to check the bzImage to get uncompressed vmlinux size.
YH
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 4:50 ` Yinghai Lu
@ 2008-04-21 8:03 ` Mitch Bradley
0 siblings, 0 replies; 109+ messages in thread
From: Mitch Bradley @ 2008-04-21 8:03 UTC (permalink / raw)
To: Yinghai Lu
Cc: Andres Salomon, H. Peter Anvin, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Yinghai Lu wrote:
>> ...
>
> geode is using SMI to simulate the pci conf space, wonder that could be problem.
>
On the current OLPC system, we don't use the SMI-based PCI config space
simulator. The code for that "VSA" module is only partially open
sourced (some of it is open, and some of it is just not available). The
parts of it for which we do have source can only be compiled with an old
proprietary toolchain that is no longer available.
Instead of using the SMI-based simulation, we have added a PCI
configuration access method in the kernel that supplies the necessary
information from a table. The code for that hardware-specific access
method is roughly 40 lines of code plus a few data tables.
In the past few weeks, I have developed a rather complete Open
Firmware-based reimplementation of the SMI PCI config hardware
emulator. All-told, it requires over 1000 lines. It remains to be
seen whether the complicated version will ultimately be deployed.
Personally, I find it distasteful to use a lot of code to make the
hardware pretend that it is something other than what it really is, when
a much smaller driver works just as well. The SMI-based emulator is
quite difficult to understand and maintain, because the Geode SMI
handling mechanism is complex, incompletely documented, and suffers from
many of the multiple-mode-switches problems as real-mode to
protected-mode gateway code.
> later you have 64 runtime service for 64 platform like UEFI?
>
Possibly. 64-bit systems are not a problem per se - there have been
64-bit OFW implementations for 64-bit architectures like SPARC and Alpha
dating back to a long time ago. The main issue from my point of view is
whether or not there is a customer to motivate the work.
> YH
>
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 4:54 ` Yinghai Lu
@ 2008-04-21 8:22 ` Mitch Bradley
0 siblings, 0 replies; 109+ messages in thread
From: Mitch Bradley @ 2008-04-21 8:22 UTC (permalink / raw)
To: Yinghai Lu
Cc: H. Peter Anvin, Andres Salomon, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Yinghai Lu wrote:
>
>> path" for kernel builds.
>>
>> b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if any,
>> at 0x800000.
>>
>
> so you are assuming that your uncompressed vmlinux only use less 8M space?
>
> you are supposed to check the bzImage to get uncompressed vmlinux size.
>
The 0x800000 ramdisk load address is an OLPC-specific firmware
implementation detail that could easily be changed without affecting
anything else. I probably shouldn't have mentioned it because it isn't
really an integral part of the interface "contract".
I certainly hope that the OLPC kernel never gets anywhere near that
size. The OLPC hardware has limited configurability, so it's not
plausible that the kernel would grow that large to include a huge kit of
drivers. If the kernel file becomes large as a result of including the
initramfs in the same file, the 0x800000 ramdisk load address won't
apply (because there won't be a separate load of the initramfs file), so
the kernel could be extend way past that boundary with no problems.
If we get to the point where we do need huge kernels on OLPC, we can
release a firmware upgrade along with the new OS. We have mechanisms
for coordinating firmware and OS upgrades.
If a new customer for OFW on x86 appears, I'll remember to float the
boundary above the bzImage uncompressed size (assuming that the bzimage
format is still applicable when that happens).
> YH
>
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* [Was: 2.6.25-mm1]
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
` (9 preceding siblings ...)
2008-04-20 11:29 ` internal compiler error: SIGSEGV [Was: 2.6.25-mm1] Jiri Slaby
@ 2008-04-21 8:31 ` Jiri Slaby
2008-04-21 9:06 ` Al Viro
10 siblings, 1 reply; 109+ messages in thread
From: Jiri Slaby @ 2008-04-21 8:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Al Viro, linux-fsdevel
On 04/18/2008 10:47 AM, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
Hi,
$ ls /usr/share/man/cat3readlin
Segmentation fault
[the file doesn't exist.]
This is probably the same bug as in -rc8-mm2 I reported here:
http://www.opensubscriber.com/message/linux-kernel@vger.kernel.org/9008289.html
general protection fault: 0000 [1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:19.0/net/eth0/statistics/collisions
CPU 0
Modules linked in: test ipv6 tun bitrev arc4 ecb crypto_blkcipher cryptomgr
crypto_algapi ath5k mac80211 crc32 sr_mod usbhid ohci1394 rtc_cmos hid rtc_core
cfg80211 ieee1394 cdrom ehci_hcd rtc_lib ff_memless floppy evdev
Pid: 24838, comm: man Not tainted 2.6.25-mm1_64 #403
RIP: 0010:[<ffffffff802aca27>] [<ffffffff802aca27>] __d_lookup+0x97/0x160
RSP: 0018:ffff8100337d1b98 EFLAGS: 00010206
RAX: 00f0000000000000 RBX: 00f0000000000000 RCX: 0000000000000012
RDX: ffff8100200830e0 RSI: ffff8100337d1ca8 RDI: ffff810079195708
RBP: ffff8100337d1bf8 R08: ffff8100337d1ca8 R09: 0000000000000000
R10: 000000000000013d R11: 0000000000000246 R12: ffff8100200830c8
R13: 00000000198eaed5 R14: ffff810079195708 R15: ffff8100337d1bc8
FS: 00007f447b5c06f0(0000) GS:ffffffff80664000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000001484f88 CR3: 000000005fac4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process man (pid: 24838, threadinfo ffff8100337d0000, task ffff810034418000)
Stack: ffff8100337d1ca8 000000000000000b ffff810079195710 0000000b792561a0
ffff81003136600f ffffffff802f9073 00f0000000000000 0000000000000001
ffff8100337d1e48 ffff8100337d1e48 ffff8100337d1ca8 ffff8100337d1cb8
Call Trace:
[<ffffffff802f9073>] ? ext3_lookup+0xc3/0x100
[<ffffffff802a1e85>] do_lookup+0x35/0x220
[<ffffffff802a22c2>] __link_path_walk+0x252/0x1010
[<ffffffff802b20ba>] ? mntput_no_expire+0x2a/0x140
[<ffffffff802a30ee>] path_walk+0x6e/0xe0
[<ffffffff802a33b2>] do_path_lookup+0xa2/0x240
[<ffffffff802a38b7>] __path_lookup_intent_open+0x67/0xd0
[<ffffffff802a392c>] path_lookup_open+0xc/0x10
[<ffffffff802a487a>] do_filp_open+0xaa/0x990
[<ffffffff8024f8b4>] ? up+0x34/0x50
[<ffffffff804fd619>] ? unlock_kernel+0x29/0x30
[<ffffffff802b20ba>] ? mntput_no_expire+0x2a/0x140
[<ffffffff80295ddc>] ? get_unused_fd_flags+0x8c/0x140
[<ffffffff80295f06>] do_sys_open+0x76/0x110
[<ffffffff80295fcb>] sys_open+0x1b/0x20
[<ffffffff8020b91b>] system_call_after_swapgs+0x7b/0x80
Code: 48 89 c3 48 8b 55 d0 8b 45 bc 48 85 d2 48 89 45 a8 75 18 eb 5f 0f 1f 80 00
00 00 00 48 8b 1b 48 89 5d d0 49 8b 07 48 85 c0 74 49 <48> 8b 03 4c 8d 63 e8 0f
18 08 45 39 6c 24 30 75 e0 4d 39 74 24
RIP [<ffffffff802aca27>] __d_lookup+0x97/0x160
RSP <ffff8100337d1b98>
---[ end trace cb4ec4895332b217 ]---
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Was: 2.6.25-mm1]
2008-04-21 8:31 ` Jiri Slaby
@ 2008-04-21 9:06 ` Al Viro
2008-04-21 9:37 ` fault in __d_lookup " Jiri Slaby
0 siblings, 1 reply; 109+ messages in thread
From: Al Viro @ 2008-04-21 9:06 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, linux-fsdevel
On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
struct qstr *qstr;
if (dentry->d_name.hash != hash)
continue;
walking into node == (struct hlist_node *)0x00f0000000000000...
^ permalink raw reply [flat|nested] 109+ messages in thread
* fault in __d_lookup [Was: 2.6.25-mm1]
2008-04-21 9:06 ` Al Viro
@ 2008-04-21 9:37 ` Jiri Slaby
2008-04-21 9:45 ` Al Viro
0 siblings, 1 reply; 109+ messages in thread
From: Jiri Slaby @ 2008-04-21 9:37 UTC (permalink / raw)
To: Al Viro; +Cc: Andrew Morton, linux-kernel, linux-fsdevel
On 04/21/2008 11:06 AM, Al Viro wrote:
> On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
>
> hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
> struct qstr *qstr;
>
> if (dentry->d_name.hash != hash)
> continue;
>
> walking into node == (struct hlist_node *)0x00f0000000000000...
Yup, true, In the last oops I stuck on memcmp few lines below.
BTW. it's 100% reproducible after it happens once, but fixable by reboot. Any
tests I should run (memtest, some printks sticked anywhere)?
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: fault in __d_lookup [Was: 2.6.25-mm1]
2008-04-21 9:37 ` fault in __d_lookup " Jiri Slaby
@ 2008-04-21 9:45 ` Al Viro
2008-04-21 9:59 ` Jiri Slaby
0 siblings, 1 reply; 109+ messages in thread
From: Al Viro @ 2008-04-21 9:45 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, linux-kernel, linux-fsdevel
On Mon, Apr 21, 2008 at 11:37:40AM +0200, Jiri Slaby wrote:
> On 04/21/2008 11:06 AM, Al Viro wrote:
> >On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
> >
> > hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
> > struct qstr *qstr;
> >
> > if (dentry->d_name.hash != hash)
> > continue;
> >
> >walking into node == (struct hlist_node *)0x00f0000000000000...
>
> Yup, true, In the last oops I stuck on memcmp few lines below.
>
> BTW. it's 100% reproducible after it happens once, but fixable by reboot.
> Any tests I should run (memtest, some printks sticked anywhere)?
Well, if list has such turd in it, you'll certainly hit it every time
you walk that list, so 100% reproducible is not surprising.
How well is it reproducible from fresh boot?
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: fault in __d_lookup [Was: 2.6.25-mm1]
2008-04-21 9:45 ` Al Viro
@ 2008-04-21 9:59 ` Jiri Slaby
2008-04-21 13:42 ` Rafael J. Wysocki
2008-04-21 17:23 ` Matthew Wilcox
0 siblings, 2 replies; 109+ messages in thread
From: Jiri Slaby @ 2008-04-21 9:59 UTC (permalink / raw)
To: Al Viro; +Cc: Andrew Morton, linux-kernel, linux-fsdevel
On 04/21/2008 11:45 AM, Al Viro wrote:
> On Mon, Apr 21, 2008 at 11:37:40AM +0200, Jiri Slaby wrote:
>> On 04/21/2008 11:06 AM, Al Viro wrote:
>>> On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
>>>
>>> hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
>>> struct qstr *qstr;
>>>
>>> if (dentry->d_name.hash != hash)
>>> continue;
>>>
>>> walking into node == (struct hlist_node *)0x00f0000000000000...
>> Yup, true, In the last oops I stuck on memcmp few lines below.
>>
>> BTW. it's 100% reproducible after it happens once, but fixable by reboot.
>> Any tests I should run (memtest, some printks sticked anywhere)?
>
> Well, if list has such turd in it, you'll certainly hit it every time
> you walk that list, so 100% reproducible is not surprising.
>
> How well is it reproducible from fresh boot?
Few days with suspend/resume cycles. This one was booted 12 hours ago, one
suspend/resume. Will keep an eye on it and keep you informed.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 4:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 6:33 ` 2.6.25-mm1 Joseph Fannin
@ 2008-04-21 11:07 ` Takashi Iwai
2008-04-21 17:44 ` 2.6.25-mm1 (snd-pcsp causes driver conflict) Stas Sergeev
2008-04-21 19:45 ` 2.6.25-mm1 Stas Sergeev
2008-04-21 14:06 ` 2.6.25-mm1 Takashi Iwai
2 siblings, 2 replies; 109+ messages in thread
From: Takashi Iwai @ 2008-04-21 11:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Dmitry Torokhov, Joseph Fannin, linux-kernel, Greg KH,
Kay Sievers, Stas Sergeev
[Added snd-pcsp author to Cc]
At Fri, 18 Apr 2008 21:29:34 -0700,
Andrew Morton wrote:
>
> On Sat, 19 Apr 2008 00:14:29 -0400 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
> > On Fri, Apr 18, 2008 at 08:02:37PM -0700, Andrew Morton wrote:
> > > On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> > >
> > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
> > > >
> > > > I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
> > > > least, since that's the earliest -mm I've built in a while. I don't
> > > > get the same in mainline.
> > > >
> > > > No idea who to CC:
> > >
> > > I have a few ideas.
> > >
> > > > I've sat on this report long enough.
> > >
> > > Thanks for the report.
> > >
> > > > I'm going to send a few different reports in separate mails, so I'll
> > > > put my dmesg and .config up on a server:
> > > >
> > > > http://home.columbus.rr.com/jfannin3/dmesg.txt
> > > > http://home.columbus.rr.com/jfannin3/config-2.6.25-mm1.txt
> > > >
> > > > [ 451.915553] sysfs: duplicate filename 'pcspkr' can not be created
> > > > [ 451.915731] ------------[ cut here ]------------
> > > > [ 451.915851] WARNING: at fs/sysfs/dir.c:427 sysfs_add_one+0x85/0xe0()
> > > > [ 451.915981] Modules linked in: snd_pcsp(+) ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart snd_seq_dummy snd_seq_oss snd_seq_midi psmouse snd_rawmidi serio_raw snd_seq_midi_event snd_seq button i2c_viapro snd_timer snd_seq_device pcspkr i2c_core snd snd_page_alloc via686a shpchp pci_hotplug parport_pc parport via_agp agpgart soundcore evdev sg sr_mod cdrom sd_mod 8139cp aic7xxx scsi_transport_spi scsi_mod 8139too mii uhci_hcd usbcore raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 multipath linear md_mod thermal processor fan fuse ext4dev mbcache jbd2 crc16
> > > > [ 451.918960] Pid: 2740, comm: modprobe Tainted: G W 2.6.25-mm1 #7
> > > > [ 451.929271] [<c0130fa9>] warn_on_slowpath+0x59/0x80
> > > > [ 451.929500] [<c0132400>] ? vprintk+0x2f0/0x4a0
> > > > [ 451.929723] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > > > [ 451.929918] [<c01c6a7a>] ? ifind+0x4a/0xa0
> > > > [ 451.930126] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > > > [ 451.930334] [<c015535b>] ? trace_hardirqs_on+0xb/0x10
> > > > [ 451.930534] [<c01325d0>] ? printk+0x20/0x30
> > > > [ 451.930727] [<c01fcc45>] sysfs_add_one+0x85/0xe0
> > > > [ 451.930900] [<c01fd89e>] create_dir+0x4e/0xb0
> > > > [ 451.931064] [<c01fd930>] sysfs_create_dir+0x30/0x50
> > > > [ 451.931291] [<c0356adc>] ? _spin_unlock+0x2c/0x50
> > > > [ 451.931485] [<c023dac6>] kobject_add_internal+0xb6/0x190
> > > > [ 451.931656] [<c023dc22>] ? kobject_set_name_vargs+0x32/0x40
> > > > [ 451.931857] [<c023dc8a>] kobject_add_varg+0x5a/0x60
> > > > [ 451.932022] [<c023e12f>] kobject_init_and_add+0x2f/0x40
> > > > [ 451.932188] [<c02a3e44>] bus_add_driver+0x94/0x250
> > > > [ 451.932364] [<c02a5062>] driver_register+0x42/0xf0
> > > > [ 451.932533] [<c02a6c56>] platform_driver_register+0x66/0x70
> > > > [ 451.932702] [<cc04b02a>] pcsp_init+0x2a/0x2c [snd_pcsp]
> > > > [ 451.932877] [<c015e137>] sys_init_module+0x87/0x1a0
> > > > [ 451.933043] [<c0155216>] ? trace_hardirqs_on_caller+0x16/0x150
> > > > [ 451.933246] [<c024314c>] ? trace_hardirqs_on_thunk+0xc/0x10
> > > > [ 451.933453] [<c0104077>] sysenter_past_esp+0x78/0xc5
Seems that snd-pcsp registers as "pcspkr", which is identical with
input pc-speaker driver. Does the patch below fix the problem?
Takashi
---
diff -r e8f61dd0b153 sound/drivers/pcsp/pcsp.c
--- a/sound/drivers/pcsp/pcsp.c Thu Apr 17 17:58:34 2008 +0200
+++ b/sound/drivers/pcsp/pcsp.c Mon Apr 21 13:06:35 2008 +0200
@@ -21,7 +21,7 @@
MODULE_DESCRIPTION("PC-Speaker driver");
MODULE_LICENSE("GPL");
MODULE_SUPPORTED_DEVICE("{{PC-Speaker, pcsp}}");
-MODULE_ALIAS("platform:pcspkr");
+MODULE_ALIAS("platform:snd_pcsp");
static int index = SNDRV_DEFAULT_IDX1; /* Index 0-MAX */
static char *id = SNDRV_DEFAULT_STR1; /* ID for this card */
@@ -214,7 +214,7 @@
static struct platform_driver pcsp_platform_driver = {
.driver = {
- .name = "pcspkr",
+ .name = "snd_pcsp",
.owner = THIS_MODULE,
},
.probe = pcsp_probe,
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 3:39 ` Mitch Bradley
2008-04-21 4:54 ` Yinghai Lu
@ 2008-04-21 11:36 ` H. Peter Anvin
2008-04-21 13:09 ` H. Peter Anvin
` (2 more replies)
2008-04-21 15:05 ` Jordan Crouse
2 siblings, 3 replies; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-21 11:36 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Mitch Bradley wrote:
>
> d) OFW itself lives at the top of the virtual address space, just below
> the ROM. (The ROM is mapped virtual=physical for convenience) OFW
> uses RAM allocated from the top of physical memory, mapped at the
> aforementioned high virtual addresses. One page directory entry - the
> next to last one - is used for that RAM mapping and also for mapping
> additional miscellaneous I/O devices. The 8MB frame buffer requires 2
> additional PDEs, just below. When Linux takes over the display, OFW no
> longer needs the frame buffer mapping, but it is convenient to preserve
> that mapping temporarily while using OFW as a debugger.
>
So let me see here... you want the virtual address range [0xffc00000,
0xfff00000) to be reserved for OFW, and you are prohibiting the kernel
from using PAE?
> e) Low memory - everything except the ~1Meg that OFW lives in - is
> mapped virtual=physical.
Are you making this assumption when called from the kernel, too?
> j) Linux must save the following information during early startup:
> 1) The callback function address - either from the initial value of eax
> or from the OFW info block.
> 2) The the next-to-last page directory entry - just the pointer to the
> page table. The page table itself lives in OFW's reserved memory.
>
> k) When calling back into OFW, Linux must:
> 1) Establish a page directory that contains OFW's PDE (saved in j2
> above) and that maps the client interface argument array, including any
> buffer pointers.
> 2) Call callback_function with the address of the argument array in
> eax. (Ordinary 32-bit near call).
>
> For all of the OLPC kernel's current callbacks into OFW, the
> requirements (j2) and (k1) are easily satisfied by "priming"
> swapper_pg_dir with the contents of the current page directory (as
> pointed to by the CR3 register).
I do not like it, simply because it amounts to "initialize this
otherwise zero-initialized piece of data without making any kind of
reservations and blindly hope nothing else overwrites it."
I'm also troubled with the assumption that the kernel doesn't use PAE.
I realize that this is not an issue for OLPC, but it certainly makes
this a less-than-generic solution.
Having mapped page table entries which are not under kernel control is a
very serious problem for PAT - PAT requires, by hardware specification,
the kernel to eliminate all potential aliases with different mappings.
One way to deal with this, of course, is to save the firmware-provided
PGD and only use it for OFW calls. On the other hand, perhaps a better
questions is to what extent it is needed at all.
Furthermore, since you're using a nonstandard OFW interface (not
compliant with the x86 OFW binding document), all of this should be
called something like OLPC_OFW to make it clear that it's the OLPC variant.
If I had designed this, I would probably have used an SMI; since you
have control over the firmware you can do that. SMI saves the entire
machine state including all the modes, cleans them all up for you, and
puts it all back together at RSM time. It is slow, of course, but it
completely decouples the firmware and the OS, which is why it's used.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 11:36 ` H. Peter Anvin
@ 2008-04-21 13:09 ` H. Peter Anvin
2008-04-21 13:13 ` H. Peter Anvin
2008-04-21 13:19 ` H. Peter Anvin
2 siblings, 0 replies; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-21 13:09 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Okay, stepping back a few steps, it's pretty clear that most of my
objections aren't really an issue for Geode/OLPC; however, I *really*
don't want others to pick it up as being "the" Open Firmware interface.
Within those constraints it makes sense to set up the PDEs in
swapper_pg_dir and let them propagate using the normal mechanisms.
** This is assuming that your OF interface does not rely on a 1:1
mapping of low memory being present at the time it makes a call. If it
*does*, then a separate page directory needs to be maintained for the OF
class. **
Thus, I'm willing to accept this with these changes:
- Please name things specific to the interface (as opposed to Open
Firmware in general, like the device tree) olpc_ofw or olpcfw, to denote
that this is an OLPC-specific interface. Thus,
CONFIG_OLPC_OPEN_FIRMWARE or something along those lines.
- Make it explicit in Kconfig that OLPC_OPEN_FIRMWARE conflicts with
X86_PAE, 64BIT, or X86_PAT.
- Change VMALLOC_END in include/asm-x86/pgtable_32.h so the kernel will
know to avoid this virtual memory range.
- Add a memory region to arch/x86/mm/dump_tabletables.c.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 11:36 ` H. Peter Anvin
2008-04-21 13:09 ` H. Peter Anvin
@ 2008-04-21 13:13 ` H. Peter Anvin
2008-04-21 13:19 ` H. Peter Anvin
2 siblings, 0 replies; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-21 13:13 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Okay, stepping back a few steps, it's pretty clear that most of my
objections aren't really an issue for Geode/OLPC; however, I *really*
don't want others to pick it up as being "the" Open Firmware interface.
Within those constraints it makes sense to set up the PDEs in
swapper_pg_dir and let them propagate using the normal mechanisms.
** This is assuming that your OF interface does not rely on a 1:1
mapping of low memory being present at the time it makes a call. If it
*does*, then a separate page directory needs to be maintained for the OF
class. **
Thus, I'm willing to accept this with these changes:
- Please name things specific to the interface (as opposed to Open
Firmware in general, like the device tree) olpc_ofw or olpcfw, to denote
that this is an OLPC-specific interface. Thus,
CONFIG_OLPC_OPEN_FIRMWARE or something along those lines.
- Make it explicit in Kconfig that OLPC_OPEN_FIRMWARE conflicts with
X86_PAE, 64BIT, or X86_PAT.
- Change VMALLOC_END in include/asm-x86/pgtable_32.h so the kernel will
know to avoid this virtual memory range.
- Add a memory region to arch/x86/mm/dump_tabletables.c.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 11:36 ` H. Peter Anvin
2008-04-21 13:09 ` H. Peter Anvin
2008-04-21 13:13 ` H. Peter Anvin
@ 2008-04-21 13:19 ` H. Peter Anvin
2 siblings, 0 replies; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-21 13:19 UTC (permalink / raw)
To: Mitch Bradley
Cc: Andres Salomon, Yinghai Lu, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
Okay, stepping back a few steps, it's pretty clear that most of my
objections aren't really an issue for Geode/OLPC; however, I *really*
don't want others to pick it up as being "the" Open Firmware interface.
Within those constraints it makes sense to set up the PDEs in
swapper_pg_dir and let them propagate using the normal mechanisms.
** This is assuming that your OF interface does not rely on a 1:1
mapping of low memory being present at the time it makes a call. If it
*does*, then a separate page directory needs to be maintained for the OF
class. **
Thus, I'm willing to accept this with these changes:
- Please name things specific to the interface (as opposed to Open
Firmware in general, like the device tree) olpc_ofw or olpcfw, to denote
that this is an OLPC-specific interface. Thus,
CONFIG_OLPC_OPEN_FIRMWARE or something along those lines.
- Make it explicit in Kconfig that OLPC_OPEN_FIRMWARE conflicts with
X86_PAE, 64BIT, or X86_PAT.
- Change VMALLOC_END in include/asm-x86/pgtable_32.h so the kernel will
know to avoid this virtual memory range.
- Add a memory region to arch/x86/mm/dump_tabletables.c.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: fault in __d_lookup [Was: 2.6.25-mm1]
2008-04-21 9:59 ` Jiri Slaby
@ 2008-04-21 13:42 ` Rafael J. Wysocki
2008-04-21 17:23 ` Matthew Wilcox
1 sibling, 0 replies; 109+ messages in thread
From: Rafael J. Wysocki @ 2008-04-21 13:42 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Al Viro, Andrew Morton, linux-kernel, linux-fsdevel
On Monday, 21 of April 2008, Jiri Slaby wrote:
> On 04/21/2008 11:45 AM, Al Viro wrote:
> > On Mon, Apr 21, 2008 at 11:37:40AM +0200, Jiri Slaby wrote:
> >> On 04/21/2008 11:06 AM, Al Viro wrote:
> >>> On Mon, Apr 21, 2008 at 10:31:40AM +0200, Jiri Slaby wrote:
> >>>
> >>> hlist_for_each_entry_rcu(dentry, node, head, d_hash) {
> >>> struct qstr *qstr;
> >>>
> >>> if (dentry->d_name.hash != hash)
> >>> continue;
> >>>
> >>> walking into node == (struct hlist_node *)0x00f0000000000000...
> >> Yup, true, In the last oops I stuck on memcmp few lines below.
> >>
> >> BTW. it's 100% reproducible after it happens once, but fixable by reboot.
> >> Any tests I should run (memtest, some printks sticked anywhere)?
> >
> > Well, if list has such turd in it, you'll certainly hit it every time
> > you walk that list, so 100% reproducible is not surprising.
> >
> > How well is it reproducible from fresh boot?
>
> Few days with suspend/resume cycles. This one was booted 12 hours ago, one
> suspend/resume. Will keep an eye on it and keep you informed.
I think that's exactly the same problem I reported here:
http://lkml.org/lkml/2008/4/20/182
for 2.6.25-git2, so it hit the mainline and seems to be related to RCU.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 4:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 6:33 ` 2.6.25-mm1 Joseph Fannin
2008-04-21 11:07 ` 2.6.25-mm1 Takashi Iwai
@ 2008-04-21 14:06 ` Takashi Iwai
2008-04-21 17:55 ` 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC) Stas Sergeev
2 siblings, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-04-21 14:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Dmitry Torokhov, Joseph Fannin, linux-kernel, Greg KH,
Kay Sievers, Stas Sergeev
At Fri, 18 Apr 2008 21:29:34 -0700,
Andrew Morton wrote:
>
> >
> > Cool things there:
> >
> > +#ifdef CONFIG_DEBUG_PAGEALLOC
> > + /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets
> > alert */
> > + printk(KERN_WARNING
> > + "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
> > + "You have to disable it if you want to use the PC-Speaker
> > "
> > + "driver.\n"
> > + "Unless it is disabled, enjoy the horrible, distorted "
> > + "and crackling noise.\n");
> > +#endif
>
> heh.
>
> CONFIG_DEBUG_PAGEALLOC is a very heavy consumer of CPU cycles. I'm not
> surprised that it would whack what I presume to be a very latency-sensitive
> driver.
We can add simply a dependncy to Kconfig if this really matters.
Takashi
---
diff -r e8f61dd0b153 sound/drivers/Kconfig
--- a/sound/drivers/Kconfig Thu Apr 17 17:58:34 2008 +0200
+++ b/sound/drivers/Kconfig Mon Apr 21 16:06:09 2008 +0200
@@ -7,6 +7,7 @@
config SND_PCSP
tristate "Internal PC speaker support"
depends on X86_PC && HIGH_RES_TIMERS
+ depends on !DEBUG_PAGEALLOC
help
If you don't have a sound card in your computer, you can include a
driver for the PC speaker which allows it to act like a primitive
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 4:05 ` Mitch Bradley
2008-04-21 4:26 ` David Miller
2008-04-21 4:50 ` Yinghai Lu
@ 2008-04-21 14:24 ` Andres Salomon
2008-04-21 15:54 ` David Woodhouse
2 siblings, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-21 14:24 UTC (permalink / raw)
To: Mitch Bradley
Cc: Yinghai Lu, H. Peter Anvin, Eric W. Biederman, Ingo Molnar,
Andrew Morton, Joseph Fannin, linux-kernel, jordan.crouse
On Sun, 20 Apr 2008 18:05:26 -1000
Mitch Bradley <wmb@firmworks.com> wrote:
>
>
> Yinghai Lu wrote:
> > On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley <wmb@firmworks.com> wrote:
> >
> >>
> >> Yinghai Lu wrote:
> >>
> >>
> >>> how about changing to ofw_32.c?
> >>>
> >>> YH
> >>>
> >>>
> >>>
> >> Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"? That
> >> seems like a good idea to me.
> >>
> >
> > Yes.
> >
> > BTW, why olpc need OFW runtime service?
> > why not just put the info in in ram with some signiture, so
> > kernel/util just need to loot at the table if needed?
> >
>
> In SPARC land, at least on SunOS and Solaris, it was very convenient for
> debugging to interrupt the OS with Stop-A and use OFW to inspect the
> system state. That was especially handy for live crash analysis. Dumps
> are useful as far as they go, but they often fail to capture detailed
> I/O device state.
>
> I was hoping to do that on x86 too. So far we (OLPC) haven't
> implemented a sysrq hook to enter OFW, but I haven't given up hope yet.
> It doesn't cost much to leave OFW around, but once you decide to eject
> it, you can't easily get it back.
>
I'm not actually convinced that we *do* want to keep OFW resident in memory,
especially given the memory tricks we need to play. I also don't actually
like the OFW interface that we. The debugging aspect of it was a
compelling argument up until a week ago (when kernel debuggers started
finally finding their way into the kernel).
However, until we clean up the promfs stuff, there's no chance of getting
an OFW device tree upstream.
> Apple made the early decision to eject OFW and just keep a device tree
> table. That decision was probably due to several factors, including the
> rather lame state of Apple's first OFW implementation and the complexity
> of their OS startup process at the time (which included "trampolining"
> to a 68000 emulator to run their legacy code). Once they went down that
> path, the die was cast, and the PowerPC community got used to the "OFW
> ends up as just a table" idea.
>
> >
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-19 17:50 ` 2.6.25-mm1 Andres Salomon
@ 2008-04-21 14:56 ` Jordan Crouse
2008-04-21 15:05 ` 2.6.25-mm1 Andres Salomon
0 siblings, 1 reply; 109+ messages in thread
From: Jordan Crouse @ 2008-04-21 14:56 UTC (permalink / raw)
To: Andres Salomon; +Cc: Andrew Morton, jfannin, linux-kernel, mingo
On 19/04/08 13:50 -0400, Andres Salomon wrote:
> On Sat, 19 Apr 2008 10:38:33 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@queued.net> wrote:
> > > On Fri, 18 Apr 2008 20:29:25 -0700
> > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> > > >
> > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> [...]
> > > >
> > > > which we probably just shouldn't do this at all unless we're running on the
> > > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
> > > > hardware! Perhaps the warning should just be removed.
> > >
> > > Hm. We could either protect that code with an:
> > >
> > > if (!is_geode())
> > > return;
> > >
> > > Or I could add the OpenFirmware patches which would allow us to get
> > > rid of this code, and instead check for the existence of OFW using
> > > that.
> > >
> > > The former is quick and easy; the latter is (imo) nicer, so long as
> > > people don't have problems w/ the OFW code. :)
> > >
> >
> > Do both ;)
> >
> > The quick-n-easy version sounds suitable for now.
>
> Heh, I already had sent the nicer version. If people have some fundamental
> problem w/ it, I can send the quick-n-easy version.
I prefer the nicer version. It is not a good policy IMHO to wrap OLPC
specfic code with is_geode() and friends. Even by Geode standards, we've
abused the code greatly for the benefit of the Geode, and few of those
abuses would translate very well even to the general Geode community. I
would prefer that we use the is_olpc() and #ifdef wrappers to ensure
that the code that is exclusively OLPC stays exclusively OLPC.
Thanks,
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: OLPC: Add support for calling into Open Firmware
2008-04-21 15:05 ` Jordan Crouse
@ 2008-04-21 14:58 ` H. Peter Anvin
0 siblings, 0 replies; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-21 14:58 UTC (permalink / raw)
To: Jordan Crouse
Cc: Mitch Bradley, Andres Salomon, Yinghai Lu, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel
Jordan Crouse wrote:
>
> This is off topic slightly, but let it be known that the coreboot project
> considers OFW a very valid option for x86 platforms. A kernel that
> worked happily with OFW would greatly encourage people to adopt it in
> lieu of other BIOS / firmware solutions.
>
> I return you to your previously scheduled debate.
>
The interface they are proposing is definitely not suitable for upward
extension, for the reasons already mentioned. However, they have units
in the field, and the amount of changes required to support another
interface should be relatively minor.
Hence my insistence that we don't promote it as *the* OFW interface, but
*a* OFW interface.
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-21 14:56 ` 2.6.25-mm1 Jordan Crouse
@ 2008-04-21 15:05 ` Andres Salomon
2008-04-21 15:12 ` 2.6.25-mm1 Jordan Crouse
0 siblings, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-21 15:05 UTC (permalink / raw)
To: Jordan Crouse; +Cc: Andrew Morton, jfannin, linux-kernel, mingo
On Mon, 21 Apr 2008 08:56:19 -0600
Jordan Crouse <jordan.crouse@amd.com> wrote:
> On 19/04/08 13:50 -0400, Andres Salomon wrote:
> > On Sat, 19 Apr 2008 10:38:33 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@queued.net> wrote:
> > > > On Fri, 18 Apr 2008 20:29:25 -0700
> > > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > > >
> > > > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> > > > >
> > > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > [...]
> > > > >
> > > > > which we probably just shouldn't do this at all unless we're running on the
> > > > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
> > > > > hardware! Perhaps the warning should just be removed.
> > > >
> > > > Hm. We could either protect that code with an:
> > > >
> > > > if (!is_geode())
> > > > return;
> > > >
> > > > Or I could add the OpenFirmware patches which would allow us to get
> > > > rid of this code, and instead check for the existence of OFW using
> > > > that.
> > > >
> > > > The former is quick and easy; the latter is (imo) nicer, so long as
> > > > people don't have problems w/ the OFW code. :)
> > > >
> > >
> > > Do both ;)
> > >
> > > The quick-n-easy version sounds suitable for now.
> >
> > Heh, I already had sent the nicer version. If people have some fundamental
> > problem w/ it, I can send the quick-n-easy version.
>
> I prefer the nicer version. It is not a good policy IMHO to wrap OLPC
> specfic code with is_geode() and friends. Even by Geode standards, we've
> abused the code greatly for the benefit of the Geode, and few of those
> abuses would translate very well even to the general Geode community. I
> would prefer that we use the is_olpc() and #ifdef wrappers to ensure
> that the code that is exclusively OLPC stays exclusively OLPC.
>
> Thanks,
> Jordan
>
Yeah, like I said; the nicer version is the _correct_ way to do things. I
just fear that the OFW code isn't ready for merging (see hpa's concerns).
The code is already #ifdef'd (the original reporter had enabled
CONFIG_OLPC), and the code in question is what determines what is_olpc()
should return. is_geode() is just to narrow the scope of what hardware
the check runs on.
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: OLPC: Add support for calling into Open Firmware
2008-04-21 3:39 ` Mitch Bradley
2008-04-21 4:54 ` Yinghai Lu
2008-04-21 11:36 ` H. Peter Anvin
@ 2008-04-21 15:05 ` Jordan Crouse
2008-04-21 14:58 ` H. Peter Anvin
2 siblings, 1 reply; 109+ messages in thread
From: Jordan Crouse @ 2008-04-21 15:05 UTC (permalink / raw)
To: Mitch Bradley
Cc: H. Peter Anvin, Andres Salomon, Yinghai Lu, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel
On 20/04/08 17:39 -1000, Mitch Bradley wrote:
> H. Peter Anvin wrote:
>> Mitch Bradley wrote:
>>>
>>> The x86 architecture doesn't make this problem easy.
>>>
>>
>> [long rant about the x86 architecture]
>>
>> It would be more useful if you described the actual defined entry
>> conditions from OpenFirmware look like, including if they are well-defined
>> for all OF implementations or only for OLPC.
>>
>> -hpa
>
> Fair enough...
>
> To get the second subquestion out of the way: At the present time, on the
> x86 architecture, "all OF implementations" and "OLPC" are effectively the
> same. I am unaware of any other x86 OFW deployments in current use. There
> have been some in the past, on bespoke systems such as Network Appliance
> servers and at least one settop box, but those have fallen by the wayside
> as those companies have shifted over to commodity PC hardware. The current
> market status quo is that x86 boards are primarily designed for Windows,
> and thus must run legacy BIOS, with some recent migration to EFI, neither
> of which are open source in the strong sense. While I would like to see
> more OFW penetration into the larger x86 market, I don't really expect it.
> x86 motherboard manufacturing is becoming more and more difficult as signal
> speeds increase, leading to a decline in the number of manufacturers. The
> existing manufacturers depend on Windows for sales volume and their
> internal procedures and working knowledge are based on legacy BIOS.
/me puts on his coreboot hat
This is off topic slightly, but let it be known that the coreboot project
considers OFW a very valid option for x86 platforms. A kernel that
worked happily with OFW would greatly encourage people to adopt it in
lieu of other BIOS / firmware solutions.
I return you to your previously scheduled debate.
Jordan
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-18 14:49 ` Reuben Farrelly
@ 2008-04-21 15:06 ` Ingo Molnar
2008-04-22 1:48 ` Arjan van de Ven
0 siblings, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2008-04-21 15:06 UTC (permalink / raw)
To: Reuben Farrelly; +Cc: Andrew Morton, linux-kernel, Arjan van de Ven
* Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
>> hm, does it boot up fine with the attached patch and stackprotector
>> enabled? It appears that your system got to the self-test so
>> stackprotector is working mostly - it's just that the self-test went
>> wrong.
>
> It boots up fine with that patch below and:
>
> tornado boot # grep STACKPROTECT /boot/config-2.6.25-mm1-wip
> CONFIG_CC_STACKPROTECTOR_ALL=y
> CONFIG_CC_STACKPROTECTOR=y
>
> In fact I'm running with it applied right now and it all seems good so
> far, so I guess that's confirmation that it is just the test itself
> which is problematic?
yeah. Arjan - any new patches to try that might fix the bootup test?
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-21 15:05 ` 2.6.25-mm1 Andres Salomon
@ 2008-04-21 15:12 ` Jordan Crouse
0 siblings, 0 replies; 109+ messages in thread
From: Jordan Crouse @ 2008-04-21 15:12 UTC (permalink / raw)
To: Andres Salomon; +Cc: Andrew Morton, jfannin, linux-kernel, mingo
On 21/04/08 11:05 -0400, Andres Salomon wrote:
> On Mon, 21 Apr 2008 08:56:19 -0600
> Jordan Crouse <jordan.crouse@amd.com> wrote:
>
> > On 19/04/08 13:50 -0400, Andres Salomon wrote:
> > > On Sat, 19 Apr 2008 10:38:33 -0700
> > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > > > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon <dilinger@queued.net> wrote:
> > > > > On Fri, 18 Apr 2008 20:29:25 -0700
> > > > > Andrew Morton <akpm@linux-foundation.org> wrote:
> > > > >
> > > > > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
> > > > > >
> > > > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
> > > [...]
> > > > > >
> > > > > > which we probably just shouldn't do this at all unless we're running on the
> > > > > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
> > > > > > hardware! Perhaps the warning should just be removed.
> > > > >
> > > > > Hm. We could either protect that code with an:
> > > > >
> > > > > if (!is_geode())
> > > > > return;
> > > > >
> > > > > Or I could add the OpenFirmware patches which would allow us to get
> > > > > rid of this code, and instead check for the existence of OFW using
> > > > > that.
> > > > >
> > > > > The former is quick and easy; the latter is (imo) nicer, so long as
> > > > > people don't have problems w/ the OFW code. :)
> > > > >
> > > >
> > > > Do both ;)
> > > >
> > > > The quick-n-easy version sounds suitable for now.
> > >
> > > Heh, I already had sent the nicer version. If people have some fundamental
> > > problem w/ it, I can send the quick-n-easy version.
> >
> > I prefer the nicer version. It is not a good policy IMHO to wrap OLPC
> > specfic code with is_geode() and friends. Even by Geode standards, we've
> > abused the code greatly for the benefit of the Geode, and few of those
> > abuses would translate very well even to the general Geode community. I
> > would prefer that we use the is_olpc() and #ifdef wrappers to ensure
> > that the code that is exclusively OLPC stays exclusively OLPC.
> >
> > Thanks,
> > Jordan
> >
>
> Yeah, like I said; the nicer version is the _correct_ way to do things. I
> just fear that the OFW code isn't ready for merging (see hpa's concerns).
>
> The code is already #ifdef'd (the original reporter had enabled
> CONFIG_OLPC), and the code in question is what determines what is_olpc()
> should return. is_geode() is just to narrow the scope of what hardware
> the check runs on.
My bad, I missed the key points. This still is dangerous on a generic
Geode, but at least if they encounter the problem, we can loudly proclaim
"Don't do that".
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 14:24 ` Andres Salomon
@ 2008-04-21 15:54 ` David Woodhouse
2008-04-21 16:57 ` H. Peter Anvin
2008-04-21 17:03 ` Andres Salomon
0 siblings, 2 replies; 109+ messages in thread
From: David Woodhouse @ 2008-04-21 15:54 UTC (permalink / raw)
To: Andres Salomon
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 2008-04-21 at 10:24 -0400, Andres Salomon wrote:
> I'm not actually convinced that we *do* want to keep OFW resident in memory,
> especially given the memory tricks we need to play. I also don't actually
> like the OFW interface that we. The debugging aspect of it was a
> compelling argument up until a week ago (when kernel debuggers started
> finally finding their way into the kernel).
I don't actually think that the debugging aspect was _ever_ a compelling
argument. It might have made it theoretically possible for _Mitch_ to
debug kernel problems, should he be inclined to do so -- but for the
rest of us mere mortals it's just a PITA trying to keep OpenFirmware
live. A gdb stub is much more useful, in my experience.
> However, until we clean up the promfs stuff, there's no chance of getting
> an OFW device tree upstream.
I see no reason why we shouldn't be able to create a 'flattened'
device-tree during early boot, like the PowerPC kernel does. And use it
thereafter, having quiesced OpenFirmware. Haven't we already been
working on unifying this between SPARC and PowerPC kernels?
I definitely don't think we need to play these tricks to keep
OpenFirmware resident while the kernel is running. Take a look at your
second patch -- it's _all_ just lookups in the device-tree, and you're
inventing a new way to do it instead of using the existing one.
--
dwmw2
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 15:54 ` David Woodhouse
@ 2008-04-21 16:57 ` H. Peter Anvin
2008-04-21 18:54 ` David Woodhouse
2008-04-21 17:03 ` Andres Salomon
1 sibling, 1 reply; 109+ messages in thread
From: H. Peter Anvin @ 2008-04-21 16:57 UTC (permalink / raw)
To: David Woodhouse
Cc: Andres Salomon, Mitch Bradley, Yinghai Lu, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
David Woodhouse wrote:
>
>> However, until we clean up the promfs stuff, there's no chance of getting
>> an OFW device tree upstream.
>
> I see no reason why we shouldn't be able to create a 'flattened'
> device-tree during early boot, like the PowerPC kernel does. And use it
> thereafter, having quiesced OpenFirmware. Haven't we already been
> working on unifying this between SPARC and PowerPC kernels?
>
> I definitely don't think we need to play these tricks to keep
> OpenFirmware resident while the kernel is running. Take a look at your
> second patch -- it's _all_ just lookups in the device-tree, and you're
> inventing a new way to do it instead of using the existing one.
>
If so, would this apply to OLPC as well?
-hpa
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 15:54 ` David Woodhouse
2008-04-21 16:57 ` H. Peter Anvin
@ 2008-04-21 17:03 ` Andres Salomon
2008-04-21 19:18 ` David Woodhouse
1 sibling, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-21 17:03 UTC (permalink / raw)
To: David Woodhouse
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 21 Apr 2008 16:54:13 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2008-04-21 at 10:24 -0400, Andres Salomon wrote:
> > I'm not actually convinced that we *do* want to keep OFW resident in memory,
> > especially given the memory tricks we need to play. I also don't actually
> > like the OFW interface that we. The debugging aspect of it was a
> > compelling argument up until a week ago (when kernel debuggers started
> > finally finding their way into the kernel).
>
> I don't actually think that the debugging aspect was _ever_ a compelling
> argument. It might have made it theoretically possible for _Mitch_ to
> debug kernel problems, should he be inclined to do so -- but for the
> rest of us mere mortals it's just a PITA trying to keep OpenFirmware
> live. A gdb stub is much more useful, in my experience.
>
> > However, until we clean up the promfs stuff, there's no chance of getting
> > an OFW device tree upstream.
>
> I see no reason why we shouldn't be able to create a 'flattened'b
> device-tree during early boot, like the PowerPC kernel does. And use it
> thereafter, having quiesced OpenFirmware. Haven't we already been
> working on unifying this between SPARC and PowerPC kernels?
Quite simply, it's a lot more work (*and* we have to play nice w/
sparc and ppc). I had intended to eventually do it, but first I wanted
to get this stuff in for 2.6.26 so that we could at least boot upstream
kernels on XOs.
I was also hoping to not get into this conversation, but alas.. too
late. :)
>
> I definitely don't think we need to play these tricks to keep
> OpenFirmware resident while the kernel is running. Take a look at your
> second patch -- it's _all_ just lookups in the device-tree, and you're
> inventing a new way to do it instead of using the existing one.
>
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: fault in __d_lookup [Was: 2.6.25-mm1]
2008-04-21 9:59 ` Jiri Slaby
2008-04-21 13:42 ` Rafael J. Wysocki
@ 2008-04-21 17:23 ` Matthew Wilcox
1 sibling, 0 replies; 109+ messages in thread
From: Matthew Wilcox @ 2008-04-21 17:23 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Al Viro, Andrew Morton, linux-kernel, linux-fsdevel
On Mon, Apr 21, 2008 at 11:59:51AM +0200, Jiri Slaby wrote:
> On 04/21/2008 11:45 AM, Al Viro wrote:
> >Well, if list has such turd in it, you'll certainly hit it every time
> >you walk that list, so 100% reproducible is not surprising.
> >
> >How well is it reproducible from fresh boot?
>
> Few days with suspend/resume cycles. This one was booted 12 hours ago, one
> suspend/resume. Will keep an eye on it and keep you informed.
Shall we see if we can catch it earlier? I have no idea if this will
help ... I haven't even booted it on a testmachine yet ;-) If I got
something wrong, it'll BUG() pretty early.
diff --git a/include/linux/list.h b/include/linux/list.h
index 75ce2cb..238ca1e 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -724,10 +724,17 @@ static inline int hlist_empty(const struct hlist_head *h)
return !h->first;
}
+#ifdef CONFIG_DEBUG_LIST
+extern void hlist_check(struct hlist_node *n);
+#else
+#define hlist_check(n) do { } while (0)
+#endif
+
static inline void __hlist_del(struct hlist_node *n)
{
struct hlist_node *next = n->next;
struct hlist_node **pprev = n->pprev;
+ hlist_check(n);
*pprev = next;
if (next)
next->pprev = pprev;
@@ -785,6 +792,7 @@ static inline void hlist_replace_rcu(struct hlist_node *old,
{
struct hlist_node *next = old->next;
+ hlist_check(old);
new->next = next;
new->pprev = old->pprev;
smp_wmb();
@@ -840,6 +848,7 @@ static inline void hlist_add_head_rcu(struct hlist_node *n,
static inline void hlist_add_before(struct hlist_node *n,
struct hlist_node *next)
{
+ hlist_check(next);
n->pprev = next->pprev;
n->next = next;
next->pprev = &n->next;
@@ -849,6 +858,7 @@ static inline void hlist_add_before(struct hlist_node *n,
static inline void hlist_add_after(struct hlist_node *n,
struct hlist_node *next)
{
+ hlist_check(next);
next->next = n->next;
n->next = next;
next->pprev = &n->next;
@@ -878,6 +888,7 @@ static inline void hlist_add_after(struct hlist_node *n,
static inline void hlist_add_before_rcu(struct hlist_node *n,
struct hlist_node *next)
{
+ hlist_check(next);
n->pprev = next->pprev;
n->next = next;
smp_wmb();
@@ -906,6 +917,7 @@ static inline void hlist_add_before_rcu(struct hlist_node *n,
static inline void hlist_add_after_rcu(struct hlist_node *prev,
struct hlist_node *n)
{
+ hlist_check(prev);
n->next = prev->next;
n->pprev = &prev->next;
smp_wmb();
diff --git a/lib/list_debug.c b/lib/list_debug.c
index 4350ba9..00b56bf 100644
--- a/lib/list_debug.c
+++ b/lib/list_debug.c
@@ -1,5 +1,8 @@
/*
* Copyright 2006, Red Hat, Inc., Dave Jones
+ * Copyright 2008 Intel Corporation
+ * Author: Matthew Wilcox <willy@linux.intel.com>
+ *
* Released under the General Public License (GPL).
*
* This file contains the linked list implementations for
@@ -76,3 +79,18 @@ void list_del(struct list_head *entry)
entry->prev = LIST_POISON2;
}
EXPORT_SYMBOL(list_del);
+
+void hlist_check(struct hlist_node *n)
+{
+ if (unlikely(*n->pprev != n)) {
+ printk(KERN_ERR "hlist corruption. *pprev should be %p, "
+ "but was %p\n", n, *n->pprev);
+ BUG();
+ }
+ if (unlikely(n->next != NULL && n->next->pprev != &n->next)) {
+ printk(KERN_ERR "hlist corruption. n->next->pprev should be"
+ "%p, but was %p\n", &n->next, n->next->pprev);
+ BUG();
+ }
+}
+EXPORT_SYMBOL(hlist_check);
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply related [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp causes driver conflict)
2008-04-21 11:07 ` 2.6.25-mm1 Takashi Iwai
@ 2008-04-21 17:44 ` Stas Sergeev
2008-04-22 10:09 ` Takashi Iwai
2008-04-21 19:45 ` 2.6.25-mm1 Stas Sergeev
1 sibling, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-21 17:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Takashi Iwai, Dmitry Torokhov, Joseph Fannin, linux-kernel,
Greg KH, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]
Hello.
Takashi Iwai wrote:
> [Added snd-pcsp author to Cc]
Thanks.
> Seems that snd-pcsp registers as "pcspkr", which is identical with
> input pc-speaker driver. Does the patch below fix the problem?
Actually it does not. The reason is that
then it fails to match the platform device,
which is created in arch/x86/kernel/pcspeaker.c,
with the name of "pcspkr".
But we already had the patch for that in an
alsa tree, it probably got forgotten. Here
it is:
http://hg-mirror.alsa-project.org/alsa-driver/raw-file/90eeee75052f/utils/patches/pcsp-kernel-2.6.22-01.diff
Also attaching it here.
It simply disables the pcspkr driver in
Kconfig. snd-pcsp has the copy of that
driver, so that only one driver would
drive the device.
Does that fix look good? (presumably acked
by Takashi, otherwise the patch wouldn't
be in an alsa tree)
---------------
- Prevent pcspkr driver from being built
together with snd-pcsp. snd-pcsp fully
superceeds pcspkr.
- Update CREDITS file. :)
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
Acked-by: Takashi Iwai <tiwai@suse.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pcsp-kernel-2.6.24-01.diff --]
[-- Type: text/x-patch; name="pcsp-kernel-2.6.24-01.diff", Size: 1248 bytes --]
diff -urN linux-2.6.24/CREDITS linux-2.6.24-pcsp-kern/CREDITS
--- linux-2.6.24/CREDITS 2008-01-27 16:13:20.000000000 +0300
+++ linux-2.6.24-pcsp-kern/CREDITS 2008-01-27 17:03:31.000000000 +0300
@@ -403,6 +403,8 @@
N: Erik Inge Bolsø
E: knan@mo.himolde.no
D: Misc kernel hacks
+D: Updated PC speaker driver for 2.3
+S: Norway
N: Andreas E. Bombe
E: andreas.bombe@munich.netsurf.de
@@ -3109,6 +3111,12 @@
S: Sunnyvale, California 94088-4132
S: USA
+N: Stas Sergeev
+E: stsp@users.sourceforge.net
+D: PCM PC-Speaker driver
+D: misc fixes
+S: Russia
+
N: Simon Shapiro
E: shimon@i-Connect.Net
W: http://www.-i-Connect.Net/~shimon
diff -urN linux-2.6.24/drivers/input/misc/Kconfig linux-2.6.24-pcsp-kern/drivers/input/misc/Kconfig
--- linux-2.6.24/drivers/input/misc/Kconfig 2008-01-27 16:13:43.000000000 +0300
+++ linux-2.6.24-pcsp-kern/drivers/input/misc/Kconfig 2008-01-27 17:03:31.000000000 +0300
@@ -14,7 +14,8 @@
config INPUT_PCSPKR
tristate "PC Speaker support"
- depends on ALPHA || X86 || MIPS || PPC_PREP || PPC_CHRP || PPC_PSERIES
+ depends on (ALPHA || X86 || MIPS || PPC_PREP || PPC_CHRP || \
+ PPC_PSERIES) && SND_PCSP=n
help
Say Y here if you want the standard PC Speaker to be used for
bells and whistles.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-21 14:06 ` 2.6.25-mm1 Takashi Iwai
@ 2008-04-21 17:55 ` Stas Sergeev
2008-04-22 10:13 ` Takashi Iwai
0 siblings, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-21 17:55 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Andrew Morton, Dmitry Torokhov, Joseph Fannin, linux-kernel
Hello.
Takashi Iwai wrote:
>> CONFIG_DEBUG_PAGEALLOC is a very heavy consumer of CPU cycles. I'm not
>> surprised that it would whack what I presume to be a very latency-sensitive
>> driver.
> We can add simply a dependncy to Kconfig if this really matters.
I think this is a bit too heavy-handed.
That thing adds a lot of noise to the sound,
but it doesn't really prevent the driver from
working properly. And perhaps there are
other options with the same effect?
Also, that would motivate people to
optimize DEBUG_PAGEALLOC, while otherwise
they wouldn't know. :)
What is the problem with the warning
exactly? If it makes problems, we can
just remove it and update the help text
instead, for example.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 16:57 ` H. Peter Anvin
@ 2008-04-21 18:54 ` David Woodhouse
0 siblings, 0 replies; 109+ messages in thread
From: David Woodhouse @ 2008-04-21 18:54 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Andres Salomon, Mitch Bradley, Yinghai Lu, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 2008-04-21 at 12:57 -0400, H. Peter Anvin wrote:
> David Woodhouse wrote:
> >
> >> However, until we clean up the promfs stuff, there's no chance of getting
> >> an OFW device tree upstream.
> >
> > I see no reason why we shouldn't be able to create a 'flattened'
> > device-tree during early boot, like the PowerPC kernel does. And use it
> > thereafter, having quiesced OpenFirmware. Haven't we already been
> > working on unifying this between SPARC and PowerPC kernels?
> >
> > I definitely don't think we need to play these tricks to keep
> > OpenFirmware resident while the kernel is running. Take a look at your
> > second patch -- it's _all_ just lookups in the device-tree, and you're
> > inventing a new way to do it instead of using the existing one.
> >
>
> If so, would this apply to OLPC as well?
Yes. The 'second patch' to which I refer is the one which makes OLPC
platform code use the calls in OpenFirmware... all of them gratuitous.
--
dwmw2
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 17:03 ` Andres Salomon
@ 2008-04-21 19:18 ` David Woodhouse
2008-04-21 19:46 ` Andres Salomon
0 siblings, 1 reply; 109+ messages in thread
From: David Woodhouse @ 2008-04-21 19:18 UTC (permalink / raw)
To: Andres Salomon
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 2008-04-21 at 13:03 -0400, Andres Salomon wrote:
> Quite simply, it's a lot more work (*and* we have to play nice w/
> sparc and ppc).
It's only more work because we did it the wrong way in the first place.
If only someone had pointed it out at the time... :)
For interaction with device-tree properties in generic code, you should
be using the functions defined in <linux/of.h>.
Creating the static device-tree before we quiesce OpenFirmware surely
shouldn't be so hard? Can't we cut and paste most of that code anyway?
> I had intended to eventually do it, but first I wanted
> to get this stuff in for 2.6.26 so that we could at least boot upstream
> kernels on XOs.
Is it only the things in your second patch which need to be made to
work? One of them was already working, by grubbing around in the BIOS
directly -- so all we need is the board revision, isn't it? Can we get
that from the EC for now?
--
dwmw2
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1
2008-04-21 11:07 ` 2.6.25-mm1 Takashi Iwai
2008-04-21 17:44 ` 2.6.25-mm1 (snd-pcsp causes driver conflict) Stas Sergeev
@ 2008-04-21 19:45 ` Stas Sergeev
1 sibling, 0 replies; 109+ messages in thread
From: Stas Sergeev @ 2008-04-21 19:45 UTC (permalink / raw)
To: Joseph Fannin; +Cc: Andrew Morton, Dmitry Torokhov, linux-kernel
Hi.
On Fri, 18 Apr 2008 22:13:43 -0400 Joseph Fannin <jfannin@gmail.com> wrote:
>>>>
>>>>> On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
>>>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25/2.6.25-mm1/
>>>>> I've been seeing the following backtraces since 2.6.25-rc8-mm1 -- at
>>>>> least, since that's the earliest -mm I've built in a while. I don't
>>>>> get the same in mainline.
As a quick workaround, say N to INPUT_PCSPKR:
│ Prompt: PC Speaker support
│ Location:
│ -> Device Drivers
│ -> Input device support
│ -> Generic input layer (needed for keyboard, mouse, ...)
(INPUT │
│ -> Miscellaneous devices (INPUT_MISC [=y])
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 19:18 ` David Woodhouse
@ 2008-04-21 19:46 ` Andres Salomon
2008-04-21 20:25 ` David Woodhouse
0 siblings, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-21 19:46 UTC (permalink / raw)
To: David Woodhouse
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 21 Apr 2008 20:18:11 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2008-04-21 at 13:03 -0400, Andres Salomon wrote:
> > Quite simply, it's a lot more work (*and* we have to play nice w/
> > sparc and ppc).
>
> It's only more work because we did it the wrong way in the first place.
> If only someone had pointed it out at the time... :)
>
Yes, and if only we had an infinite number of kernel hackers who had time
to work on such things, then we could've done things differently.
> For interaction with device-tree properties in generic code, you should
> be using the functions defined in <linux/of.h>.
>
At the time [the OFW interface] was written, linux/of.h didn't *exist*.
> Creating the static device-tree before we quiesce OpenFirmware surely
> shouldn't be so hard? Can't we cut and paste most of that code anyway?
>
We're not adding a device tree right now, we're adding a method for
querying OFW for information. Eventually that information should be
obtained from a device tree. However, that's going to take additional time,
and I'd like to get rid of some of these patches that we've been carrying
around.
> > I had intended to eventually do it, but first I wanted
> > to get this stuff in for 2.6.26 so that we could at least boot upstream
> > kernels on XOs.
>
> Is it only the things in your second patch which need to be made to
> work? One of them was already working, by grubbing around in the BIOS
> directly -- so all we need is the board revision, isn't it? Can we get
> that from the EC for now?
>
Well, no, it wasn't already working; that's the reason this whole
thread started. It was crashing someone's machine. That's why the OFW
interface, as imperfect as it is, is an _improvement_.
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
2008-04-21 19:46 ` Andres Salomon
@ 2008-04-21 20:25 ` David Woodhouse
2008-04-21 21:02 ` [PATCH] OLPC: only check for OFW signature on VSA-less Geodes Andres Salomon
0 siblings, 1 reply; 109+ messages in thread
From: David Woodhouse @ 2008-04-21 20:25 UTC (permalink / raw)
To: Andres Salomon
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 2008-04-21 at 15:46 -0400, Andres Salomon wrote:
> Well, no, it wasn't already working; that's the reason this whole
> thread started. It was crashing someone's machine. That's why the OFW
> interface, as imperfect as it is, is an _improvement_.
You're proposing a new interface between bootloader and kernel as a
temporary hack just to work around that until we fix it properly?
That seems like overkill to me. I'd just go for is_geode() as you
suggested, and maybe PCI configuration tricks to detect the lack of VSA
so we can be _fairly_ sure it's OLPC before we poke at it?
Or why not try '!page_is_ram(0xffffffc0 >> PAGE_SHIFT)' if it's just to
avoid that particular warning? :)
--
dwmw2
^ permalink raw reply [flat|nested] 109+ messages in thread
* [PATCH] OLPC: only check for OFW signature on VSA-less Geodes
2008-04-21 20:25 ` David Woodhouse
@ 2008-04-21 21:02 ` Andres Salomon
2008-04-21 21:17 ` Jordan Crouse
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Andres Salomon @ 2008-04-21 21:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 21 Apr 2008 21:25:17 +0100
David Woodhouse <dwmw2@infradead.org> wrote:
> On Mon, 2008-04-21 at 15:46 -0400, Andres Salomon wrote:
> > Well, no, it wasn't already working; that's the reason this whole
> > thread started. It was crashing someone's machine. That's why the OFW
> > interface, as imperfect as it is, is an _improvement_.
>
> You're proposing a new interface between bootloader and kernel as a
> temporary hack just to work around that until we fix it properly?
>
> That seems like overkill to me. I'd just go for is_geode() as you
> suggested, and maybe PCI configuration tricks to detect the lack of VSA
> so we can be _fairly_ sure it's OLPC before we poke at it?
>
> Or why not try '!page_is_ram(0xffffffc0 >> PAGE_SHIFT)' if it's just to
> avoid that particular warning? :)
>
Okay, does anyone have a problem with this?
The OFW sig check requires an ioremap that is dangerous on non-OLPC
systems. Long term, we should be getting the signature from the
device tree (/openprom/model), but for right now just limit the
check to only run on a subset of Geode (GX2/LX) systems.
Signed-off-by: Andres Salomon <dilinger@debian.org>
---
arch/x86/kernel/olpc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/olpc.c b/arch/x86/kernel/olpc.c
index 11670be..3e66722 100644
--- a/arch/x86/kernel/olpc.c
+++ b/arch/x86/kernel/olpc.c
@@ -211,6 +211,10 @@ static int __init olpc_init(void)
{
unsigned char *romsig;
+ /* The ioremap check is dangerous; limit what we run it on */
+ if (!is_geode() || geode_has_vsa2())
+ return 0;
+
spin_lock_init(&ec_lock);
romsig = ioremap(0xffffffc0, 16);
--
1.5.4.4
--
Need a kernel or Debian developer? Contact me, I'm looking for contracts.
^ permalink raw reply related [flat|nested] 109+ messages in thread
* Re: OLPC: only check for OFW signature on VSA-less Geodes
2008-04-21 21:02 ` [PATCH] OLPC: only check for OFW signature on VSA-less Geodes Andres Salomon
@ 2008-04-21 21:17 ` Jordan Crouse
2008-04-21 21:17 ` [PATCH] " David Woodhouse
2008-04-29 3:06 ` Andrew Morton
2 siblings, 0 replies; 109+ messages in thread
From: Jordan Crouse @ 2008-04-21 21:17 UTC (permalink / raw)
To: Andres Salomon
Cc: David Woodhouse, Mitch Bradley, Yinghai Lu, H. Peter Anvin,
Eric W. Biederman, Ingo Molnar, Andrew Morton, Joseph Fannin,
linux-kernel
On 21/04/08 17:02 -0400, Andres Salomon wrote:
> On Mon, 21 Apr 2008 21:25:17 +0100
> David Woodhouse <dwmw2@infradead.org> wrote:
>
> > On Mon, 2008-04-21 at 15:46 -0400, Andres Salomon wrote:
> > > Well, no, it wasn't already working; that's the reason this whole
> > > thread started. It was crashing someone's machine. That's why the OFW
> > > interface, as imperfect as it is, is an _improvement_.
> >
> > You're proposing a new interface between bootloader and kernel as a
> > temporary hack just to work around that until we fix it properly?
> >
> > That seems like overkill to me. I'd just go for is_geode() as you
> > suggested, and maybe PCI configuration tricks to detect the lack of VSA
> > so we can be _fairly_ sure it's OLPC before we poke at it?
> >
> > Or why not try '!page_is_ram(0xffffffc0 >> PAGE_SHIFT)' if it's just to
> > avoid that particular warning? :)
> >
>
>
> Okay, does anyone have a problem with this?
>
>
>
>
>
>
> The OFW sig check requires an ioremap that is dangerous on non-OLPC
> systems. Long term, we should be getting the signature from the
> device tree (/openprom/model), but for right now just limit the
> check to only run on a subset of Geode (GX2/LX) systems.
>
> Signed-off-by: Andres Salomon <dilinger@debian.org>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
> diff --git a/arch/x86/kernel/olpc.c b/arch/x86/kernel/olpc.c
> index 11670be..3e66722 100644
> --- a/arch/x86/kernel/olpc.c
> +++ b/arch/x86/kernel/olpc.c
> @@ -211,6 +211,10 @@ static int __init olpc_init(void)
> {
> unsigned char *romsig;
>
> + /* The ioremap check is dangerous; limit what we run it on */
> + if (!is_geode() || geode_has_vsa2())
> + return 0;
> +
> spin_lock_init(&ec_lock);
>
> romsig = ioremap(0xffffffc0, 16);
> --
> 1.5.4.4
>
>
> --
> Need a kernel or Debian developer? Contact me, I'm looking for contracts.
>
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH] OLPC: only check for OFW signature on VSA-less Geodes
2008-04-21 21:02 ` [PATCH] OLPC: only check for OFW signature on VSA-less Geodes Andres Salomon
2008-04-21 21:17 ` Jordan Crouse
@ 2008-04-21 21:17 ` David Woodhouse
2008-04-29 3:06 ` Andrew Morton
2 siblings, 0 replies; 109+ messages in thread
From: David Woodhouse @ 2008-04-21 21:17 UTC (permalink / raw)
To: Andres Salomon
Cc: Mitch Bradley, Yinghai Lu, H. Peter Anvin, Eric W. Biederman,
Ingo Molnar, Andrew Morton, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 2008-04-21 at 17:02 -0400, Andres Salomon wrote:
> The OFW sig check requires an ioremap that is dangerous on non-OLPC
> systems. Long term, we should be getting the signature from the
> device tree (/openprom/model), but for right now just limit the
> check to only run on a subset of Geode (GX2/LX) systems.
That looks saner to me for now.
Acked-By: David Woodhouse <dwmw2@infradead.org>
--
dwmw2
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-21 15:06 ` Ingo Molnar
@ 2008-04-22 1:48 ` Arjan van de Ven
2008-04-22 2:04 ` Valdis.Kletnieks
2008-04-22 8:34 ` Ingo Molnar
0 siblings, 2 replies; 109+ messages in thread
From: Arjan van de Ven @ 2008-04-22 1:48 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Reuben Farrelly, Andrew Morton, linux-kernel
On Mon, 21 Apr 2008 17:06:04 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Reuben Farrelly <reuben-linuxkernel@reub.net> wrote:
>
> >> hm, does it boot up fine with the attached patch and
> >> stackprotector enabled? It appears that your system got to the
> >> self-test so stackprotector is working mostly - it's just that the
> >> self-test went wrong.
> >
> > It boots up fine with that patch below and:
> >
> > tornado boot # grep STACKPROTECT /boot/config-2.6.25-mm1-wip
> > CONFIG_CC_STACKPROTECTOR_ALL=y
> > CONFIG_CC_STACKPROTECTOR=y
> >
> > In fact I'm running with it applied right now and it all seems good
> > so far, so I guess that's confirmation that it is just the test
> > itself which is problematic?
>
> yeah. Arjan - any new patches to try that might fix the bootup test?
>
I've looked at the disassembly and compared it to mine, and the gcc is doing
something... rather unexpected.
The only thing I can think of is the patch below, it should make it a ton
more robust...
From: Arjan van de Ven <arjan@linux.intel.com>
Subject: x86: be more conversative about the stack-protector test
This patch makes the stack-protector self-test more robust against
weird stack layouts; rather than assuming that a local variable is
layed out in a certain way, we first check this against the known
canary value (before we poison it).
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
diff --git a/kernel/panic.c b/kernel/panic.c
index c92c1e2..b4a6a05 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -351,7 +351,10 @@ static noinline void __stack_chk_test_func(void)
}
#endif
barrier();
- memset(&foo, 0, 2*sizeof(foo)); /* deliberate buffer overflow */
+ if (current->stack_canary == *(((unsigned long *)&foo)+1))
+ *(((unsigned long *)&foo)+1) = 0;
+ else
+ printk(KERN_ERR "No -ftack-protector canary found\n");
barrier();
}
^ permalink raw reply related [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-22 1:48 ` Arjan van de Ven
@ 2008-04-22 2:04 ` Valdis.Kletnieks
2008-04-22 8:34 ` Ingo Molnar
1 sibling, 0 replies; 109+ messages in thread
From: Valdis.Kletnieks @ 2008-04-22 2:04 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Ingo Molnar, Reuben Farrelly, Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
On Mon, 21 Apr 2008 18:48:59 PDT, Arjan van de Ven said:
Typo alert?
> diff --git a/kernel/panic.c b/kernel/panic.c
> index c92c1e2..b4a6a05 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -351,7 +351,10 @@ static noinline void __stack_chk_test_func(void)
> }
> #endif
> barrier();
> - memset(&foo, 0, 2*sizeof(foo)); /* deliberate buffer overflow */
> + if (current->stack_canary == *(((unsigned long *)&foo)+1))
> + *(((unsigned long *)&foo)+1) = 0;
> + else
> + printk(KERN_ERR "No -ftack-protector canary found\n");
-fstack?
> barrier();
> }
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-22 1:48 ` Arjan van de Ven
2008-04-22 2:04 ` Valdis.Kletnieks
@ 2008-04-22 8:34 ` Ingo Molnar
2008-04-22 14:29 ` Arjan van de Ven
1 sibling, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2008-04-22 8:34 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Reuben Farrelly, Andrew Morton, linux-kernel
* Arjan van de Ven <arjan@infradead.org> wrote:
> > yeah. Arjan - any new patches to try that might fix the bootup test?
>
> I've looked at the disassembly and compared it to mine, and the gcc is
> doing something... rather unexpected. The only thing I can think of is
> the patch below, it should make it a ton more robust...
> - memset(&foo, 0, 2*sizeof(foo)); /* deliberate buffer overflow */
> + if (current->stack_canary == *(((unsigned long *)&foo)+1))
> + *(((unsigned long *)&foo)+1) = 0;
> + else
> + printk(KERN_ERR "No -ftack-protector canary found\n");
ok, i queued this up. (with the typo that Valdis noticed fixed)
but ... this bug needs to be figured out, not worked around.
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp causes driver conflict)
2008-04-21 17:44 ` 2.6.25-mm1 (snd-pcsp causes driver conflict) Stas Sergeev
@ 2008-04-22 10:09 ` Takashi Iwai
2008-04-22 17:54 ` Stas Sergeev
0 siblings, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-04-22 10:09 UTC (permalink / raw)
To: Stas Sergeev
Cc: Andrew Morton, Dmitry Torokhov, Joseph Fannin, linux-kernel,
Greg KH, Kay Sievers
At Mon, 21 Apr 2008 21:44:33 +0400,
Stas Sergeev wrote:
>
> Hello.
>
> Takashi Iwai wrote:
> > [Added snd-pcsp author to Cc]
> Thanks.
>
> > Seems that snd-pcsp registers as "pcspkr", which is identical with
> > input pc-speaker driver. Does the patch below fix the problem?
> Actually it does not. The reason is that
> then it fails to match the platform device,
> which is created in arch/x86/kernel/pcspeaker.c,
> with the name of "pcspkr".
Hm, the hardcoded string is no good thing.
It should be defined in the common header if it's used in multiple
places.
I'm not 100% certain whether restrictng this in Kconfig is the correct
fix. Basically this doesn't stop building both drivers. In theory,
we can switch them dynamically.
But, it's the easiest way to avoid unnecessary bugs right now, so
let's merge it.
> But we already had the patch for that in an
> alsa tree, it probably got forgotten. Here
> it is:
> http://hg-mirror.alsa-project.org/alsa-driver/raw-file/90eeee75052f/utils/patches/pcsp-kernel-2.6.22-01.diff
Err, no, this wasn't merged to sound git tree because apparently the
patch is to 2.6.22 and you didn't resubmit it...
> Also attaching it here.
> It simply disables the pcspkr driver in
> Kconfig. snd-pcsp has the copy of that
> driver, so that only one driver would
> drive the device.
>
> Does that fix look good? (presumably acked
> by Takashi, otherwise the patch wouldn't
> be in an alsa tree)
No, I gave no ACK yet. The alsa-driver tree is our playground, and
the patch merged to that tree doesn't mean that I approved it for
linux-kernel merge.
> diff -urN linux-2.6.24/drivers/input/misc/Kconfig linux-2.6.24-pcsp-kern/drivers/input/misc/Kconfig
> --- linux-2.6.24/drivers/input/misc/Kconfig 2008-01-27 16:13:43.000000000 +0300
> +++ linux-2.6.24-pcsp-kern/drivers/input/misc/Kconfig 2008-01-27 17:03:31.000000000 +0300
> @@ -14,7 +14,8 @@
>
> config INPUT_PCSPKR
> tristate "PC Speaker support"
> - depends on ALPHA || X86 || MIPS || PPC_PREP || PPC_CHRP || PPC_PSERIES
> + depends on (ALPHA || X86 || MIPS || PPC_PREP || PPC_CHRP || \
> + PPC_PSERIES) && SND_PCSP=n
I'd rather add a new line with a single "depends on SND_PCSP=n".
You see a clear difference in the art of dependencies, one for
architectures and one for driver-specific.
thanks,
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-21 17:55 ` 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC) Stas Sergeev
@ 2008-04-22 10:13 ` Takashi Iwai
2008-04-22 14:01 ` Dmitry Torokhov
2008-04-22 18:31 ` Stas Sergeev
0 siblings, 2 replies; 109+ messages in thread
From: Takashi Iwai @ 2008-04-22 10:13 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Andrew Morton, Dmitry Torokhov, Joseph Fannin, linux-kernel
At Mon, 21 Apr 2008 21:55:27 +0400,
Stas Sergeev wrote:
>
> Hello.
>
> Takashi Iwai wrote:
> >> CONFIG_DEBUG_PAGEALLOC is a very heavy consumer of CPU cycles. I'm not
> >> surprised that it would whack what I presume to be a very latency-sensitive
> >> driver.
> > We can add simply a dependncy to Kconfig if this really matters.
> I think this is a bit too heavy-handed.
> That thing adds a lot of noise to the sound,
> but it doesn't really prevent the driver from
> working properly. And perhaps there are
> other options with the same effect?
> Also, that would motivate people to
> optimize DEBUG_PAGEALLOC, while otherwise
> they wouldn't know. :)
>
> What is the problem with the warning
> exactly? If it makes problems, we can
> just remove it and update the help text
> instead, for example.
It's no big problem but I just find the phrase "you have to
disable..." too strict. It's just a sound-quality problem as you
mentioned in the above.
BTW, I noticed that the message includes a few line breaks. You need
a proper KERN_ prefix for each line in such a case. A fix patch would
be appreciated.
thanks,
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-22 10:13 ` Takashi Iwai
@ 2008-04-22 14:01 ` Dmitry Torokhov
2008-04-22 16:42 ` Stas Sergeev
2008-04-22 18:31 ` Stas Sergeev
1 sibling, 1 reply; 109+ messages in thread
From: Dmitry Torokhov @ 2008-04-22 14:01 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Stas Sergeev, Andrew Morton, Joseph Fannin, linux-kernel
Hi, Takashi, Stas,
On Tue, Apr 22, 2008 at 12:13:48PM +0200, Takashi Iwai wrote:
>
> It's no big problem but I just find the phrase "you have to
> disable..." too strict. It's just a sound-quality problem as you
> mentioned in the above.
>
Just out of curiosity, what is the sound quality with the PC speaker?
Not to belittle Stas's effort, but how relevant is this driver for
mainline given that it os pretty much impossible nowadays to find a
motherboard without on-board sound?
--
Dmitry
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: StackProtector Oopses - Re: 2.6.25-mm1
2008-04-22 8:34 ` Ingo Molnar
@ 2008-04-22 14:29 ` Arjan van de Ven
0 siblings, 0 replies; 109+ messages in thread
From: Arjan van de Ven @ 2008-04-22 14:29 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Reuben Farrelly, Andrew Morton, linux-kernel
On Tue, 22 Apr 2008 10:34:08 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Arjan van de Ven <arjan@infradead.org> wrote:
>
> > > yeah. Arjan - any new patches to try that might fix the bootup
> > > test?
> >
> > I've looked at the disassembly and compared it to mine, and the gcc
> > is doing something... rather unexpected. The only thing I can think
> > of is the patch below, it should make it a ton more robust...
>
> > - memset(&foo, 0, 2*sizeof(foo)); /* deliberate buffer
> > overflow */
> > + if (current->stack_canary == *(((unsigned long *)&foo)+1))
> > + *(((unsigned long *)&foo)+1) = 0;
> > + else
> > + printk(KERN_ERR "No -ftack-protector canary
> > found\n");
>
> ok, i queued this up. (with the typo that Valdis noticed fixed)
>
> but ... this bug needs to be figured out, not worked around.
well what I figured out was that the stack layout was "different".
Why/how I don't know, but being more robust against that is a good idea
in general.
--
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-22 14:01 ` Dmitry Torokhov
@ 2008-04-22 16:42 ` Stas Sergeev
0 siblings, 0 replies; 109+ messages in thread
From: Stas Sergeev @ 2008-04-22 16:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel, Takashi Iwai
Hello.
Dmitry Torokhov wrote:
> Just out of curiosity, what is the sound quality with the PC speaker?
That depends on the speaker itself.
If it is large enough (not a piezo
tablet), then the sound probably
matches the telephone. :)
> Not to belittle Stas's effort, but how relevant is this driver for
> mainline given that it os pretty much impossible nowadays to find a
> motherboard without on-board sound?
I know it is used because people are
mailing me about it. Mainly on servers
I think, as on a desktop its value it
really questionable. :)
The real problem is that the board
manufacturers put the piezo beepers
these days, and also nvidia already
excluded the necessary capabilities
from their NForce chipset. So in the
future it may indeed became out of
the use.
By the way, you may be surprised, but
I am still being asked by various people
to write an LPT DAC (Covox) sound driver
(the ancient OSS-based pc-speaker driver
supported also that).
I guess people just like to use all
the hardware they have, even if it is
not really very usefull.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp causes driver conflict)
2008-04-22 10:09 ` Takashi Iwai
@ 2008-04-22 17:54 ` Stas Sergeev
2008-04-23 8:55 ` Takashi Iwai
0 siblings, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-22 17:54 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
Hello.
Takashi Iwai wrote:
> Err, no, this wasn't merged to sound git tree because apparently the
> patch is to 2.6.22 and you didn't resubmit it...
That's simply because the old one
applies fine. :)
> No, I gave no ACK yet.
OK, sorry.
> I'd rather add a new line with a single "depends on SND_PCSP=n".
> You see a clear difference in the art of dependencies, one for
> architectures and one for driver-specific.
Done.
---
- Update CREDITS with the pc-speaker
driver authors.
- Prevent pcspkr from being built together
with snd-pcsp.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pcsp-kernel-2.6.25-01.diff --]
[-- Type: text/x-patch; name="pcsp-kernel-2.6.25-01.diff", Size: 1174 bytes --]
diff -ur linux-2.6.25/CREDITS linux-2.6.25-pcsp-kern/CREDITS
--- linux-2.6.25/CREDITS 2008-02-16 22:37:23.000000000 +0300
+++ linux-2.6.25-pcsp-kern/CREDITS 2008-04-22 21:45:23.000000000 +0400
@@ -403,6 +403,8 @@
N: Erik Inge Bolsø
E: knan@mo.himolde.no
D: Misc kernel hacks
+D: Updated PC speaker driver for 2.3
+S: Norway
N: Andreas E. Bombe
E: andreas.bombe@munich.netsurf.de
@@ -3116,6 +3118,12 @@
S: Sunnyvale, California 94088-4132
S: USA
+N: Stas Sergeev
+E: stsp@users.sourceforge.net
+D: PCM PC-Speaker driver
+D: misc fixes
+S: Russia
+
N: Simon Shapiro
E: shimon@i-Connect.Net
W: http://www.-i-Connect.Net/~shimon
diff -ur linux-2.6.25/drivers/input/misc/Kconfig linux-2.6.25-pcsp-kern/drivers/input/misc/Kconfig
--- linux-2.6.25/drivers/input/misc/Kconfig 2008-04-22 20:50:41.000000000 +0400
+++ linux-2.6.25-pcsp-kern/drivers/input/misc/Kconfig 2008-04-22 21:45:23.000000000 +0400
@@ -15,6 +15,7 @@
config INPUT_PCSPKR
tristate "PC Speaker support"
depends on ALPHA || X86 || MIPS || PPC_PREP || PPC_CHRP || PPC_PSERIES
+ depends on SND_PCSP=n
help
Say Y here if you want the standard PC Speaker to be used for
bells and whistles.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-22 10:13 ` Takashi Iwai
2008-04-22 14:01 ` Dmitry Torokhov
@ 2008-04-22 18:31 ` Stas Sergeev
2008-04-23 8:49 ` Takashi Iwai
1 sibling, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-22 18:31 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 370 bytes --]
Hello.
Takashi Iwai wrote:
> It's no big problem but I just find the phrase "you have to
> disable..." too strict. It's just a sound-quality problem as you
> mentioned in the above.
> BTW, I noticed that the message includes a few line breaks. You need
> a proper KERN_ prefix for each line in such a case. A fix patch would
> be appreciated.
Like the attached one?
[-- Attachment #2: pcsp_wrn.diff --]
[-- Type: text/x-patch, Size: 1047 bytes --]
# HG changeset patch
# User Stas Sergeev <stsp@users.sourceforge.net>
# Date 1208888978 -14400
# Node ID 00c36aa3903d861198e8f57c46e75194f3e172d6
# Parent f8fbce7ba45922a73a9679d68c4a4b07ebef42de
pcsp: fix wording in DEBUG_PAGEALLOC warning.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
diff -r f8fbce7ba459 -r 00c36aa3903d drivers/pcsp/pcsp.c
--- a/drivers/pcsp/pcsp.c Tue Apr 22 18:39:49 2008 +0200
+++ b/drivers/pcsp/pcsp.c Tue Apr 22 22:29:38 2008 +0400
@@ -147,12 +147,8 @@ static int __devinit alsa_card_pcsp_init
#ifdef CONFIG_DEBUG_PAGEALLOC
/* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets alert */
- printk(KERN_WARNING
- "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
- "You have to disable it if you want to use the PC-Speaker "
- "driver.\n"
- "Unless it is disabled, enjoy the horrible, distorted "
- "and crackling noise.\n");
+ printk(KERN_WARNING "PCSP: CONFIG_DEBUG_PAGEALLOC is enabled, "
+ KERN_WARNING "which may make the sound noisy.\n");
#endif
return 0;
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-22 18:31 ` Stas Sergeev
@ 2008-04-23 8:49 ` Takashi Iwai
2008-04-23 14:18 ` Takashi Iwai
2008-04-23 20:02 ` Stas Sergeev
0 siblings, 2 replies; 109+ messages in thread
From: Takashi Iwai @ 2008-04-23 8:49 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
At Tue, 22 Apr 2008 22:31:01 +0400,
Stas Sergeev wrote:
>
> # HG changeset patch
> # User Stas Sergeev <stsp@users.sourceforge.net>
> # Date 1208888978 -14400
> # Node ID 00c36aa3903d861198e8f57c46e75194f3e172d6
> # Parent f8fbce7ba45922a73a9679d68c4a4b07ebef42de
> pcsp: fix wording in DEBUG_PAGEALLOC warning.
>
> Signed-off-by: Stas Sergeev <stsp@aknet.ru>
>
> diff -r f8fbce7ba459 -r 00c36aa3903d drivers/pcsp/pcsp.c
> --- a/drivers/pcsp/pcsp.c Tue Apr 22 18:39:49 2008 +0200
> +++ b/drivers/pcsp/pcsp.c Tue Apr 22 22:29:38 2008 +0400
> @@ -147,12 +147,8 @@ static int __devinit alsa_card_pcsp_init
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
> /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets alert */
> - printk(KERN_WARNING
> - "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
> - "You have to disable it if you want to use the PC-Speaker "
> - "driver.\n"
> - "Unless it is disabled, enjoy the horrible, distorted "
> - "and crackling noise.\n");
> + printk(KERN_WARNING "PCSP: CONFIG_DEBUG_PAGEALLOC is enabled, "
> + KERN_WARNING "which may make the sound noisy.\n");
Missing \n in the first line?
thanks,
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp causes driver conflict)
2008-04-22 17:54 ` Stas Sergeev
@ 2008-04-23 8:55 ` Takashi Iwai
2008-04-23 14:14 ` Takashi Iwai
0 siblings, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-04-23 8:55 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Andrew Morton, linux-kernel
At Tue, 22 Apr 2008 21:54:46 +0400,
Stas Sergeev wrote:
>
> Hello.
>
> Takashi Iwai wrote:
> > Err, no, this wasn't merged to sound git tree because apparently the
> > patch is to 2.6.22 and you didn't resubmit it...
> That's simply because the old one
> applies fine. :)
>
> > No, I gave no ACK yet.
> OK, sorry.
>
> > I'd rather add a new line with a single "depends on SND_PCSP=n".
> > You see a clear difference in the art of dependencies, one for
> > architectures and one for driver-specific.
> Done.
>
> ---
> - Update CREDITS with the pc-speaker
> driver authors.
> - Prevent pcspkr from being built together
> with snd-pcsp.
>
> Signed-off-by: Stas Sergeev <stsp@aknet.ru>
Thanks, applied to my git tree.
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
Meanwhile, we need to add a similar depenency to snd-pcsp as well, no?
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp causes driver conflict)
2008-04-23 8:55 ` Takashi Iwai
@ 2008-04-23 14:14 ` Takashi Iwai
0 siblings, 0 replies; 109+ messages in thread
From: Takashi Iwai @ 2008-04-23 14:14 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Andrew Morton, linux-kernel
At Wed, 23 Apr 2008 10:55:08 +0200,
I wrote:
>
> At Tue, 22 Apr 2008 21:54:46 +0400,
> Stas Sergeev wrote:
> >
> > Hello.
> >
> > Takashi Iwai wrote:
> > > Err, no, this wasn't merged to sound git tree because apparently the
> > > patch is to 2.6.22 and you didn't resubmit it...
> > That's simply because the old one
> > applies fine. :)
> >
> > > No, I gave no ACK yet.
> > OK, sorry.
> >
> > > I'd rather add a new line with a single "depends on SND_PCSP=n".
> > > You see a clear difference in the art of dependencies, one for
> > > architectures and one for driver-specific.
> > Done.
> >
> > ---
> > - Update CREDITS with the pc-speaker
> > driver authors.
> > - Prevent pcspkr from being built together
> > with snd-pcsp.
> >
> > Signed-off-by: Stas Sergeev <stsp@aknet.ru>
>
> Thanks, applied to my git tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
>
> Meanwhile, we need to add a similar depenency to snd-pcsp as well, no?
Fixed on ALSA tree now.
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-23 8:49 ` Takashi Iwai
@ 2008-04-23 14:18 ` Takashi Iwai
2008-04-23 20:02 ` Stas Sergeev
1 sibling, 0 replies; 109+ messages in thread
From: Takashi Iwai @ 2008-04-23 14:18 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
At Wed, 23 Apr 2008 10:49:00 +0200,
I wrote:
>
> At Tue, 22 Apr 2008 22:31:01 +0400,
> Stas Sergeev wrote:
> >
> > # HG changeset patch
> > # User Stas Sergeev <stsp@users.sourceforge.net>
> > # Date 1208888978 -14400
> > # Node ID 00c36aa3903d861198e8f57c46e75194f3e172d6
> > # Parent f8fbce7ba45922a73a9679d68c4a4b07ebef42de
> > pcsp: fix wording in DEBUG_PAGEALLOC warning.
> >
> > Signed-off-by: Stas Sergeev <stsp@aknet.ru>
> >
> > diff -r f8fbce7ba459 -r 00c36aa3903d drivers/pcsp/pcsp.c
> > --- a/drivers/pcsp/pcsp.c Tue Apr 22 18:39:49 2008 +0200
> > +++ b/drivers/pcsp/pcsp.c Tue Apr 22 22:29:38 2008 +0400
> > @@ -147,12 +147,8 @@ static int __devinit alsa_card_pcsp_init
> >
> > #ifdef CONFIG_DEBUG_PAGEALLOC
> > /* Well, CONFIG_DEBUG_PAGEALLOC makes the sound horrible. Lets alert */
> > - printk(KERN_WARNING
> > - "PCSP: Warning, CONFIG_DEBUG_PAGEALLOC is enabled!\n"
> > - "You have to disable it if you want to use the PC-Speaker "
> > - "driver.\n"
> > - "Unless it is disabled, enjoy the horrible, distorted "
> > - "and crackling noise.\n");
> > + printk(KERN_WARNING "PCSP: CONFIG_DEBUG_PAGEALLOC is enabled, "
> > + KERN_WARNING "which may make the sound noisy.\n");
>
> Missing \n in the first line?
Fixed on ALSA tree now, too.
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-23 8:49 ` Takashi Iwai
2008-04-23 14:18 ` Takashi Iwai
@ 2008-04-23 20:02 ` Stas Sergeev
2008-04-24 9:40 ` Takashi Iwai
1 sibling, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-23 20:02 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
Hello.
Takashi Iwai wrote:
>> + printk(KERN_WARNING "PCSP: CONFIG_DEBUG_PAGEALLOC is enabled, "
>> + KERN_WARNING "which may make the sound noisy.\n");
> Missing \n in the first line?
This was intentional - wanted it to
print in a single line. You see a space
there for that reason.
Should the second KERN_WARNING be removed
then, or what is the problem exactly?
>> - Prevent pcspkr from being built together
>> > with snd-pcsp.
>> >
>> > Signed-off-by: Stas Sergeev <stsp@aknet.ru>
> Thanks, applied to my git tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> Meanwhile, we need to add a similar depenency to snd-pcsp as well, no?
I personally don't think so.
snd-pcsp has the excact copy of the pcspkr
code built-in, so I thought pcspkr can be
obsoleted in the future. From that point of
view, having snd-pcsp enabled and not even
seeing pcspkr in a menuconfig is fine.
While otherwise (you ocasionally enable
pcspkr and don't even see snd-pcsp then)
is not fine.
You mentioned earlier that you would like
to be able to swap those drivers dynamically,
but... what's the use? With such a dependancy
added, many people will not even know about
snd-pcsp as they already have pcspkr enabled.
> Fixed on ALSA tree now.
Oh...
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-23 20:02 ` Stas Sergeev
@ 2008-04-24 9:40 ` Takashi Iwai
2008-04-25 3:51 ` Stas Sergeev
0 siblings, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-04-24 9:40 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
At Thu, 24 Apr 2008 00:02:06 +0400,
Stas Sergeev wrote:
>
> Hello.
>
> Takashi Iwai wrote:
> >> + printk(KERN_WARNING "PCSP: CONFIG_DEBUG_PAGEALLOC is enabled, "
> >> + KERN_WARNING "which may make the sound noisy.\n");
> > Missing \n in the first line?
> This was intentional - wanted it to
> print in a single line. You see a space
> there for that reason.
> Should the second KERN_WARNING be removed
> then, or what is the problem exactly?
Then you don't need KERN_WARNING there.
The problem is that you need KERN_* prefix again after the line break
(\n). Your original patch didn't do that properly.
> >> - Prevent pcspkr from being built together
> >> > with snd-pcsp.
> >> >
> >> > Signed-off-by: Stas Sergeev <stsp@aknet.ru>
> > Thanks, applied to my git tree.
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > Meanwhile, we need to add a similar depenency to snd-pcsp as well, no?
> I personally don't think so.
> snd-pcsp has the excact copy of the pcspkr
> code built-in, so I thought pcspkr can be
> obsoleted in the future. From that point of
> view, having snd-pcsp enabled and not even
> seeing pcspkr in a menuconfig is fine.
> While otherwise (you ocasionally enable
> pcspkr and don't even see snd-pcsp then)
> is not fine.
No, I don't think input-pcspkr would be ever easily obsoleted by
snd-pcsp. People definitely want a system without the sound subsystem
but with a beep.
> You mentioned earlier that you would like
> to be able to swap those drivers dynamically,
> but... what's the use? With such a dependancy
> added, many people will not even know about
> snd-pcsp as they already have pcspkr enabled.
Think about distro. They could distribute both modules if both modules
can be replacible. Otherwise, snd-pcsp won't be enabled on most
distros, I guess.
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-24 9:40 ` Takashi Iwai
@ 2008-04-25 3:51 ` Stas Sergeev
2008-04-25 6:28 ` Takashi Iwai
0 siblings, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-25 3:51 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
Hello.
Takashi Iwai wrote:
> No, I don't think input-pcspkr would be ever easily obsoleted by
> snd-pcsp. People definitely want a system without the sound subsystem
> but with a beep.
If you don't enable sound, then you
can't enable snd-pcsp, and so the
pcspkr can be enabled.
But if you have enabled the sound,
what's the use in not seeing the
snd-pcsp in the config?
Because most people already had
pcspkr enabled I guess, this just
reduces the availability of snd-pcsp
by an order of magnitude. And the
reason for that, is... ?
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 3:51 ` Stas Sergeev
@ 2008-04-25 6:28 ` Takashi Iwai
2008-04-25 16:45 ` Stas Sergeev
0 siblings, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-04-25 6:28 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
At Fri, 25 Apr 2008 07:51:58 +0400,
Stas Sergeev wrote:
>
> Hello.
>
> Takashi Iwai wrote:
> > No, I don't think input-pcspkr would be ever easily obsoleted by
> > snd-pcsp. People definitely want a system without the sound subsystem
> > but with a beep.
> If you don't enable sound, then you
> can't enable snd-pcsp, and so the
> pcspkr can be enabled.
Yeah, of course. Don't mix up with the argument about Kconfig
dependency issues. I just reacted against your statement that input
pcspkr driver will be obsoleted.
> But if you have enabled the sound,
> what's the use in not seeing the
> snd-pcsp in the config?
> Because most people already had
> pcspkr enabled I guess, this just
> reduces the availability of snd-pcsp
> by an order of magnitude. And the
> reason for that, is... ?
I actually removed the dependency from snd-pcsp Kconfig again since
this causes a dependency loop (at least, kbuild can't handle
properly).
But anyway, as mentioned in my previous post, snd-pcsp wouldn't be
enabled on most of distros' kernels because it cannot be built
together with input-pcspkr driver, unfortunately...
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 6:28 ` Takashi Iwai
@ 2008-04-25 16:45 ` Stas Sergeev
2008-04-25 16:51 ` Takashi Iwai
2008-04-25 18:09 ` Dmitry Torokhov
0 siblings, 2 replies; 109+ messages in thread
From: Stas Sergeev @ 2008-04-25 16:45 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
Hello.
Takashi Iwai wrote:
> Yeah, of course. Don't mix up with the argument about Kconfig
> dependency issues. I just reacted against your statement that input
> pcspkr driver will be obsoleted.
Those are the different ones of course.
For me the dependancy issue is a primary
problem of course, so the other one I
simply ducked.
> I actually removed the dependency from snd-pcsp Kconfig again since
> this causes a dependency loop (at least, kbuild can't handle
> properly).
OK, good to know this. :)
> But anyway, as mentioned in my previous post, snd-pcsp wouldn't be
> enabled on most of distros' kernels because it cannot be built
> together with input-pcspkr driver, unfortunately...
Yes, making them to play well together is
something to think about too. But I don't
see how it can affect the distributors.
If the distro doesn't have the sound enabled,
then it won't enable snd-pcsp no matter
what. If it does have the sound enabled,
then why would it ever want to use pcspkr
instead of snd-pcsp?
I see this issue mostly as a theoretical
one. If you see the real problems with
the current situation, please let me know.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 16:45 ` Stas Sergeev
@ 2008-04-25 16:51 ` Takashi Iwai
2008-04-25 17:25 ` Stas Sergeev
2008-05-02 16:44 ` Takashi Iwai
2008-04-25 18:09 ` Dmitry Torokhov
1 sibling, 2 replies; 109+ messages in thread
From: Takashi Iwai @ 2008-04-25 16:51 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
At Fri, 25 Apr 2008 20:45:51 +0400,
Stas Sergeev wrote:
>
> > But anyway, as mentioned in my previous post, snd-pcsp wouldn't be
> > enabled on most of distros' kernels because it cannot be built
> > together with input-pcspkr driver, unfortunately...
> Yes, making them to play well together is
> something to think about too. But I don't
> see how it can affect the distributors.
> If the distro doesn't have the sound enabled,
> then it won't enable snd-pcsp no matter
> what. If it does have the sound enabled,
> then why would it ever want to use pcspkr
> instead of snd-pcsp?
The sound subsystem is enabled (loaded) only when necessary.
As long as there are many systems without the sound subsystem
(i.e. servers), snd-pcsp wouldn't be built (thus not provided even as
a module) for their kernels because it prevents input-pcspkr.
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 16:51 ` Takashi Iwai
@ 2008-04-25 17:25 ` Stas Sergeev
2008-05-02 16:44 ` Takashi Iwai
1 sibling, 0 replies; 109+ messages in thread
From: Stas Sergeev @ 2008-04-25 17:25 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
Hello.
Takashi Iwai wrote:
> The sound subsystem is enabled (loaded) only when necessary.
> As long as there are many systems without the sound subsystem
> (i.e. servers),
Is it really a problem for the server
admin to just tolerate a few extra modules
being loaded? I really don't know, I just
thought it is not.
Of course the one may not like the fact
that after the kernel update, he gets a
few modules more in lsmod output; someone
may even call it a bloat...
$ lsmod |wc -l
79
Doesn't look too small already. :)
Anyway, I guess we'll soon find out the
numbers, unless someone will come up with
the good way to make those drivers to
play better together and to not depend
on each other, which looks a bit difficult
from the first glance.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 16:45 ` Stas Sergeev
2008-04-25 16:51 ` Takashi Iwai
@ 2008-04-25 18:09 ` Dmitry Torokhov
2008-04-25 18:31 ` Stas Sergeev
1 sibling, 1 reply; 109+ messages in thread
From: Dmitry Torokhov @ 2008-04-25 18:09 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Takashi Iwai, linux-kernel
Hi Stas,
On Fri, Apr 25, 2008 at 08:45:51PM +0400, Stas Sergeev wrote:
> Hello.
>
> Takashi Iwai wrote:
>
> > But anyway, as mentioned in my previous post, snd-pcsp wouldn't be
> > enabled on most of distros' kernels because it cannot be built
> > together with input-pcspkr driver, unfortunately...
> Yes, making them to play well together is
> something to think about too. But I don't
> see how it can affect the distributors.
> If the distro doesn't have the sound enabled,
> then it won't enable snd-pcsp no matter
> what. If it does have the sound enabled,
> then why would it ever want to use pcspkr
> instead of snd-pcsp?
Given agerage quality of the speakers in the current boxes and
abudance of on-board sound I doubt any distriution would want to have
snd-pcsp enabled since there is a chance it may come up as a primary
(default) sound device. At least my experience with F[C]7 that
juggling 3 sound cards is not very easy.
--
Dmitry
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 18:09 ` Dmitry Torokhov
@ 2008-04-25 18:31 ` Stas Sergeev
2008-04-25 18:37 ` Dmitry Torokhov
0 siblings, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-04-25 18:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Takashi Iwai, linux-kernel
Hello.
Dmitry Torokhov wrote:
> abudance of on-board sound I doubt any distriution would want to have
> snd-pcsp enabled since there is a chance it may come up as a primary
> (default) sound device.
I avoid that by adding
options snd-pcsp index=1
into /etc/modprobe.conf.
Maybe index=5 or alike would be
safer for those who have many cards.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 18:31 ` Stas Sergeev
@ 2008-04-25 18:37 ` Dmitry Torokhov
0 siblings, 0 replies; 109+ messages in thread
From: Dmitry Torokhov @ 2008-04-25 18:37 UTC (permalink / raw)
To: Stas Sergeev; +Cc: Takashi Iwai, linux-kernel
On Fri, Apr 25, 2008 at 10:31:21PM +0400, Stas Sergeev wrote:
> Hello.
>
> Dmitry Torokhov wrote:
> > abudance of on-board sound I doubt any distriution would want to have
> > snd-pcsp enabled since there is a chance it may come up as a primary
> > (default) sound device.
> I avoid that by adding
> options snd-pcsp index=1
> into /etc/modprobe.conf.
> Maybe index=5 or alike would be
> safer for those who have many cards.
Yes, it could be. But face it, the number of users wanting to play
musuc through PC speaker is quite small and unlikely to increase in
the future.
--
Dmitry
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH] OLPC: only check for OFW signature on VSA-less Geodes
2008-04-21 21:02 ` [PATCH] OLPC: only check for OFW signature on VSA-less Geodes Andres Salomon
2008-04-21 21:17 ` Jordan Crouse
2008-04-21 21:17 ` [PATCH] " David Woodhouse
@ 2008-04-29 3:06 ` Andrew Morton
2008-04-29 5:32 ` [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline Andres Salomon
2 siblings, 1 reply; 109+ messages in thread
From: Andrew Morton @ 2008-04-29 3:06 UTC (permalink / raw)
To: Andres Salomon
Cc: David Woodhouse, Mitch Bradley, Yinghai Lu, H. Peter Anvin,
Eric W. Biederman, Ingo Molnar, Joseph Fannin, linux-kernel,
jordan.crouse
On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon <dilinger@queued.net> wrote:
> + if (!is_geode() || geode_has_vsa2())
geode_has_vsa2() is a fairly expensive-looking function and afacit only
needs to be evaluated once per boot. Perhaps we should cache it somewhere?
^ permalink raw reply [flat|nested] 109+ messages in thread
* [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline
2008-04-29 3:06 ` Andrew Morton
@ 2008-04-29 5:32 ` Andres Salomon
2008-04-29 20:35 ` Andrew Morton
0 siblings, 1 reply; 109+ messages in thread
From: Andres Salomon @ 2008-04-29 5:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: H. Peter Anvin, Ingo Molnar, linux-kernel, jordan.crouse
On Mon, 28 Apr 2008 20:06:51 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon <dilinger@queued.net> wrote:
>
> > + if (!is_geode() || geode_has_vsa2())
>
> geode_has_vsa2() is a fairly expensive-looking function and afacit only
> needs to be evaluated once per boot. Perhaps we should cache it somewhere?
>
How about this?
This moves geode_has_vsa2 into a .c file, caches the result we get from
the VSA virtual registers, and causes the function to no longer be inline.
Signed-off-by: Andres Salomon <dilinger@debian.org>
---
arch/x86/kernel/geode_32.c | 19 +++++++++++++++++++
include/asm-x86/geode.h | 11 +----------
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/geode_32.c b/arch/x86/kernel/geode_32.c
index 9dad6ca..1cb8225 100644
--- a/arch/x86/kernel/geode_32.c
+++ b/arch/x86/kernel/geode_32.c
@@ -161,6 +161,25 @@ void geode_gpio_setup_event(unsigned int gpio, int pair, int pme)
}
EXPORT_SYMBOL_GPL(geode_gpio_setup_event);
+static int has_vsa2 = -1;
+
+int geode_has_vsa2(void)
+{
+ if (has_vsa2 == -1) {
+ /*
+ * The VSA has virtual registers that we can query for a
+ * signature.
+ */
+ outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
+ outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
+
+ has_vsa2 = (inw(VSA_VRC_DATA) == VSA_SIG);
+ }
+
+ return has_vsa2;
+}
+EXPORT_SYMBOL_GPL(geode_has_vsa2);
+
static int __init geode_southbridge_init(void)
{
if (!is_geode())
diff --git a/include/asm-x86/geode.h b/include/asm-x86/geode.h
index 7154dc4..8a53bc8 100644
--- a/include/asm-x86/geode.h
+++ b/include/asm-x86/geode.h
@@ -185,16 +185,7 @@ static inline int is_geode(void)
return (is_geode_gx() || is_geode_lx());
}
-/*
- * The VSA has virtual registers that we can query for a signature.
- */
-static inline int geode_has_vsa2(void)
-{
- outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
- outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
-
- return (inw(VSA_VRC_DATA) == VSA_SIG);
-}
+extern int geode_has_vsa2(void);
/* MFGPTs */
--
1.5.5
^ permalink raw reply related [flat|nested] 109+ messages in thread
* Re: [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline
2008-04-29 5:32 ` [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline Andres Salomon
@ 2008-04-29 20:35 ` Andrew Morton
2008-04-29 20:57 ` Andres Salomon
0 siblings, 1 reply; 109+ messages in thread
From: Andrew Morton @ 2008-04-29 20:35 UTC (permalink / raw)
To: Andres Salomon; +Cc: hpa, mingo, linux-kernel, jordan.crouse
On Tue, 29 Apr 2008 01:32:13 -0400
Andres Salomon <dilinger@queued.net> wrote:
> On Mon, 28 Apr 2008 20:06:51 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon <dilinger@queued.net> wrote:
> >
> > > + if (!is_geode() || geode_has_vsa2())
> >
> > geode_has_vsa2() is a fairly expensive-looking function and afacit only
> > needs to be evaluated once per boot. Perhaps we should cache it somewhere?
> >
>
> How about this?
>
Looks sane. Although one wonders if it should be cached as one of the
standard x86 feature bit thingies which show up in /proc/cpuinfo's 'flags'
field.
> +static int has_vsa2 = -1;
> +
> +int geode_has_vsa2(void)
> +{
> + if (has_vsa2 == -1) {
> + /*
> + * The VSA has virtual registers that we can query for a
> + * signature.
> + */
> + outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
> + outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
> +
> + has_vsa2 = (inw(VSA_VRC_DATA) == VSA_SIG);
> + }
> +
> + return has_vsa2;
> +}
> +EXPORT_SYMBOL_GPL(geode_has_vsa2);
nit:
--- a/arch/x86/kernel/geode_32.c
+++ a/arch/x86/kernel/geode_32.c
@@ -161,10 +161,10 @@ void geode_gpio_setup_event(unsigned int
}
EXPORT_SYMBOL_GPL(geode_gpio_setup_event);
-static int has_vsa2 = -1;
-
int geode_has_vsa2(void)
{
+ static int has_vsa2 = -1;
+
if (has_vsa2 == -1) {
/*
* The VSA has virtual registers that we can query for a
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline
2008-04-29 20:35 ` Andrew Morton
@ 2008-04-29 20:57 ` Andres Salomon
0 siblings, 0 replies; 109+ messages in thread
From: Andres Salomon @ 2008-04-29 20:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: hpa, mingo, linux-kernel, jordan.crouse
On Tue, 29 Apr 2008 13:35:12 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 29 Apr 2008 01:32:13 -0400
> Andres Salomon <dilinger@queued.net> wrote:
>
> > On Mon, 28 Apr 2008 20:06:51 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Mon, 21 Apr 2008 17:02:30 -0400 Andres Salomon <dilinger@queued.net> wrote:
> > >
> > > > + if (!is_geode() || geode_has_vsa2())
> > >
> > > geode_has_vsa2() is a fairly expensive-looking function and afacit only
> > > needs to be evaluated once per boot. Perhaps we should cache it somewhere?
> > >
> >
> > How about this?
> >
>
> Looks sane. Although one wonders if it should be cached as one of the
> standard x86 feature bit thingies which show up in /proc/cpuinfo's 'flags'
> field.
>
The VSA lives in a weird place between hardware and BIOS. I'm not
really sure whether it's appropriate for it to be an x86_cap_flags (it
hadn't occurred to me), but I think of it more as BIOS. Jordan, what do
you think?
> > +static int has_vsa2 = -1;
> > +
> > +int geode_has_vsa2(void)
> > +{
> > + if (has_vsa2 == -1) {
> > + /*
> > + * The VSA has virtual registers that we can query for a
> > + * signature.
> > + */
> > + outw(VSA_VR_UNLOCK, VSA_VRC_INDEX);
> > + outw(VSA_VR_SIGNATURE, VSA_VRC_INDEX);
> > +
> > + has_vsa2 = (inw(VSA_VRC_DATA) == VSA_SIG);
> > + }
> > +
> > + return has_vsa2;
> > +}
> > +EXPORT_SYMBOL_GPL(geode_has_vsa2);
>
> nit:
>
> --- a/arch/x86/kernel/geode_32.c
> +++ a/arch/x86/kernel/geode_32.c
> @@ -161,10 +161,10 @@ void geode_gpio_setup_event(unsigned int
> }
> EXPORT_SYMBOL_GPL(geode_gpio_setup_event);
>
> -static int has_vsa2 = -1;
> -
> int geode_has_vsa2(void)
> {
> + static int has_vsa2 = -1;
> +
Looks good.
Acked-by: Andres Salomon <dilinger@debian.org>
> if (has_vsa2 == -1) {
> /*
> * The VSA has virtual registers that we can query for a
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-04-25 16:51 ` Takashi Iwai
2008-04-25 17:25 ` Stas Sergeev
@ 2008-05-02 16:44 ` Takashi Iwai
2008-05-02 16:57 ` Stas Sergeev
1 sibling, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-05-02 16:44 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
t Fri, 25 Apr 2008 18:51:04 +0200,
I wrote:
>
> At Fri, 25 Apr 2008 20:45:51 +0400,
> Stas Sergeev wrote:
> >
> > > But anyway, as mentioned in my previous post, snd-pcsp wouldn't be
> > > enabled on most of distros' kernels because it cannot be built
> > > together with input-pcspkr driver, unfortunately...
> > Yes, making them to play well together is
> > something to think about too. But I don't
> > see how it can affect the distributors.
> > If the distro doesn't have the sound enabled,
> > then it won't enable snd-pcsp no matter
> > what. If it does have the sound enabled,
> > then why would it ever want to use pcspkr
> > instead of snd-pcsp?
>
> The sound subsystem is enabled (loaded) only when necessary.
> As long as there are many systems without the sound subsystem
> (i.e. servers), snd-pcsp wouldn't be built (thus not provided even as
> a module) for their kernels because it prevents input-pcspkr.
... and I completely missed the viewpoint of device allocation.
Yeah, that'll be a bit hackish.
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-05-02 16:44 ` Takashi Iwai
@ 2008-05-02 16:57 ` Stas Sergeev
2008-05-06 10:20 ` Takashi Iwai
0 siblings, 1 reply; 109+ messages in thread
From: Stas Sergeev @ 2008-05-02 16:57 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
Takashi Iwai wrote:
>> The sound subsystem is enabled (loaded) only when necessary.
>> As long as there are many systems without the sound subsystem
>> (i.e. servers), snd-pcsp wouldn't be built (thus not provided even as
>> a module) for their kernels because it prevents input-pcspkr.
> ... and I completely missed the viewpoint of device allocation.
> Yeah, that'll be a bit hackish.
I'll appreciate if your replies
became a bit less cryptic... ;)
What will be a bit hackish?
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-05-02 16:57 ` Stas Sergeev
@ 2008-05-06 10:20 ` Takashi Iwai
2008-05-06 16:51 ` Stas Sergeev
0 siblings, 1 reply; 109+ messages in thread
From: Takashi Iwai @ 2008-05-06 10:20 UTC (permalink / raw)
To: Stas Sergeev; +Cc: linux-kernel
At Fri, 02 May 2008 20:57:00 +0400,
Stas Sergeev wrote:
>
> Takashi Iwai wrote:
> >> The sound subsystem is enabled (loaded) only when necessary.
> >> As long as there are many systems without the sound subsystem
> >> (i.e. servers), snd-pcsp wouldn't be built (thus not provided even as
> >> a module) for their kernels because it prevents input-pcspkr.
> > ... and I completely missed the viewpoint of device allocation.
> > Yeah, that'll be a bit hackish.
> I'll appreciate if your replies
> became a bit less cryptic... ;)
> What will be a bit hackish?
[Oops, overseen this follow up]
One problem is that we cannot load two drivers to a single device
right now. Even if you have input pcspkr and snd-pcsp modules, you
have to blacklist one of two modules so that udev loads the one
properly. Because of this, snd-pcsp will be unlikely activated for
most systems as default.
For avoiding this, you'll have a few choices:
a) implement pcspkr-core driver, and make input-pcspkr and snd-pcsp on
that core module
b) make snd-pcsp copmletely rely on input pcspkr, implement as an
add-on by adding hook to each driver callback and event handler of
pcspkr
c) implement snd-pcsp as another individual platform driver and adds a
hook to pcskr event handler of pcspkr
The case (a) would make things more complicated and give less
solution.
In the case (b), the modification of pcspkr.c would be big, and
would be ugly.
The case (c) was my proposal. But in this case, the driver will
become likely self consistent; it allocates its own device at init.
In anyway, there is no sexy way to auto-load snd-pcsp (partly because
it's the purpose -- avoid loading the sound subsystem unless really
necessary). That's why I called it hackish.
Takashi
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC)
2008-05-06 10:20 ` Takashi Iwai
@ 2008-05-06 16:51 ` Stas Sergeev
0 siblings, 0 replies; 109+ messages in thread
From: Stas Sergeev @ 2008-05-06 16:51 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
Hello.
Takashi Iwai wrote:
> The case (c) was my proposal. But in this case, the driver will
> become likely self consistent; it allocates its own device at init.
> In anyway, there is no sexy way to auto-load snd-pcsp (partly because
> it's the purpose -- avoid loading the sound subsystem unless really
> necessary). That's why I called it hackish.
I thought all (or most) alsa drivers
are allocating device on init, even
though this is explicitly discouraged
in the docs. So I was considering this
as a possible solution with the minimal
drawback.
But... as long as the autoloading by
default is not needed, and both drivers
can be at least built together, and not
too much distros have pcspkr built-in,
I thought the current solution - having
pcspkr as the default but to let the user
to choose snd-pcsp, is not all that bad
too. I guess it costs only adding a single
alias into modprobe.conf to choose snd-pcsp.
And I also think _most_ distros do not
mind having the sound subsystem loaded
by default, but some certainly do. For
those that do, the user will have to add
an alias. For others - he may get snd-pcsp
right away. IMHO this is rather acceptable.
^ permalink raw reply [flat|nested] 109+ messages in thread
end of thread, other threads:[~2008-05-06 16:51 UTC | newest]
Thread overview: 109+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-18 8:47 2.6.25-mm1 Andrew Morton
2008-04-18 11:26 ` [PATCH] 2.6.25-mm1 - Build Failure with PWRficient onchip memory controller driver Kamalesh Babulal
2008-04-18 13:02 ` StackProtector Oopses - Re: 2.6.25-mm1 Reuben Farrelly
2008-04-18 13:36 ` Ingo Molnar
2008-04-18 13:51 ` Arjan van de Ven
2008-04-18 14:41 ` Reuben Farrelly
2008-04-18 14:49 ` Reuben Farrelly
2008-04-21 15:06 ` Ingo Molnar
2008-04-22 1:48 ` Arjan van de Ven
2008-04-22 2:04 ` Valdis.Kletnieks
2008-04-22 8:34 ` Ingo Molnar
2008-04-22 14:29 ` Arjan van de Ven
2008-04-18 16:40 ` 2.6.25-mm1 (build error: driver core) Randy Dunlap
2008-04-18 16:56 ` Greg KH
2008-04-18 18:38 ` Dan Williams
2008-04-18 16:45 ` 2.6.25-mm1 (build error: trace selftest) Randy Dunlap
2008-04-18 20:14 ` 2.6.25-mm1 Valdis.Kletnieks
2008-04-18 23:09 ` 2.6.25-mm1: orphaned files after build Alexey Dobriyan
2008-04-19 2:13 ` 2.6.25-mm1 Joseph Fannin
2008-04-19 3:02 ` 2.6.25-mm1 Andrew Morton
2008-04-19 4:14 ` 2.6.25-mm1 Dmitry Torokhov
2008-04-19 4:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 6:33 ` 2.6.25-mm1 Joseph Fannin
2008-04-21 11:07 ` 2.6.25-mm1 Takashi Iwai
2008-04-21 17:44 ` 2.6.25-mm1 (snd-pcsp causes driver conflict) Stas Sergeev
2008-04-22 10:09 ` Takashi Iwai
2008-04-22 17:54 ` Stas Sergeev
2008-04-23 8:55 ` Takashi Iwai
2008-04-23 14:14 ` Takashi Iwai
2008-04-21 19:45 ` 2.6.25-mm1 Stas Sergeev
2008-04-21 14:06 ` 2.6.25-mm1 Takashi Iwai
2008-04-21 17:55 ` 2.6.25-mm1 (snd-pcsp doesn't like DEBUG_PAGEALLOC) Stas Sergeev
2008-04-22 10:13 ` Takashi Iwai
2008-04-22 14:01 ` Dmitry Torokhov
2008-04-22 16:42 ` Stas Sergeev
2008-04-22 18:31 ` Stas Sergeev
2008-04-23 8:49 ` Takashi Iwai
2008-04-23 14:18 ` Takashi Iwai
2008-04-23 20:02 ` Stas Sergeev
2008-04-24 9:40 ` Takashi Iwai
2008-04-25 3:51 ` Stas Sergeev
2008-04-25 6:28 ` Takashi Iwai
2008-04-25 16:45 ` Stas Sergeev
2008-04-25 16:51 ` Takashi Iwai
2008-04-25 17:25 ` Stas Sergeev
2008-05-02 16:44 ` Takashi Iwai
2008-05-02 16:57 ` Stas Sergeev
2008-05-06 10:20 ` Takashi Iwai
2008-05-06 16:51 ` Stas Sergeev
2008-04-25 18:09 ` Dmitry Torokhov
2008-04-25 18:31 ` Stas Sergeev
2008-04-25 18:37 ` Dmitry Torokhov
2008-04-19 2:25 ` 2.6.25-mm1 Joseph Fannin
2008-04-19 3:08 ` 2.6.25-mm1 Andrew Morton
2008-04-19 3:10 ` 2.6.25-mm1 Joseph Fannin
2008-04-19 3:29 ` 2.6.25-mm1 Andrew Morton
2008-04-19 13:25 ` 2.6.25-mm1 Andres Salomon
2008-04-19 17:38 ` 2.6.25-mm1 Andrew Morton
2008-04-19 17:50 ` 2.6.25-mm1 Andres Salomon
2008-04-21 14:56 ` 2.6.25-mm1 Jordan Crouse
2008-04-21 15:05 ` 2.6.25-mm1 Andres Salomon
2008-04-21 15:12 ` 2.6.25-mm1 Jordan Crouse
2008-04-19 17:39 ` [PATCH 1/2] OLPC: Add support for calling into Open Firmware Andres Salomon
2008-04-20 10:34 ` Yinghai Lu
2008-04-20 12:07 ` H. Peter Anvin
2008-04-20 17:59 ` Andres Salomon
2008-04-20 18:42 ` Mitch Bradley
2008-04-20 19:12 ` H. Peter Anvin
2008-04-21 3:39 ` Mitch Bradley
2008-04-21 4:54 ` Yinghai Lu
2008-04-21 8:22 ` Mitch Bradley
2008-04-21 11:36 ` H. Peter Anvin
2008-04-21 13:09 ` H. Peter Anvin
2008-04-21 13:13 ` H. Peter Anvin
2008-04-21 13:19 ` H. Peter Anvin
2008-04-21 15:05 ` Jordan Crouse
2008-04-21 14:58 ` H. Peter Anvin
2008-04-20 19:13 ` [PATCH 1/2] " H. Peter Anvin
2008-04-21 3:09 ` Mitch Bradley
2008-04-21 3:15 ` Yinghai Lu
2008-04-21 4:05 ` Mitch Bradley
2008-04-21 4:26 ` David Miller
2008-04-21 4:50 ` Yinghai Lu
2008-04-21 8:03 ` Mitch Bradley
2008-04-21 14:24 ` Andres Salomon
2008-04-21 15:54 ` David Woodhouse
2008-04-21 16:57 ` H. Peter Anvin
2008-04-21 18:54 ` David Woodhouse
2008-04-21 17:03 ` Andres Salomon
2008-04-21 19:18 ` David Woodhouse
2008-04-21 19:46 ` Andres Salomon
2008-04-21 20:25 ` David Woodhouse
2008-04-21 21:02 ` [PATCH] OLPC: only check for OFW signature on VSA-less Geodes Andres Salomon
2008-04-21 21:17 ` Jordan Crouse
2008-04-21 21:17 ` [PATCH] " David Woodhouse
2008-04-29 3:06 ` Andrew Morton
2008-04-29 5:32 ` [PATCH] x86: GEODE: cache results from geode_has_vsa2() and uninline Andres Salomon
2008-04-29 20:35 ` Andrew Morton
2008-04-29 20:57 ` Andres Salomon
2008-04-19 17:39 ` [PATCH 2/2] OLPC: drop pre-OpenFirmware workarounds Andres Salomon
2008-04-19 18:21 ` 2.6.25-mm1 Arjan van de Ven
2008-04-20 11:29 ` internal compiler error: SIGSEGV [Was: 2.6.25-mm1] Jiri Slaby
2008-04-21 8:31 ` Jiri Slaby
2008-04-21 9:06 ` Al Viro
2008-04-21 9:37 ` fault in __d_lookup " Jiri Slaby
2008-04-21 9:45 ` Al Viro
2008-04-21 9:59 ` Jiri Slaby
2008-04-21 13:42 ` Rafael J. Wysocki
2008-04-21 17:23 ` Matthew Wilcox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).