Skip to contentSkip to conversation

2.6.15-rc5-mm1

DISCUSSION Andrew Morton 23 participants 53 messages Dec 5, 2005 – Dec 14, 2005

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 2 lines · Andrew Morton

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

Signature · 1 line
Carlos Martín       http://www.cmartin.tk
#2 lore raw
Quoted 45 lines · Carlos Martín
Quoted 2 lines · Andrew Morton

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} 
Quoted 8 lines

<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.

Quoted 13 lines

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

Signature · 1 line
Carlos Martín       http://www.cmartin.tk
#3 lore raw
Quoted 4 lines · Andrew Morton
Quoted 2 lines
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

#4 lore raw

2.6.15-rc5-mm1: git-alsa-vs-git-pcmcia.patch introduces new compile errors

In reply to Andrew Morton
Quoted 7 lines · Andrew Morton

...
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

Signature · 4 lines
       "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
#5 lore raw

Re: 2.6.15-rc5-mm1: git-alsa-vs-git-pcmcia.patch introduces new compile errors

At Mon, 5 Dec 2005 20:06:32 +0100,

Quoted 12 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton

...
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)

Quoted 2 lines

git-alsa.patch removes some more code git-alsa-vs-git-pcmcia.patch adds users for:

(snip)

Quoted 2 lines

cu
Adrian

My bad, the below is the fixed patch.

Andrew, could you replace with this one?

thanks,

Takashi

---

sound/pcmcia/vx/vxpocket.c renamed from sound/pcmcia/vx/vxpocket.c-dist +49 -59
@@ -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;
sound/pcmcia/pdaudiocf/pdaudiocf.c renamed from sound/pcmcia/pdaudiocf/pdaudiocf.c-dist +43 -66

153 lines not on this page · raw message

#6 lore raw

2.6.15-rc5-mm1: USB_IP problems

In reply to Andrew Morton
Quoted 7 lines · Andrew Morton

...
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

Signature · 4 lines
       "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
#7 lore raw

Re: 2.6.15-rc5-mm1: USB_IP problems

Quoted 11 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton

...
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"?

Quoted 3 lines

- 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

#8 lore raw

Re: 2.6.15-rc5-mm1: USB_IP problems

Quoted 7 lines · Greg KH
Quoted 6 lines · Adrian Bunk
Quoted 5 lines · Andrew Morton

...
Subsystem trees
...
+gregkh-usb-usbip.patch

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

USB tree updates
...

Problems with this patch:
- USB_IP: no need for a "default N"

Why not? Is that the "default"?
...

Yes.

Quoted 1 line

greg k-h

cu
Adrian

Signature · 4 lines
       "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
#9 lore raw
In reply to Andrew Morton
Quoted 4 lines · Andrew Morton

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))

#10 lore raw

copy linux-usb-devel list...

Quoted 34 lines · J.A. Magallon
Quoted 4 lines · Andrew Morton

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))

Signature · 1 line
~Randy
#11 lore raw
In reply to J.A. Magallon
Quoted 21 lines · J.A. Magallon
Quoted 4 lines · Andrew Morton

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
Quoted 6 lines

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

#12 lore raw
Quoted 29 lines · Greg KH
Quoted 21 lines · J.A. Magallon
Quoted 4 lines · Andrew Morton

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
Quoted 6 lines

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 ?

Quoted 7 lines

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))

#13 lore raw
Quoted 42 lines · J.A. Magallon
Quoted 29 lines · Greg KH
Quoted 21 lines · J.A. Magallon
Quoted 4 lines · Andrew Morton

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
Quoted 6 lines

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 ?

Quoted 7 lines

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.

Quoted 9 lines

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))

#14 lore raw
Quoted 11 lines · J.A. Magallon
Quoted 11 lines

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).

Quoted 9 lines
Quoted 2 lines

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..

#15 lore raw
Quoted 19 lines · Andrew Morton
Quoted 18 lines · J.A. Magallon
Quoted 4 lines

Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will try to boot whith them.

Quoted 9 lines

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:

Quoted 6 lines
Quoted 2 lines

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

drivers/usb/core/message.c +3 -3
Index: 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,
#16 lore raw
Quoted 47 lines · Alan Stern
Quoted 19 lines · Andrew Morton
Quoted 18 lines · J.A. Magallon
Quoted 4 lines

Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will try to boot whith them.

Quoted 9 lines

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:

Quoted 6 lines
Quoted 2 lines

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
===================================================================

drivers/usb/core/message.c +0 -1
@@ -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;

drivers/usb/core/message.c free_interfaces: · line 1397

Quoted 10 lines
drivers/usb/core/message.c +3 -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))

#17 lore raw
Quoted 5 lines · J.A. Magallon

Bingo! This corrected the problem. I applied it to rc5-mm2 and booted nicely. One less bug.

A side question. Are this messages dangerous ?

Quoted 7 lines

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.

Quoted 7 lines

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

