2.6.15-rc5-mm1

2.6.15-rc5-mm1

[Andrew Morton]

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

Re: 2.6.15-rc5-mm1

[Carlos Martín]

On Monday 05 December 2005 08:21, Andrew Morton wrote:
> 
> 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

Hi,

 I've been getting these:

Dec 27 14:32:45 kiopa kernel: BUG: soft lockup detected on CPU#1!
Dec 27 14:32:45 kiopa kernel: CPU 1:
Dec 27 14:32:45 kiopa kernel: Modules linked in: ipv6 parport_pc parport 
psmouse ns558 analog pcspkr snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm 
gameport ohci_hcd snd_timer ide_cd cdrom forcedeth snd ehci_hcd usbcore 
snd_page_alloc evdev unix
Dec 27 14:32:45 kiopa kernel: Pid: 0, comm: swapper Not tainted 2.6.15-rc5-mm1 
#2
Dec 27 14:32:45 kiopa kernel: RIP: 0010:[<ffffffff80311453>] 
<ffffffff80311453>{_spin_unlock_irq+19}
Dec 27 14:32:45 kiopa kernel: RSP: 0000:ffff810001ffbf08  EFLAGS: 00000246
Dec 27 14:32:45 kiopa kernel: RAX: ffff810001ff3fd8 RBX: ffff810001ffbe58 RCX: 
ffffffff8040fba0
Dec 27 14:32:45 kiopa kernel: RDX: 0000000000000001 RSI: ffff810001e19ad8 RDI: 
ffff810001e18c20
Dec 27 14:32:45 kiopa kernel: RBP: ffffffff8010e354 R08: 00000000000000e9 R09: 
0000000000000000
Dec 27 14:32:45 kiopa kernel: R10: 0000000000000000 R11: ffff810001e17660 R12: 
ffffffff8014cd49
Dec 27 14:32:45 kiopa kernel: R13: ffffffff801106ff R14: ffff810001ff3f18 R15: 
ffff810001ffbf18
Dec 27 14:32:45 kiopa kernel: FS:  0000000000000000(0000) GS:ffffffff8041c080
(0000) knlGS:00000000556b26c0
Dec 27 14:32:45 kiopa kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 
000000008005003b
Dec 27 14:32:45 kiopa kernel: CR2: 0000000056b8d012 CR3: 000000003cc2c000 CR4: 
00000000000006e0
Dec 27 14:32:45 kiopa kernel: 
Dec 27 14:32:45 kiopa kernel: Call Trace: <IRQ> 
<ffffffff80311449>{_spin_unlock_irq+9} 
<ffffffff8810db70>{:ipv6:addrconf_verify+0}
Dec 27 14:32:45 kiopa kernel:        
<ffffffff8014d0e2>{run_ktimeout_softirq+370} 
<ffffffff801394c4>{__do_softirq+100}
Dec 27 14:32:45 kiopa kernel:        <ffffffff8010f166>{call_softirq+30} 
<ffffffff801106bc>{do_softirq+44}
Dec 27 14:32:45 kiopa kernel:        <ffffffff801391a8>{irq_exit+72} 
<ffffffff8010e9ca>{apic_timer_interrupt+98}
Dec 27 14:32:45 kiopa kernel:         <EOI> 
<ffffffff80311449>{_spin_unlock_irq+9} <ffffffff8030fed0>{thread_return+95}
Dec 27 14:32:45 kiopa kernel:        <ffffffff8010c69d>{default_idle+45} 
<ffffffff8010c731>{cpu_idle+97}
Dec 27 14:32:45 kiopa kernel:        <ffffffff80433ea5>{start_secondary+1253}

The full log is at http://www.cmartin.tk/linux/dmesg.bz2 which is 7.9M 
uncompressed, with just the logs from the last boot.

The date is wrong because this is a second boot. Time goes extremely fast. 
When I rebooted into an older kernel it said it was the 8th July 2006!

The system halts for up to a minute (I got a console login timeout out after 
60secs). The keyboard lights still change, but the cursor on the screen stays 
put. After a bit things return to normal for a bit, repeat until reboot.

   cmn
-- 
Carlos Martín       http://www.cmartin.tk

Re: 2.6.15-rc5-mm1

[Andrew Morton]

Carlos Martín <carlos@cmartin.tk> wrote:
>
> On Monday 05 December 2005 08:21, Andrew Morton wrote:
> > 
> > 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> 
> Hi,
> 
>  I've been getting these:
> 
> Dec 27 14:32:45 kiopa kernel: BUG: soft lockup detected on CPU#1!
> Dec 27 14:32:45 kiopa kernel: CPU 1:
> Dec 27 14:32:45 kiopa kernel: Modules linked in: ipv6 parport_pc parport 
> psmouse ns558 analog pcspkr snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm 
> gameport ohci_hcd snd_timer ide_cd cdrom forcedeth snd ehci_hcd usbcore 
> snd_page_alloc evdev unix
> Dec 27 14:32:45 kiopa kernel: Pid: 0, comm: swapper Not tainted 2.6.15-rc5-mm1 
> #2
> Dec 27 14:32:45 kiopa kernel: RIP: 0010:[<ffffffff80311453>] 
> <ffffffff80311453>{_spin_unlock_irq+19}
> Dec 27 14:32:45 kiopa kernel: RSP: 0000:ffff810001ffbf08  EFLAGS: 00000246
> Dec 27 14:32:45 kiopa kernel: RAX: ffff810001ff3fd8 RBX: ffff810001ffbe58 RCX: 
> ffffffff8040fba0
> Dec 27 14:32:45 kiopa kernel: RDX: 0000000000000001 RSI: ffff810001e19ad8 RDI: 
> ffff810001e18c20
> Dec 27 14:32:45 kiopa kernel: RBP: ffffffff8010e354 R08: 00000000000000e9 R09: 
> 0000000000000000
> Dec 27 14:32:45 kiopa kernel: R10: 0000000000000000 R11: ffff810001e17660 R12: 
> ffffffff8014cd49
> Dec 27 14:32:45 kiopa kernel: R13: ffffffff801106ff R14: ffff810001ff3f18 R15: 
> ffff810001ffbf18
> Dec 27 14:32:45 kiopa kernel: FS:  0000000000000000(0000) GS:ffffffff8041c080
> (0000) knlGS:00000000556b26c0
> Dec 27 14:32:45 kiopa kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 
> 000000008005003b
> Dec 27 14:32:45 kiopa kernel: CR2: 0000000056b8d012 CR3: 000000003cc2c000 CR4: 
> 00000000000006e0
> Dec 27 14:32:45 kiopa kernel: 
> Dec 27 14:32:45 kiopa kernel: Call Trace: <IRQ> 
> <ffffffff80311449>{_spin_unlock_irq+9} 
> <ffffffff8810db70>{:ipv6:addrconf_verify+0}
> Dec 27 14:32:45 kiopa kernel:        
> <ffffffff8014d0e2>{run_ktimeout_softirq+370} 
> <ffffffff801394c4>{__do_softirq+100}
> Dec 27 14:32:45 kiopa kernel:        <ffffffff8010f166>{call_softirq+30} 
> <ffffffff801106bc>{do_softirq+44}
> Dec 27 14:32:45 kiopa kernel:        <ffffffff801391a8>{irq_exit+72} 
> <ffffffff8010e9ca>{apic_timer_interrupt+98}
> Dec 27 14:32:45 kiopa kernel:         <EOI> 
> <ffffffff80311449>{_spin_unlock_irq+9} <ffffffff8030fed0>{thread_return+95}
> Dec 27 14:32:45 kiopa kernel:        <ffffffff8010c69d>{default_idle+45} 
> <ffffffff8010c731>{cpu_idle+97}
> Dec 27 14:32:45 kiopa kernel:        <ffffffff80433ea5>{start_secondary+1253}

At a guess I'd say the new ktimeout code is playing up.

> The full log is at http://www.cmartin.tk/linux/dmesg.bz2 which is 7.9M 
> uncompressed, with just the logs from the last boot.
> 
> The date is wrong because this is a second boot. Time goes extremely fast. 
> When I rebooted into an older kernel it said it was the 8th July 2006!
> 
> The system halts for up to a minute (I got a console login timeout out after 
> 60secs). The keyboard lights still change, but the cursor on the screen stays 
> put. After a bit things return to normal for a bit, repeat until reboot.
> 
>    cmn
> -- 
> Carlos Martín       http://www.cmartin.tk

Re: 2.6.15-rc5-mm1

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > Dec 27 14:32:45 kiopa kernel: BUG: soft lockup detected on CPU#1!
> > Dec 27 14:32:45 kiopa kernel: CPU 1:

> At a guess I'd say the new ktimeout code is playing up.

hm, the ktimeout patches only rename, they do not change any code or 
semantics.

	Ingo

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

[Adrian Bunk]

On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
>...
>  Subsystem trees
>...
> +git-alsa-vs-git-pcmcia.patch
> 
>  Try to fix clash between two subsystem trees
>...

git-alsa.patch completely removes pdacf_t, and this patch adds a user 
resulting in the following compile error:

<--  snip  -->

...
  CC      sound/pcmcia/pdaudiocf/pdaudiocf.o
sound/pcmcia/pdaudiocf/pdaudiocf.c: In function 'pdacf_suspend':
sound/pcmcia/pdaudiocf/pdaudiocf.c:301: warning: passing argument 1 of 'snd_pdacf_suspend' from incompatible pointer type
sound/pcmcia/pdaudiocf/pdaudiocf.c: In function 'pdacf_resume':
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: 'pdacf_t' undeclared (first use in this function)
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: (Each undeclared identifier is reported only once
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: for each function it appears in.)
sound/pcmcia/pdaudiocf/pdaudiocf.c:314: error: 'chip' undeclared (first use in this function)
make[3]: *** [sound/pcmcia/pdaudiocf/pdaudiocf.o] Error 1

<--  snip  -->

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

<--  snip  -->

...
  CC      sound/pcmcia/vx/vxpocket.o
sound/pcmcia/vx/vxpocket.c: In function 'vxp_suspend':
sound/pcmcia/vx/vxpocket.c:296: error: 'struct snd_card' has no member named 'pm_suspend'
sound/pcmcia/vx/vxpocket.c:298: error: 'struct snd_card' has no member named 'pm_suspend'
sound/pcmcia/vx/vxpocket.c: In function 'vxp_resume':
sound/pcmcia/vx/vxpocket.c:310: error: 'vx_core_t' undeclared (first use in this function)
sound/pcmcia/vx/vxpocket.c:310: error: (Each undeclared identifier is reported only once
sound/pcmcia/vx/vxpocket.c:310: error: for each function it appears in.)
sound/pcmcia/vx/vxpocket.c:310: error: 'chip' undeclared (first use in this function)
make[3]: *** [sound/pcmcia/vx/vxpocket.o] Error 1

<--  snip  -->

cu
Adrian

-- 

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

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

[Takashi Iwai]

