ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
linus.patch
git-acpi.patch
git-alsa.patch
git-blktrace.patch
git-block.patch
git-cfq.patch
git-cifs.patch
git-cpufreq.patch
git-drm.patch
git-audit.patch
git-ia64.patch
git-ieee1394.patch
git-kbuild.patch
git-libata-all.patch
git-netdev-all.patch
git-net.patch
git-ntfs.patch
git-ocfs2.patch
git-powerpc.patch
git-sym2.patch
git-pcmcia.patch
git-alsa-vs-git-pcmcia.patch
git-scsi-misc-fixup.patch
git-sas-jg.patch
git-xfs.patch
git-cryptodev.patch
Subsystem trees
-ehci-hang-fix.patch -e1000-fix-for-dhcp-issue.patch
-acpi-fix-passive-thermal-management.patch
-acpi-leave-thermal-passive-cooling-when-machine-cooled-down.patch
-acpi-fix-null-deref-in-video-lcd-brightness.patch
-acpi-scan-revert-acpi_bus_find_driver-return-value-check.patch
-process-events-connector-uid_t-gid_t-size-issues.patch
-fix-crash-when-ptrace-poking-hugepage-areas.patch
-fix-rebooting-on-hp-nc6120-laptop.patch
-fix-swsusp-on-machines-not-supporting-s4.patch
pfnmap-fix-2615-rc3-driver-breakage.patch
-ppc-fix-floating-point-register-corruption.patch
-reiserfs-handle-cnode-allocation-failure-gracefully.patch
-hfsplus-dont-modify-journaled-volume.patch
-setting-irq-affinity-is-broken-in-ia32-with-msi-enabled.patch
-fbdev-cirrusfb-driver-cleanup-and-bug-fixes.patch
-fbdev-cg3fb-kconfig-fix.patch -git-acpi-build-fix-3.patch
-acpi-handle-fadt-20-xpmtmr-address-0-case.patch
-acpi-should-depend-on-not-select-pci.patch
-set-ibm-thinkpad-extras-to-default-n-in-kconfig.patch
-git-acpi-update-8250_acpi.patch -cpufreq-nforce2c-fix-u320-test.patch
-cpufreq-documentation-for-ondemand-and-conservative.patch
-cpufreq_conservative-ondemand-invert-meaning-of-ignore-nice.patch
-gregkh-driver-merge-hotplug-and-uevent-vio-fix.patch
-gregkh-driver-merge-hotplug-and-uevent-macio_asic-fix.patch
-kobject_uevent-config_netn-fix.patch
-broken-kref-counting-in-find-functions.patch
-gregkh-driver-kill-hotplug-word-from-driver-core-memory-fix.patch
-b44-missing-netif_wake_queue-in-b44_open.patch
-git-net-selinux-xfrmc-build-fix.patch
-b44-missing-netif_wake_queue-in-b44_open.patch
-git-net-selinux-xfrmc-build-fix.patch
-kill-libata-scsi_wait_req-usage-make-libata-compile-in-fix.patch
-mptfusion-bad-scsi-performance-fix.patch
-gregkh-pci-pci-driver-owner-removal-fix-aic94xx_init.patch
-aic94xx_init-needs-dma-mappingh.patch
-sas_task-needs-timerh.patch
-sas_event-needs-schedh.patch
-gregkh-usb-usb-documentation-update.patch
-gregkh-usb-additional-device-id-for-conexant-accessrunner-usb-driver.patch
-gregkh-usb-usb-fix-usb-suspend-resume-crasher.patch
-ipw2200-kzalloc-conversion-and-kconfig-dependency-fix.patch
-duplicate-ipw_debug-option-for-ipw2100-and-2200.patch
-ppc32-fix-incorrect-pci-frequency-value.patch
-ppc32-fix-treeboot-image-entrypoint.patch
-apm_emuc-fix-a-missing-check-on-misc_register-return-code.patch
-i386-x86_64-remove-preempt-disable-calls-in-lowlevel-ipi.patch
-x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is-fix.patch
-x86_64-fix-page-fault-from-show_trace.patch
-x86_64-fix-single-step-handling-for-32bit-processes.patch
-arm-sema_count-removal.patch
-arm-ixdp425-setup-bug.patch
-nfs-work-correctly-with-single-page-writepage-calls.patch
Merged
+kprobes-reference-count-the-modules-when-probed-on-it.patch
kprobes fix
+x86-fix-nmi-with-cpu-hotplug.patch
x86 NMI fix
+kbuild-fixes.patch
build system fixes
+ext3-fix-mount-options-documentation.patch
ext3 documentation
+i386-x86-64-implement-fallback-for-pci-mmconfig-to-type1.patch
+x86_64-i386-correct-for-broken-mcfg-tables-on-k8-systems.patch
+i386-x86-64-fix-iounmap-lock-ordering.patch
x86_64 update
+gregkh-driver-klist-fix-broken-kref-counting-in-find-functions.patch
+gregkh-driver-allow-overlapping-resources-for-platform-devices.patch
+gregkh-driver-kobject_uevent-config_net-n-fix.patch
Driver tree updates
+gregkh-i2c-hwmon-lm85-adt7463-vrm-10.patch
+gregkh-i2c-hwmon-w83627thf-fix-vrm-and-vid.patch
+gregkh-i2c-hwmon-w83627thf-vid-documentation-update.patch
+gregkh-i2c-i2c-rtc8564-remove-duplicate-bcd-macros.patch
+gregkh-i2c-i2c-parport-barco-ltp-dvi.patch
+gregkh-i2c-hwmon-vt8231-new-driver.patch
+gregkh-i2c-i2c-drop-driver-flags-01-df-dummy.patch
+gregkh-i2c-i2c-drop-driver-flags-02-df-notify.patch
+gregkh-i2c-i2c-drop-driver-flags-03-flags.patch
+gregkh-i2c-i2c-client-use-01-drop-multiple-use-flag.patch
+gregkh-i2c-i2c-client-use-02-make-use-flag-default.patch
+gregkh-i2c-i2c-client-use-03-allow-multiple-use.patch
+gregkh-i2c-i2c-doc-porting-clients-update.patch
+gregkh-i2c-i2c-core-get-client-is-gone.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-01-core.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-02-chips.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-03-hwmon.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-04-macintosh.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-05-media.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-06-oss.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-07-ppc.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-08-acorn.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-09-video.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-10-arm.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-11-documentation.patch
+gregkh-i2c-i2c-drop-driver-owner-and-name-12-fix-debug.patch
+gregkh-i2c-i2c-dev-dynamic_class.patch
i2c tree
+ieee1394-write-broadcast_channel-only-to-select-nodes.patch
1394 fix
+git-libata-all-stat_sil-build-fix.patch
Fix git-libata-all.patch
+mtd-onenand-genericc-needs-platform_deviceh-and-use-flash_platform_data.patch
MTD fix
+gregkh-pci-shpchp-replace-pci_find_slot-with-pci_get_slot.patch
+gregkh-pci-shpchp-fix-improper-reference-to-slot-avail-regsister.patch
+gregkh-pci-shpchp-fix-improper-reference-to-mode-1-ecc-capability-bit.patch
+gregkh-pci-shpchp-fix-improper-mmio-mapping.patch
+gregkh-pci-shpchp-fix-improper-write-to-command-completion-detect-bit.patch
+gregkh-pci-shpchp-fix-improper-wait-for-command-completion.patch
+gregkh-pci-pci-irq.c-trivial-printk-and-dbg-updates.patch
PCI tree updates
+arch-replace-pci_module_init-with-pci_register_driver.patch
+drivers-block-replace-pci_module_init-with-pci_register_driver.patch
+drivers-net-replace-pci_module_init-with-pci_register_driver.patch
+drivers-scsi-replace-pci_module_init-with-pci_register_driver.patch
+drivers-rest-replace-pci_module_init-with-pci_register_driver.patch
PCI API cleanups
+git-alsa-vs-git-pcmcia.patch
Try to fix clash between two subsystem trees
+gregkh-usb-usbserial-adds-missing-checks-and-bug-fix.patch
+gregkh-usb-usbserial-race-condition-fix.patch
+gregkh-usb-usb-input-touchkitusb-handle-multiple-packets.patch
+gregkh-usb-usb-don-t-allocate-dma-pools-for-pio-hcds.patch
+gregkh-usb-usb-gadget-file_storage-remove-volatile-declarations.patch
+gregkh-usb-usb-gadget-dummy_hcd-updates-to-hcd-state.patch
+gregkh-usb-usb-don-t-assume-root-hub-resume-succeeds.patch
+gregkh-usb-drivers-usb-misc-sisusbvga-sisusb.c-remove-dead-code.patch
+gregkh-usb-usb-mark-various-usb-tables-const.patch
+gregkh-usb-correct-ohci-pxa27x-suspend-resume-struct-confusion.patch
+gregkh-usb-usb-storage-add-unusual_devs-entry-for-nikon-coolpix-2000.patch
+gregkh-usb-usb-pl2303_update_line_status-data-length-fix.patch
+gregkh-usb-usb-ati_remote-use-time_before-and-friends.patch
+gregkh-usb-uhci-change-uhci_explen-macro.patch
gregkh-usb-usb-gotemp.patch
+gregkh-usb-usbip.patch
USB tree updates
+force-starget-scsi_level-in-usb-storage-scsigluec.patch
+usb-storage-add-debug-entry-for-report-luns.patch
USB fixes
+x86_64-dma32-fix-mask.patch
+x86_64-shrink-additional-cpus.patch
+x86_64-hotplug-cpu-doc.patch
+x86_64-remove-hlt-counter.patch
+x86_64-constant-tsc-update.patch
+x86_64-cpufreq-constant-tsc.patch
+x86_64-hpet-fallback.patch
+x86_64-amd-cpuid-update.patch
+x86_64-check-ioapic.patch
+x86_64-apic-cmdline.patch
+x86_64-debug-stack.patch
+x86_64-hpet-overflow.patch
+x86_64-another-mb-for-smpbootc.patch
+x86_64-increase-MCE-bank-counts.patch
+x86_64-Remove-preempt-disable-calls-in-lowlevel-IPI.patch
+x86_64-Dont-IPI-to-offline-cpus-on-shutdown.patch
+x86_64-disable-LAPIC-completely-for-offline-CPU.patch
+x86_64-fix-single-step-handling-for-32bit-processes.patch
+x86_64-fix-page-fault-from-show_trace.patch
+x86_64-fls-in-asm-for-x86_64.patch
x86_64 tree
+x86_64-cpufreq-constant-tsc-fix.patch
+x86_64-hpet-overflow-fix.patch
Fix it
+slab-remove-nested-ifdef-config_numa.patch
cleanup
+mm-bad_page-opt.patch
+mm-rmap-opt.patch
+mm-pfault-opt.patch
+mm-pcp-drain-tweak.patch
+drop-pagecache.patch
+vmscan-balancing-fix.patch
MM tuneups
-the-second-param-of-addrconf_ifdown-in-function-addrconf_notify.patch
Dropped - wrong.
+add-mips-dependency-for-dm9000-driver.patch
+ieee80211_crypt_tkip-depends-on-net_radio.patch
netdev fixes
+keys-remove-key-duplication.patch
mey management cleanup
+ppc32-remove-jumbo-member-from-ocp_func_emac_data.patch
+arch-ppc-kernel-idlec-dont-declare-cpu-variable-in-non-smp-kernels.patch
+ppc32-remove-unused-variables.patch
ppc32 updates
+x86-missing-printk-newline-in-apic-boot-option-parser.patch
+i386-support-for-the-geode-cs5535-companion-chip.patch
+i386-support-for-the-geode-cs5535-companion-chip-tidy.patch
+cpu-frequency-display-in-proc-cpuinfo.patch
+x86-fls-in-asm.patch
+arch-i386-kernel-msrc-removed-unused-variable.patch
x86 updates
-x86_64-div-by-zero-fix.patch
Dropped - fixed by other means.
+swsusp-improve-freeing-of-memory-fix.patch
+swsusp-fix-enough_free_mem.patch
software suspend fixes
-ext3_readdir-use-generic-readahead-fixes.patch
Folded into ext3_readdir-use-generic-readahead.patch
-cpuset-change-marker-for-relative-numbering.patch
Dropped by request
-dont-include-schedh-from-moduleh.patch
Dropped - stuff broke
+rcu-file-use-atomic-primitives-fix.patch
Fix rcu-file-use-atomic-primitives.patch
-writeback_control-flag-writepages.patch
Dropped, but it'll come back.
+move-swiotlb-header-file-into-common-code-fix-2.patch
Fix move-swiotlb-header-file-into-common-code.patch some more.
+printk-levels-for-spinlock-debug.patch
+printk-levels-for-i386-oops-code.patch
+drivers-connector-cn_procc-typos.patch
+aoe-type-cleanups.patch
+aoe-skb_check-cleanup.patch
+drivers-mfd-header-included-twice.patch
+documentation-small-applying-patchestxt-update.patch
+fs-remove-s_old_blocksize-from-struct-super_block.patch
+remove-unused-blkp-field-in-percpu_data.patch
Little tweaks
+fix-handling-of-elf-segments-with-zero-filesize.patch
ELF fix
+add-tainting-for-proprietary-helper-modules.patch
Special-base ndiswrapper and driverloader: make them taint the kernel.
-mtd-dataflash-driver-spi-framework.patch
+mtd-dataflash-driver-spi-framework-2.patch
New version
+spi-add-spi_driver-to-spi-framework.patch
+spi-ads7836-uses-spi_driver.patch
+spi-add-spi_bitbang-driver.patch
+spi-add-spi_bitbang-driver-fix.patch
SPI update
-perfmon2-reserve-system-calls.patch
Dropped - needs some review and discussion before we can proceed.
-ktimers-kt2.patch
-ktimers-kt2-export-mktime.patch
-ktimers-rounding-fix.patch
-ktimers-timespec-off-by-one.patch
+ktimers-move-div_long_long_rem-out-of-jiffiesh.patch
+ktimers-remove-duplicate-div_long_long_rem-implementation.patch
+ktimers-deinline-mktime-and-set_normalized_timespec.patch
+ktimers-clean-up-mktime-and-add-const-modifiers.patch
+ktimers-export-deinlined-mktime.patch
+ktimers-remove-unused-clock-constants.patch
+ktimers-cleanup-clock-constants-coding-style.patch
+ktimers-coding-style-and-whitespace-cleanup-timeh.patch
+ktimers-make-clock-selectors-in-posix-timers-const.patch
+ktimers-coding-style-and-white-space-cleanup-posix-timerh.patch
+ktimers-create-timespec_valid-macro.patch
+ktimers-check-user-space-timespec-in-do_sys_settimeofday.patch
+ktimers-introduce-nsec_t-type-and-conversion-functions.patch
+ktimers-introduce-ktime_t-time-format.patch
+ktimers-ktimer-core-code.patch
+ktimers-ktimer-documentation.patch
+ktimers-switch-itimers-to-ktimer.patch
+ktimers-remove-now-unnecessary-includes.patch
+ktimers-introduce-ktimer_nanosleep-apis.patch
+ktimers-convert-sys_nanosleep-to-ktimer_nanosleep.patch
+ktimers-switch-clock_nanosleep-to-ktimer-nanosleep-api.patch
+ktimers-convert-posix-interval-timers-to-use-ktimers.patch
+ktimers-simplify-ktimers-rearm-code.patch
+ktimers-split-timeout-code-into-kernel-ktimeoutc.patch
+ktimers-create-ktimeouth-and-move-timerh-code-into-it.patch
+ktimers-rename-struct-timer_list-to-struct-ktimeout.patch
+ktimers-convert-timer_list-users-to-ktimeout.patch
+ktimers-convert-ktimeouth-and-create-wrappers.patch
+ktimers-convert-ktimeoutc-to-ktimeout-struct-and-apis.patch
+ktimers-ktimeout-documentation.patch
+ktimers-rename-init_ktimeout-to-ktimeout_init.patch
+ktimers-rename-setup_ktimeout-to-ktimeout_setup.patch
+ktimers-rename-add_ktimeout_on-to-ktimeout_add_on.patch
+ktimers-rename-del_ktimeout-to-ktimeout_del.patch
+ktimers-rename-__mod_ktimeout-to-__mod_ktimeout.patch
+ktimers-rename-mod_ktimeout-to-ktimeout_mod.patch
+ktimers-rename-next_ktimeout_interrupt-to.patch
+ktimers-rename-add_ktimeout-to-ktimeout_add.patch
+ktimers-rename-try_to_del_ktimeout_sync-to.patch
+ktimers-rename-del_ktimeout_sync-to-del_ktimeout_sync.patch
+ktimers-rename-del_singleshot_ktimeout_sync-to.patch
+ktimers-rename-timer_softirq-to-timeout_softirq.patch
+ktimers-ktimeout-code-style-cleanups.patch
+ktimers-ktimeout-code-style-cleanups-fix.patch
ktimer update. I stil have no clue why it was necessary to rename timer_list to ktimeout.
+scheduler-cache-hot-autodetect-less-verbose.patch
+scheduler-cache-hot-autodetect-docs.patch
Document and quieten scheduler-cache-hot-autodetect.patch
+ide-modalias-support-for-autoloading-of-ide-cd-ide-disk.patch
IDE module aliases
+fbdev-sstfb-driver-cleanups.patch
fbdev cleanup
+md-support-check-without-repair-of-raid10-arrays.patch
+md-allow-raid1-to-check-consistency.patch
+md-make-sure-read-error-on-last-working-drive-of-raid1-actually-returns-failure.patch
+md-auto-correct-correctable-read-errors-in-raid10.patch
+md-raid10-read-error-handling-resync-and-read-only.patch
+md-make-proc-mdstat-pollable.patch
+md-clean-up-page-related-names-in-md.patch
+md-convert-md-to-use-kzalloc-throughout.patch
+md-tidy-up-raid5-6-hash-table-code.patch
+md-convert-various-kmap-calls-to-kmap_atomic.patch
+md-convert-recently-exported-symbol-to-gpl.patch
+md-break-out-of-a-loop-that-doesnt-need-to-run-to-completion.patch
+md-remove-personality-numbering-from-md.patch
+md-fix-possible-problem-in-raid1-raid10-error-overwriting.patch
+md-change-case-of-raid-level-reported-in-sys-mdx-md-level.patch
+md-remove-inappropriate-limits-in-md-bitmap-configuration.patch
RAID update
+docbook-add-gitignore-file.patch
+add-git-tree-for-docbook.patch
+net-make-function-pointer-argument-parseable-by-kernel-doc.patch
+docbook-fix-kernel-doc-comments.patch
+docbook-warn-for-missing-macro-parameters.patch
docbook updates
-preempt-tracing.patch
This broke.
+drivers-block-use-time_after-and-friends.patch
+nvidia-agp-use-time_before_eq.patch
+ide-tape-use-time_after-time_after_eq.patch
+drivers-net-use-time_after-and-friends.patch
+drivers-scsi-use-time_after-and-friends.patch
jiffy haldning cleanups
+tty-layer-buffering-revamp-jsm-is-broken.patch
Mark the JSM driver as broken - it needs redoing for the tty buffering revamp.
+drivers-replace-pci_module_init-with-pci_register_driver-in-mm.patch
+sound-replace-pci_module_init-with-pci_register_driver-in-mm.patch
+pci-schedule-removal-of-pci_module_init-was-re-patch.patch
PCI API cleanups
All 950 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/patch-list
On Monday 05 December 2005 08:21, Andrew Morton wrote:
>
>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
Hi,
I've been getting these:
Dec 27 14:32:45 kiopa kernel: BUG: soft lockup detected on CPU#1!
Dec 27 14:32:45 kiopa kernel: CPU 1:
Dec 27 14:32:45 kiopa kernel: Modules linked in: ipv6 parport_pc parport
psmouse ns558 analog pcspkr snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm
gameport ohci_hcd snd_timer ide_cd cdrom forcedeth snd ehci_hcd usbcore
snd_page_alloc evdev unix
Dec 27 14:32:45 kiopa kernel: Pid: 0, comm: swapper Not tainted 2.6.15-rc5-mm1
#2
Dec 27 14:32:45 kiopa kernel: RIP: 0010:[<ffffffff80311453>]
<ffffffff80311453>{_spin_unlock_irq+19}
Dec 27 14:32:45 kiopa kernel: RSP: 0000:ffff810001ffbf08 EFLAGS: 00000246
Dec 27 14:32:45 kiopa kernel: RAX: ffff810001ff3fd8 RBX: ffff810001ffbe58 RCX:
ffffffff8040fba0
Dec 27 14:32:45 kiopa kernel: RDX: 0000000000000001 RSI: ffff810001e19ad8 RDI:
ffff810001e18c20
Dec 27 14:32:45 kiopa kernel: RBP: ffffffff8010e354 R08: 00000000000000e9 R09:
0000000000000000
Dec 27 14:32:45 kiopa kernel: R10: 0000000000000000 R11: ffff810001e17660 R12:
ffffffff8014cd49
Dec 27 14:32:45 kiopa kernel: R13: ffffffff801106ff R14: ffff810001ff3f18 R15:
ffff810001ffbf18
Dec 27 14:32:45 kiopa kernel: FS: 0000000000000000(0000) GS:ffffffff8041c080
(0000) knlGS:00000000556b26c0
Dec 27 14:32:45 kiopa kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
000000008005003b
Dec 27 14:32:45 kiopa kernel: CR2: 0000000056b8d012 CR3: 000000003cc2c000 CR4:
00000000000006e0
Dec 27 14:32:45 kiopa kernel:
Dec 27 14:32:45 kiopa kernel: Call Trace: <IRQ>
<ffffffff80311449>{_spin_unlock_irq+9}
<ffffffff8810db70>{:ipv6:addrconf_verify+0}
Dec 27 14:32:45 kiopa kernel:
<ffffffff8014d0e2>{run_ktimeout_softirq+370}
<ffffffff801394c4>{__do_softirq+100}
Dec 27 14:32:45 kiopa kernel: <ffffffff8010f166>{call_softirq+30}
<ffffffff801106bc>{do_softirq+44}
Dec 27 14:32:45 kiopa kernel: <ffffffff801391a8>{irq_exit+72}
<ffffffff8010e9ca>{apic_timer_interrupt+98}
Dec 27 14:32:45 kiopa kernel: <EOI>
<ffffffff80311449>{_spin_unlock_irq+9} <ffffffff8030fed0>{thread_return+95}
Dec 27 14:32:45 kiopa kernel: <ffffffff8010c69d>{default_idle+45}
<ffffffff8010c731>{cpu_idle+97}
Dec 27 14:32:45 kiopa kernel: <ffffffff80433ea5>{start_secondary+1253}
The full log is at http://www.cmartin.tk/linux/dmesg.bz2 which is 7.9M
uncompressed, with just the logs from the last boot.
The date is wrong because this is a second boot. Time goes extremely fast.
When I rebooted into an older kernel it said it was the 8th July 2006!
The system halts for up to a minute (I got a console login timeout out after
60secs). The keyboard lights still change, but the cursor on the screen stays
put. After a bit things return to normal for a bit, repeat until reboot.
cmn
--
Carlos Mart?n http://www.cmartin.tk
On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
>...
> Subsystem trees
>...
> +git-alsa-vs-git-pcmcia.patch
>
> Try to fix clash between two subsystem trees
>...
git-alsa.patch completely removes pdacf_t, and this patch adds a user
resulting in the following compile error:
<-- snip -->
...
CC sound/pcmcia/pdaudiocf/pdaudiocf.o
sound/pcmcia/pdaudiocf/pdaudiocf.c: In function 'pdacf_suspend':
sound/pcmcia/pdaudiocf/pdaudiocf.c:301: warning: passing argument 1 of 'snd_pdacf_suspend' from incompatible pointer type
sound/pcmcia/pdaudiocf/pdaudiocf.c: In function 'pdacf_resume':
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: 'pdacf_t' undeclared (first use in this function)
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: (Each undeclared identifier is reported only once
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: for each function it appears in.)
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: 'chip' undeclared (first use in this function)
make[3]: *** [sound/pcmcia/pdaudiocf/pdaudiocf.o] Error 1
<-- snip -->
git-alsa.patch removes some more code git-alsa-vs-git-pcmcia.patch adds
users for:
<-- snip -->
...
CC sound/pcmcia/vx/vxpocket.o
sound/pcmcia/vx/vxpocket.c: In function 'vxp_suspend':
sound/pcmcia/vx/vxpocket.c:296: error: 'struct snd_card' has no member named 'pm_suspend'
sound/pcmcia/vx/vxpocket.c:298: error: 'struct snd_card' has no member named 'pm_suspend'
sound/pcmcia/vx/vxpocket.c: In function 'vxp_resume':
sound/pcmcia/vx/vxpocket.c:310: error: 'vx_core_t' undeclared (first use in this function)
sound/pcmcia/vx/vxpocket.c:310: error: (Each undeclared identifier is reported only once
sound/pcmcia/vx/vxpocket.c:310: error: for each function it appears in.)
sound/pcmcia/vx/vxpocket.c:310: error: 'chip' undeclared (first use in this function)
make[3]: *** [sound/pcmcia/vx/vxpocket.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
At Mon, 5 Dec 2005 20:06:32 +0100,
Adrian Bunk wrote:
>
> On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
> >...
> > Subsystem trees
> >...
> > +git-alsa-vs-git-pcmcia.patch
> >
> > Try to fix clash between two subsystem trees
> >...
>
> git-alsa.patch completely removes pdacf_t, and this patch adds a user
> resulting in the following compile error:
(snip)
> git-alsa.patch removes some more code git-alsa-vs-git-pcmcia.patch adds
> users for:
(snip)
> cu
> Adrian
My bad, the below is the fixed patch.
Andrew, could you replace with this one?
thanks,
Takashi
---
--- linux-2.6.15-rc5/sound/pcmcia/vx/vxpocket.c-dist 2005-12-05 20:57:55.000000000 +0100
+++ linux-2.6.15-rc5/sound/pcmcia/vx/vxpocket.c 2005-12-05 21:01:28.000000000 +0100
@@ -133,11 +133,9 @@ static struct snd_vx_hardware vxp440_hw
*/
static struct snd_vxpocket *snd_vxpocket_new(struct snd_card *card, int ibl)
{
- client_reg_t client_reg; /* Register with cardmgr */
dev_link_t *link; /* Info for cardmgr */
struct vx_core *chip;
struct snd_vxpocket *vxp;
- int ret;
static struct snd_device_ops ops = {
.dev_free = snd_vxpocket_dev_free,
};
@@ -286,67 +284,55 @@ failed:
kfree(parse);
}
+#ifdef CONFIG_PM
-/*
- * event callback
- */
-static int vxpocket_event(event_t event, int priority, event_callback_args_t *args)
+static int vxp_suspend(struct pcmcia_device *dev)
{
- dev_link_t *link = args->client_data;
+ dev_link_t *link = dev_to_instance(dev);
struct vx_core *chip = link->priv;
- switch (event) {
- case CS_EVENT_CARD_REMOVAL:
- snd_printdd(KERN_DEBUG "CARD_REMOVAL..\n");
- link->state &= ~DEV_PRESENT;
- if (link->state & DEV_CONFIG)
- chip->chip_status |= VX_STAT_IS_STALE;
- break;
- case CS_EVENT_CARD_INSERTION:
- snd_printdd(KERN_DEBUG "CARD_INSERTION..\n");
- link->state |= DEV_PRESENT | DEV_CONFIG_PENDING;
- vxpocket_config(link);
- break;
-#ifdef CONFIG_PM
- case CS_EVENT_PM_SUSPEND:
- snd_printdd(KERN_DEBUG "SUSPEND\n");
- link->state |= DEV_SUSPEND;
+ snd_printdd(KERN_DEBUG "SUSPEND\n");
+ link->state |= DEV_SUSPEND;
+ if (chip) {
+ snd_printdd(KERN_DEBUG "snd_vx_suspend calling\n");
+ snd_vx_suspend(chip, PMSG_SUSPEND);
+ }
+ snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
+ if (link->state & DEV_CONFIG)
+ pcmcia_release_configuration(link->handle);
+
+ return 0;
+}
+
+static int vxp_resume(struct pcmcia_device *dev)
+{
+ dev_link_t *link = dev_to_instance(dev);
+ struct vx_core *chip = link->priv;
+
+ snd_printdd(KERN_DEBUG "RESUME\n");
+ link->state &= ~DEV_SUSPEND;
+
+ snd_printdd(KERN_DEBUG "CARD_RESET\n");
+ if (DEV_OK(link)) {
+ //struct snd_vxpocket *vxp = (struct snd_vxpocket *)chip;
+ snd_printdd(KERN_DEBUG "requestconfig...\n");
+ pcmcia_request_configuration(link->handle, &link->conf);
if (chip) {
- snd_printdd(KERN_DEBUG "snd_vx_suspend calling\n");
- snd_vx_suspend(chip, PMSG_SUSPEND);
- }
- /* Fall through... */
- case CS_EVENT_RESET_PHYSICAL:
- snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
- if (link->state & DEV_CONFIG)
- pcmcia_release_configuration(link->handle);
- break;
- case CS_EVENT_PM_RESUME:
- snd_printdd(KERN_DEBUG "RESUME\n");
- link->state &= ~DEV_SUSPEND;
- /* Fall through... */
- case CS_EVENT_CARD_RESET:
- snd_printdd(KERN_DEBUG "CARD_RESET\n");
- if (DEV_OK(link)) {
- //struct snd_vxpocket *vxp = (struct snd_vxpocket *)chip;
- snd_printdd(KERN_DEBUG "requestconfig...\n");
- pcmcia_request_configuration(link->handle, &link->conf);
- if (chip) {
- snd_printdd(KERN_DEBUG "calling snd_vx_resume\n");
- snd_vx_resume(chip);
- }
+ snd_printdd(KERN_DEBUG "calling snd_vx_resume\n");
+ snd_vx_resume(chip);
}
- snd_printdd(KERN_DEBUG "resume done!\n");
- break;
-#endif
}
+ snd_printdd(KERN_DEBUG "resume done!\n");
+
return 0;
}
+#endif
+
/*
*/
-static dev_link_t *vxpocket_attach(void)
+static int vxpocket_attach(struct pcmcia_device *p_dev)
{
struct snd_card *card;
struct snd_vxpocket *vxp;
@@ -359,22 +345,22 @@ static dev_link_t *vxpocket_attach(void)
}
if (i >= SNDRV_CARDS) {
snd_printk(KERN_ERR "vxpocket: too many cards found\n");
- return NULL;
+ return -EINVAL;
}
if (! enable[i])
- return NULL; /* disabled explicitly */
+ return -ENODEV; /* disabled explicitly */
/* ok, create a card instance */
card = snd_card_new(index[i], id[i], THIS_MODULE, 0);
if (card == NULL) {
snd_printk(KERN_ERR "vxpocket: cannot create a card instance\n");
- return NULL;
+ return -ENOMEM;
}
vxp = snd_vxpocket_new(card, ibl[i]);
if (! vxp) {
snd_card_free(card);
- return NULL;
+ return -ENODEV;
}
card->private_data = vxp;
@@ -382,17 +368,21 @@ static dev_link_t *vxpocket_attach(void)
card_alloc |= 1 << i;
/* Chain drivers */
- vxp->link.next = dev_list;
- dev_list = &vxp->link;
+ vxp->link.next = NULL;
- return &vxp->link;
+ vxp->link.handle = p_dev;
+ vxp->link.state |= DEV_PRESENT | DEV_CONFIG_PENDING;
+ p_dev->instance = &vxp->link;
+ vxpocket_config(&vxp->link);
+
+ return 0;
}
-static void vxpocket_detach(dev_link_t *link)
+static void vxpocket_detach(struct pcmcia_device *p_dev)
{
+ dev_link_t *link = dev_to_instance(p_dev);
struct snd_vxpocket *vxp;
struct vx_core *chip;
- dev_link_t **linkp;
if (! link)
return;
--- linux-2.6.15-rc5/sound/pcmcia/pdaudiocf/pdaudiocf.c-dist 2005-12-05 20:57:51.000000000 +0100
+++ linux-2.6.15-rc5/sound/pcmcia/pdaudiocf/pdaudiocf.c 2005-12-05 21:01:16.000000000 +0100
@@ -52,16 +52,13 @@ MODULE_PARM_DESC(enable, "Enable " CARD_
/*
*/
-static dev_info_t dev_info = "snd-pdaudiocf";
static struct snd_card *card_list[SNDRV_CARDS];
-static dev_link_t *dev_list;
/*
* prototypes
*/
static void pdacf_config(dev_link_t *link);
-static int pdacf_event(event_t event, int priority, event_callback_args_t *args);
-static void snd_pdacf_detach(dev_link_t *link);
+static void snd_pdacf_detach(struct pcmcia_device *p_dev);
static void pdacf_release(dev_link_t *link)
{
@@ -99,11 +96,10 @@ static int snd_pdacf_dev_free(struct snd
/*
* snd_pdacf_attach - attach callback for cs
*/
-static dev_link_t *snd_pdacf_attach(void)
+static int snd_pdacf_attach(struct pcmcia_device *p_dev)
{
- client_reg_t client_reg; /* Register with cardmgr */
- dev_link_t *link; /* Info for cardmgr */
- int i, ret;
+ int i;
+ dev_link_t *link; /* Info for cardmgr */
struct snd_pdacf *pdacf;
struct snd_card *card;
static struct snd_device_ops ops = {
@@ -216,21 +212,13 @@ static int snd_pdacf_assign_resources(st
/*
* snd_pdacf_detach - detach callback for cs
*/
-static void snd_pdacf_detach(dev_link_t *link)
+static void snd_pdacf_detach(struct pcmcia_device *p_dev)
{
+ dev_link_t *link = dev_to_instance(p_dev);
struct snd_pdacf *chip = link->priv;
snd_printdd(KERN_DEBUG "pdacf_detach called\n");
- /* Remove the interface data from the linked list */
- {
- dev_link_t **linkp;
- /* Locate device structure */
- for (linkp = &dev_list; *linkp; linkp = &(*linkp)->next)
- if (*linkp == link)
- break;
- if (*linkp)
- *linkp = link->next;
- }
+
if (chip->chip_status & PDAUDIOCF_STAT_IS_CONFIGURED)
snd_pdacf_powerdown(chip);
chip->chip_status |= PDAUDIOCF_STAT_IS_STALE; /* to be sure */
@@ -299,62 +287,51 @@ failed:
pcmcia_release_irq(link->handle, &link->irq);
}
-/*
- * event callback
- */
-static int pdacf_event(event_t event, int priority, event_callback_args_t *args)
+#ifdef CONFIG_PM
+
+static int pdacf_suspend(struct pcmcia_device *dev)
{
- dev_link_t *link = args->client_data;
+ dev_link_t *link = dev_to_instance(dev);
struct snd_pdacf *chip = link->priv;
- switch (event) {
- case CS_EVENT_CARD_REMOVAL:
- snd_printdd(KERN_DEBUG "CARD_REMOVAL..\n");
- link->state &= ~DEV_PRESENT;
- if (link->state & DEV_CONFIG) {
- chip->chip_status |= PDAUDIOCF_STAT_IS_STALE;
- }
- break;
- case CS_EVENT_CARD_INSERTION:
- snd_printdd(KERN_DEBUG "CARD_INSERTION..\n");
- link->state |= DEV_PRESENT;
- pdacf_config(link);
- break;
-#ifdef CONFIG_PM
- case CS_EVENT_PM_SUSPEND:
- snd_printdd(KERN_DEBUG "SUSPEND\n");
- link->state |= DEV_SUSPEND;
+ snd_printdd(KERN_DEBUG "SUSPEND\n");
+ link->state |= DEV_SUSPEND;
+ if (chip) {
+ snd_printdd(KERN_DEBUG "snd_pdacf_suspend calling\n");
+ snd_pdacf_suspend(chip, PMSG_SUSPEND);
+ }
+
+ snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
+ if (link->state & DEV_CONFIG)
+ pcmcia_release_configuration(link->handle);
+
+ return 0;
+}
+
+static int pdacf_resume(struct pcmcia_device *dev)
+{
+ dev_link_t *link = dev_to_instance(dev);
+ struct snd_pdacf *chip = link->priv;
+
+ snd_printdd(KERN_DEBUG "RESUME\n");
+ link->state &= ~DEV_SUSPEND;
+
+ snd_printdd(KERN_DEBUG "CARD_RESET\n");
+ if (DEV_OK(link)) {
+ snd_printdd(KERN_DEBUG "requestconfig...\n");
+ pcmcia_request_configuration(link->handle, &link->conf);
if (chip) {
- snd_printdd(KERN_DEBUG "snd_pdacf_suspend calling\n");
- snd_pdacf_suspend(chip, PMSG_SUSPEND);
- }
- /* Fall through... */
- case CS_EVENT_RESET_PHYSICAL:
- snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
- if (link->state & DEV_CONFIG)
- pcmcia_release_configuration(link->handle);
- break;
- case CS_EVENT_PM_RESUME:
- snd_printdd(KERN_DEBUG "RESUME\n");
- link->state &= ~DEV_SUSPEND;
- /* Fall through... */
- case CS_EVENT_CARD_RESET:
- snd_printdd(KERN_DEBUG "CARD_RESET\n");
- if (DEV_OK(link)) {
- snd_printdd(KERN_DEBUG "requestconfig...\n");
- pcmcia_request_configuration(link->handle, &link->conf);
- if (chip) {
- snd_printdd(KERN_DEBUG "calling snd_pdacf_resume\n");
- snd_pdacf_resume(chip);
- }
+ snd_printdd(KERN_DEBUG "calling snd_pdacf_resume\n");
+ snd_pdacf_resume(chip);
}
- snd_printdd(KERN_DEBUG "resume done!\n");
- break;
-#endif
}
+ snd_printdd(KERN_DEBUG "resume done!\n");
+
return 0;
}
+#endif
+
/*
* Module entry points
*/
On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
>...
> Subsystem trees
>...
> +gregkh-usb-usbip.patch
>
> USB tree updates
>...
Problems with this patch:
- USB_IP: no need for a "default N"
- USB_IP must be a tristate, because currently the illegal configurations
USB=m, USB_IP=y, USB_IP_{VHCI,STUB}=y are allowed
- compilation fails with USB_IP_VHCI=y, USB_IP_STUB=y:
<-- snip -->
...
LD drivers/usb/ip/built-in.o
drivers/usb/ip/stub.o: In function `usbip_pack_pdu':
: multiple definition of `usbip_pack_pdu'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o: In function `usbip_task_init':
: multiple definition of `usbip_task_init'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o: In function `setreuse':
: multiple definition of `setreuse'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o: In function `usbip_start_eh':
: multiple definition of `usbip_start_eh'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o:(.data+0x0): multiple definition of
`usbip_debug_flag'
drivers/usb/ip/vhci-hcd.o:(.data+0x0): first defined here
...
make[3]: *** [drivers/usb/ip/built-in.o] Error 1
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
>
I still get this oops on boot, then the machine freezes hard on the init
process:
usb_set_configuration+0x22b/0x4df
usb_new_device+0x105/0x158
hub_port_connect_change+0x2de/0x37e
clear_port_feature+0x48/0x4d
hub_events+0x2aa/0x42f
hub_thread+0x14/0xe2
autoremove_wake_function+0x0/0x37
kthread+0x93/0x97
kthread+0x0/0x97
kernel_thread_helper+0x5/0xb
udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
failed.
I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
Any ideas ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
copy linux-usb-devel list...
On Tue, 6 Dec 2005, J.A. Magallon wrote:
> On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> >
> >
>
> I still get this oops on boot, then the machine freezes hard on the init
> process:
>
> usb_set_configuration+0x22b/0x4df
> usb_new_device+0x105/0x158
> hub_port_connect_change+0x2de/0x37e
> clear_port_feature+0x48/0x4d
> hub_events+0x2aa/0x42f
> hub_thread+0x14/0xe2
> autoremove_wake_function+0x0/0x37
> kthread+0x93/0x97
> kthread+0x0/0x97
> kernel_thread_helper+0x5/0xb
>
> udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> failed.
>
> I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
>
> Any ideas ?
>
> --
> J.A. Magallon <jamagallon()able!es> \ Software is like sex:
> werewolf!able!es \ It's better when it's free
> Mandriva Linux release 2006.1 (Cooker) for i586
> Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
>
--
~Randy
Carlos Mart?n <[email protected]> wrote:
>
> On Monday 05 December 2005 08:21, Andrew Morton wrote:
> >
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
> Hi,
>
> I've been getting these:
>
> Dec 27 14:32:45 kiopa kernel: BUG: soft lockup detected on CPU#1!
> Dec 27 14:32:45 kiopa kernel: CPU 1:
> Dec 27 14:32:45 kiopa kernel: Modules linked in: ipv6 parport_pc parport
> psmouse ns558 analog pcspkr snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm
> gameport ohci_hcd snd_timer ide_cd cdrom forcedeth snd ehci_hcd usbcore
> snd_page_alloc evdev unix
> Dec 27 14:32:45 kiopa kernel: Pid: 0, comm: swapper Not tainted 2.6.15-rc5-mm1
> #2
> Dec 27 14:32:45 kiopa kernel: RIP: 0010:[<ffffffff80311453>]
> <ffffffff80311453>{_spin_unlock_irq+19}
> Dec 27 14:32:45 kiopa kernel: RSP: 0000:ffff810001ffbf08 EFLAGS: 00000246
> Dec 27 14:32:45 kiopa kernel: RAX: ffff810001ff3fd8 RBX: ffff810001ffbe58 RCX:
> ffffffff8040fba0
> Dec 27 14:32:45 kiopa kernel: RDX: 0000000000000001 RSI: ffff810001e19ad8 RDI:
> ffff810001e18c20
> Dec 27 14:32:45 kiopa kernel: RBP: ffffffff8010e354 R08: 00000000000000e9 R09:
> 0000000000000000
> Dec 27 14:32:45 kiopa kernel: R10: 0000000000000000 R11: ffff810001e17660 R12:
> ffffffff8014cd49
> Dec 27 14:32:45 kiopa kernel: R13: ffffffff801106ff R14: ffff810001ff3f18 R15:
> ffff810001ffbf18
> Dec 27 14:32:45 kiopa kernel: FS: 0000000000000000(0000) GS:ffffffff8041c080
> (0000) knlGS:00000000556b26c0
> Dec 27 14:32:45 kiopa kernel: CS: 0010 DS: 0018 ES: 0018 CR0:
> 000000008005003b
> Dec 27 14:32:45 kiopa kernel: CR2: 0000000056b8d012 CR3: 000000003cc2c000 CR4:
> 00000000000006e0
> Dec 27 14:32:45 kiopa kernel:
> Dec 27 14:32:45 kiopa kernel: Call Trace: <IRQ>
> <ffffffff80311449>{_spin_unlock_irq+9}
> <ffffffff8810db70>{:ipv6:addrconf_verify+0}
> Dec 27 14:32:45 kiopa kernel:
> <ffffffff8014d0e2>{run_ktimeout_softirq+370}
> <ffffffff801394c4>{__do_softirq+100}
> Dec 27 14:32:45 kiopa kernel: <ffffffff8010f166>{call_softirq+30}
> <ffffffff801106bc>{do_softirq+44}
> Dec 27 14:32:45 kiopa kernel: <ffffffff801391a8>{irq_exit+72}
> <ffffffff8010e9ca>{apic_timer_interrupt+98}
> Dec 27 14:32:45 kiopa kernel: <EOI>
> <ffffffff80311449>{_spin_unlock_irq+9} <ffffffff8030fed0>{thread_return+95}
> Dec 27 14:32:45 kiopa kernel: <ffffffff8010c69d>{default_idle+45}
> <ffffffff8010c731>{cpu_idle+97}
> Dec 27 14:32:45 kiopa kernel: <ffffffff80433ea5>{start_secondary+1253}
At a guess I'd say the new ktimeout code is playing up.
> The full log is at http://www.cmartin.tk/linux/dmesg.bz2 which is 7.9M
> uncompressed, with just the logs from the last boot.
>
> The date is wrong because this is a second boot. Time goes extremely fast.
> When I rebooted into an older kernel it said it was the 8th July 2006!
>
> The system halts for up to a minute (I got a console login timeout out after
> 60secs). The keyboard lights still change, but the cursor on the screen stays
> put. After a bit things return to normal for a bit, repeat until reboot.
>
> cmn
> --
> Carlos Mart?n http://www.cmartin.tk
* Andrew Morton <[email protected]> wrote:
> > Dec 27 14:32:45 kiopa kernel: BUG: soft lockup detected on CPU#1!
> > Dec 27 14:32:45 kiopa kernel: CPU 1:
> At a guess I'd say the new ktimeout code is playing up.
hm, the ktimeout patches only rename, they do not change any code or
semantics.
Ingo
When CONFIG_PAGE_OWNER=y, there is a bug in page allocation failure path.
(turn on Kernel Hacking -> Track page owner)
Patch is attached below.
error message is this
==
Dec 6 22:21:34 aworks kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000020
Dec 6 22:21:34 aworks kernel: printing eip:
Dec 6 22:21:34 aworks kernel: c0148267
Dec 6 22:21:34 aworks kernel: *pde = 00000000
Dec 6 22:21:34 aworks kernel: Oops: 0002 [#1]
Dec 6 22:21:34 aworks kernel: SMP
Dec 6 22:21:34 aworks kernel: last sysfs file: /class/vc/vcs2/dev
Dec 6 22:21:34 aworks kernel: Modules linked in: video
Dec 6 22:21:34 aworks kernel: CPU: 0
Dec 6 22:21:34 aworks kernel: EIP: 0060:[<c0148267>] Not tainted VLI
Dec 6 22:21:34 aworks kernel: EFLAGS: 00010286 (2.6.15-rc5-mm1)
Dec 6 22:21:34 aworks kernel: EIP is at __alloc_pages+0x297/0x3c0
Dec 6 22:21:34 aworks su(pam_unix)[2660]: session closed for user root
Dec 6 22:21:34 aworks kernel: eax: 0000000a ebx: e884c000 ecx: 00000000 edx: e884decc
Dec 6 22:21:34 aworks kernel: esi: 000242d2 edi: 00000000 ebp: e884decc esp: e884de88
Dec 6 22:21:34 aworks kernel: ds: 007b es: 007b ss: 0068
Dec 6 22:21:34 aworks kernel: Process bash (pid: 2663, threadinfo=e884c000 task=ed9ff070)
Dec 6 22:21:34 aworks kernel: Stack: <0>000242d2 0000000a c04a3ba8 00000042 00000000 000242d2 c04a3ba8 0000000a
Dec 6 22:21:34 aworks kernel: <0>00000010 00000000 e884c000 00000042 e884dea6 00000000 c1090000 000001f4
Dec 6 22:21:34 aworks kernel: <0>ec06abc0 e884ded8 c015ce58 c1090000 e884def0 c015d117 c1090000 e884dfa0
Dec 6 22:21:34 aworks kernel: Call Trace:
Dec 6 22:21:34 aworks kernel: [<c0103dc2>] show_stack+0xa2/0xe0
Dec 6 22:21:34 aworks kernel: [<c0103f8f>] show_registers+0x16f/0x200
Dec 6 22:21:34 aworks kernel: [<c01041df>] die+0x11f/0x1b0
Dec 6 22:21:34 aworks kernel: [<c0428500>] do_page_fault+0x330/0x638
Dec 6 22:21:34 aworks kernel: [<c0103a4f>] error_code+0x4f/0x54
Dec 6 22:21:34 aworks kernel: [<c015ce58>] alloc_fresh_huge_page+0x18/0x50
Dec 6 22:21:34 aworks kernel: [<c015d117>] set_max_huge_pages+0x47/0xc0
Dec 6 22:21:34 aworks kernel: [<c015d1d1>] hugetlb_sysctl_handler+0x41/0x50
Dec 6 22:21:34 aworks kernel: [<c0125c48>] do_rw_proc+0xe8/0x100
Dec 6 22:21:34 aworks kernel: [<c0125cde>] proc_writesys+0x2e/0x30
Dec 6 22:21:34 aworks kernel: [<c01668b6>] vfs_write+0xa6/0x190
Dec 6 22:21:34 aworks kernel: [<c0166a57>] sys_write+0x47/0x70
Dec 6 22:21:34 aworks kernel: [<c0102ecf>] sysenter_past_esp+0x54/0x75
Dec 6 22:21:34 aworks kernel: Code: c0 89 44 24 04 89 54 24 08 e8 06 6c fd ff e8 b1 bb fb ff e8 ac ce fc ff 8b 4d e0 8b 45 d8 8d 5d ec 89 ea 81 e3 00 e0 ff ff 89 cf <89> 41 20 89 71 24 83 c7 28 31 c0 b9 08 00 00 00 f3 ab 31 f6 39
==
--Kame
---
Fix NULL pointer reference of set_page_owner() in allcation faulure path.
Signed-Off-by: Kamezawa Hiroyuki <[email protected]>
Index: linux-2.6.15-rc5-mm1.org/mm/page_alloc.c
===================================================================
--- linux-2.6.15-rc5-mm1.org.orig/mm/page_alloc.c
+++ linux-2.6.15-rc5-mm1.org/mm/page_alloc.c
@@ -1136,7 +1136,8 @@ nopage:
}
got_pg:
#ifdef CONFIG_PAGE_OWNER
- set_page_owner(page, order, gfp_mask);
+ if (page)
+ set_page_owner(page, order, gfp_mask);
#endif
return page;
}
On Mon, Dec 05, 2005 at 10:40:55PM +0100, Adrian Bunk wrote:
> On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
> >...
> > Subsystem trees
> >...
> > +gregkh-usb-usbip.patch
> >
> > USB tree updates
> >...
>
> Problems with this patch:
> - USB_IP: no need for a "default N"
Why not? Is that the "default"?
> - USB_IP must be a tristate, because currently the illegal configurations
> USB=m, USB_IP=y, USB_IP_{VHCI,STUB}=y are allowed
> - compilation fails with USB_IP_VHCI=y, USB_IP_STUB=y:
Yeah, sorry about that. This code is going to get a lot of scrubbing
before it will go into mainline. Thanks for your patch, I'll apply it.
greg k-h
On Tue, Dec 06, 2005 at 04:02:16PM -0800, Greg KH wrote:
> On Mon, Dec 05, 2005 at 10:40:55PM +0100, Adrian Bunk wrote:
> > On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
> > >...
> > > Subsystem trees
> > >...
> > > +gregkh-usb-usbip.patch
> > >
> > > USB tree updates
> > >...
> >
> > Problems with this patch:
> > - USB_IP: no need for a "default N"
>
> Why not? Is that the "default"?
>...
Yes.
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi,
On Monday, 5 December 2005 08:21, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
}-- snip --{
> +x86_64-hpet-overflow.patch
This patch breaks resume from disk badly. The box hangs solid as soon as interrupts
are reenabled during resume (right after the image has been read). Unfortunately
> +x86_64-hpet-overflow-fix.patch
does not help.
Greetings,
Rafael
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
Update:
On Wednesday, 7 December 2005 01:46, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
> }-- snip --{
> > +x86_64-hpet-overflow.patch
>
> This patch breaks resume from disk badly. The box hangs solid as soon as interrupts
> are reenabled during resume (right after the image has been read).
I've just managed to get a call trace from it, which is appended.
Greetings,
Rafael
swsusp: Reading resume file was successful
PM: Preparing devices for restore.
Suspending device 1.0
Suspending device ide1
Suspending device 0.1
Suspending device ide0
Suspending device serial8250
Suspending device serio4
Suspending device serio3
Suspending device serio2
Suspending device serio1
Suspending device serio0
Suspending device i8042
Suspending device vesafb.0
Suspending device 0000:01:00.0
Suspending device 0000:02:02.0
Suspending device 0000:02:01.4
Suspending device 0000:02:01.3
Suspending device 0000:02:01.2
Suspending device 0000:02:01.1
Suspending device 0000:02:01.0
Suspending device 0000:02:00.0
Suspending device 0000:00:18.3
Suspending device 0000:00:18.2
Suspending device 0000:00:18.1
Suspending device 0000:00:18.0
Suspending device 0000:00:0b.0
Suspending device 0000:00:0a.0
Suspending device 0000:00:08.0
Suspending device 0000:00:06.0
Suspending device 0000:00:02.2
Suspending device 0000:00:02.1
Suspending device 0000:00:02.0
Suspending device 0000:00:01.1
Suspending device 0000:00:01.0
Suspending device 0000:00:00.0
Suspending device pci0000:00
Suspending device platform
PM: Restoring saved image.
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: usbserial thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia firmware_class yenta_socket rsrc_nonstatic pcmcia_core evdev joydev sg usbhid st
sr_mod ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom dm_mod parport_pc lp parport
Pid: 3304, comm: bash Not tainted 2.6.15-rc5-mm1 #1
RIP: 0010:[<ffffffff8013c87d>] <ffffffff8013c87d>{do_timer+77}
RSP: 0018:ffffffff80481eb8 EFLAGS: 00000002
RAX: 000000001d0f8788 RBX: 00000255e7679aa8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000003d09fa RDI: 0000000000000000
RBP: ffffffff80481ed8 R08: 0000000000000040 R09: 00000000ffffffff
R10: 0000000094fc4b38 R11: 00000000c0010008 R12: 000002560cbc37bc
R13: ffff81002bd63d38 R14: ffff81002bd63d38 R15: 0000000000000000
FS: 00002aaaab28fe80(0000) GS:ffffffff8050f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaaac2000 CR3: 000000002ad20000 CR4: 00000000000006e0
Process bash (pid: 3304, threadinfo ffff81002bd62000, task ffff810001fdb790)
Stack: 0000000000000fed 00000000000002b7 0000000000000b18 000002560cbc37bb
ffffffff80481f08 ffffffff80112dd1 ffffffff803d39c0 0000000000000000
ffff81002bd63d38 0000000000000000
Call Trace: <IRQ> <ffffffff80112dd1>{timer_interrupt+689} <ffffffff8015ae83>{handle_IRQ_event+51}
<ffffffff8015af72>{__do_IRQ+162} <ffffffff80111097>{do_IRQ+55}
<ffffffff8010f0b0>{ret_from_intr+0} <EOI> <ffffffff8011ae3d>{enable_lapic_nmi_watchdog+29}
<ffffffff8011ae63>{lapic_nmi_resume+19} <ffffffff8015296d>{swsusp_suspend+93}
<ffffffff8015296a>{swsusp_suspend+90} <ffffffff801537b8>{pm_suspend_disk+88}
<ffffffff80151266>{enter_state+118} <ffffffff801514a7>{state_store+119}
<ffffffff801c09a4>{subsys_attr_store+36} <ffffffff801c0e2a>{sysfs_write_file+202}
<ffffffff80180549>{vfs_write+233} <ffffffff801806f0>{sys_write+80}
<ffffffff8010eb0e>{system_call+126}
Code: 48 ff cb 48 85 c9 48 89 ce 74 25 8b 05 de 38 2a 00 48 63 d0
console shuts up ...
<7>APIC error on CPU0: 00(00)
Kernel panic - not syncing: Aiee, killing interrupt handler!
I don't know how resume normally handles the re-syncing of the wall
clock, but the problem here is obvious: do_timer runs a loop to
increment jiffies, which may require significant amounts of time
(depending how long the system was sleeping).
Whatever mechanism was previously used to adjust the wall clock during
resume, this (a) has to happen before enabling interrupts and (b) has to
communicate to the timer interrupt handler to adjust its last time stamp
taken (to compare against in the next run). Clearly, the code was broken
already before, as it doesn't handle the resume case (where the HPET
value read is entirely unrelated to the one read during the last timer
interrupt before suspend) at all, and even in the TSC timer case it
simply checks whether the TSC delta is negative (which is not a valid
condition, as, between the booting of the system and the OS resume there
may elapse more time than the system was running altogether prior to
suspend).
Jan
>>> "Rafael J. Wysocki" <[email protected]> 08.12.05 00:15:01 >>>
Update:
On Wednesday, 7 December 2005 01:46, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> >
> >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
> }-- snip --{
> > +x86_64-hpet-overflow.patch
>
> This patch breaks resume from disk badly. The box hangs solid as
soon as interrupts
> are reenabled during resume (right after the image has been read).
I've just managed to get a call trace from it, which is appended.
Greetings,
Rafael
swsusp: Reading resume file was successful
PM: Preparing devices for restore.
Suspending device 1.0
Suspending device ide1
Suspending device 0.1
Suspending device ide0
Suspending device serial8250
Suspending device serio4
Suspending device serio3
Suspending device serio2
Suspending device serio1
Suspending device serio0
Suspending device i8042
Suspending device vesafb.0
Suspending device 0000:01:00.0
Suspending device 0000:02:02.0
Suspending device 0000:02:01.4
Suspending device 0000:02:01.3
Suspending device 0000:02:01.2
Suspending device 0000:02:01.1
Suspending device 0000:02:01.0
Suspending device 0000:02:00.0
Suspending device 0000:00:18.3
Suspending device 0000:00:18.2
Suspending device 0000:00:18.1
Suspending device 0000:00:18.0
Suspending device 0000:00:0b.0
Suspending device 0000:00:0a.0
Suspending device 0000:00:08.0
Suspending device 0000:00:06.0
Suspending device 0000:00:02.2
Suspending device 0000:00:02.1
Suspending device 0000:00:02.0
Suspending device 0000:00:01.1
Suspending device 0000:00:01.0
Suspending device 0000:00:00.0
Suspending device pci0000:00
Suspending device platform
PM: Restoring saved image.
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: usbserial thermal processor fan button battery ac
snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia
firmware_class yenta_socket rsrc_nonstatic pcmcia_core evdev joydev sg
usbhid st
sr_mod ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom dm_mod
parport_pc lp parport
Pid: 3304, comm: bash Not tainted 2.6.15-rc5-mm1 #1
RIP: 0010:[<ffffffff8013c87d>] <ffffffff8013c87d>{do_timer+77}
RSP: 0018:ffffffff80481eb8 EFLAGS: 00000002
RAX: 000000001d0f8788 RBX: 00000255e7679aa8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000003d09fa RDI: 0000000000000000
RBP: ffffffff80481ed8 R08: 0000000000000040 R09: 00000000ffffffff
R10: 0000000094fc4b38 R11: 00000000c0010008 R12: 000002560cbc37bc
R13: ffff81002bd63d38 R14: ffff81002bd63d38 R15: 0000000000000000
FS: 00002aaaab28fe80(0000) GS:ffffffff8050f000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaaac2000 CR3: 000000002ad20000 CR4: 00000000000006e0
Process bash (pid: 3304, threadinfo ffff81002bd62000, task
ffff810001fdb790)
Stack: 0000000000000fed 00000000000002b7 0000000000000b18
000002560cbc37bb
ffffffff80481f08 ffffffff80112dd1 ffffffff803d39c0
0000000000000000
ffff81002bd63d38 0000000000000000
Call Trace: <IRQ> <ffffffff80112dd1>{timer_interrupt+689}
<ffffffff8015ae83>{handle_IRQ_event+51}
<ffffffff8015af72>{__do_IRQ+162} <ffffffff80111097>{do_IRQ+55}
<ffffffff8010f0b0>{ret_from_intr+0} <EOI>
<ffffffff8011ae3d>{enable_lapic_nmi_watchdog+29}
<ffffffff8011ae63>{lapic_nmi_resume+19}
<ffffffff8015296d>{swsusp_suspend+93}
<ffffffff8015296a>{swsusp_suspend+90}
<ffffffff801537b8>{pm_suspend_disk+88}
<ffffffff80151266>{enter_state+118}
<ffffffff801514a7>{state_store+119}
<ffffffff801c09a4>{subsys_attr_store+36}
<ffffffff801c0e2a>{sysfs_write_file+202}
<ffffffff80180549>{vfs_write+233}
<ffffffff801806f0>{sys_write+80}
<ffffffff8010eb0e>{system_call+126}
Code: 48 ff cb 48 85 c9 48 89 ce 74 25 8b 05 de 38 2a 00 48 63 d0
console shuts up ...
<7>APIC error on CPU0: 00(00)
Kernel panic - not syncing: Aiee, killing interrupt handler!
Hi,
On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> I don't know how resume normally handles the re-syncing of the wall
> clock, but the problem here is obvious: do_timer runs a loop to
> increment jiffies, which may require significant amounts of time
> (depending how long the system was sleeping).
>
> Whatever mechanism was previously used to adjust the wall clock during
> resume, this (a) has to happen before enabling interrupts and (b) has to
> communicate to the timer interrupt handler to adjust its last time stamp
> taken (to compare against in the next run). Clearly, the code was broken
> already before, as it doesn't handle the resume case (where the HPET
> value read is entirely unrelated to the one read during the last timer
> interrupt before suspend) at all, and even in the TSC timer case it
> simply checks whether the TSC delta is negative (which is not a valid
> condition, as, between the booting of the system and the OS resume there
> may elapse more time than the system was running altogether prior to
> suspend).
Well, I'm not an expert, but I think I understand your argumentation.
However, the problem is that resume _works_ without the patch
and doesn't work with it, which is a regression. (BTW, without
the patch the wall clock is evidently correct after resume.)
Frankly I don't know who should fix the broken code, but my
understanding has always been that if someone's patch
introduces a regression, he/she ough to change the patch
so that it does not happen.
Greetings,
Rafael
> >>> "Rafael J. Wysocki" <[email protected]> 08.12.05 00:15:01 >>>
> Update:
>
> On Wednesday, 7 December 2005 01:46, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> > >
> > >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
> >
> > }-- snip --{
> > > +x86_64-hpet-overflow.patch
> >
> > This patch breaks resume from disk badly. The box hangs solid as
> soon as interrupts
> > are reenabled during resume (right after the image has been read).
>
> I've just managed to get a call trace from it, which is appended.
>
> Greetings,
> Rafael
>
>
> swsusp: Reading resume file was successful
> PM: Preparing devices for restore.
> Suspending device 1.0
> Suspending device ide1
> Suspending device 0.1
> Suspending device ide0
> Suspending device serial8250
> Suspending device serio4
> Suspending device serio3
> Suspending device serio2
> Suspending device serio1
> Suspending device serio0
> Suspending device i8042
> Suspending device vesafb.0
> Suspending device 0000:01:00.0
> Suspending device 0000:02:02.0
> Suspending device 0000:02:01.4
> Suspending device 0000:02:01.3
> Suspending device 0000:02:01.2
> Suspending device 0000:02:01.1
> Suspending device 0000:02:01.0
> Suspending device 0000:02:00.0
> Suspending device 0000:00:18.3
> Suspending device 0000:00:18.2
> Suspending device 0000:00:18.1
> Suspending device 0000:00:18.0
> Suspending device 0000:00:0b.0
> Suspending device 0000:00:0a.0
> Suspending device 0000:00:08.0
> Suspending device 0000:00:06.0
> Suspending device 0000:00:02.2
> Suspending device 0000:00:02.1
> Suspending device 0000:00:02.0
> Suspending device 0000:00:01.1
> Suspending device 0000:00:01.0
> Suspending device 0000:00:00.0
> Suspending device pci0000:00
> Suspending device platform
> PM: Restoring saved image.
> NMI Watchdog detected LOCKUP on CPU 0
> CPU 0
> Modules linked in: usbserial thermal processor fan button battery ac
> snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
> pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia
> firmware_class yenta_socket rsrc_nonstatic pcmcia_core evdev joydev sg
> usbhid st
> sr_mod ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom dm_mod
> parport_pc lp parport
> Pid: 3304, comm: bash Not tainted 2.6.15-rc5-mm1 #1
> RIP: 0010:[<ffffffff8013c87d>] <ffffffff8013c87d>{do_timer+77}
> RSP: 0018:ffffffff80481eb8 EFLAGS: 00000002
> RAX: 000000001d0f8788 RBX: 00000255e7679aa8 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000003d09fa RDI: 0000000000000000
> RBP: ffffffff80481ed8 R08: 0000000000000040 R09: 00000000ffffffff
> R10: 0000000094fc4b38 R11: 00000000c0010008 R12: 000002560cbc37bc
> R13: ffff81002bd63d38 R14: ffff81002bd63d38 R15: 0000000000000000
> FS: 00002aaaab28fe80(0000) GS:ffffffff8050f000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002aaaaaac2000 CR3: 000000002ad20000 CR4: 00000000000006e0
> Process bash (pid: 3304, threadinfo ffff81002bd62000, task
> ffff810001fdb790)
> Stack: 0000000000000fed 00000000000002b7 0000000000000b18
> 000002560cbc37bb
> ffffffff80481f08 ffffffff80112dd1 ffffffff803d39c0
> 0000000000000000
> ffff81002bd63d38 0000000000000000
> Call Trace: <IRQ> <ffffffff80112dd1>{timer_interrupt+689}
> <ffffffff8015ae83>{handle_IRQ_event+51}
> <ffffffff8015af72>{__do_IRQ+162} <ffffffff80111097>{do_IRQ+55}
> <ffffffff8010f0b0>{ret_from_intr+0} <EOI>
> <ffffffff8011ae3d>{enable_lapic_nmi_watchdog+29}
> <ffffffff8011ae63>{lapic_nmi_resume+19}
> <ffffffff8015296d>{swsusp_suspend+93}
> <ffffffff8015296a>{swsusp_suspend+90}
> <ffffffff801537b8>{pm_suspend_disk+88}
> <ffffffff80151266>{enter_state+118}
> <ffffffff801514a7>{state_store+119}
> <ffffffff801c09a4>{subsys_attr_store+36}
> <ffffffff801c0e2a>{sysfs_write_file+202}
> <ffffffff80180549>{vfs_write+233}
> <ffffffff801806f0>{sys_write+80}
> <ffffffff8010eb0e>{system_call+126}
>
> Code: 48 ff cb 48 85 c9 48 89 ce 74 25 8b 05 de 38 2a 00 48 63 d0
> console shuts up ...
> <7>APIC error on CPU0: 00(00)
> Kernel panic - not syncing: Aiee, killing interrupt handler!
>
>
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
In file included from sound/pci/ens1371.c:2:
sound/pci/ens1370.c: In function `snd_audiopci_probe':
sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
reported only once
sound/pci/ens1370.c:2462: error: for each function it appears in.)
sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
function)
make[2]: *** [sound/pci/ens1371.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Thanks,
Badari
Badari Pulavarty wrote:
> On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
>
> In file included from sound/pci/ens1371.c:2:
> sound/pci/ens1370.c: In function `snd_audiopci_probe':
> sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
> function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
> reported only once
> sound/pci/ens1370.c:2462: error: for each function it appears in.)
> sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
> function)
> make[2]: *** [sound/pci/ens1371.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
>
>
> Thanks,
> Badari
>
Thank you for the report, can you please raise a bug on
http://bugzilla.kernel.org/
or
http://alsa-project.org/
We can then track this, and fix it.
FYI, I can reproduce the problem here already.
Update:
On Thursday, 8 December 2005 11:53, Rafael J. Wysocki wrote:
> On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
> >
> > Whatever mechanism was previously used to adjust the wall clock during
> > resume, this (a) has to happen before enabling interrupts and (b) has to
> > communicate to the timer interrupt handler to adjust its last time stamp
> > taken (to compare against in the next run). Clearly, the code was broken
> > already before, as it doesn't handle the resume case (where the HPET
> > value read is entirely unrelated to the one read during the last timer
> > interrupt before suspend) at all, and even in the TSC timer case it
> > simply checks whether the TSC delta is negative (which is not a valid
> > condition, as, between the booting of the system and the OS resume there
> > may elapse more time than the system was running altogether prior to
> > suspend).
>
> Well, I'm not an expert, but I think I understand your argumentation.
> However, the problem is that resume _works_ without the patch
> and doesn't work with it, which is a regression. (BTW, without
> the patch the wall clock is evidently correct after resume.)
>
> Frankly I don't know who should fix the broken code,
FWIW, I have tried to fix it myself.
The appended patch seems to work on my box, but I'm afraid
it's not the right fix (at least in general). Please advise.
Greetings,
Rafael
arch/x86_64/kernel/time.c | 15 +++++++++++++++
1 files changed, 15 insertions(+)
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
--- linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c 2005-12-08 21:39:29.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c 2005-12-08 22:44:48.000000000 +0100
@@ -1117,6 +1117,7 @@
unsigned long sec;
unsigned long ctime = get_cmos_time();
unsigned long sleep_length = (ctime - sleep_start) * HZ;
+ long offset = 0;
if (vxtime.hpet_address)
hpet_reenable();
@@ -1125,6 +1126,20 @@
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(&xtime_lock,flags);
+ if (vxtime.hpet_address)
+ offset = hpet_readl(HPET_COUNTER);
+ if (hpet_use_timer) {
+ unsigned int hi1 = hpet64 > 0 ? hpet_readl(HPET_COUNTER+4) : 0;
+
+ offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+ if (hpet64 > 0)
+ offset += (long)(offset >= 0 ? hi1 : hpet_readl(HPET_COUNTER+4)) << 32;
+ else
+ offset = (unsigned int)offset;
+ }
+ if (vxtime.mode == VXTIME_HPET)
+ vxtime.last = offset;
+ rdtscll_sync(&vxtime.last_tsc);
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
write_sequnlock_irqrestore(&xtime_lock,flags);
On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
> I don't know how resume normally handles the re-syncing of the wall
> clock, but the problem here is obvious: do_timer runs a loop to
> increment jiffies, which may require significant amounts of time
> (depending how long the system was sleeping).
It would be good if someone could submit a patch to fix
this up properly. It indeed sounds wrong.
The HPET patch seems to be generally unhappy. With it applied
I get lots of obviously wrong softlockup warnings from the
softlockup watchdog thread on a dual NForce4 system. So something
goes wrong with the timing there. The strange thing
is that the system doesn't even have a HPET table so HPET code shouldn't
be executed - but it goes away when I revert the patch. Very
mysterious.
Also I think vgettimeofday doesn't handle 64bit HPET correctly
yet. Also why does it not use hpet_readq?
I suspect the 64bit HPET patch needs some more cooking. I think
I will drop it for now.
I would suggest you submit the cleanups in there separately
(without changing semantics yet)
then it will be easier to test in the future too.
-Andi
Hi,
On Thursday, 8 December 2005 23:47, Andi Kleen wrote:
> On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
>
> It would be good if someone could submit a patch to fix
> this up properly. It indeed sounds wrong.
Well, timer_resume() does adjust jiffies and wall_jiffies.
The problem seems to be that vxtime.last and/or vxtime.last_tsc are not
adjusted by it which makes the timer interrupt handler unhappy (with the
hpet-overflow patch applied, that is).
Greetings,
Rafael
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
On Thu, Dec 08, 2005 at 11:09:43AM -0800, Badari Pulavarty wrote:
> On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
> In file included from sound/pci/ens1371.c:2:
> sound/pci/ens1370.c: In function `snd_audiopci_probe':
> sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
> function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
> reported only once
> sound/pci/ens1370.c:2462: error: for each function it appears in.)
> sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
> function)
> make[2]: *** [sound/pci/ens1371.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
Jaroslav, this seems to come from your
[ALSA] ens1371: added spdif and lineio module option
patch in the ALSA git tree if SUPPORT_JOYSTICK=n.
> Thanks,
> Badari
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
I just noticed (maybe too late) that this kernel has the "pata_via"
driver and decided to try it. It works here, but has one drawback: it is
slower than the old "via82cxxx" IDE driver.
My configuration with the via82cxxx driver:
/dev/hda = disk, QUANTUM FIREBALLlct20
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1
/dev/hdb = SAMSUNG CD-ROM SC-148F
Drive is old, supports only mdma2
There are also /dev/hdc and /dev/hdd, irrelevant here.
With the via82cxxx driver, I can get speed around 20 MB/s from /dev/hda.
The pata_via driver downgrades this to 7 MB/s because it needlessly
drops the disk to MWDMA2 mode.
--
Alexander E. Patrakov
Alexander E. Patrakov wrote:
> Andrew Morton wrote:
>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>>
>
>
> I just noticed (maybe too late) that this kernel has the "pata_via"
> driver and decided to try it. It works here, but has one drawback: it is
> slower than the old "via82cxxx" IDE driver.
>
> My configuration with the via82cxxx driver:
>
> /dev/hda = disk, QUANTUM FIREBALLlct20
> Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1
>
> /dev/hdb = SAMSUNG CD-ROM SC-148F
> Drive is old, supports only mdma2
>
> There are also /dev/hdc and /dev/hdd, irrelevant here.
>
> With the via82cxxx driver, I can get speed around 20 MB/s from /dev/hda.
> The pata_via driver downgrades this to 7 MB/s because it needlessly
> drops the disk to MWDMA2 mode.
That's expected, as libata currently limits all drives on a bus to the
maximum speed of the slowest drive. That's needed by some controllers,
but not all.
I'm pretty sure Alan plans to fix that (at least ISTR him mentioning it).
Jeff
On Fri, 9 Dec 2005, Adrian Bunk wrote:
> On Thu, Dec 08, 2005 at 11:09:43AM -0800, Badari Pulavarty wrote:
> > On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> >
> > In file included from sound/pci/ens1371.c:2:
> > sound/pci/ens1370.c: In function `snd_audiopci_probe':
> > sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
> > function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
> > reported only once
> > sound/pci/ens1370.c:2462: error: for each function it appears in.)
> > sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
> > function)
> > make[2]: *** [sound/pci/ens1371.o] Error 1
> > make[2]: *** Waiting for unfinished jobs....
>
> Jaroslav, this seems to come from your
>
> [ALSA] ens1371: added spdif and lineio module option
>
> patch in the ALSA git tree if SUPPORT_JOYSTICK=n.
It's already fixed in ALSA git tree:
[ALSA] ens1371: fix compilation without SUPPORT_JOYSTICK
Modules: ENS1370/1+ driver
Move the spdif and lineio parameters around so that they are compiled
even when SUPPORT_JOYSTICK isn't set.
Signed-off-by: Clemens Ladisch <[email protected]>
Jaroslav
-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
>>> Andi Kleen <[email protected]> 08.12.05 23:47:35 >>>
>On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
>> I don't know how resume normally handles the re-syncing of the wall
>> clock, but the problem here is obvious: do_timer runs a loop to
>> increment jiffies, which may require significant amounts of time
>> (depending how long the system was sleeping).
>
>It would be good if someone could submit a patch to fix
>this up properly. It indeed sounds wrong.
With the nlkd patches I actually submitted code that does deal with the
calculation when significant amounts of ticks have been missed. However,
this is only part of the problem. What is more important first is for
the resume code to tell the timer interrupt handlers that it shouldn't
consider the last TSC (or other time stamp) value read prior to suspend,
but rather start anew.
>The HPET patch seems to be generally unhappy. With it applied
>I get lots of obviously wrong softlockup warnings from the
>softlockup watchdog thread on a dual NForce4 system. So something
>goes wrong with the timing there. The strange thing
>is that the system doesn't even have a HPET table so HPET code
shouldn't
>be executed - but it goes away when I revert the patch. Very
>mysterious.
It doesn't only change the HPET code, the TSC code was suffering from
overflow problems, too, which the patch also tries to address. I can't,
however, see where or how it would cause softlockup reports. Do the
printed call stacks provide any useful information?
>Also I think vgettimeofday doesn't handle 64bit HPET correctly
>yet. Also why does it not use hpet_readq?
For the simple reason that there is no way to know whether the entire
interconnect from CPU to HPET is (at least) 64 bits wide. At least
theoretically implementations are permitted to use 32-bit components;
the HPET spec specifically warns about that.
>I suspect the 64bit HPET patch needs some more cooking. I think
>I will drop it for now.
>
>I would suggest you submit the cleanups in there separately
>(without changing semantics yet)
>then it will be easier to test in the future too.
What cleanups are you referring to here?
Jan
> >The HPET patch seems to be generally unhappy. With it applied
> >I get lots of obviously wrong softlockup warnings from the
> >softlockup watchdog thread on a dual NForce4 system. So something
> >goes wrong with the timing there. The strange thing
> >is that the system doesn't even have a HPET table so HPET code
> shouldn't
> >be executed - but it goes away when I revert the patch. Very
> >mysterious.
>
> It doesn't only change the HPET code, the TSC code was suffering from
> overflow problems, too, which the patch also tries to address. I can't,
> however, see where or how it would cause softlockup reports. Do the
> printed call stacks provide any useful information?
No they occur in random places - often even in idle.
>
> >Also I think vgettimeofday doesn't handle 64bit HPET correctly
> >yet. Also why does it not use hpet_readq?
>
> For the simple reason that there is no way to know whether the entire
> interconnect from CPU to HPET is (at least) 64 bits wide. At least
> theoretically implementations are permitted to use 32-bit components;
> the HPET spec specifically warns about that.
Doesn't that refer to the CPUs ?
>
> >I suspect the 64bit HPET patch needs some more cooking. I think
> >I will drop it for now.
> >
> >I would suggest you submit the cleanups in there separately
> >(without changing semantics yet)
> >then it will be easier to test in the future too.
>
> What cleanups are you referring to here?
Like the removal of the HPET.*DANGEROUS hack and some others.
-Andi
It's a possible way to address this, but I'd rather just set a flag
indicating that the last-whatever values should not be considered (to
get into a state just like after initial boot). Jan
>>> "Rafael J. Wysocki" <[email protected]> 08.12.05 23:35:49 >>>
Update:
On Thursday, 8 December 2005 11:53, Rafael J. Wysocki wrote:
> On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the
wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
> >
> > Whatever mechanism was previously used to adjust the wall clock
during
> > resume, this (a) has to happen before enabling interrupts and (b)
has to
> > communicate to the timer interrupt handler to adjust its last time
stamp
> > taken (to compare against in the next run). Clearly, the code was
broken
> > already before, as it doesn't handle the resume case (where the
HPET
> > value read is entirely unrelated to the one read during the last
timer
> > interrupt before suspend) at all, and even in the TSC timer case
it
> > simply checks whether the TSC delta is negative (which is not a
valid
> > condition, as, between the booting of the system and the OS resume
there
> > may elapse more time than the system was running altogether prior
to
> > suspend).
>
> Well, I'm not an expert, but I think I understand your
argumentation.
> However, the problem is that resume _works_ without the patch
> and doesn't work with it, which is a regression. (BTW, without
> the patch the wall clock is evidently correct after resume.)
>
> Frankly I don't know who should fix the broken code,
FWIW, I have tried to fix it myself.
The appended patch seems to work on my box, but I'm afraid
it's not the right fix (at least in general). Please advise.
Greetings,
Rafael
arch/x86_64/kernel/time.c | 15 +++++++++++++++
1 files changed, 15 insertions(+)
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
---
linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c 2005-12-08
21:39:29.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c 2005-12-08
22:44:48.000000000 +0100
@@ -1117,6 +1117,7 @@
unsigned long sec;
unsigned long ctime = get_cmos_time();
unsigned long sleep_length = (ctime - sleep_start) * HZ;
+ long offset = 0;
if (vxtime.hpet_address)
hpet_reenable();
@@ -1125,6 +1126,20 @@
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(&xtime_lock,flags);
+ if (vxtime.hpet_address)
+ offset = hpet_readl(HPET_COUNTER);
+ if (hpet_use_timer) {
+ unsigned int hi1 = hpet64 > 0 ?
hpet_readl(HPET_COUNTER+4) : 0;
+
+ offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+ if (hpet64 > 0)
+ offset += (long)(offset >= 0 ? hi1 :
hpet_readl(HPET_COUNTER+4)) << 32;
+ else
+ offset = (unsigned int)offset;
+ }
+ if (vxtime.mode == VXTIME_HPET)
+ vxtime.last = offset;
+ rdtscll_sync(&vxtime.last_tsc);
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
write_sequnlock_irqrestore(&xtime_lock,flags);
On Fri, Dec 09, 2005 at 10:15:51AM +0100, Jan Beulich wrote:
> It's a possible way to address this, but I'd rather just set a flag
> indicating that the last-whatever values should not be considered (to
> get into a state just like after initial boot). Jan
Sounds reasonable.
-Andi
>> >Also I think vgettimeofday doesn't handle 64bit HPET correctly
>> >yet. Also why does it not use hpet_readq?
>>
>> For the simple reason that there is no way to know whether the
entire
>> interconnect from CPU to HPET is (at least) 64 bits wide. At least
>> theoretically implementations are permitted to use 32-bit
components;
>> the HPET spec specifically warns about that.
>
>Doesn't that refer to the CPUs ?
No, all bus components and other chips between CPU and the implementing
chip (including the latter) must have 64-bit data paths and guarantee
not to break up 64-bit reads into pairs of 32-bit ones. Actually, it's
the other way around - since most modern 32-but x86 CPUs have (as far as
I know) 64-bit data busses, it is normally not the CPU that restricts
accesses to 32 bits.
Jan
On Friday, 9 December 2005 10:15, Jan Beulich wrote:
> It's a possible way to address this, but I'd rather just set a flag
> indicating that the last-whatever values should not be considered (to
> get into a state just like after initial boot). Jan
OK, but what is the interrupt handler supposed to do if the
vxtime.last* values are invalid? I guess assume delta = 0?
BTW, in the interrupt handler there is:
__asm__("mulq %1\n\t"
"shrdq $32, %%rdx, %0"
: "+a" (delta)
: "rm" (vxtime.tsc_quot)
: "rdx");
Is the "+a" a typo?
Rafael
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
>>> "Rafael J. Wysocki" <[email protected]> 09.12.05 12:20:05 >>>
>On Friday, 9 December 2005 10:15, Jan Beulich wrote:
>> It's a possible way to address this, but I'd rather just set a flag
>> indicating that the last-whatever values should not be considered
(to
>> get into a state just like after initial boot). Jan
>
>OK, but what is the interrupt handler supposed to do if the
>vxtime.last* values are invalid? I guess assume delta = 0?
As I said, the state should be (re)set to whatever is in effect at
boot.
>BTW, in the interrupt handler there is:
>
> __asm__("mulq %1\n\t"
> "shrdq $32, %%rdx, %0"
> : "+a" (delta)
> : "rm" (vxtime.tsc_quot)
> : "rdx");
>
>Is the "+a" a typo?
Why would you think so?
Jan
On Friday, 9 December 2005 13:41, Jan Beulich wrote:
> >>> "Rafael J. Wysocki" <[email protected]> 09.12.05 12:20:05 >>>
> >On Friday, 9 December 2005 10:15, Jan Beulich wrote:
> >> It's a possible way to address this, but I'd rather just set a flag
> >> indicating that the last-whatever values should not be considered
> (to
> >> get into a state just like after initial boot). Jan
> >
> >OK, but what is the interrupt handler supposed to do if the
> >vxtime.last* values are invalid? I guess assume delta = 0?
>
> As I said, the state should be (re)set to whatever is in effect at
> boot.
>
> >BTW, in the interrupt handler there is:
> >
> > __asm__("mulq %1\n\t"
> > "shrdq $32, %%rdx, %0"
> > : "+a" (delta)
> > : "rm" (vxtime.tsc_quot)
> > : "rdx");
> >
> >Is the "+a" a typo?
>
> Why would you think so?
Well, "=" is usually used in that context and "+", "=" are on the same key. ;-)
Rafael
--
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
On Friday, 9 December 2005 13:41, Jan Beulich wrote:
> >>> "Rafael J. Wysocki" <[email protected]> 09.12.05 12:20:05 >>>
> >On Friday, 9 December 2005 10:15, Jan Beulich wrote:
> >> It's a possible way to address this, but I'd rather just set a flag
> >> indicating that the last-whatever values should not be considered
> (to
> >> get into a state just like after initial boot). Jan
> >
> >OK, but what is the interrupt handler supposed to do if the
> >vxtime.last* values are invalid? I guess assume delta = 0?
>
> As I said, the state should be (re)set to whatever is in effect at
> boot.
Is the appended patch better than the previous one?
Rafael
arch/x86_64/kernel/time.c | 9 +++++++++
1 files changed, 9 insertions(+)
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
--- linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c 2005-12-08 22:57:33.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c 2005-12-09 14:37:31.000000000 +0100
@@ -65,6 +65,7 @@ unsigned long hpet_tick;
static int hpet_use_timer;
unsigned long vxtime_hz = PIT_TICK_RATE;
unsigned long long monotonic_base;
+static int vxtime_last_invalid; /* for the interrupt handler */
static int report_lost_ticks; /* command line option */
@@ -417,6 +418,13 @@ static irqreturn_t timer_interrupt(int i
rdtscll_sync(&tsc);
+ if (vxtime_last_invalid) {
+ if (vxtime.mode == VXTIME_HPET)
+ vxtime.last = offset;
+ vxtime.last_tsc = tsc;
+ vxtime_last_invalid = 0;
+ }
+
if (vxtime.mode == VXTIME_HPET) {
if (hpet64 > 0) {
unsigned long delta = offset - vxtime.last;
@@ -1125,6 +1133,7 @@ static int timer_resume(struct sys_devic
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(&xtime_lock,flags);
+ vxtime_last_invalid = 1;
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
write_sequnlock_irqrestore(&xtime_lock,flags);
On Tue, Dec 06, 2005 at 12:05:24AM +0100, J.A. Magallon wrote:
> On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> >
> >
>
> I still get this oops on boot, then the machine freezes hard on the init
> process:
>
> usb_set_configuration+0x22b/0x4df
> usb_new_device+0x105/0x158
> hub_port_connect_change+0x2de/0x37e
> clear_port_feature+0x48/0x4d
> hub_events+0x2aa/0x42f
> hub_thread+0x14/0xe2
> autoremove_wake_function+0x0/0x37
> kthread+0x93/0x97
> kthread+0x0/0x97
> kernel_thread_helper+0x5/0xb
>
> udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> failed.
>
> I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
>
> Any ideas ?
Do you have the same problem with 2.6.15-rc5?
What is in /etc/udev/agents.d/usb/usbcore?
What distro is this?
What kind of usb devices do you have attached?
thanks,
greg k-h
On Sat, 10 Dec 2005 15:36:55 -0800, Greg KH <[email protected]> wrote:
> On Tue, Dec 06, 2005 at 12:05:24AM +0100, J.A. Magallon wrote:
> > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > >
> > >
> >
> > I still get this oops on boot, then the machine freezes hard on the init
> > process:
> >
> > usb_set_configuration+0x22b/0x4df
> > usb_new_device+0x105/0x158
> > hub_port_connect_change+0x2de/0x37e
> > clear_port_feature+0x48/0x4d
> > hub_events+0x2aa/0x42f
> > hub_thread+0x14/0xe2
> > autoremove_wake_function+0x0/0x37
> > kthread+0x93/0x97
> > kthread+0x0/0x97
> > kernel_thread_helper+0x5/0xb
> >
> > udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> > failed.
> >
> > I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
> >
> > Any ideas ?
>
> Do you have the same problem with 2.6.15-rc5?
>
> What is in /etc/udev/agents.d/usb/usbcore?
> What distro is this?
> What kind of usb devices do you have attached?
>
> thanks,
Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
try to boot whith them.
For the rest of your questions:
- I have no /etc/udev/agents.d/usb/usbcore
- I have killed all the devfs compat scripts/rules (BTW, when will be finally
erradicated from udev ;) ?
- Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
were with 075).
More info soon...
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
On Sun, 11 Dec 2005 00:46:11 +0100, "J.A. Magallon" <[email protected]> wrote:
> On Sat, 10 Dec 2005 15:36:55 -0800, Greg KH <[email protected]> wrote:
>
> > On Tue, Dec 06, 2005 at 12:05:24AM +0100, J.A. Magallon wrote:
> > > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
> > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > >
> > > >
> > >
> > > I still get this oops on boot, then the machine freezes hard on the init
> > > process:
> > >
> > > usb_set_configuration+0x22b/0x4df
> > > usb_new_device+0x105/0x158
> > > hub_port_connect_change+0x2de/0x37e
> > > clear_port_feature+0x48/0x4d
> > > hub_events+0x2aa/0x42f
> > > hub_thread+0x14/0xe2
> > > autoremove_wake_function+0x0/0x37
> > > kthread+0x93/0x97
> > > kthread+0x0/0x97
> > > kernel_thread_helper+0x5/0xb
> > >
> > > udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> > > failed.
> > >
> > > I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
> > >
> > > Any ideas ?
> >
> > Do you have the same problem with 2.6.15-rc5?
> >
> > What is in /etc/udev/agents.d/usb/usbcore?
> > What distro is this?
> > What kind of usb devices do you have attached?
> >
> > thanks,
>
> Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> try to boot whith them.
>
> For the rest of your questions:
> - I have no /etc/udev/agents.d/usb/usbcore
> - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> erradicated from udev ;) ?
> - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> were with 075).
>
> More info soon...
>
No problems with plain rc5. It does not seem to _always_ happen on -mm1,
I thing I even got a clean boot, but just one.
Detailed oops screenshot is here:
http://belly.cps.unizar.es/~magallon/oops/oops.jpg
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
>Is the appended patch better than the previous one?
It looks better, but still not ideal. While I hinted towards using a
flag, I didn't necessarily mean this in the exact sense (I just didn't
look at how exactly the resume code is structured, nor did I exactly
remember how the init code sets up things). Now having looked at the
code, it'd seem to me that resume should just duplicate part of what
init() does: initialize vxtime.last and/or vxtime.last_tsc. But for
making things accurate, the value stored in vxtime.last_tsc may need
adjustment (so that it matches the value that would have been stored one
timer tick before the first timer tick after resume).
I'm sorry for not immediately coming up with an appropriate patch
myself, but I'm currently hunting down a problem more severe than broken
resume (and Andi indicated he wants some polishing done on the original
patch anyway).
Jan
***************
arch/x86_64/kernel/time.c | 9 +++++++++
1 files changed, 9 insertions(+)
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
---
linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c 2005-12-08
22:57:33.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c 2005-12-09
14:37:31.000000000 +0100
@@ -65,6 +65,7 @@ unsigned long hpet_tick;
static int hpet_use_timer;
unsigned long vxtime_hz = PIT_TICK_RATE;
unsigned long long monotonic_base;
+static int vxtime_last_invalid; /* for the interrupt
handler */
static int report_lost_ticks; /* command line option
*/
@@ -417,6 +418,13 @@ static irqreturn_t timer_interrupt(int i
rdtscll_sync(&tsc);
+ if (vxtime_last_invalid) {
+ if (vxtime.mode == VXTIME_HPET)
+ vxtime.last = offset;
+ vxtime.last_tsc = tsc;
+ vxtime_last_invalid = 0;
+ }
+
if (vxtime.mode == VXTIME_HPET) {
if (hpet64 > 0) {
unsigned long delta = offset - vxtime.last;
@@ -1125,6 +1133,7 @@ static int timer_resume(struct sys_devic
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(&xtime_lock,flags);
+ vxtime_last_invalid = 1;
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
write_sequnlock_irqrestore(&xtime_lock,flags);
> I'm sorry for not immediately coming up with an appropriate patch
> myself, but I'm currently hunting down a problem more severe than broken
> resume (and Andi indicated he wants some polishing done on the original
> patch anyway).
... and one would need to work out why the softlockup detector
triggered. The patch is out of the tree right now.
-Andi
On Gwe, 2005-12-09 at 06:09 +0500, Alexander E. Patrakov wrote:
> With the via82cxxx driver, I can get speed around 20 MB/s from /dev/hda.
> The pata_via driver downgrades this to 7 MB/s because it needlessly
> drops the disk to MWDMA2 mode.
This is fixed in the ide patches I've been posting and has been fixed
for a long time. The libata core in the base kernel however isn't bright
enough to independantly tune master and slave.
Jeff asked me to finish sorting out and testing some other things with
those changes (notably ata_piix) to ensure that they don't break
existing setups. I've got that mostly done now although it took some
time because both the original ata_piix and the ide/pci/piix driver turn
out to contain bad mistakes.
I hope to be able to feed the relevant stuff to Jeff this week.
"J.A. Magallon" <[email protected]> wrote:
>
> > Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> > try to boot whith them.
> >
> > For the rest of your questions:
> > - I have no /etc/udev/agents.d/usb/usbcore
> > - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> > erradicated from udev ;) ?
> > - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> > were with 075).
> >
> > More info soon...
> >
>
> No problems with plain rc5. It does not seem to _always_ happen on -mm1,
> I thing I even got a clean boot, but just one.
> Detailed oops screenshot is here:
>
> http://belly.cps.unizar.es/~magallon/oops/oops.jpg
>
Thanks for that.
Let's add the usb list..
On Mon, 12 Dec 2005, Andrew Morton wrote:
> "J.A. Magallon" <[email protected]> wrote:
> >
> > > Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> > > try to boot whith them.
> > >
> > > For the rest of your questions:
> > > - I have no /etc/udev/agents.d/usb/usbcore
> > > - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> > > erradicated from udev ;) ?
> > > - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> > > were with 075).
> > >
> > > More info soon...
> > >
> >
> > No problems with plain rc5. It does not seem to _always_ happen on -mm1,
> > I thing I even got a clean boot, but just one.
> > Detailed oops screenshot is here:
> >
> > http://belly.cps.unizar.es/~magallon/oops/oops.jpg
> >
>
> Thanks for that.
>
> Let's add the usb list..
Uh-oh. Looks like this one was my fault... Clashing uses of a local
variable. :-(
Does this patch fix it?
Alan Stern
Index: usb-2.6/drivers/usb/core/message.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -1387,11 +1387,11 @@ free_interfaces:
if (dev->state != USB_STATE_ADDRESS)
usb_disable_device (dev, 1); // Skip ep0
- n = dev->bus_mA - cp->desc.bMaxPower * 2;
- if (n < 0)
+ i = dev->bus_mA - cp->desc.bMaxPower * 2;
+ if (i < 0)
dev_warn(&dev->dev, "new config #%d exceeds power "
"limit by %dmA\n",
- configuration, -n);
+ configuration, -i);
if ((ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
USB_REQ_SET_CONFIGURATION, 0, configuration, 0,
On Mon, 12 Dec 2005 22:44:57 -0500 (EST), Alan Stern <[email protected]> wrote:
> On Mon, 12 Dec 2005, Andrew Morton wrote:
>
> > "J.A. Magallon" <[email protected]> wrote:
> > >
> > > > Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> > > > try to boot whith them.
> > > >
> > > > For the rest of your questions:
> > > > - I have no /etc/udev/agents.d/usb/usbcore
> > > > - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> > > > erradicated from udev ;) ?
> > > > - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> > > > were with 075).
> > > >
> > > > More info soon...
> > > >
> > >
> > > No problems with plain rc5. It does not seem to _always_ happen on -mm1,
> > > I thing I even got a clean boot, but just one.
> > > Detailed oops screenshot is here:
> > >
> > > http://belly.cps.unizar.es/~magallon/oops/oops.jpg
> > >
> >
> > Thanks for that.
> >
> > Let's add the usb list..
>
> Uh-oh. Looks like this one was my fault... Clashing uses of a local
> variable. :-(
>
> Does this patch fix it?
>
> Alan Stern
>
>
>
> Index: usb-2.6/drivers/usb/core/message.c
> ===================================================================
> --- usb-2.6.orig/drivers/usb/core/message.c
> +++ usb-2.6/drivers/usb/core/message.c
> @@ -1387,11 +1387,11 @@ free_interfaces:
> if (dev->state != USB_STATE_ADDRESS)
> usb_disable_device (dev, 1); // Skip ep0
>
> - n = dev->bus_mA - cp->desc.bMaxPower * 2;
> - if (n < 0)
> + i = dev->bus_mA - cp->desc.bMaxPower * 2;
> + if (i < 0)
> dev_warn(&dev->dev, "new config #%d exceeds power "
> "limit by %dmA\n",
> - configuration, -n);
> + configuration, -i);
>
> if ((ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
> USB_REQ_SET_CONFIGURATION, 0, configuration, 0,
>
Bingo! This corrected the problem. I applied it to rc5-mm2 and booted nicely.
One less bug.
A side question. Are this messages dangerous ?
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xed200000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb 1-1: unable to read config index 0 descriptor/all
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
usb 1-1: can't read configurations, error -71
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected
lspci:
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)
Thanks for all.
But don't be too happy, I have a couple things in the queue, like SMP
kernel not booting with 'nosmp' :).
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-rc5-mm2 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
On Tue, 13 Dec 2005, J.A. Magallon wrote:
> Bingo! This corrected the problem. I applied it to rc5-mm2 and booted nicely.
> One less bug.
>
> A side question. Are this messages dangerous ?
>
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 2 ports detected
> ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
> PCI: Setting latency timer of device 0000:00:1d.7 to 64
> ehci_hcd 0000:00:1d.7: EHCI Host Controller
> PCI: cache line size of 128 is not supported by device 0000:00:1d.7
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't think that matters. It's more informational than a warning.
> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
> ehci_hcd 0000:00:1d.7: irq 19, io mem 0xed200000
> ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> usb 1-1: unable to read config index 0 descriptor/all
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> usb 1-1: can't read configurations, error -71
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These messages indicate a real problem. The device plugged into your
first USB port didn't respond to a request. It might not matter though,
because the system will retry. If the device works then you don't need to
worry about it.
Alan Stern
On Tuesday 13 December 2005 7:35 am, Alan Stern wrote:
> On Tue, 13 Dec 2005, J.A. Magallon wrote:
> > PCI: cache line size of 128 is not supported by device 0000:00:1d.7
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I don't think that matters. It's more informational than a warning.
I don't even know why the PCI layer thinks we need to know about it.
Probably that came out as a side effect of noticing that the PCI
Memory-Write-Invalidate (MWI) cycle support can't be enabled; it's
an optional performance optimization, not widely supported for USB.
On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
>
mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
all know.
Final attack against binary drivers ? Or just an API change ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam4 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
"J.A. Magallon" <[email protected]> wrote:
>
> On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> >
>
> mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> all know.
That'll be gregkh-pci-shot-accross-the-bow.patch.
> Final attack against binary drivers ? Or just an API change ?
A joke, I believe.
On Tue, 13 Dec 2005 15:24:50 -0800, Andrew Morton <[email protected]> wrote:
> "J.A. Magallon" <[email protected]> wrote:
> >
> > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > >
> >
> > mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> > all know.
>
> That'll be gregkh-pci-shot-accross-the-bow.patch.
>
> > Final attack against binary drivers ? Or just an API change ?
>
> A joke, I believe.
:))
Thanks.
BTW, is there any easy way to get a reverse patch, apart from patch -R
and rediff ?
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam4 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
"J.A. Magallon" <[email protected]> writes:
> BTW, is there any easy way to get a reverse patch, apart from patch -R
> and rediff ?
Emacs' diff-mode can reverse patches.
--
Ben Pfaff
email: [email protected]
web: http://benpfaff.org
"J.A. Magallon" <[email protected]> wrote:
>
> On Tue, 13 Dec 2005 15:24:50 -0800, Andrew Morton <[email protected]> wrote:
>
> > "J.A. Magallon" <[email protected]> wrote:
> > >
> > > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
> > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > >
> > >
> > > mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> > > all know.
> >
> > That'll be gregkh-pci-shot-accross-the-bow.patch.
> >
> > > Final attack against binary drivers ? Or just an API change ?
> >
> > A joke, I believe.
>
> :))
> Thanks.
>
> BTW, is there any easy way to get a reverse patch, apart from patch -R
> and rediff ?
That's the easiest (only?) way...
I'll drop the patch from -mm.
On Tuesday 13 December 2005 19:22, Andrew Morton wrote:
> "J.A. Magallon" <[email protected]> wrote:
> >
> > On Tue, 13 Dec 2005 15:24:50 -0800, Andrew Morton <[email protected]> wrote:
> >
> > > "J.A. Magallon" <[email protected]> wrote:
> > > >
> > > > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <[email protected]> wrote:
> > > >
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > > >
> > > >
> > > > mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> > > > all know.
> > >
> > > That'll be gregkh-pci-shot-accross-the-bow.patch.
> > >
> > > > Final attack against binary drivers ? Or just an API change ?
> > >
> > > A joke, I believe.
> >
> > :))
> > Thanks.
> >
> > BTW, is there any easy way to get a reverse patch, apart from patch -R
> > and rediff ?
>
> That's the easiest (only?) way...
>
interdiff original.patch /dev/null > reversed.patch
--
Dmitry