#18 lore raw
Quoted 6 lines · Alan Stern
Quoted 2 lines · J.A. Magallon

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.

#19 lore raw
In reply to Andrew Morton

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.

mm/page_alloc.c +2 -1
Index: 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;
 }
#20 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

In reply to Andrew Morton

Hi,

Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

}-- snip --{

Quoted 1 line

+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

Quoted 1 line

+x86_64-hpet-overflow-fix.patch

does not help.

Greetings,
Rafael

Signature · 1 line
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
#21 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Update:

Quoted 11 lines · Rafael J. Wysocki

Hi,

Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

}-- snip --{

Quoted 1 line

+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!
#22 lore raw

[discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

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

Quoted 1 line
Quoted 1 line
Quoted 1 line

"Rafael J. Wysocki" <[email protected]> 08.12.05 00:15:01 >>>

Update:

Quoted 5 lines · Rafael J. Wysocki

Hi,

Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

Quoted 5 lines

}-- snip --{

Quoted 1 line

+x86_64-hpet-overflow.patch

This patch breaks resume from disk badly. The box hangs solid as

soon as interrupts

Quoted 1 line

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!
#23 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Hi,

Quoted 5 lines · Jan Beulich

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).

Quoted 11 lines

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

Quoted 115 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Rafael J. Wysocki" <[email protected]> 08.12.05 00:15:01 >>>

Update:

Quoted 5 lines · Rafael J. Wysocki

Hi,

Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

Quoted 5 lines

}-- snip --{

Quoted 1 line

+x86_64-hpet-overflow.patch

This patch breaks resume from disk badly. The box hangs solid as

soon as interrupts

Quoted 1 line

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!
Signature · 1 line
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
#24 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Update:

Quoted 18 lines · Rafael J. Wysocki
Quoted 5 lines · Jan Beulich

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).

Quoted 11 lines

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).

Quoted 6 lines

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(+)
arch/x86_64/kernel/time.c +15 -0
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
@@ -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);
#25 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

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

Quoted 1 line
Quoted 1 line
Quoted 1 line

"Rafael J. Wysocki" <[email protected]> 08.12.05 23:35:49 >>>

Update:

Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Jan Beulich

I don't know how resume normally handles the re-syncing of the

wall

Quoted 5 lines
Quoted 5 lines

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

Quoted 1 line
Quoted 1 line

resume, this (a) has to happen before enabling interrupts and (b)

has to

Quoted 1 line
Quoted 1 line

communicate to the timer interrupt handler to adjust its last time

stamp

Quoted 1 line
Quoted 1 line

taken (to compare against in the next run). Clearly, the code was

broken

Quoted 1 line
Quoted 1 line

already before, as it doesn't handle the resume case (where the

HPET

Quoted 1 line
Quoted 1 line

value read is entirely unrelated to the one read during the last

timer

Quoted 1 line
Quoted 1 line

interrupt before suspend) at all, and even in the TSC timer case

it

Quoted 1 line
Quoted 1 line

simply checks whether the TSC delta is negative (which is not a

valid

Quoted 1 line
Quoted 1 line

condition, as, between the booting of the system and the OS resume

there

Quoted 1 line
Quoted 1 line

may elapse more time than the system was running altogether prior

to

Quoted 3 lines
Quoted 1 line

suspend).

Well, I'm not an expert, but I think I understand your

argumentation.

Quoted 5 lines

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);

#26 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 3 lines · Jan Beulich

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

#27 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

In reply to Jan Beulich
Quoted 3 lines · Jan Beulich

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

Signature · 1 line
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
#28 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 4 lines
Quoted 1 line
Quoted 1 line

"Rafael J. Wysocki" <[email protected]> 09.12.05 12:20:05 >>>

Quoted 2 lines · Jan Beulich

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

Quoted 4 lines
Quoted 1 line

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.

Quoted 9 lines

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

#29 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 21 lines · Jan Beulich
Quoted 4 lines
Quoted 1 line
Quoted 1 line

"Rafael J. Wysocki" <[email protected]> 09.12.05 12:20:05 >>>

Quoted 2 lines · Jan Beulich

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

Quoted 4 lines
Quoted 1 line

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.

Quoted 8 lines

BTW, in the interrupt handler there is:

		__asm__("mulq %1\n\t"
		        "shrdq $32, %%rdx, %0"
		        : "+a" (delta)
		        : "rm" (vxtime.tsc_quot)
		        : "rdx");
Quoted 3 lines
Quoted 1 line

Is the "+a" a typo?

Why would you think so?

Well, "=" is usually used in that context and "+", "=" are on the same key. ;-)

Rafael

Signature · 1 line
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
#30 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

In reply to Jan Beulich
Quoted 4 lines · Jan Beulich
Quoted 4 lines
Quoted 1 line
Quoted 1 line

"Rafael J. Wysocki" <[email protected]> 09.12.05 12:20:05 >>>