At Mon, 5 Dec 2005 20:06:32 +0100,
Adrian Bunk wrote:
> 
> On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
> >...
> >  Subsystem trees
> >...
> > +git-alsa-vs-git-pcmcia.patch
> > 
> >  Try to fix clash between two subsystem trees
> >...
> 
> git-alsa.patch completely removes pdacf_t, and this patch adds a user 
> resulting in the following compile error:
(snip)
> git-alsa.patch removes some more code git-alsa-vs-git-pcmcia.patch adds 
> users for:
(snip)
> cu
> Adrian

My bad, the below is the fixed patch.

Andrew, could you replace with this one?


thanks,

Takashi

---
--- linux-2.6.15-rc5/sound/pcmcia/vx/vxpocket.c-dist	2005-12-05 20:57:55.000000000 +0100
+++ linux-2.6.15-rc5/sound/pcmcia/vx/vxpocket.c	2005-12-05 21:01:28.000000000 +0100
@@ -133,11 +133,9 @@ static struct snd_vx_hardware vxp440_hw 
  */
 static struct snd_vxpocket *snd_vxpocket_new(struct snd_card *card, int ibl)
 {
-	client_reg_t client_reg;	/* Register with cardmgr */
 	dev_link_t *link;		/* Info for cardmgr */
 	struct vx_core *chip;
 	struct snd_vxpocket *vxp;
-	int ret;
 	static struct snd_device_ops ops = {
 		.dev_free =	snd_vxpocket_dev_free,
 	};
@@ -286,67 +284,55 @@ failed:
 	kfree(parse);
 }
 
+#ifdef CONFIG_PM
 
-/*
- * event callback
- */
-static int vxpocket_event(event_t event, int priority, event_callback_args_t *args)
+static int vxp_suspend(struct pcmcia_device *dev)
 {
-	dev_link_t *link = args->client_data;
+	dev_link_t *link = dev_to_instance(dev);
 	struct vx_core *chip = link->priv;
 
-	switch (event) {
-	case CS_EVENT_CARD_REMOVAL:
-		snd_printdd(KERN_DEBUG "CARD_REMOVAL..\n");
-		link->state &= ~DEV_PRESENT;
-		if (link->state & DEV_CONFIG)
-			chip->chip_status |= VX_STAT_IS_STALE;
-		break;
-	case CS_EVENT_CARD_INSERTION:
-		snd_printdd(KERN_DEBUG "CARD_INSERTION..\n");
-		link->state |= DEV_PRESENT | DEV_CONFIG_PENDING;
-		vxpocket_config(link);
-		break;
-#ifdef CONFIG_PM
-	case CS_EVENT_PM_SUSPEND:
-		snd_printdd(KERN_DEBUG "SUSPEND\n");
-		link->state |= DEV_SUSPEND;
+	snd_printdd(KERN_DEBUG "SUSPEND\n");
+	link->state |= DEV_SUSPEND;
+	if (chip) {
+		snd_printdd(KERN_DEBUG "snd_vx_suspend calling\n");
+		snd_vx_suspend(chip, PMSG_SUSPEND);
+	}
+	snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
+	if (link->state & DEV_CONFIG)
+		pcmcia_release_configuration(link->handle);
+
+	return 0;
+}
+
+static int vxp_resume(struct pcmcia_device *dev)
+{
+	dev_link_t *link = dev_to_instance(dev);
+	struct vx_core *chip = link->priv;
+
+	snd_printdd(KERN_DEBUG "RESUME\n");
+	link->state &= ~DEV_SUSPEND;
+
+	snd_printdd(KERN_DEBUG "CARD_RESET\n");
+	if (DEV_OK(link)) {
+		//struct snd_vxpocket *vxp = (struct snd_vxpocket *)chip;
+		snd_printdd(KERN_DEBUG "requestconfig...\n");
+		pcmcia_request_configuration(link->handle, &link->conf);
 		if (chip) {
-			snd_printdd(KERN_DEBUG "snd_vx_suspend calling\n");
-			snd_vx_suspend(chip, PMSG_SUSPEND);
-		}
-		/* Fall through... */
-	case CS_EVENT_RESET_PHYSICAL:
-		snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
-		if (link->state & DEV_CONFIG)
-			pcmcia_release_configuration(link->handle);
-		break;
-	case CS_EVENT_PM_RESUME:
-		snd_printdd(KERN_DEBUG "RESUME\n");
-		link->state &= ~DEV_SUSPEND;
-		/* Fall through... */
-	case CS_EVENT_CARD_RESET:
-		snd_printdd(KERN_DEBUG "CARD_RESET\n");
-		if (DEV_OK(link)) {
-			//struct snd_vxpocket *vxp = (struct snd_vxpocket *)chip;
-			snd_printdd(KERN_DEBUG "requestconfig...\n");
-			pcmcia_request_configuration(link->handle, &link->conf);
-			if (chip) {
-				snd_printdd(KERN_DEBUG "calling snd_vx_resume\n");
-				snd_vx_resume(chip);
-			}
+			snd_printdd(KERN_DEBUG "calling snd_vx_resume\n");
+			snd_vx_resume(chip);
 		}
-		snd_printdd(KERN_DEBUG "resume done!\n");
-		break;
-#endif
 	}
+	snd_printdd(KERN_DEBUG "resume done!\n");
+
 	return 0;
 }
 
+#endif
+
 
 /*
  */
-static dev_link_t *vxpocket_attach(void)
+static int vxpocket_attach(struct pcmcia_device *p_dev)
 {
 	struct snd_card *card;
 	struct snd_vxpocket *vxp;
@@ -359,22 +345,22 @@ static dev_link_t *vxpocket_attach(void)
 	}
 	if (i >= SNDRV_CARDS) {
 		snd_printk(KERN_ERR "vxpocket: too many cards found\n");
-		return NULL;
+		return -EINVAL;
 	}
 	if (! enable[i])
-		return NULL; /* disabled explicitly */
+		return -ENODEV; /* disabled explicitly */
 
 	/* ok, create a card instance */
 	card = snd_card_new(index[i], id[i], THIS_MODULE, 0);
 	if (card == NULL) {
 		snd_printk(KERN_ERR "vxpocket: cannot create a card instance\n");
-		return NULL;
+		return -ENOMEM;
 	}
 
 	vxp = snd_vxpocket_new(card, ibl[i]);
 	if (! vxp) {
 		snd_card_free(card);
-		return NULL;
+		return -ENODEV;
 	}
 	card->private_data = vxp;
 
@@ -382,17 +368,21 @@ static dev_link_t *vxpocket_attach(void)
 	card_alloc |= 1 << i;
 
 	/* Chain drivers */
-	vxp->link.next = dev_list;
-	dev_list = &vxp->link;
+	vxp->link.next = NULL;
 
-	return &vxp->link;
+	vxp->link.handle = p_dev;
+	vxp->link.state |= DEV_PRESENT | DEV_CONFIG_PENDING;
+	p_dev->instance = &vxp->link;
+	vxpocket_config(&vxp->link);
+
+	return 0;
 }
 
-static void vxpocket_detach(dev_link_t *link)
+static void vxpocket_detach(struct pcmcia_device *p_dev)
 {
+	dev_link_t *link = dev_to_instance(p_dev);
 	struct snd_vxpocket *vxp;
 	struct vx_core *chip;
-	dev_link_t **linkp;
 
 	if (! link)
 		return;
--- linux-2.6.15-rc5/sound/pcmcia/pdaudiocf/pdaudiocf.c-dist	2005-12-05 20:57:51.000000000 +0100
+++ linux-2.6.15-rc5/sound/pcmcia/pdaudiocf/pdaudiocf.c	2005-12-05 21:01:16.000000000 +0100
@@ -52,16 +52,13 @@ MODULE_PARM_DESC(enable, "Enable " CARD_
 /*
  */
 
-static dev_info_t dev_info = "snd-pdaudiocf";
 static struct snd_card *card_list[SNDRV_CARDS];
-static dev_link_t *dev_list;
 
 /*
  * prototypes
  */
 static void pdacf_config(dev_link_t *link);
-static int pdacf_event(event_t event, int priority, event_callback_args_t *args);
-static void snd_pdacf_detach(dev_link_t *link);
+static void snd_pdacf_detach(struct pcmcia_device *p_dev);
 
 static void pdacf_release(dev_link_t *link)
 {
@@ -99,11 +96,10 @@ static int snd_pdacf_dev_free(struct snd
 /*
  * snd_pdacf_attach - attach callback for cs
  */
-static dev_link_t *snd_pdacf_attach(void)
+static int snd_pdacf_attach(struct pcmcia_device *p_dev)
 {
-	client_reg_t client_reg;	/* Register with cardmgr */
-	dev_link_t *link;		/* Info for cardmgr */
-	int i, ret;
+	int i;
+	dev_link_t *link;               /* Info for cardmgr */
 	struct snd_pdacf *pdacf;
 	struct snd_card *card;
 	static struct snd_device_ops ops = {
@@ -216,21 +212,13 @@ static int snd_pdacf_assign_resources(st
 /*
  * snd_pdacf_detach - detach callback for cs
  */
-static void snd_pdacf_detach(dev_link_t *link)
+static void snd_pdacf_detach(struct pcmcia_device *p_dev)
 {
+	dev_link_t *link = dev_to_instance(p_dev);
 	struct snd_pdacf *chip = link->priv;
 
 	snd_printdd(KERN_DEBUG "pdacf_detach called\n");
-	/* Remove the interface data from the linked list */
-	{
-		dev_link_t **linkp;
-		/* Locate device structure */
-		for (linkp = &dev_list; *linkp; linkp = &(*linkp)->next)
-			if (*linkp == link)
-				break;
-		if (*linkp)
-			*linkp = link->next;
-	}
+
 	if (chip->chip_status & PDAUDIOCF_STAT_IS_CONFIGURED)
 		snd_pdacf_powerdown(chip);
 	chip->chip_status |= PDAUDIOCF_STAT_IS_STALE; /* to be sure */
@@ -299,62 +287,51 @@ failed:
 	pcmcia_release_irq(link->handle, &link->irq);
 }
 
-/*
- * event callback
- */
-static int pdacf_event(event_t event, int priority, event_callback_args_t *args)
+#ifdef CONFIG_PM
+
+static int pdacf_suspend(struct pcmcia_device *dev)
 {
-	dev_link_t *link = args->client_data;
+	dev_link_t *link = dev_to_instance(dev);
 	struct snd_pdacf *chip = link->priv;
 
-	switch (event) {
-	case CS_EVENT_CARD_REMOVAL:
-		snd_printdd(KERN_DEBUG "CARD_REMOVAL..\n");
-		link->state &= ~DEV_PRESENT;
-		if (link->state & DEV_CONFIG) {
-			chip->chip_status |= PDAUDIOCF_STAT_IS_STALE;
-		}
-		break;
-	case CS_EVENT_CARD_INSERTION:
-		snd_printdd(KERN_DEBUG "CARD_INSERTION..\n");
-		link->state |= DEV_PRESENT;
-		pdacf_config(link);
-		break;
-#ifdef CONFIG_PM
-	case CS_EVENT_PM_SUSPEND:
-		snd_printdd(KERN_DEBUG "SUSPEND\n");
-		link->state |= DEV_SUSPEND;
+	snd_printdd(KERN_DEBUG "SUSPEND\n");
+	link->state |= DEV_SUSPEND;
+	if (chip) {
+		snd_printdd(KERN_DEBUG "snd_pdacf_suspend calling\n");
+		snd_pdacf_suspend(chip, PMSG_SUSPEND);
+	}
+
+	snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
+	if (link->state & DEV_CONFIG)
+		pcmcia_release_configuration(link->handle);
+
+	return 0;
+}
+
+static int pdacf_resume(struct pcmcia_device *dev)
+{
+	dev_link_t *link = dev_to_instance(dev);
+	struct snd_pdacf *chip = link->priv;
+
+	snd_printdd(KERN_DEBUG "RESUME\n");
+	link->state &= ~DEV_SUSPEND;
+
+	snd_printdd(KERN_DEBUG "CARD_RESET\n");
+	if (DEV_OK(link)) {
+		snd_printdd(KERN_DEBUG "requestconfig...\n");
+		pcmcia_request_configuration(link->handle, &link->conf);
 		if (chip) {
-			snd_printdd(KERN_DEBUG "snd_pdacf_suspend calling\n");
-			snd_pdacf_suspend(chip, PMSG_SUSPEND);
-		}
-		/* Fall through... */
-	case CS_EVENT_RESET_PHYSICAL:
-		snd_printdd(KERN_DEBUG "RESET_PHYSICAL\n");
-		if (link->state & DEV_CONFIG)
-			pcmcia_release_configuration(link->handle);
-		break;
-	case CS_EVENT_PM_RESUME:
-		snd_printdd(KERN_DEBUG "RESUME\n");
-		link->state &= ~DEV_SUSPEND;
-		/* Fall through... */
-	case CS_EVENT_CARD_RESET:
-		snd_printdd(KERN_DEBUG "CARD_RESET\n");
-		if (DEV_OK(link)) {
-			snd_printdd(KERN_DEBUG "requestconfig...\n");
-			pcmcia_request_configuration(link->handle, &link->conf);
-			if (chip) {
-				snd_printdd(KERN_DEBUG "calling snd_pdacf_resume\n");
-				snd_pdacf_resume(chip);
-			}
+			snd_printdd(KERN_DEBUG "calling snd_pdacf_resume\n");
+			snd_pdacf_resume(chip);
 		}
-		snd_printdd(KERN_DEBUG "resume done!\n");
-		break;
-#endif
 	}
+	snd_printdd(KERN_DEBUG "resume done!\n");
+
 	return 0;
 }
 
+#endif
+
 /*
  * Module entry points
  */

2.6.15-rc5-mm1: USB_IP problems

[Adrian Bunk]

On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
>...
>  Subsystem trees
>...
> +gregkh-usb-usbip.patch
> 
>  USB tree updates
>...

Problems with this patch:
- USB_IP: no need for a "default N"
- USB_IP must be a tristate, because currently the illegal configurations 
  USB=m, USB_IP=y, USB_IP_{VHCI,STUB}=y are allowed
- compilation fails with USB_IP_VHCI=y, USB_IP_STUB=y:

<--  snip  -->

...
  LD      drivers/usb/ip/built-in.o
drivers/usb/ip/stub.o: In function `usbip_pack_pdu':
: multiple definition of `usbip_pack_pdu'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o: In function `usbip_task_init':
: multiple definition of `usbip_task_init'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o: In function `setreuse':
: multiple definition of `setreuse'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o: In function `usbip_start_eh':
: multiple definition of `usbip_start_eh'
drivers/usb/ip/vhci-hcd.o:: first defined here
drivers/usb/ip/stub.o:(.data+0x0): multiple definition of 
`usbip_debug_flag'
drivers/usb/ip/vhci-hcd.o:(.data+0x0): first defined here
...
make[3]: *** [drivers/usb/ip/built-in.o] Error 1

<--  snip  -->


cu
Adrian

-- 

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

Re: 2.6.15-rc5-mm1: USB_IP problems

[Greg KH]

On Mon, Dec 05, 2005 at 10:40:55PM +0100, Adrian Bunk wrote:
> On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
> >...
> >  Subsystem trees
> >...
> > +gregkh-usb-usbip.patch
> > 
> >  USB tree updates
> >...
> 
> Problems with this patch:
> - USB_IP: no need for a "default N"

Why not?  Is that the "default"?

> - USB_IP must be a tristate, because currently the illegal configurations 
>   USB=m, USB_IP=y, USB_IP_{VHCI,STUB}=y are allowed
> - compilation fails with USB_IP_VHCI=y, USB_IP_STUB=y:

Yeah, sorry about that.  This code is going to get a lot of scrubbing
before it will go into mainline.  Thanks for your patch, I'll apply it.

greg k-h

Re: 2.6.15-rc5-mm1: USB_IP problems

[Adrian Bunk]

On Tue, Dec 06, 2005 at 04:02:16PM -0800, Greg KH wrote:
> On Mon, Dec 05, 2005 at 10:40:55PM +0100, Adrian Bunk wrote:
> > On Sun, Dec 04, 2005 at 11:21:53PM -0800, Andrew Morton wrote:
> > >...
> > >  Subsystem trees
> > >...
> > > +gregkh-usb-usbip.patch
> > > 
> > >  USB tree updates
> > >...
> > 
> > Problems with this patch:
> > - USB_IP: no need for a "default N"
> 
> Why not?  Is that the "default"?
>...

Yes.

> greg k-h

cu
Adrian

-- 

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

Re: 2.6.15-rc5-mm1

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:

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

I still get this oops on boot, then the machine freezes hard on the init
process:

usb_set_configuration+0x22b/0x4df
usb_new_device+0x105/0x158
hub_port_connect_change+0x2de/0x37e
clear_port_feature+0x48/0x4d
hub_events+0x2aa/0x42f
hub_thread+0x14/0xe2
autoremove_wake_function+0x0/0x37
kthread+0x93/0x97
kthread+0x0/0x97
kernel_thread_helper+0x5/0xb

udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
failed.

I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.

Any ideas ?

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-rc5-mm1

[Randy.Dunlap]

copy linux-usb-devel list...

On Tue, 6 Dec 2005, J.A. Magallon wrote:

> On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> >
> >
>
> I still get this oops on boot, then the machine freezes hard on the init
> process:
>
> usb_set_configuration+0x22b/0x4df
> usb_new_device+0x105/0x158
> hub_port_connect_change+0x2de/0x37e
> clear_port_feature+0x48/0x4d
> hub_events+0x2aa/0x42f
> hub_thread+0x14/0xe2
> autoremove_wake_function+0x0/0x37
> kthread+0x93/0x97
> kthread+0x0/0x97
> kernel_thread_helper+0x5/0xb
>
> udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> failed.
>
> I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
>
> Any ideas ?
>
> --
> J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
> werewolf!able!es                         \         It's better when it's free
> Mandriva Linux release 2006.1 (Cooker) for i586
> Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))
>

-- 
~Randy

Re: 2.6.15-rc5-mm1

[Greg KH]

On Tue, Dec 06, 2005 at 12:05:24AM +0100, J.A. Magallon wrote:
> On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > 
> > 
> 
> I still get this oops on boot, then the machine freezes hard on the init
> process:
> 
> usb_set_configuration+0x22b/0x4df
> usb_new_device+0x105/0x158
> hub_port_connect_change+0x2de/0x37e
> clear_port_feature+0x48/0x4d
> hub_events+0x2aa/0x42f
> hub_thread+0x14/0xe2
> autoremove_wake_function+0x0/0x37
> kthread+0x93/0x97
> kthread+0x0/0x97
> kernel_thread_helper+0x5/0xb
> 
> udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> failed.
> 
> I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
> 
> Any ideas ?

Do you have the same problem with 2.6.15-rc5?

What is in /etc/udev/agents.d/usb/usbcore?
What distro is this?
What kind of usb devices do you have attached?

thanks,

greg k-h

Re: 2.6.15-rc5-mm1

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

On Sat, 10 Dec 2005 15:36:55 -0800, Greg KH <greg@kroah.com> wrote:

> On Tue, Dec 06, 2005 at 12:05:24AM +0100, J.A. Magallon wrote:
> > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > 
> > > 
> > 
> > I still get this oops on boot, then the machine freezes hard on the init
> > process:
> > 
> > usb_set_configuration+0x22b/0x4df
> > usb_new_device+0x105/0x158
> > hub_port_connect_change+0x2de/0x37e
> > clear_port_feature+0x48/0x4d
> > hub_events+0x2aa/0x42f
> > hub_thread+0x14/0xe2
> > autoremove_wake_function+0x0/0x37
> > kthread+0x93/0x97
> > kthread+0x0/0x97
> > kernel_thread_helper+0x5/0xb
> > 
> > udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> > failed.
> > 
> > I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
> > 
> > Any ideas ?
> 
> Do you have the same problem with 2.6.15-rc5?
> 
> What is in /etc/udev/agents.d/usb/usbcore?
> What distro is this?
> What kind of usb devices do you have attached?
> 
> thanks,

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

For the rest of your questions:
- I have no /etc/udev/agents.d/usb/usbcore
- I have killed all the devfs compat scripts/rules (BTW, when will be finally
  erradicated from  udev ;) ?
- Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
  were with 075).

More info soon...

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-rc5-mm1

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 2257 bytes --]

On Sun, 11 Dec 2005 00:46:11 +0100, "J.A. Magallon" <jamagallon@able.es> wrote:

> On Sat, 10 Dec 2005 15:36:55 -0800, Greg KH <greg@kroah.com> wrote:
> 
> > On Tue, Dec 06, 2005 at 12:05:24AM +0100, J.A. Magallon wrote:
> > > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > > 
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > > 
> > > > 
> > > 
> > > I still get this oops on boot, then the machine freezes hard on the init
> > > process:
> > > 
> > > usb_set_configuration+0x22b/0x4df
> > > usb_new_device+0x105/0x158
> > > hub_port_connect_change+0x2de/0x37e
> > > clear_port_feature+0x48/0x4d
> > > hub_events+0x2aa/0x42f
> > > hub_thread+0x14/0xe2
> > > autoremove_wake_function+0x0/0x37
> > > kthread+0x93/0x97
> > > kthread+0x0/0x97
> > > kernel_thread_helper+0x5/0xb
> > > 
> > > udevd-event[694]: run_program: exec of program '/etc/udev/agents.d/usb/usbcore'
> > > failed.
> > > 
> > > I have udev-075, plain 2.6.15-rc5-mm1 + devfs-die + low1Gbmem.
> > > 
> > > Any ideas ?
> > 
> > Do you have the same problem with 2.6.15-rc5?
> > 
> > What is in /etc/udev/agents.d/usb/usbcore?
> > What distro is this?
> > What kind of usb devices do you have attached?
> > 
> > thanks,
> 
> Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> try to boot whith them.
> 
> For the rest of your questions:
> - I have no /etc/udev/agents.d/usb/usbcore
> - I have killed all the devfs compat scripts/rules (BTW, when will be finally
>   erradicated from  udev ;) ?
> - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
>   were with 075).
> 
> More info soon...
> 

No problems with plain rc5. It does not seem to _always_ happen on -mm1,
I thing I even got a clean boot, but just one. 
Detailed oops screenshot is here:

http://belly.cps.unizar.es/~magallon/oops/oops.jpg


--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam3 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-rc5-mm1

[Andrew Morton]

"J.A. Magallon" <jamagallon@able.es> wrote:
>
> > Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> > try to boot whith them.
> > 
> > For the rest of your questions:
> > - I have no /etc/udev/agents.d/usb/usbcore
> > - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> >   erradicated from  udev ;) ?
> > - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> >   were with 075).
> > 
> > More info soon...
> > 
> 
> No problems with plain rc5. It does not seem to _always_ happen on -mm1,
> I thing I even got a clean boot, but just one. 
> Detailed oops screenshot is here:
> 
> http://belly.cps.unizar.es/~magallon/oops/oops.jpg
> 

Thanks for that.

Let's add the usb list..

Re: [linux-usb-devel] Re: 2.6.15-rc5-mm1

[Alan Stern]

On Mon, 12 Dec 2005, Andrew Morton wrote:

> "J.A. Magallon" <jamagallon@able.es> wrote:
> >
> > > Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> > > try to boot whith them.
> > > 
> > > For the rest of your questions:
> > > - I have no /etc/udev/agents.d/usb/usbcore
> > > - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> > >   erradicated from  udev ;) ?
> > > - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> > >   were with 075).
> > > 
> > > More info soon...
> > > 
> > 
> > No problems with plain rc5. It does not seem to _always_ happen on -mm1,
> > I thing I even got a clean boot, but just one. 
> > Detailed oops screenshot is here:
> > 
> > http://belly.cps.unizar.es/~magallon/oops/oops.jpg
> > 
> 
> Thanks for that.
> 
> Let's add the usb list..