Quoted 2 lines · Jan Beulich

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

Quoted 8 lines

(to

Quoted 4 lines
Quoted 1 line

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(+)
arch/x86_64/kernel/time.c +9 -0
Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
@@ -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);
#31 lore raw

Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 1 line

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);

#32 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 4 lines

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

#33 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

In reply to Jan Beulich
Quoted 4 lines · Jan Beulich

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

#34 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Hi,

Quoted 8 lines · Andi Kleen
Quoted 4 lines · Jan Beulich

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

Signature · 1 line
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin
#35 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

In reply to Andi Kleen
Quoted 9 lines
Quoted 1 line
Quoted 1 line

Andi Kleen <[email protected]> 08.12.05 23:47:35 >>>

Quoted 4 lines · Jan Beulich

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.

Quoted 5 lines

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

Quoted 2 lines

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?

Quoted 2 lines

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.

Quoted 6 lines

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

#36 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 5 lines
Quoted 5 lines

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

Quoted 8 lines

shouldn't

Quoted 2 lines

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.

Quoted 8 lines
Quoted 3 lines

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 ?

Quoted 9 lines
Quoted 7 lines

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

#37 lore raw

Re: [discuss] Re: 2.6.15-rc5-mm1 (x86_64-hpet-overflow.patch breaks resume from disk)

Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

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

Quoted 2 lines
Quoted 2 lines

interconnect from CPU to HPET is (at least) 64 bits wide. At least theoretically implementations are permitted to use 32-bit

components;

Quoted 3 lines
Quoted 1 line

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

#38 lore raw
In reply to Andrew Morton
Quoted 1 line · Andrew Morton

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

#39 lore raw
Quoted 17 lines · Badari Pulavarty
Quoted 1 line · Andrew Morton

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....

Quoted 3 lines

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.

#40 lore raw
In reply to Badari Pulavarty
Quoted 13 lines · Badari Pulavarty
Quoted 1 line · Andrew Morton

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.

Quoted 2 lines

Thanks,
Badari

cu
Adrian

Signature · 12 lines
       "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



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
#41 lore raw
In reply to Badari Pulavarty
Quoted 13 lines · Badari Pulavarty
Quoted 1 line · Andrew Morton

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.

Quoted 2 lines

Thanks,
Badari

cu
Adrian

Signature · 4 lines
       "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
#42 lore raw
Quoted 15 lines · Adrian Bunk
Quoted 13 lines · Badari Pulavarty
Quoted 1 line · Andrew Morton

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....

Quoted 5 lines

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.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

#43 lore raw
In reply to Adrian Bunk
Quoted 15 lines · Adrian Bunk
Quoted 13 lines · Badari Pulavarty
Quoted 1 line · Andrew Morton

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....

Quoted 5 lines

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.

Jaroslav

-----
Jaroslav Kysela <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

#44 lore raw
In reply to Andrew Morton
Quoted 1 line · Andrew Morton

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.

Signature · 1 line
Alexander E. Patrakov
#45 lore raw
Quoted 13 lines · Alexander E. Patrakov
Quoted 2 lines · Andrew Morton

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

Quoted 6 lines

/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

#46 lore raw
In reply to Alexander E. Patrakov
Quoted 3 lines · Alexander E. Patrakov

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.

#47 lore raw
In reply to Andrew Morton
Quoted 3 lines · Andrew Morton

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))

#48 lore raw
Quoted 9 lines · J.A. Magallon
Quoted 3 lines · Andrew Morton

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.

Quoted 1 line

Final attack against binary drivers ? Or just an API change ?

A joke, I believe.

#49 lore raw
Quoted 8 lines · Andrew Morton
Quoted 7 lines · J.A. Magallon
Quoted 3 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

Quoted 8 lines
Quoted 2 lines

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.

Quoted 1 line

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))

#50 lore raw
Quoted 2 lines · J.A. Magallon

BTW, is there any easy way to get a reverse patch, apart from patch -R and rediff ?

Emacs' diff-mode can reverse patches.

Signature · 3 lines
Ben Pfaff 
email: [email protected]
web: http://benpfaff.org
#51 lore raw
In reply to J.A. Magallon
Quoted 18 lines · J.A. Magallon
Quoted 15 lines · Andrew Morton
Quoted 9 lines · J.A. Magallon
Quoted 3 lines · Andrew Morton

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.

Quoted 1 line

Final attack against binary drivers ? Or just an API change ?

Quoted 7 lines
Quoted 1 line

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.

#52 lore raw
Quoted 21 lines · Andrew Morton
Quoted 20 lines · J.A. Magallon
Quoted 16 lines · Andrew Morton
Quoted 9 lines · J.A. Magallon
Quoted 3 lines · Andrew Morton

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.

Quoted 1 line

Final attack against binary drivers ? Or just an API change ?

A joke, I believe.

Quoted 8 lines
Quoted 5 lines

:))
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

Signature · 1 line
Dmitry