Uh-oh.  Looks like this one was my fault...  Clashing uses of a local 
variable.  :-(

Does this patch fix it?

Alan Stern



Index: usb-2.6/drivers/usb/core/message.c
===================================================================
--- usb-2.6.orig/drivers/usb/core/message.c
+++ usb-2.6/drivers/usb/core/message.c
@@ -1387,11 +1387,11 @@ free_interfaces:
 	if (dev->state != USB_STATE_ADDRESS)
 		usb_disable_device (dev, 1);	// Skip ep0
 
-	n = dev->bus_mA - cp->desc.bMaxPower * 2;
-	if (n < 0)
+	i = dev->bus_mA - cp->desc.bMaxPower * 2;
+	if (i < 0)
 		dev_warn(&dev->dev, "new config #%d exceeds power "
 				"limit by %dmA\n",
-				configuration, -n);
+				configuration, -i);
 
 	if ((ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
 			USB_REQ_SET_CONFIGURATION, 0, configuration, 0,

Re: [linux-usb-devel] Re: 2.6.15-rc5-mm1

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]

On Mon, 12 Dec 2005 22:44:57 -0500 (EST), Alan Stern <stern@rowland.harvard.edu> wrote:

> On Mon, 12 Dec 2005, Andrew Morton wrote:
> 
> > "J.A. Magallon" <jamagallon@able.es> wrote:
> > >
> > > > Sorry for the delay. I'm just compiling all rcs from rc2 to rc5 and will
> > > > try to boot whith them.
> > > > 
> > > > For the rest of your questions:
> > > > - I have no /etc/udev/agents.d/usb/usbcore
> > > > - I have killed all the devfs compat scripts/rules (BTW, when will be finally
> > > >   erradicated from  udev ;) ?
> > > > - Distro: Mandriva Cooker, updated daily, udev-077 now (the hangs I reported
> > > >   were with 075).
> > > > 
> > > > More info soon...
> > > > 
> > > 
> > > No problems with plain rc5. It does not seem to _always_ happen on -mm1,
> > > I thing I even got a clean boot, but just one. 
> > > Detailed oops screenshot is here:
> > > 
> > > http://belly.cps.unizar.es/~magallon/oops/oops.jpg
> > > 
> > 
> > Thanks for that.
> > 
> > Let's add the usb list..
> 
> Uh-oh.  Looks like this one was my fault...  Clashing uses of a local 
> variable.  :-(
> 
> Does this patch fix it?
> 
> Alan Stern
> 
> 
> 
> Index: usb-2.6/drivers/usb/core/message.c
> ===================================================================
> --- usb-2.6.orig/drivers/usb/core/message.c
> +++ usb-2.6/drivers/usb/core/message.c
> @@ -1387,11 +1387,11 @@ free_interfaces:
>  	if (dev->state != USB_STATE_ADDRESS)
>  		usb_disable_device (dev, 1);	// Skip ep0
>  
> -	n = dev->bus_mA - cp->desc.bMaxPower * 2;
> -	if (n < 0)
> +	i = dev->bus_mA - cp->desc.bMaxPower * 2;
> +	if (i < 0)
>  		dev_warn(&dev->dev, "new config #%d exceeds power "
>  				"limit by %dmA\n",
> -				configuration, -n);
> +				configuration, -i);
>  
>  	if ((ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
>  			USB_REQ_SET_CONFIGURATION, 0, configuration, 0,
> 

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

A side question. Are this messages dangerous ?

hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xed200000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb 1-1: unable to read config index 0 descriptor/all
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
usb 1-1: can't read configurations, error -71
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 8 ports detected

lspci:
00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02)


Thanks for all.

But don't be too happy, I have a couple things in the queue, like SMP
kernel not booting with 'nosmp' :).

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-rc5-mm2 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-usb-devel] Re: 2.6.15-rc5-mm1

[Alan Stern]

On Tue, 13 Dec 2005, J.A. Magallon wrote:

> Bingo! This corrected the problem. I applied it to rc5-mm2 and booted nicely.
> One less bug.
> 
> A side question. Are this messages dangerous ?
> 
> hub 4-0:1.0: USB hub found
> hub 4-0:1.0: 2 ports detected
> ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19
> PCI: Setting latency timer of device 0000:00:1d.7 to 64
> ehci_hcd 0000:00:1d.7: EHCI Host Controller
> PCI: cache line size of 128 is not supported by device 0000:00:1d.7
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't think that matters.  It's more informational than a warning.

> ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5
> ehci_hcd 0000:00:1d.7: irq 19, io mem 0xed200000
> ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> usb 1-1: unable to read config index 0 descriptor/all
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> usb 1-1: can't read configurations, error -71
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

These messages indicate a real problem.  The device plugged into your 
first USB port didn't respond to a request.  It might not matter though, 
because the system will retry.  If the device works then you don't need to 
worry about it.

Alan Stern

Re: [linux-usb-devel] Re: 2.6.15-rc5-mm1

[David Brownell]

On Tuesday 13 December 2005 7:35 am, Alan Stern wrote:
> On Tue, 13 Dec 2005, J.A. Magallon wrote:

> > PCI: cache line size of 128 is not supported by device 0000:00:1d.7
> >     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I don't think that matters.  It's more informational than a warning.

I don't even know why the PCI layer thinks we need to know about it.

Probably that came out as a side effect of noticing that the PCI
Memory-Write-Invalidate (MWI) cycle support can't be enabled; it's
an optional performance optimization, not widely supported for USB.

Re: 2.6.15-rc5-mm1

[KAMEZAWA Hiroyuki]

When CONFIG_PAGE_OWNER=y, there is a bug in page allocation failure path.
(turn on Kernel Hacking -> Track page owner)

Patch is attached below.
error message is this
==
Dec  6 22:21:34 aworks kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000020
Dec  6 22:21:34 aworks kernel:  printing eip:
Dec  6 22:21:34 aworks kernel: c0148267
Dec  6 22:21:34 aworks kernel: *pde = 00000000
Dec  6 22:21:34 aworks kernel: Oops: 0002 [#1]
Dec  6 22:21:34 aworks kernel: SMP
Dec  6 22:21:34 aworks kernel: last sysfs file: /class/vc/vcs2/dev
Dec  6 22:21:34 aworks kernel: Modules linked in: video
Dec  6 22:21:34 aworks kernel: CPU:    0
Dec  6 22:21:34 aworks kernel: EIP:    0060:[<c0148267>]    Not tainted VLI
Dec  6 22:21:34 aworks kernel: EFLAGS: 00010286   (2.6.15-rc5-mm1)
Dec  6 22:21:34 aworks kernel: EIP is at __alloc_pages+0x297/0x3c0
Dec  6 22:21:34 aworks su(pam_unix)[2660]: session closed for user root
Dec  6 22:21:34 aworks kernel: eax: 0000000a   ebx: e884c000   ecx: 00000000   edx: e884decc
Dec  6 22:21:34 aworks kernel: esi: 000242d2   edi: 00000000   ebp: e884decc   esp: e884de88
Dec  6 22:21:34 aworks kernel: ds: 007b   es: 007b   ss: 0068
Dec  6 22:21:34 aworks kernel: Process bash (pid: 2663, threadinfo=e884c000 task=ed9ff070)
Dec  6 22:21:34 aworks kernel: Stack: <0>000242d2 0000000a c04a3ba8 00000042 00000000 000242d2 c04a3ba8 0000000a
Dec  6 22:21:34 aworks kernel:        <0>00000010 00000000 e884c000 00000042 e884dea6 00000000 c1090000 000001f4
Dec  6 22:21:34 aworks kernel:        <0>ec06abc0 e884ded8 c015ce58 c1090000 e884def0 c015d117 c1090000 e884dfa0
Dec  6 22:21:34 aworks kernel: Call Trace:
Dec  6 22:21:34 aworks kernel:  [<c0103dc2>] show_stack+0xa2/0xe0
Dec  6 22:21:34 aworks kernel:  [<c0103f8f>] show_registers+0x16f/0x200
Dec  6 22:21:34 aworks kernel:  [<c01041df>] die+0x11f/0x1b0
Dec  6 22:21:34 aworks kernel:  [<c0428500>] do_page_fault+0x330/0x638
Dec  6 22:21:34 aworks kernel:  [<c0103a4f>] error_code+0x4f/0x54
Dec  6 22:21:34 aworks kernel:  [<c015ce58>] alloc_fresh_huge_page+0x18/0x50
Dec  6 22:21:34 aworks kernel:  [<c015d117>] set_max_huge_pages+0x47/0xc0
Dec  6 22:21:34 aworks kernel:  [<c015d1d1>] hugetlb_sysctl_handler+0x41/0x50
Dec  6 22:21:34 aworks kernel:  [<c0125c48>] do_rw_proc+0xe8/0x100
Dec  6 22:21:34 aworks kernel:  [<c0125cde>] proc_writesys+0x2e/0x30
Dec  6 22:21:34 aworks kernel:  [<c01668b6>] vfs_write+0xa6/0x190
Dec  6 22:21:34 aworks kernel:  [<c0166a57>] sys_write+0x47/0x70
Dec  6 22:21:34 aworks kernel:  [<c0102ecf>] sysenter_past_esp+0x54/0x75
Dec  6 22:21:34 aworks kernel: Code: c0 89 44 24 04 89 54 24 08 e8 06 6c fd ff e8 b1 bb fb ff e8 ac ce fc ff 8b 4d e0 8b 45 d8 8d 5d ec 89 ea 81 e3 00 e0 ff ff 89 cf <89> 41 20 89 71 24 83 c7 28 31 c0 b9 08 00 00 00 f3 ab 31 f6 39
==

--Kame
---
Fix NULL pointer reference of set_page_owner() in allcation faulure path.

Signed-Off-by: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitu.com>

Index: linux-2.6.15-rc5-mm1.org/mm/page_alloc.c
===================================================================
--- linux-2.6.15-rc5-mm1.org.orig/mm/page_alloc.c
+++ linux-2.6.15-rc5-mm1.org/mm/page_alloc.c
@@ -1136,7 +1136,8 @@ nopage:
  	}
  got_pg:
  #ifdef CONFIG_PAGE_OWNER
-	set_page_owner(page, order, gfp_mask);
+	if (page)
+		set_page_owner(page, order, gfp_mask);
  #endif
  	return page;
  }

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

[Rafael J. Wysocki]

Hi,

On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

}-- snip --{
> +x86_64-hpet-overflow.patch

This patch breaks resume from disk badly.  The box hangs solid as soon as interrupts
are reenabled during resume (right after the image has been read).  Unfortunately

> +x86_64-hpet-overflow-fix.patch

does not help.

Greetings,
Rafael


-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin

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

[Rafael J. Wysocki]

Update:

On Wednesday, 7 December 2005 01:46, Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> 
> }-- snip --{
> > +x86_64-hpet-overflow.patch
> 
> This patch breaks resume from disk badly.  The box hangs solid as soon as interrupts
> are reenabled during resume (right after the image has been read).

I've just managed to get a call trace from it, which is appended.

Greetings,
Rafael


swsusp: Reading resume file was successful
PM: Preparing devices for restore.
Suspending device 1.0
Suspending device ide1
Suspending device 0.1
Suspending device ide0
Suspending device serial8250
Suspending device serio4
Suspending device serio3
Suspending device serio2
Suspending device serio1
Suspending device serio0
Suspending device i8042
Suspending device vesafb.0
Suspending device 0000:01:00.0
Suspending device 0000:02:02.0
Suspending device 0000:02:01.4
Suspending device 0000:02:01.3
Suspending device 0000:02:01.2
Suspending device 0000:02:01.1
Suspending device 0000:02:01.0
Suspending device 0000:02:00.0
Suspending device 0000:00:18.3
Suspending device 0000:00:18.2
Suspending device 0000:00:18.1
Suspending device 0000:00:18.0
Suspending device 0000:00:0b.0
Suspending device 0000:00:0a.0
Suspending device 0000:00:08.0
Suspending device 0000:00:06.0
Suspending device 0000:00:02.2
Suspending device 0000:00:02.1
Suspending device 0000:00:02.0
Suspending device 0000:00:01.1
Suspending device 0000:00:01.0
Suspending device 0000:00:00.0
Suspending device pci0000:00
Suspending device platform
PM: Restoring saved image.
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: usbserial thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia firmware_class yenta_socket rsrc_nonstatic pcmcia_core evdev joydev sg usbhid st
 sr_mod ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom dm_mod parport_pc lp parport
Pid: 3304, comm: bash Not tainted 2.6.15-rc5-mm1 #1
RIP: 0010:[<ffffffff8013c87d>] <ffffffff8013c87d>{do_timer+77}
RSP: 0018:ffffffff80481eb8  EFLAGS: 00000002
RAX: 000000001d0f8788 RBX: 00000255e7679aa8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000003d09fa RDI: 0000000000000000
RBP: ffffffff80481ed8 R08: 0000000000000040 R09: 00000000ffffffff
R10: 0000000094fc4b38 R11: 00000000c0010008 R12: 000002560cbc37bc
R13: ffff81002bd63d38 R14: ffff81002bd63d38 R15: 0000000000000000
FS:  00002aaaab28fe80(0000) GS:ffffffff8050f000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaaac2000 CR3: 000000002ad20000 CR4: 00000000000006e0
Process bash (pid: 3304, threadinfo ffff81002bd62000, task ffff810001fdb790)
Stack: 0000000000000fed 00000000000002b7 0000000000000b18 000002560cbc37bb
       ffffffff80481f08 ffffffff80112dd1 ffffffff803d39c0 0000000000000000
       ffff81002bd63d38 0000000000000000
Call Trace: <IRQ> <ffffffff80112dd1>{timer_interrupt+689} <ffffffff8015ae83>{handle_IRQ_event+51}
       <ffffffff8015af72>{__do_IRQ+162} <ffffffff80111097>{do_IRQ+55}
       <ffffffff8010f0b0>{ret_from_intr+0}  <EOI> <ffffffff8011ae3d>{enable_lapic_nmi_watchdog+29}
       <ffffffff8011ae63>{lapic_nmi_resume+19} <ffffffff8015296d>{swsusp_suspend+93}
       <ffffffff8015296a>{swsusp_suspend+90} <ffffffff801537b8>{pm_suspend_disk+88}
       <ffffffff80151266>{enter_state+118} <ffffffff801514a7>{state_store+119}
       <ffffffff801c09a4>{subsys_attr_store+36} <ffffffff801c0e2a>{sysfs_write_file+202}
       <ffffffff80180549>{vfs_write+233} <ffffffff801806f0>{sys_write+80}
       <ffffffff8010eb0e>{system_call+126}

Code: 48 ff cb 48 85 c9 48 89 ce 74 25 8b 05 de 38 2a 00 48 63 d0
console shuts up ...
 <7>APIC error on CPU0: 00(00)
Kernel panic - not syncing: Aiee, killing interrupt handler!

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

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

Whatever mechanism was previously used to adjust the wall clock during
resume, this (a) has to happen before enabling interrupts and (b) has to
communicate to the timer interrupt handler to adjust its last time stamp
taken (to compare against in the next run). Clearly, the code was broken
already before, as it doesn't handle the resume case (where the HPET
value read is entirely unrelated to the one read during the last timer
interrupt before suspend) at all, and even in the TSC timer case it
simply checks whether the TSC delta is negative (which is not a valid
condition, as, between the booting of the system and the OS resume there
may elapse more time than the system was running altogether prior to
suspend).

Jan

>>> "Rafael J. Wysocki" <rjw@sisk.pl> 08.12.05 00:15:01 >>>
Update:

On Wednesday, 7 December 2005 01:46, Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> > 
> >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

> 
> }-- snip --{
> > +x86_64-hpet-overflow.patch
> 
> This patch breaks resume from disk badly.  The box hangs solid as
soon as interrupts
> are reenabled during resume (right after the image has been read).

I've just managed to get a call trace from it, which is appended.

Greetings,
Rafael


swsusp: Reading resume file was successful
PM: Preparing devices for restore.
Suspending device 1.0
Suspending device ide1
Suspending device 0.1
Suspending device ide0
Suspending device serial8250
Suspending device serio4
Suspending device serio3
Suspending device serio2
Suspending device serio1
Suspending device serio0
Suspending device i8042
Suspending device vesafb.0
Suspending device 0000:01:00.0
Suspending device 0000:02:02.0
Suspending device 0000:02:01.4
Suspending device 0000:02:01.3
Suspending device 0000:02:01.2
Suspending device 0000:02:01.1
Suspending device 0000:02:01.0
Suspending device 0000:02:00.0
Suspending device 0000:00:18.3
Suspending device 0000:00:18.2
Suspending device 0000:00:18.1
Suspending device 0000:00:18.0
Suspending device 0000:00:0b.0
Suspending device 0000:00:0a.0
Suspending device 0000:00:08.0
Suspending device 0000:00:06.0
Suspending device 0000:00:02.2
Suspending device 0000:00:02.1
Suspending device 0000:00:02.0
Suspending device 0000:00:01.1
Suspending device 0000:00:01.0
Suspending device 0000:00:00.0
Suspending device pci0000:00
Suspending device platform
PM: Restoring saved image.
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: usbserial thermal processor fan button battery ac
snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia
firmware_class yenta_socket rsrc_nonstatic pcmcia_core evdev joydev sg
usbhid st
 sr_mod ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom dm_mod
parport_pc lp parport
Pid: 3304, comm: bash Not tainted 2.6.15-rc5-mm1 #1
RIP: 0010:[<ffffffff8013c87d>] <ffffffff8013c87d>{do_timer+77}
RSP: 0018:ffffffff80481eb8  EFLAGS: 00000002
RAX: 000000001d0f8788 RBX: 00000255e7679aa8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 00000000003d09fa RDI: 0000000000000000
RBP: ffffffff80481ed8 R08: 0000000000000040 R09: 00000000ffffffff
R10: 0000000094fc4b38 R11: 00000000c0010008 R12: 000002560cbc37bc
R13: ffff81002bd63d38 R14: ffff81002bd63d38 R15: 0000000000000000
FS:  00002aaaab28fe80(0000) GS:ffffffff8050f000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002aaaaaac2000 CR3: 000000002ad20000 CR4: 00000000000006e0
Process bash (pid: 3304, threadinfo ffff81002bd62000, task
ffff810001fdb790)
Stack: 0000000000000fed 00000000000002b7 0000000000000b18
000002560cbc37bb
       ffffffff80481f08 ffffffff80112dd1 ffffffff803d39c0
0000000000000000
       ffff81002bd63d38 0000000000000000
Call Trace: <IRQ> <ffffffff80112dd1>{timer_interrupt+689}
<ffffffff8015ae83>{handle_IRQ_event+51}
       <ffffffff8015af72>{__do_IRQ+162} <ffffffff80111097>{do_IRQ+55}
       <ffffffff8010f0b0>{ret_from_intr+0}  <EOI>
<ffffffff8011ae3d>{enable_lapic_nmi_watchdog+29}
       <ffffffff8011ae63>{lapic_nmi_resume+19}
<ffffffff8015296d>{swsusp_suspend+93}
       <ffffffff8015296a>{swsusp_suspend+90}
<ffffffff801537b8>{pm_suspend_disk+88}
       <ffffffff80151266>{enter_state+118}
<ffffffff801514a7>{state_store+119}
       <ffffffff801c09a4>{subsys_attr_store+36}
<ffffffff801c0e2a>{sysfs_write_file+202}
       <ffffffff80180549>{vfs_write+233}
<ffffffff801806f0>{sys_write+80}
       <ffffffff8010eb0e>{system_call+126}

Code: 48 ff cb 48 85 c9 48 89 ce 74 25 8b 05 de 38 2a 00 48 63 d0
console shuts up ...
 <7>APIC error on CPU0: 00(00)
Kernel panic - not syncing: Aiee, killing interrupt handler!

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

[Rafael J. Wysocki]

Hi,

On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> I don't know how resume normally handles the re-syncing of the wall
> clock, but the problem here is obvious: do_timer runs a loop to
> increment jiffies, which may require significant amounts of time
> (depending how long the system was sleeping).
> 
> Whatever mechanism was previously used to adjust the wall clock during
> resume, this (a) has to happen before enabling interrupts and (b) has to
> communicate to the timer interrupt handler to adjust its last time stamp
> taken (to compare against in the next run). Clearly, the code was broken
> already before, as it doesn't handle the resume case (where the HPET
> value read is entirely unrelated to the one read during the last timer
> interrupt before suspend) at all, and even in the TSC timer case it
> simply checks whether the TSC delta is negative (which is not a valid
> condition, as, between the booting of the system and the OS resume there
> may elapse more time than the system was running altogether prior to
> suspend).

Well, I'm not an expert, but I think I understand your argumentation.
However, the problem is that resume _works_ without the patch
and doesn't work with it, which is a regression.  (BTW, without
the patch the wall clock is evidently correct after resume.)

Frankly I don't know who should fix the broken code, but my
understanding has always been that if someone's patch
introduces a regression, he/she ough to change the patch
so that it does not happen.

Greetings,
Rafael


> >>> "Rafael J. Wysocki" <rjw@sisk.pl> 08.12.05 00:15:01 >>>
> Update:
> 
> On Wednesday, 7 December 2005 01:46, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Monday, 5 December 2005 08:21, Andrew Morton wrote:
> > > 
> > >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> 
> > 
> > }-- snip --{
> > > +x86_64-hpet-overflow.patch
> > 
> > This patch breaks resume from disk badly.  The box hangs solid as
> soon as interrupts
> > are reenabled during resume (right after the image has been read).
> 
> I've just managed to get a call trace from it, which is appended.
> 
> Greetings,
> Rafael
> 
> 
> swsusp: Reading resume file was successful
> PM: Preparing devices for restore.
> Suspending device 1.0
> Suspending device ide1
> Suspending device 0.1
> Suspending device ide0
> Suspending device serial8250
> Suspending device serio4
> Suspending device serio3
> Suspending device serio2
> Suspending device serio1
> Suspending device serio0
> Suspending device i8042
> Suspending device vesafb.0
> Suspending device 0000:01:00.0
> Suspending device 0000:02:02.0
> Suspending device 0000:02:01.4
> Suspending device 0000:02:01.3
> Suspending device 0000:02:01.2
> Suspending device 0000:02:01.1
> Suspending device 0000:02:01.0
> Suspending device 0000:02:00.0
> Suspending device 0000:00:18.3
> Suspending device 0000:00:18.2
> Suspending device 0000:00:18.1
> Suspending device 0000:00:18.0
> Suspending device 0000:00:0b.0
> Suspending device 0000:00:0a.0
> Suspending device 0000:00:08.0
> Suspending device 0000:00:06.0
> Suspending device 0000:00:02.2
> Suspending device 0000:00:02.1
> Suspending device 0000:00:02.0
> Suspending device 0000:00:01.1
> Suspending device 0000:00:01.0
> Suspending device 0000:00:00.0
> Suspending device pci0000:00
> Suspending device platform
> PM: Restoring saved image.
> NMI Watchdog detected LOCKUP on CPU 0
> CPU 0
> Modules linked in: usbserial thermal processor fan button battery ac
> snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_
> pcm snd_timer snd soundcore snd_page_alloc af_packet pcmcia
> firmware_class yenta_socket rsrc_nonstatic pcmcia_core evdev joydev sg
> usbhid st
>  sr_mod ehci_hcd ohci_hcd sk98lin sd_mod scsi_mod ide_cd cdrom dm_mod
> parport_pc lp parport
> Pid: 3304, comm: bash Not tainted 2.6.15-rc5-mm1 #1
> RIP: 0010:[<ffffffff8013c87d>] <ffffffff8013c87d>{do_timer+77}
> RSP: 0018:ffffffff80481eb8  EFLAGS: 00000002
> RAX: 000000001d0f8788 RBX: 00000255e7679aa8 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 00000000003d09fa RDI: 0000000000000000
> RBP: ffffffff80481ed8 R08: 0000000000000040 R09: 00000000ffffffff
> R10: 0000000094fc4b38 R11: 00000000c0010008 R12: 000002560cbc37bc
> R13: ffff81002bd63d38 R14: ffff81002bd63d38 R15: 0000000000000000
> FS:  00002aaaab28fe80(0000) GS:ffffffff8050f000(0000)
> knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002aaaaaac2000 CR3: 000000002ad20000 CR4: 00000000000006e0
> Process bash (pid: 3304, threadinfo ffff81002bd62000, task
> ffff810001fdb790)
> Stack: 0000000000000fed 00000000000002b7 0000000000000b18
> 000002560cbc37bb
>        ffffffff80481f08 ffffffff80112dd1 ffffffff803d39c0
> 0000000000000000
>        ffff81002bd63d38 0000000000000000
> Call Trace: <IRQ> <ffffffff80112dd1>{timer_interrupt+689}
> <ffffffff8015ae83>{handle_IRQ_event+51}
>        <ffffffff8015af72>{__do_IRQ+162} <ffffffff80111097>{do_IRQ+55}
>        <ffffffff8010f0b0>{ret_from_intr+0}  <EOI>
> <ffffffff8011ae3d>{enable_lapic_nmi_watchdog+29}
>        <ffffffff8011ae63>{lapic_nmi_resume+19}
> <ffffffff8015296d>{swsusp_suspend+93}
>        <ffffffff8015296a>{swsusp_suspend+90}
> <ffffffff801537b8>{pm_suspend_disk+88}
>        <ffffffff80151266>{enter_state+118}
> <ffffffff801514a7>{state_store+119}
>        <ffffffff801c09a4>{subsys_attr_store+36}
> <ffffffff801c0e2a>{sysfs_write_file+202}
>        <ffffffff80180549>{vfs_write+233}
> <ffffffff801806f0>{sys_write+80}
>        <ffffffff8010eb0e>{system_call+126}
> 
> Code: 48 ff cb 48 85 c9 48 89 ce 74 25 8b 05 de 38 2a 00 48 63 d0
> console shuts up ...
>  <7>APIC error on CPU0: 00(00)
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> 
> 

-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin

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

[Rafael J. Wysocki]

Update:

On Thursday, 8 December 2005 11:53, Rafael J. Wysocki wrote:
> On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
> > 
> > Whatever mechanism was previously used to adjust the wall clock during
> > resume, this (a) has to happen before enabling interrupts and (b) has to
> > communicate to the timer interrupt handler to adjust its last time stamp
> > taken (to compare against in the next run). Clearly, the code was broken
> > already before, as it doesn't handle the resume case (where the HPET
> > value read is entirely unrelated to the one read during the last timer
> > interrupt before suspend) at all, and even in the TSC timer case it
> > simply checks whether the TSC delta is negative (which is not a valid
> > condition, as, between the booting of the system and the OS resume there
> > may elapse more time than the system was running altogether prior to
> > suspend).
> 
> Well, I'm not an expert, but I think I understand your argumentation.
> However, the problem is that resume _works_ without the patch
> and doesn't work with it, which is a regression.  (BTW, without
> the patch the wall clock is evidently correct after resume.)
> 
> Frankly I don't know who should fix the broken code,

FWIW, I have tried to fix it myself.

The appended patch seems to work on my box, but I'm afraid
it's not the right fix (at least in general).  Please advise.

Greetings,
Rafael


 arch/x86_64/kernel/time.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+)

Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
--- linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c	2005-12-08 21:39:29.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c	2005-12-08 22:44:48.000000000 +0100
@@ -1117,6 +1117,7 @@
 	unsigned long sec;
 	unsigned long ctime = get_cmos_time();
 	unsigned long sleep_length = (ctime - sleep_start) * HZ;
+	long offset = 0;
 
 	if (vxtime.hpet_address)
 		hpet_reenable();
@@ -1125,6 +1126,20 @@
 
 	sec = ctime + clock_cmos_diff;
 	write_seqlock_irqsave(&xtime_lock,flags);
+	if (vxtime.hpet_address)
+		offset = hpet_readl(HPET_COUNTER);
+	if (hpet_use_timer) {
+		unsigned int hi1 = hpet64 > 0 ? hpet_readl(HPET_COUNTER+4) : 0;
+
+		offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+		if (hpet64 > 0)
+			offset += (long)(offset >= 0 ? hi1 : hpet_readl(HPET_COUNTER+4)) << 32;
+		else
+			offset = (unsigned int)offset;
+	}
+	if (vxtime.mode == VXTIME_HPET)
+		vxtime.last = offset;
+	rdtscll_sync(&vxtime.last_tsc);
 	xtime.tv_sec = sec;
 	xtime.tv_nsec = 0;
 	write_sequnlock_irqrestore(&xtime_lock,flags);

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

[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

>>> "Rafael J. Wysocki" <rjw@sisk.pl> 08.12.05 23:35:49 >>>
Update:

On Thursday, 8 December 2005 11:53, Rafael J. Wysocki wrote:
> On Thursday, 8 December 2005 09:43, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the
wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
> > 
> > Whatever mechanism was previously used to adjust the wall clock
during
> > resume, this (a) has to happen before enabling interrupts and (b)
has to
> > communicate to the timer interrupt handler to adjust its last time
stamp
> > taken (to compare against in the next run). Clearly, the code was
broken
> > already before, as it doesn't handle the resume case (where the
HPET
> > value read is entirely unrelated to the one read during the last
timer
> > interrupt before suspend) at all, and even in the TSC timer case
it
> > simply checks whether the TSC delta is negative (which is not a
valid
> > condition, as, between the booting of the system and the OS resume
there
> > may elapse more time than the system was running altogether prior
to
> > suspend).
> 
> Well, I'm not an expert, but I think I understand your
argumentation.
> However, the problem is that resume _works_ without the patch
> and doesn't work with it, which is a regression.  (BTW, without
> the patch the wall clock is evidently correct after resume.)
> 
> Frankly I don't know who should fix the broken code,

FWIW, I have tried to fix it myself.

The appended patch seems to work on my box, but I'm afraid
it's not the right fix (at least in general).  Please advise.

Greetings,
Rafael


 arch/x86_64/kernel/time.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+)

Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
---
linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c	2005-12-08
21:39:29.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c	2005-12-08
22:44:48.000000000 +0100
@@ -1117,6 +1117,7 @@
 	unsigned long sec;
 	unsigned long ctime = get_cmos_time();
 	unsigned long sleep_length = (ctime - sleep_start) * HZ;
+	long offset = 0;
 
 	if (vxtime.hpet_address)
 		hpet_reenable();
@@ -1125,6 +1126,20 @@
 
 	sec = ctime + clock_cmos_diff;
 	write_seqlock_irqsave(&xtime_lock,flags);
+	if (vxtime.hpet_address)
+		offset = hpet_readl(HPET_COUNTER);
+	if (hpet_use_timer) {
+		unsigned int hi1 = hpet64 > 0 ?
hpet_readl(HPET_COUNTER+4) : 0;
+
+		offset = hpet_readl(HPET_T0_CMP) - hpet_tick;
+		if (hpet64 > 0)
+			offset += (long)(offset >= 0 ? hi1 :
hpet_readl(HPET_COUNTER+4)) << 32;
+		else
+			offset = (unsigned int)offset;
+	}
+	if (vxtime.mode == VXTIME_HPET)
+		vxtime.last = offset;
+	rdtscll_sync(&vxtime.last_tsc);
 	xtime.tv_sec = sec;
 	xtime.tv_nsec = 0;
 	write_sequnlock_irqrestore(&xtime_lock,flags);

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

[Andi Kleen]

On Fri, Dec 09, 2005 at 10:15:51AM +0100, Jan Beulich wrote:
> It's a possible way to address this, but I'd rather just set a flag
> indicating that the last-whatever values should not be considered (to
> get into a state just like after initial boot). Jan

Sounds reasonable.
-Andi

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

[Rafael J. Wysocki]

On Friday, 9 December 2005 10:15, Jan Beulich wrote:
> It's a possible way to address this, but I'd rather just set a flag
> indicating that the last-whatever values should not be considered (to
> get into a state just like after initial boot). Jan

OK, but what is the interrupt handler supposed to do if the
vxtime.last* values are invalid?  I guess assume delta = 0?

BTW, in the interrupt handler there is:

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

Is the "+a" a typo?

Rafael


-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin

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

[Jan Beulich]

>>> "Rafael J. Wysocki" <rjw@sisk.pl> 09.12.05 12:20:05 >>>
>On Friday, 9 December 2005 10:15, Jan Beulich wrote:
>> It's a possible way to address this, but I'd rather just set a flag
>> indicating that the last-whatever values should not be considered
(to
>> get into a state just like after initial boot). Jan
>
>OK, but what is the interrupt handler supposed to do if the
>vxtime.last* values are invalid?  I guess assume delta = 0?

As I said, the state should be (re)set to whatever is in effect at
boot.

>BTW, in the interrupt handler there is:
>
>		__asm__("mulq %1\n\t"
>		        "shrdq $32, %%rdx, %0"
>		        : "+a" (delta)
>		        : "rm" (vxtime.tsc_quot)
>		        : "rdx");
>
>Is the "+a" a typo?

Why would you think so?

Jan

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

[Rafael J. Wysocki]

On Friday, 9 December 2005 13:41, Jan Beulich wrote:
> >>> "Rafael J. Wysocki" <rjw@sisk.pl> 09.12.05 12:20:05 >>>
> >On Friday, 9 December 2005 10:15, Jan Beulich wrote:
> >> It's a possible way to address this, but I'd rather just set a flag
> >> indicating that the last-whatever values should not be considered
> (to
> >> get into a state just like after initial boot). Jan
> >
> >OK, but what is the interrupt handler supposed to do if the
> >vxtime.last* values are invalid?  I guess assume delta = 0?
> 
> As I said, the state should be (re)set to whatever is in effect at
> boot.
> 
> >BTW, in the interrupt handler there is:
> >
> >		__asm__("mulq %1\n\t"
> >		        "shrdq $32, %%rdx, %0"
> >		        : "+a" (delta)
> >		        : "rm" (vxtime.tsc_quot)
> >		        : "rdx");
> >
> >Is the "+a" a typo?
> 
> Why would you think so?

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

Rafael


-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin

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

[Rafael J. Wysocki]

On Friday, 9 December 2005 13:41, Jan Beulich wrote:
> >>> "Rafael J. Wysocki" <rjw@sisk.pl> 09.12.05 12:20:05 >>>
> >On Friday, 9 December 2005 10:15, Jan Beulich wrote:
> >> It's a possible way to address this, but I'd rather just set a flag
> >> indicating that the last-whatever values should not be considered
> (to
> >> get into a state just like after initial boot). Jan
> >
> >OK, but what is the interrupt handler supposed to do if the
> >vxtime.last* values are invalid?  I guess assume delta = 0?
> 
> As I said, the state should be (re)set to whatever is in effect at
> boot.

Is the appended patch better than the previous one?

Rafael


 arch/x86_64/kernel/time.c |    9 +++++++++
 1 files changed, 9 insertions(+)

Index: linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c
===================================================================
--- linux-2.6.15-rc5-mm1.orig/arch/x86_64/kernel/time.c	2005-12-08 22:57:33.000000000 +0100
+++ linux-2.6.15-rc5-mm1/arch/x86_64/kernel/time.c	2005-12-09 14:37:31.000000000 +0100
@@ -65,6 +65,7 @@ unsigned long hpet_tick;
 static int hpet_use_timer;
 unsigned long vxtime_hz = PIT_TICK_RATE;
 unsigned long long monotonic_base;
+static int vxtime_last_invalid;		/* for the interrupt handler */
 static int report_lost_ticks;			/* command line option */
 
 
@@ -417,6 +418,13 @@ static irqreturn_t timer_interrupt(int i
 
 	rdtscll_sync(&tsc);
 
+	if (vxtime_last_invalid) {
+		if (vxtime.mode == VXTIME_HPET)
+			vxtime.last = offset;
+		vxtime.last_tsc = tsc;
+		vxtime_last_invalid = 0;
+	}
+
 	if (vxtime.mode == VXTIME_HPET) {
 		if (hpet64 > 0) {
 			unsigned long delta = offset - vxtime.last;
@@ -1125,6 +1133,7 @@ static int timer_resume(struct sys_devic
 
 	sec = ctime + clock_cmos_diff;
 	write_seqlock_irqsave(&xtime_lock,flags);
+	vxtime_last_invalid = 1;
 	xtime.tv_sec = sec;
 	xtime.tv_nsec = 0;
 	write_sequnlock_irqrestore(&xtime_lock,flags);

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

[Jan Beulich]

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

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

[Andi Kleen]

> 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

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

[Andi Kleen]

On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
> I don't know how resume normally handles the re-syncing of the wall
> clock, but the problem here is obvious: do_timer runs a loop to
> increment jiffies, which may require significant amounts of time
> (depending how long the system was sleeping).

It would be good if someone could submit a patch to fix
this up properly. It indeed sounds wrong.

The HPET patch seems to be generally unhappy. With it applied
I get lots of obviously wrong softlockup warnings from the
softlockup watchdog thread on a dual NForce4 system. So something
goes wrong with the timing there. The strange thing 
is that the system doesn't even have a HPET table so HPET code shouldn't
be executed - but it goes away when I revert the patch. Very
mysterious.

Also I think vgettimeofday doesn't handle 64bit HPET correctly
yet. Also why does it not use hpet_readq? 

I suspect the 64bit HPET patch needs some more cooking. I think
I will drop it for now.

I would suggest you submit the cleanups in there separately
(without changing semantics yet) 
then it will be easier to test in the future too.

-Andi

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

[Rafael J. Wysocki]

Hi,

On Thursday, 8 December 2005 23:47, Andi Kleen wrote:
> On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
> > I don't know how resume normally handles the re-syncing of the wall
> > clock, but the problem here is obvious: do_timer runs a loop to
> > increment jiffies, which may require significant amounts of time
> > (depending how long the system was sleeping).
> 
> It would be good if someone could submit a patch to fix
> this up properly. It indeed sounds wrong.

Well, timer_resume() does adjust jiffies and wall_jiffies.

The problem seems to be that vxtime.last and/or vxtime.last_tsc are not
adjusted by it which makes the timer interrupt handler unhappy (with the
hpet-overflow patch applied, that is).

Greetings,
Rafael


-- 
Beer is proof that God loves us and wants us to be happy - Benjamin Franklin

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

[Jan Beulich]

>>> Andi Kleen <ak@suse.de> 08.12.05 23:47:35 >>>
>On Thu, Dec 08, 2005 at 09:43:52AM +0100, Jan Beulich wrote:
>> I don't know how resume normally handles the re-syncing of the wall
>> clock, but the problem here is obvious: do_timer runs a loop to
>> increment jiffies, which may require significant amounts of time
>> (depending how long the system was sleeping).
>
>It would be good if someone could submit a patch to fix
>this up properly. It indeed sounds wrong.

With the nlkd patches I actually submitted code that does deal with the
calculation when significant amounts of ticks have been missed. However,
this is only part of the problem. What is more important first is for
the resume code to tell the timer interrupt handlers that it shouldn't
consider the last TSC (or other time stamp) value read prior to suspend,
but rather start anew.

>The HPET patch seems to be generally unhappy. With it applied
>I get lots of obviously wrong softlockup warnings from the
>softlockup watchdog thread on a dual NForce4 system. So something
>goes wrong with the timing there. The strange thing 
>is that the system doesn't even have a HPET table so HPET code
shouldn't
>be executed - but it goes away when I revert the patch. Very
>mysterious.

It doesn't only change the HPET code, the TSC code was suffering from
overflow problems, too, which the patch also tries to address. I can't,
however, see where or how it would cause softlockup reports. Do the
printed call stacks provide any useful information?

>Also I think vgettimeofday doesn't handle 64bit HPET correctly
>yet. Also why does it not use hpet_readq? 

For the simple reason that there is no way to know whether the entire
interconnect from CPU to HPET is (at least) 64 bits wide. At least
theoretically implementations are permitted to use 32-bit components;
the HPET spec specifically warns about that.

>I suspect the 64bit HPET patch needs some more cooking. I think
>I will drop it for now.
>
>I would suggest you submit the cleanups in there separately
>(without changing semantics yet) 
>then it will be easier to test in the future too.

What cleanups are you referring to here?

Jan

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

[Andi Kleen]

> >The HPET patch seems to be generally unhappy. With it applied
> >I get lots of obviously wrong softlockup warnings from the
> >softlockup watchdog thread on a dual NForce4 system. So something
> >goes wrong with the timing there. The strange thing 
> >is that the system doesn't even have a HPET table so HPET code
> shouldn't
> >be executed - but it goes away when I revert the patch. Very
> >mysterious.
> 
> It doesn't only change the HPET code, the TSC code was suffering from
> overflow problems, too, which the patch also tries to address. I can't,
> however, see where or how it would cause softlockup reports. Do the
> printed call stacks provide any useful information?

No they occur in random places - often even in idle.

> 
> >Also I think vgettimeofday doesn't handle 64bit HPET correctly
> >yet. Also why does it not use hpet_readq? 
> 
> For the simple reason that there is no way to know whether the entire
> interconnect from CPU to HPET is (at least) 64 bits wide. At least
> theoretically implementations are permitted to use 32-bit components;
> the HPET spec specifically warns about that.


Doesn't that refer to the CPUs ? 


> 
> >I suspect the 64bit HPET patch needs some more cooking. I think
> >I will drop it for now.
> >
> >I would suggest you submit the cleanups in there separately
> >(without changing semantics yet) 
> >then it will be easier to test in the future too.
> 
> What cleanups are you referring to here?

Like the removal of the HPET.*DANGEROUS hack and some others.

-Andi

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

[Jan Beulich]

>> >Also I think vgettimeofday doesn't handle 64bit HPET correctly
>> >yet. Also why does it not use hpet_readq? 
>> 
>> For the simple reason that there is no way to know whether the
entire
>> interconnect from CPU to HPET is (at least) 64 bits wide. At least
>> theoretically implementations are permitted to use 32-bit
components;
>> the HPET spec specifically warns about that.
>
>Doesn't that refer to the CPUs ? 

No, all bus components and other chips between CPU and the implementing
chip (including the latter) must have 64-bit data paths and guarantee
not to break up 64-bit reads into pairs of 32-bit ones. Actually, it's
the other way around - since most modern 32-but x86 CPUs have (as far as
I know) 64-bit data busses, it is normally not the CPU that restricts
accesses to 32 bits.

Jan

Re: 2.6.15-rc5-mm1

[Badari Pulavarty]

On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/

In file included from sound/pci/ens1371.c:2:
sound/pci/ens1370.c: In function `snd_audiopci_probe':
sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
reported only once
sound/pci/ens1370.c:2462: error: for each function it appears in.)
sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
function)
make[2]: *** [sound/pci/ens1371.o] Error 1
make[2]: *** Waiting for unfinished jobs....


Thanks,
Badari

Re: 2.6.15-rc5-mm1

[James Courtier-Dutton]

Badari Pulavarty wrote:
> On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> 
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> 
> 
> In file included from sound/pci/ens1371.c:2:
> sound/pci/ens1370.c: In function `snd_audiopci_probe':
> sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
> function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
> reported only once
> sound/pci/ens1370.c:2462: error: for each function it appears in.)
> sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
> function)
> make[2]: *** [sound/pci/ens1371.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> 
> 
> Thanks,
> Badari
> 

Thank you for the report, can you please raise a bug on 
http://bugzilla.kernel.org/
or
http://alsa-project.org/

We can then track this, and fix it.

FYI, I can reproduce the problem here already.

Re: 2.6.15-rc5-mm1

[Adrian Bunk]

On Thu, Dec 08, 2005 at 11:09:43AM -0800, Badari Pulavarty wrote:
> On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> 
> In file included from sound/pci/ens1371.c:2:
> sound/pci/ens1370.c: In function `snd_audiopci_probe':
> sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
> function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
> reported only once
> sound/pci/ens1370.c:2462: error: for each function it appears in.)
> sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
> function)
> make[2]: *** [sound/pci/ens1371.o] Error 1
> make[2]: *** Waiting for unfinished jobs....

Jaroslav, this seems to come from your

  [ALSA] ens1371: added spdif and lineio module option

patch in the ALSA git tree if SUPPORT_JOYSTICK=n.

> Thanks,
> Badari

cu
Adrian

-- 

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

Re: [Alsa-devel] Re: 2.6.15-rc5-mm1

[Jaroslav Kysela]

On Fri, 9 Dec 2005, Adrian Bunk wrote:

> On Thu, Dec 08, 2005 at 11:09:43AM -0800, Badari Pulavarty wrote:
> > On Sun, 2005-12-04 at 23:21 -0800, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > 
> > In file included from sound/pci/ens1371.c:2:
> > sound/pci/ens1370.c: In function `snd_audiopci_probe':
> > sound/pci/ens1370.c:2462: error: `spdif' undeclared (first use in this
> > function)sound/pci/ens1370.c:2462: error: (Each undeclared identifier is
> > reported only once
> > sound/pci/ens1370.c:2462: error: for each function it appears in.)
> > sound/pci/ens1370.c:2462: error: `lineio' undeclared (first use in this
> > function)
> > make[2]: *** [sound/pci/ens1371.o] Error 1
> > make[2]: *** Waiting for unfinished jobs....
> 
> Jaroslav, this seems to come from your
> 
>   [ALSA] ens1371: added spdif and lineio module option
> 
> patch in the ALSA git tree if SUPPORT_JOYSTICK=n.

It's already fixed in ALSA git tree:

    [ALSA] ens1371: fix compilation without SUPPORT_JOYSTICK

    Modules: ENS1370/1+ driver

    Move the spdif and lineio parameters around so that they are compiled
    even when SUPPORT_JOYSTICK isn't set.

    Signed-off-by: Clemens Ladisch <clemens@ladisch.de>


						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: 2.6.15-rc5-mm1

[Alexander E. Patrakov]

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

I just noticed (maybe too late) that this kernel has the "pata_via" 
driver and decided to try it. It works here, but has one drawback: it is 
slower than the old "via82cxxx" IDE driver.

My configuration with the via82cxxx driver:

/dev/hda = disk, QUANTUM FIREBALLlct20
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1

/dev/hdb = SAMSUNG CD-ROM SC-148F
Drive is old, supports only mdma2

There are also /dev/hdc and /dev/hdd, irrelevant here.

With the via82cxxx driver, I can get speed around 20 MB/s from /dev/hda. 
The pata_via driver downgrades this to 7 MB/s because it needlessly 
drops the disk to MWDMA2 mode.

-- 
Alexander E. Patrakov

Re: 2.6.15-rc5-mm1

[Jeff Garzik]

Alexander E. Patrakov wrote:
> Andrew Morton wrote:
> 
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/ 
>>
> 
> 
> I just noticed (maybe too late) that this kernel has the "pata_via" 
> driver and decided to try it. It works here, but has one drawback: it is 
> slower than the old "via82cxxx" IDE driver.
> 
> My configuration with the via82cxxx driver:
> 
> /dev/hda = disk, QUANTUM FIREBALLlct20
> Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1
> 
> /dev/hdb = SAMSUNG CD-ROM SC-148F
> Drive is old, supports only mdma2
> 
> There are also /dev/hdc and /dev/hdd, irrelevant here.
> 
> With the via82cxxx driver, I can get speed around 20 MB/s from /dev/hda. 
> The pata_via driver downgrades this to 7 MB/s because it needlessly 
> drops the disk to MWDMA2 mode.

That's expected, as libata currently limits all drives on a bus to the 
maximum speed of the slowest drive.  That's needed by some controllers, 
but not all.

I'm pretty sure Alan plans to fix that (at least ISTR him mentioning it).

	Jeff

Re: 2.6.15-rc5-mm1

[Alan Cox]

On Gwe, 2005-12-09 at 06:09 +0500, Alexander E. Patrakov wrote:
> With the via82cxxx driver, I can get speed around 20 MB/s from /dev/hda. 
> The pata_via driver downgrades this to 7 MB/s because it needlessly 
> drops the disk to MWDMA2 mode.

This is fixed in the ide patches I've been posting and has been fixed
for a long time. The libata core in the base kernel however isn't bright
enough to independantly tune master and slave.

Jeff asked me to finish sorting out and testing some other things with
those changes (notably ata_piix) to ensure that they don't break
existing setups. I've got that mostly done now although it took some
time because both the original ata_piix and the ide/pci/piix driver turn
out to contain bad mistakes.

I hope to be able to feed the relevant stuff to Jeff this week.

Re: 2.6.15-rc5-mm1

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:

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

mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
all know.

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

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam4 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-rc5-mm1

[Andrew Morton]

"J.A. Magallon" <jamagallon@able.es> wrote:
>
> On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > 
> 
> mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> all know.

That'll be gregkh-pci-shot-accross-the-bow.patch.

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

A joke, I believe.

Re: 2.6.15-rc5-mm1

[J.A. Magallon]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

On Tue, 13 Dec 2005 15:24:50 -0800, Andrew Morton <akpm@osdl.org> wrote:

> "J.A. Magallon" <jamagallon@able.es> wrote:
> >
> > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > 
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > 
> > 
> > mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> > all know.
> 
> That'll be gregkh-pci-shot-accross-the-bow.patch.
> 
> > Final attack against binary drivers ? Or just an API change ?
> 
> A joke, I believe.

:))
Thanks.

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

--
J.A. Magallon <jamagallon()able!es>     \               Software is like sex:
werewolf!able!es                         \         It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.14-jam4 (gcc 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.15-rc5-mm1

[Andrew Morton]

"J.A. Magallon" <jamagallon@able.es> wrote:
>
> On Tue, 13 Dec 2005 15:24:50 -0800, Andrew Morton <akpm@osdl.org> wrote:
> 
> > "J.A. Magallon" <jamagallon@able.es> wrote:
> > >
> > > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > > 
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > > 
> > > 
> > > mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> > > all know.
> > 
> > That'll be gregkh-pci-shot-accross-the-bow.patch.
> > 
> > > Final attack against binary drivers ? Or just an API change ?
> > 
> > A joke, I believe.
> 
> :))
> Thanks.
> 
> BTW, is there any easy way to get a reverse patch, apart from patch -R
> and rediff ?

That's the easiest (only?) way...

I'll drop the patch from -mm.

Re: 2.6.15-rc5-mm1

[Dmitry Torokhov]

On Tuesday 13 December 2005 19:22, Andrew Morton wrote:
> "J.A. Magallon" <jamagallon@able.es> wrote:
> >
> > On Tue, 13 Dec 2005 15:24:50 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > 
> > > "J.A. Magallon" <jamagallon@able.es> wrote:
> > > >
> > > > On Sun, 4 Dec 2005 23:21:53 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > > > 
> > > > > 
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/
> > > > > 
> > > > 
> > > > mmm, this patch GPL'ed all pci_xxxxxx functions, so it broke what you
> > > > all know.
> > > 
> > > That'll be gregkh-pci-shot-accross-the-bow.patch.
> > > 
> > > > Final attack against binary drivers ? Or just an API change ?
> > > 
> > > A joke, I believe.
> > 
> > :))
> > Thanks.
> > 
> > BTW, is there any easy way to get a reverse patch, apart from patch -R
> > and rediff ?
> 
> That's the easiest (only?) way...
>

interdiff original.patch /dev/null > reversed.patch

-- 
Dmitry

Re: 2.6.15-rc5-mm1

[Ben Pfaff]

"J.A. Magallon" <jamagallon@able.es> writes:

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

Emacs' diff-mode can reverse patches.
-- 
Ben Pfaff 
email: blp@cs.stanford.edu
web: http://benpfaff.org