2.6.14-rc2-mm1

2.6.14-rc2-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/

- Added git tree `git-sas.patch': Luben Tuikov's SAS driver and its support.

- Various random other things - nothing major.




Changes since 2.6.14-rc1-mm1:

 linus.patch
 git-cifs.patch
 git-cryptodev.patch
 git-drm.patch
 git-ia64.patch
 git-jfs.patch
 git-libata-all.patch
 git-mtd.patch
 git-netdev-all.patch
 git-nfs.patch
 git-nfs-oops-fix.patch
 git-ocfs2-prep.patch
 git-ocfs2.patch
 git-scsi-misc.patch
 git-sas.patch
 git-watchdog.patch

 Subsystem trees

-raid6-altivec-fix.patch
-sharpsl-add-missing-hunk-from-backlight-update.patch
-mtd-update-sharpsl-partition-definitions.patch
-s390-default-configuration.patch
-s390-bl_dev-array-size.patch
-s390-crypto-driver-patch-take-2.patch
-s390-show_cpuinfo-fix.patch
-s390-diag-0x308-reipl.patch
-remove-arch-arm26-boot-compressed-hw-bsec.patch
-cpu-hotplug-breaks-wake_up_new_task.patch
-s390-kernel-stack-corruption.patch
-uml-_switch_to-code-consolidation.patch
-uml-breakpoint-an-arbitrary-thread.patch
-uml-remove-a-useless-include.patch
-uml-remove-an-unused-file.patch
-uml-remove-some-build-warnings.patch
-uml-preserve-errno-in-error-paths.patch
-uml-move-libc-code-out-of-mem_userc-and-tempfilec.patch
-uml-merge-mem_userc-and-memc.patch
-uml-return-a-real-error-code.patch
-uml-remove-include-of-asm-elfh.patch
-fix-up-some-pm_message_t-types.patch
-fix-mm-kconfig-spelling.patch
-x86_64-e820c-needs-module-h.patch
-seclvl-use-securityfs-tidy.patch
-seclvl-use-securityfs-fix.patch
-hdaps-driver-update.patch
-driver-core-fix-bus_rescan_devices-race-2.patch
-i2c-kill-an-unused-i2c_adapter-struct-member.patch
-fix-buffer-overrun-in-rpadlpar_sysfsc.patch
-ibmphp-use-dword-accessors-for-pci_rom_address.patch
-pciehp-use-dword-accessors-for-pci_rom_address.patch
-shpchp-use-dword-accessors-for-pci_rom_address.patch
-qla2xxx-use-dword-accessors-for-pci_rom_address.patch
-pci-convert-kcalloc-to-kzalloc.patch
-gregkh-usb-usb-gotemp.patch
-more-device-ids-for-option-card-driver.patch
-pcnet32-set_ringparam-implementation.patch
-pcnet32-set-min-ring-size-to-4.patch
-add-smp_mb__after_clear_bit-to-unlock_kiocb.patch
-joystick-vs-xorg-fix.patch
-codingstyle-memory-allocation.patch
-files-fix-preemption-issues.patch
-files-fix-preemption-issues-tidy.patch
-fat-miss-sync-issues-on-sync-mount-miss-sync-on-write.patch
-fix-pf-request-handling.patch
-i2o-remove-class-interface.patch
-i2o-remove-i2o_device_class.patch
-driver-core-allow-nesting-classes.patch
-driver-core-make-parent-class-define-subsystem.patch
-driver-core-pass-interface-to-class-intreface-methods.patch
-driver-core-send-hotplug-event-before-adding-class-interfaces.patch
-input-kill-devfs-references.patch
-input-prepare-to-sysfs-integration.patch
-input-convert-net-bluetooth-to-dynamic-input_dev-allocation.patch
-input-convert-drivers-macintosh-to-dynamic-input_dev-allocation.patch
-input-convert-konicawc-to-dynamic-input_dev-allocation.patch
-input-convert-onetouch-to-dynamic-input_dev-allocation.patch
-drivers-input-mouse-convert-to-dynamic-input_dev-allocation.patch
-drivers-input-keyboard-convert-to-dynamic-input_dev-allocation.patch
-drivers-input-touchscreen-convert-to-dynamic-input_dev-allocation.patch
-drivers-usb-input-convert-to-dynamic-input_dev-allocation.patch
-input-convert-ucb1x00-ts-to-dynamic-input_dev-allocation.patch
-input-convert-sound-ppc-beep-to-dynamic-input_dev-allocation.patch
-input-convert-sonypi-to-dynamic-input_dev-allocation.patch
-input-convert-driver-input-misc-to-dynamic-input_dev-allocation.patch
-drivers-input-joystick-convert-to-dynamic-input_dev-allocation.patch
-drivers-media-convert-to-dynamic-input_dev-allocation.patch
-input-show-sysfs-path-in-proc-bus-input-devices.patch
-input-export-input_dev-data-via-sysfs-attributes.patch
-input-core-implement-class-hierachy.patch
-input-core-implement-class-hierachy-hdaps-fixes.patch
-input-core-remove-custom-made-hotplug-handler.patch
-input-convert-input-handlers-to-class-interfaces.patch
-input-convert-to-seq_file.patch
-ide-fix-null-request-pointer-for-taskfile-ioctl.patch

 Merged

+proc_task_root_link-c99-fix.patch
+lpfc-build-fix.patch

 old gcc fixes
 
+hostap-fix-kbuild-warning.patch

 Wrongly fix Kconfig screwup

+reboot-comment-and-factor-the-main-reboot-functions.patch
+suspend-cleanup-calling-of-power-off-methods.patch

 Power management fixes

+pci_fixup_parent_subordinate_busnr-fixes.patch

 PCI enumeration fix

+kdumpx86-add-note-type-nt_kdumpinfo-to-kernel-core-dumps.patch

 kdump feature

+acpi-handle-fadt-20-xpmtmr-address-0-case.patch

 ACPI pm_timer fix

+update-maintainers-list-with-the-kprobes-maintainers.patch

 MAINAINERS update

+v9fs-make-conv-functions-to-check-for-conv-buffer-overflow.patch
+v9fs-allocate-the-rwalk-qid-array-from-the-right-conv-buffer.patch
+v9fs-make-copy-of-the-transport-prototype-instead-of-using-it-directly.patch
+v9fs-replace-strlen-on-newly-allocated-by-__getname-buffers-to-path_max.patch
+v9fs-dont-free-root-dentry-inode-if-error-occurs-in-v9fs_get_sb.patch

 v9fs updates

+ppc64-smu-driver-update-i2c-support.patch
+ppc64-smu-driver-update-i2c-support-fix.patch

 Big update tp pmac platform driver

+acpi-disable-c2-c3-for-_all_-ibm-r40e-laptops-for-2613-bug-3549-update.patch

 Fix acpi-disable-c2-c3-for-_all_-ibm-r40e-laptops-for-2613-bug-3549.patch

+cs5535-audio-alsa-driver.patch
+cleanup-for-cs5535-audio-driver.patch

 New audio driver

+gregkh-driver-driver-ide-tape-sysfs.patch
+gregkh-driver-driver-fix-bus_rescan_devices.patch
+gregkh-driver-driver-device_is_registered.patch
+gregkh-driver-driver-fix-class-symlinks.patch

 Driver tree updates

+drm_addmap_ioctl-warning-fix.patch

 drm warning fix

+gregkh-i2c-i2c-maintainer.patch
+gregkh-i2c-hwmon-adm9240-update-01.patch
+gregkh-i2c-hwmon-adm9240-update-02.patch
+gregkh-i2c-hwmon-via686a-save-memory.patch

 i2c tree updates

+fix-broken-nvidia-device-id-in-sata_nv.patch

 SATA driver fix

+gregkh-pci-pci-remove-unused-scratch.patch
+gregkh-pci-pci-kzalloc.patch
+gregkh-pci-pci-fix-probe-warning.patch
+gregkh-pci-pci-buffer-overrun-rpaldpar.patch

 PCI tree updates

+areca-raid-linux-scsi-driver-update.patch

 Update areca-raid-linux-scsi-driver.patch

-scsi-sas-makefile-and-kconfig.patch
-sas_class-include-files-in-include-scsi-sas.patch
-sas-class-core-files.patch
-aic94xx-the-aic94xx-sas-lldd.patch
+git-sas.patch

 Adaptec Serial Attached Storage tree

+gregkh-usb-ub-burn-cd-fix.patch
+gregkh-usb-usb-option-new-ids.patch
+gregkh-usb-usb-ftdi_sio-baud-rate-change.patch
+gregkh-usb-usb-pxa2xx_udc-build-fix.patch
+gregkh-usb-usb-sl811-minor-fixes.patch
+gregkh-usb-devfs-remove-usb-mode.patch
+gregkh-usb-usb-handoff-merge.patch
+gregkh-usb-usb-power-state-01.patch
+gregkh-usb-usb-power-state-02.patch
+gregkh-usb-usb-power-state-03.patch
+gregkh-usb-usb-power-state-04.patch
+gregkh-usb-usb-power-state-05.patch
+gregkh-usb-usb-uhci-01.patch
+gregkh-usb-usb-uhci-02.patch
+gregkh-usb-usb-gotemp.patch

 USB tree updates

+gregkh-usb-usb-power-state-03-fix.patch
+gregkh-usb-usb-handoff-merge-usb-Makefile-fix.patch
+pegasus-ethernet-over-usb-driver-fixes.patch
+st5481_usb-build-fix.patch

 Various USB fixes and enhancements

+x86_64-defconfig-update.patch
-x86_64-dma32-iommu.patch
-x86_64-dma32-srat32.patch
-x86_64-vm-holes-reserved.patch
+x86_64-dma32-srat32.patch
+x86_64-vm-holes-reserved.patch
+x86_64-hpet-regs.patch
+x86_64-no-idle-tick.patch
+x86_64-nohpet.patch
+x86_64-mce-thresh.patch
+x86_64-pat-base.patch

 Various x86_64 tree updates

+x86_64-no-idle-tick-fix.patch
+x86_64-no-idle-tick-fix-2.patch
+x86_64-mce-thresh-fix.patch
+x86_64-mce-thresh-fix-2.patch

 Fix them up.

+mm-move_pte-to-remap-zero_page-fix.patch

 Fix mm-move_pte-to-remap-zero_page.patch

+eeproc-module_param_array-cleanup.patch
+b44-fix-suspend-resume.patch
+r8169-call-proper-vlan-receive-function.patch

 net driver updates

+ppc32-cleanup-amcc-ppc44x-eval-board-u-boot-support.patch
+ppc32-ifdef-out-altivec-specific-code-in-__switch_to.patch
+ppc32-handle-access-to-non-present-io-ports-on-8xx.patch

 ppc32 updates

+x86-initialise-tss-io_bitmap_owner-to-something.patch
+intel_cacheinfo-remove-max_cache_leaves-limit.patch
+i386-little-pgtableh-consolidation-vs-2-3level.patch
+x86-hot-plug-cpu-to-support-physical-add-of-new-processors.patch

 x86 updates

+x86_64-dont-use-shortcut-when-using-send_ipi_all-in-flat-mode.patch
+x86_64-init-and-zap-low-address-mappings-on-demand-for-cpu-hotplug.patch

 More x86_64 updates

+introduce-valid-callback-for-pm_ops.patch

 Power management fixlet

+uml-dont-remove-umid-files-in-conflict-case.patch
+strlcat-use-for-uml-umidc.patch
+uml-dont-redundantly-mark-pte-as-newpage-in-pte_modify.patch
+uml-fix-hang-in-tt-mode-on-fault.patch
+uml-fix-condition-in-tlb-flush.patch
+uml-run-mconsole-sysrq-in-process-context.patch
+uml-avoid-fixing-faults-while-atomic.patch
+uml-fix-gfp_-flags-usage.patch
+uml-use-gfp_atomic-for-allocations-under-spinlocks.patch
+uml-replace-printk-with-stack-friendly-printf-to-report-console-failure.patch

 UML updates

+xtensa-remove-io_remap_page_range-and-minor-clean-ups.patch

 xtensa fix

+cm4040-cardman-4040-driver-update.patch
+cm4000-cardman-4000-driver-update.patch

 Update the cardman pcmcia drivers in -mm.

-invalidate_inode_pages2_range-clean-pages-fix.patch

 Wrong, dropped.

+ext3-ext_debug-build-fixes.patch

 ext3 fixlet

+fix-bd_claim-error-code.patch

 swapon() return code fix

+reiserfs-free-checking-cleanup.patch

 reiserfs cleanup

+remove-hardcoded-send_sig_xxx-constants.patch
+cleanup-the-usage-of-send_sig_xxx-constants.patch

 Use the #defines

+little-de_thread-cleanup.patch
+introduce-setup_timer-helper.patch
+introduce-setup_timer-helper-x86_64-fix.patch
+move-tasklist-walk-from-cfq-iosched-to-elevatorc.patch

 Various code cleanups

+add-kthread_stop_sem.patch

 New workqueue featurette

+switch-sibyte-profiling-driver-to-compat_ioctl.patch
+switch-sibyte-profiling-driver-to-compat_ioctl-fix.patch
+remove-drm-ioctl32-translations-from-sparc-and-parisc.patch
+tioc-compat-ioctl-handling.patch

 ioctl() cleanups

+ntp-shift_right-cleanup.patch

 NTP cleanup

+delete-2-unreachable-statements-in-drivers-block-paride-pfc.patch
+clarify-help-text-for-init_env_arg_limit.patch
+moving-kprobes-and-oprofile-to-instrumentation-support-menu.patch

 Little fixes

+keys-add-possessor-permissions-to-keys.patch

 Key management enhancement

+fat-cleanup-and-optimization-of-checksum.patch
+fat-remove-the-unneeded-vfat_find-in-vfat_rename.patch
+fat-remove-duplicate-directory-scanning-code.patch

 fatfs updates

+i4l-update-hfc_usb-driver.patch

 ISDN driver update

+pcmcia-use-runtime-suspend-resume-support-to-unify-all-suspend-code-paths-fix.patch

 Fix pcmcia-use-runtime-suspend-resume-support-to-unify-all-suspend-code-paths.patch

+pcmcia-yenta-add-support-for-more-ti-bridges.patch
+pcmcia-yenta-optimize-interrupt-handler.patch

 Cardbus driver updates

+sched-modified-nice-support-for-smp-load-balancing.patch

 CPU scheduler improvement

+reiser4-ver_linux-dont-print-reiser4progs-version-if-none-found.patch
+reiser4-atime-update-fix.patch
+reiser4-use-try_to_freeze.patch

 reiser4 fixes

+ide-move-config_ide_max_hwifs-into-linux-ideh.patch

 IDE cleanup

+add-dm-snapshot-tutorial-in-documentation.patch

 Devicemapper documentation

+documentation-ioctl-messtxt-start-annotating-i-o.patch

 Updates to ioctl documentation

+tty-layer-buffering-revamp-icom-fixes.patch
+tty-layer-buffering-revamp-isdn-layer.patch
+driver-char-n_hdlcc-remove-unused-declaration.patch

 More tty layer fallout fixes




All 484 patches:



ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/patch-list

Re: 2.6.14-rc2-mm1

[Joel Becker]

On Wed, Sep 21, 2005 at 10:28:39PM -0700, Andrew Morton wrote:
>  git-ocfs2-prep.patch
>  git-ocfs2.patch

	As the truncate_inode_pages patch is now in Linus' git, it is
no longer in git-ocfs2.patch.  -rc2-mm1 is effectively reverting it.
git-ocfs2-prep.patch should be removed.

Joel


-- 

"There is no sincerer love than the love of food."  
         - George Bernard Shaw 

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: 2.6.14-rc2-mm1

[Reuben Farrelly]

Hi,

On 22/09/2005 5:28 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/
> 
> - Added git tree `git-sas.patch': Luben Tuikov's SAS driver and its support.
> 
> - Various random other things - nothing major.

Overall boots up and looks fine, but still seeing this oops which comes up on 
warm reboot intermittently:

ahci(0000:00:1f.2) AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
ahci(0000:00:1f.2) flags: 64bit ncq led slum part
ata1: SATA max UDMA/133 cmd 0xF8802D00 ctl 0x0 bmdma 0x0 irq 193
ata2: SATA max UDMA/133 cmd 0xF8802D80 ctl 0x0 bmdma 0x0 irq 193
ata3: SATA max UDMA/133 cmd 0xF8802E00 ctl 0x0 bmdma 0x0 irq 193
ata4: SATA max UDMA/133 cmd 0xF8802E80 ctl 0x0 bmdma 0x0 irq 193
ata1: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ahci
ata2: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ahci
ata3: no device found (phy stat 00000000)
scsi2 : ahci
ata4: no device found (phy stat 00000000)
scsi3 : ahci
   Vendor: ATA       Model: ST380817AS        Rev: 3.42
   Type:   Direct-Access                      ANSI SCSI revision: 05
   Vendor: ATA       Model: ST380817AS        Rev: 3.42
   Type:   Direct-Access                      ANSI SCSI revision: 05
scheduling while atomic: ksoftirqd/0/0x00000100/3
  [<c0103ad0>] dump_stack+0x17/0x19
  [<c031483a>] schedule+0x8ba/0xccb
  [<c0315d17>] __down+0xe5/0x126
  [<c0313f1a>] __down_failed+0xa/0x10
  [<c0233f3d>] .text.lock.main+0x2b/0x3e
  [<c022f90c>] device_del+0x35/0x5d
  [<c025d71e>] scsi_target_reap+0x89/0xa3
  [<c025ed5a>] scsi_device_dev_release+0x114/0x18b
  [<c022f504>] device_release+0x1a/0x5a
  [<c01e15c2>] kobject_cleanup+0x43/0x6b
  [<c01e15f5>] kobject_release+0xb/0xd
  [<c01e1e3c>] kref_put+0x2e/0x92
  [<c01e160b>] kobject_put+0x14/0x16
  [<c022f8d5>] put_device+0x11/0x13
  [<c0256fd8>] scsi_put_command+0x7c/0x9e
  [<c025b918>] scsi_next_command+0xf/0x19
  [<c025b9db>] scsi_end_request+0x93/0xc5
  [<c025bdd4>] scsi_io_completion+0x281/0x46a
  [<c025c1c8>] scsi_generic_done+0x2d/0x3a
  [<c0257746>] scsi_finish_command+0x7f/0x93
  [<c025762b>] scsi_softirq+0xab/0x11c
  [<c0121952>] __do_softirq+0x72/0xdc
  [<c01219f3>] do_softirq+0x37/0x39
  [<c0121eeb>] ksoftirqd+0x9f/0xf4
  [<c012ff37>] kthread+0x99/0x9d
  [<c01010b5>] kernel_thread_helper+0x5/0xb
Unable to handle kernel paging request<5>SCSI device sda: 156301488 512-byte 
hdwr sectors (80026 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
SCSI device sda: drive cache: write back
  sda: at virtual address 6b6b6b6b
  printing eip:
c025b81f
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file:
Modules linked in:
CPU:    0
EIP:    0060:[<c025b81f>]    Not tainted VLI
EFLAGS: 00010292   (2.6.14-rc2-mm1)
EIP is at scsi_run_queue+0x12/0xb8
eax: 6b6b6b6b   ebx: f7c36b70   ecx: 00000000   edx: 00000001
esi: f7c4eb6c   edi: 00000246   ebp: c1911eac   esp: c1911e98
ds: 007b   es: 007b   ss: 0068
Process ksoftirqd/0 (pid: 3, threadinfo=c1910000 task=c1942a90)
Stack: c1baf5f8 f7c36b70 f7c36b70 f7c4eb6c 00000246 c1911eb8 c025b91f f7c386e8
        c1911ed0 c025b9db f7c36b70 f7c4eb6c 00000000 00000000 c1911f28 c025bdd4
        00000001 00004f80 00000100 00000001 c1807ac0 00000000 00000000 00040000
Call Trace:
  [<c0103a83>] show_stack+0x94/0xca
  [<c0103c2c>] show_registers+0x15a/0x1ea
  [<c0103e4a>] die+0x108/0x183
  [<c03166cd>] do_page_fault+0x1ed/0x63d
  [<c0103753>] error_code+0x4f/0x54
  [<c025b91f>] scsi_next_command+0x16/0x19
  [<c025b9db>] scsi_end_request+0x93/0xc5
  [<c025bdd4>] scsi_io_completion+0x281/0x46a
  [<c025c1c8>] scsi_generic_done+0x2d/0x3a
  [<c0257746>] scsi_finish_command+0x7f/0x93
  [<c025762b>] scsi_softirq+0xab/0x11c
  [<c0121952>] __do_softirq+0x72/0xdc
  [<c01219f3>] do_softirq+0x37/0x39
  [<c0121eeb>] ksoftirqd+0x9f/0xf4
  [<c012ff37>] kthread+0x99/0x9d
  [<c01010b5>] kernel_thread_helper+0x5/0xb
Code: fd ff 8b 4d ec 8b 41 44 e8 e4 a6 0b 00 89 45 f0 89 d8 e8 34 c1 ff ff eb 
b2 55 89 e5 57 56 53 83 ec 08 89 45 f0 8b 80 10 01 00 00 <8b> 38 80 b8 85 01 
00 00 00 0f 88 8b 00 00 00 8b 47 44 e8 af a6
  <0>Kernel panic - not syncing: Fatal exception in interrupt
  <0>Rebooting in 60 seconds..


This is not new to this -mm release (I had a screen dump of it 2 weeks ago but 
I suspect it is actually a bit older than that even).

reuben

Re: 2.6.14-rc2-mm1

[Andrew Morton]

Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
> Hi,
> 
> On 22/09/2005 5:28 p.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/
> > 
> > - Added git tree `git-sas.patch': Luben Tuikov's SAS driver and its support.
> > 
> > - Various random other things - nothing major.
> 
> Overall boots up and looks fine, but still seeing this oops which comes up on 
> warm reboot intermittently:

Nasty.

> ahci(0000:00:1f.2) AHCI 0001.0000 32 slots 4 ports 1.5 Gbps 0xf impl SATA mode
> ahci(0000:00:1f.2) flags: 64bit ncq led slum part
> ata1: SATA max UDMA/133 cmd 0xF8802D00 ctl 0x0 bmdma 0x0 irq 193
> ata2: SATA max UDMA/133 cmd 0xF8802D80 ctl 0x0 bmdma 0x0 irq 193
> ata3: SATA max UDMA/133 cmd 0xF8802E00 ctl 0x0 bmdma 0x0 irq 193
> ata4: SATA max UDMA/133 cmd 0xF8802E80 ctl 0x0 bmdma 0x0 irq 193
> ata1: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
> ata1: dev 0 configured for UDMA/133
> scsi0 : ahci
> ata2: dev 0 ATA-6, max UDMA/133, 156301488 sectors: LBA48
> ata2: dev 0 configured for UDMA/133
> scsi1 : ahci
> ata3: no device found (phy stat 00000000)
> scsi2 : ahci
> ata4: no device found (phy stat 00000000)
> scsi3 : ahci
>    Vendor: ATA       Model: ST380817AS        Rev: 3.42
>    Type:   Direct-Access                      ANSI SCSI revision: 05
>    Vendor: ATA       Model: ST380817AS        Rev: 3.42
>    Type:   Direct-Access                      ANSI SCSI revision: 05
> scheduling while atomic: ksoftirqd/0/0x00000100/3
>   [<c0103ad0>] dump_stack+0x17/0x19
>   [<c031483a>] schedule+0x8ba/0xccb
>   [<c0315d17>] __down+0xe5/0x126
>   [<c0313f1a>] __down_failed+0xa/0x10
>   [<c0233f3d>] .text.lock.main+0x2b/0x3e
>   [<c022f90c>] device_del+0x35/0x5d
>   [<c025d71e>] scsi_target_reap+0x89/0xa3
>   [<c025ed5a>] scsi_device_dev_release+0x114/0x18b
>   [<c022f504>] device_release+0x1a/0x5a
>   [<c01e15c2>] kobject_cleanup+0x43/0x6b
>   [<c01e15f5>] kobject_release+0xb/0xd
>   [<c01e1e3c>] kref_put+0x2e/0x92
>   [<c01e160b>] kobject_put+0x14/0x16
>   [<c022f8d5>] put_device+0x11/0x13
>   [<c0256fd8>] scsi_put_command+0x7c/0x9e
>   [<c025b918>] scsi_next_command+0xf/0x19
>   [<c025b9db>] scsi_end_request+0x93/0xc5
>   [<c025bdd4>] scsi_io_completion+0x281/0x46a
>   [<c025c1c8>] scsi_generic_done+0x2d/0x3a
>   [<c0257746>] scsi_finish_command+0x7f/0x93
>   [<c025762b>] scsi_softirq+0xab/0x11c
>   [<c0121952>] __do_softirq+0x72/0xdc
>   [<c01219f3>] do_softirq+0x37/0x39
>   [<c0121eeb>] ksoftirqd+0x9f/0xf4
>   [<c012ff37>] kthread+0x99/0x9d
>   [<c01010b5>] kernel_thread_helper+0x5/0xb

There's a whole bunch of reasons why we cannot call scsi_target_reap() from
softirq context.  klist_del() locking and whatever semaphore that's taking
are amongst them...

> Unable to handle kernel paging request<5>SCSI device sda: 156301488 512-byte 
> hdwr sectors (80026 MB)
> SCSI device sda: drive cache: write back
> SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
> SCSI device sda: drive cache: write back
>   sda: at virtual address 6b6b6b6b
>   printing eip:
> c025b81f
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> last sysfs file:
> Modules linked in:
> CPU:    0
> EIP:    0060:[<c025b81f>]    Not tainted VLI
> EFLAGS: 00010292   (2.6.14-rc2-mm1)
> EIP is at scsi_run_queue+0x12/0xb8
> eax: 6b6b6b6b   ebx: f7c36b70   ecx: 00000000   edx: 00000001
> esi: f7c4eb6c   edi: 00000246   ebp: c1911eac   esp: c1911e98
> ds: 007b   es: 007b   ss: 0068
> Process ksoftirqd/0 (pid: 3, threadinfo=c1910000 task=c1942a90)
> Stack: c1baf5f8 f7c36b70 f7c36b70 f7c4eb6c 00000246 c1911eb8 c025b91f f7c386e8
>         c1911ed0 c025b9db f7c36b70 f7c4eb6c 00000000 00000000 c1911f28 c025bdd4
>         00000001 00004f80 00000100 00000001 c1807ac0 00000000 00000000 00040000
> Call Trace:
>   [<c0103a83>] show_stack+0x94/0xca
>   [<c0103c2c>] show_registers+0x15a/0x1ea
>   [<c0103e4a>] die+0x108/0x183
>   [<c03166cd>] do_page_fault+0x1ed/0x63d
>   [<c0103753>] error_code+0x4f/0x54
>   [<c025b91f>] scsi_next_command+0x16/0x19
>   [<c025b9db>] scsi_end_request+0x93/0xc5
>   [<c025bdd4>] scsi_io_completion+0x281/0x46a
>   [<c025c1c8>] scsi_generic_done+0x2d/0x3a
>   [<c0257746>] scsi_finish_command+0x7f/0x93
>   [<c025762b>] scsi_softirq+0xab/0x11c
>   [<c0121952>] __do_softirq+0x72/0xdc
>   [<c01219f3>] do_softirq+0x37/0x39
>   [<c0121eeb>] ksoftirqd+0x9f/0xf4
>   [<c012ff37>] kthread+0x99/0x9d
>   [<c01010b5>] kernel_thread_helper+0x5/0xb
> Code: fd ff 8b 4d ec 8b 41 44 e8 e4 a6 0b 00 89 45 f0 89 d8 e8 34 c1 ff ff eb 
> b2 55 89 e5 57 56 53 83 ec 08 89 45 f0 8b 80 10 01 00 00 <8b> 38 80 b8 85 01 
> 00 00 00 0f 88 8b 00 00 00 8b 47 44 e8 af a6
>   <0>Kernel panic - not syncing: Fatal exception in interrupt
>   <0>Rebooting in 60 seconds..
> 

It oopsed as well.   That might be a second bug.

> 
> This is not new to this -mm release (I had a screen dump of it 2 weeks ago but 
> I suspect it is actually a bit older than that even).
> 

Thanks.

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

Build breaks with this config (x440/summit): 
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/elm3b67

arch/i386/kernel/built-in.o(.init.text+0x389d): In function `set_nmi_ipi_callback':
/usr/local/autobench/var/tmp/build/arch/i386/kernel/traps.c:727: undefined reference to `usb_early_handoff'
arch/i386/kernel/built-in.o(.init.text+0x4ee0): In function `smp_read_mpc':
/usr/local/autobench/var/tmp/build/include/asm-i386/mach-summit/mach_mpparse.h:35: undefined reference to `usb_early_handoff'


Plus it panics on boot on Power-4 LPAR

Memory: 30962716k/31457280k available (4308k kernel code, 494564k reserved, 1112k data, 253k bss, 420k init)
Mount-cache hash table entries: 256
softlockup thread 0 started up.
Processor 1 found.
softlockup thread 1 started up.
Processor 2 found.
softlockup thread 2 started up.
Processor 3 found.
Brought up 4 CPUs
softlockup thread 3 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging disabled
PCI_DMA: iommu_table_setparms: /pci@3fffde0a000/pci@2,2 has missing tce entries !
Kernel panic - not syncing: iommu_init_table: Can't allocate 1729382256943765922 bytes

 <7>RTAS: event: 3, Type: Internal Device Failure, Severity: 5
ibm,os-term call failed -1

tty update speed regression (was: 2.6.14-rc2-mm1)

[Alexey Dobriyan]

I see regression in tty update speed with ADOM (ncurses based
roguelike) [1].

Messages at the top ("goblin hits you") are printed slowly. An eye can
notice letter after letter printing.

2.6.14-rc2 is OK.

I'll try to revert tty-layer-buffering-revamp*.patch pieces and see if
it'll change something.

[1] http://adom.de/adom/download/linux/adom-111-elf.tar.gz (binary only)

Re: 2.6.14-rc2-mm1

[Andrew Morton]

"Martin J. Bligh" <mbligh@mbligh.org> wrote:
>
> Build breaks with this config (x440/summit): 
> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/elm3b67
> 
> arch/i386/kernel/built-in.o(.init.text+0x389d): In function `set_nmi_ipi_callback':
> /usr/local/autobench/var/tmp/build/arch/i386/kernel/traps.c:727: undefined reference to `usb_early_handoff'
> arch/i386/kernel/built-in.o(.init.text+0x4ee0): In function `smp_read_mpc':
> /usr/local/autobench/var/tmp/build/include/asm-i386/mach-summit/mach_mpparse.h:35: undefined reference to `usb_early_handoff'
> 

grr.  David had a hack in there which caused my links to fail so I hacked
it out and broke yours.

> Plus it panics on boot on Power-4 LPAR
> 
> Memory: 30962716k/31457280k available (4308k kernel code, 494564k reserved, 1112k data, 253k bss, 420k init)
> Mount-cache hash table entries: 256
> softlockup thread 0 started up.
> Processor 1 found.
> softlockup thread 1 started up.
> Processor 2 found.
> softlockup thread 2 started up.
> Processor 3 found.
> Brought up 4 CPUs
> softlockup thread 3 started up.
> NET: Registered protocol family 16
> PCI: Probing PCI hardware
> IOMMU table initialized, virtual merging disabled
> PCI_DMA: iommu_table_setparms: /pci@3fffde0a000/pci@2,2 has missing tce entries !
> Kernel panic - not syncing: iommu_init_table: Can't allocate 1729382256943765922 bytes
> 
>  <7>RTAS: event: 3, Type: Internal Device Failure, Severity: 5
> ibm,os-term call failed -1

There are ppc64 IOMMU changes in Linus's tree...

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

>> Plus it panics on boot on Power-4 LPAR
>> 
>> Memory: 30962716k/31457280k available (4308k kernel code, 494564k reserved, 1112k data, 253k bss, 420k init)
>> Mount-cache hash table entries: 256
>> softlockup thread 0 started up.
>> Processor 1 found.
>> softlockup thread 1 started up.
>> Processor 2 found.
>> softlockup thread 2 started up.
>> Processor 3 found.
>> Brought up 4 CPUs
>> softlockup thread 3 started up.
>> NET: Registered protocol family 16
>> PCI: Probing PCI hardware
>> IOMMU table initialized, virtual merging disabled
>> PCI_DMA: iommu_table_setparms: /pci@3fffde0a000/pci@2,2 has missing tce entries !
>> Kernel panic - not syncing: iommu_init_table: Can't allocate 1729382256943765922 bytes
>> 
>>  <7>RTAS: event: 3, Type: Internal Device Failure, Severity: 5
>> ibm,os-term call failed -1
> 
> There are ppc64 IOMMU changes in Linus's tree...

Thanks. will retest with just linus.patch to confirm

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Alexey Dobriyan]

On Thu, Sep 22, 2005 at 11:50:29PM +0400, Alexey Dobriyan wrote:
> I see regression in tty update speed with ADOM (ncurses based
> roguelike) [1].
> 
> Messages at the top ("goblin hits you") are printed slowly. An eye can
> notice letter after letter printing.
> 
> 2.6.14-rc2 is OK.
> 
> I'll try to revert tty-layer-buffering-revamp*.patch pieces and see if
> it'll change something.
> 
> [1] http://adom.de/adom/download/linux/adom-111-elf.tar.gz (binary only)

Scratch TTY revamp, the sucker is
fix-sys_poll-large-timeout-handling.patch

HZ=250 here.
------------------------------------------------------------------------
From: Nishanth Aravamudan <nacc@us.ibm.com>

The @timeout parameter to sys_poll() is in milliseconds but we compare it
to (MAX_SCHEDULE_TIMEOUT / HZ), which is (jiffies/jiffies-per-sec) or
seconds.  That seems blatantly broken.  This led to improper overflow
checking for @timeout.  As Andrew Morton pointed out, the best fix is to to
check for potential overflow first, then either select an indefinite value
or convert @timeout.

To achieve this and clean-up the code, change the prototype of the sys_poll
to make it clear that the parameter is in milliseconds and introduce a
variable, timeout_jiffies to hold the corresonding jiffies value.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 fs/select.c              |   36 ++++++++++++++++++++++++++----------
 include/linux/syscalls.h |    2 +-
 2 files changed, 27 insertions(+), 11 deletions(-)

diff -puN fs/select.c~fix-sys_poll-large-timeout-handling fs/select.c
--- devel/fs/select.c~fix-sys_poll-large-timeout-handling	2005-09-10 02:35:19.000000000 -0700
+++ devel-akpm/fs/select.c	2005-09-10 03:26:17.000000000 -0700
@@ -464,15 +464,18 @@ static int do_poll(unsigned int nfds,  s
 	return count;
 }
 
-asmlinkage long sys_poll(struct pollfd __user * ufds, unsigned int nfds, long timeout)
+asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
+				long timeout_msecs)
 {
 	struct poll_wqueues table;
- 	int fdcount, err;
+	int fdcount, err;
+	int overflow;
  	unsigned int i;
 	struct poll_list *head;
  	struct poll_list *walk;
 	struct fdtable *fdt;
 	int max_fdset;
+	unsigned long timeout_jiffies;
 
 	/* Do a sanity check on nfds ... */
 	rcu_read_lock();
@@ -482,13 +485,26 @@ asmlinkage long sys_poll(struct pollfd _
 	if (nfds > max_fdset && nfds > OPEN_MAX)
 		return -EINVAL;
 
-	if (timeout) {
-		/* Careful about overflow in the intermediate values */
-		if ((unsigned long) timeout < MAX_SCHEDULE_TIMEOUT / HZ)
-			timeout = (unsigned long)(timeout*HZ+999)/1000+1;
-		else /* Negative or overflow */
-			timeout = MAX_SCHEDULE_TIMEOUT;
-	}
+	/*
+	 * We compare HZ with 1000 to work out which side of the
+	 * expression needs conversion.  Because we want to avoid
+	 * converting any value to a numerically higher value, which
+	 * could overflow.
+	 */
+#if HZ > 1000
+	overflow = timeout_msecs >= jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT);
+#else
+	overflow = msecs_to_jiffies(timeout_msecs) >= MAX_SCHEDULE_TIMEOUT;
+#endif
+
+	/*
+	 * If we would overflow in the conversion or a negative timeout
+	 * is requested, sleep indefinitely.
+	 */
+	if (overflow || timeout_msecs < 0)
+		timeout_jiffies = MAX_SCHEDULE_TIMEOUT;
+	else
+		timeout_jiffies = msecs_to_jiffies(timeout_msecs) + 1;
 
 	poll_initwait(&table);
 
@@ -519,7 +535,7 @@ asmlinkage long sys_poll(struct pollfd _
 		}
 		i -= pp->len;
 	}
-	fdcount = do_poll(nfds, head, &table, timeout);
+	fdcount = do_poll(nfds, head, &table, timeout_jiffies);
 
 	/* OK, now copy the revents fields back to user space. */
 	walk = head;
diff -puN include/linux/syscalls.h~fix-sys_poll-large-timeout-handling include/linux/syscalls.h
--- devel/include/linux/syscalls.h~fix-sys_poll-large-timeout-handling	2005-09-10 02:35:19.000000000 -0700
+++ devel-akpm/include/linux/syscalls.h	2005-09-10 02:35:19.000000000 -0700
@@ -420,7 +420,7 @@ asmlinkage long sys_socketpair(int, int,
 asmlinkage long sys_socketcall(int call, unsigned long __user *args);
 asmlinkage long sys_listen(int, int);
 asmlinkage long sys_poll(struct pollfd __user *ufds, unsigned int nfds,
-				long timeout);
+				long timeout_msecs);
 asmlinkage long sys_select(int n, fd_set __user *inp, fd_set __user *outp,
 			fd_set __user *exp, struct timeval __user *tvp);
 asmlinkage long sys_epoll_create(int size);
_

Re: 2.6.14-rc2-mm1 - ide problems ?

[Badari Pulavarty]

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

Hi Andrew,

My ide-based AMD64 machine doesn't boot 2.6.14-rc2-mm1.
Known issue ?

Thanks,
Badari



[-- Attachment #2: amd-log --]
[-- Type: text/plain, Size: 10429 bytes --]

Bootdata ok (command line is root=/dev/hda2 vga=0x314 selinux=0 splash=silent console=tty0 console=ttyS0,38400 resume=/dev/hda1 profile=2)
Linux version 2.6.14-rc2-mm1 (root@elm3b29) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Thu Sep 22 14:46:56 PDT 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ca000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000dfef0000 (usable)
 BIOS-e820: 00000000dfef0000 - 00000000dfeff000 (ACPI data)
 BIOS-e820: 00000000dfeff000 - 00000000dff00000 (ACPI NVS)
 BIOS-e820: 00000000dff00000 - 00000000e0000000 (usable)
 BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000001e0000000 (usable)
Scanning NUMA topology in Northbridge 24
Number of nodes 4
Node 0 MemBase 0000000000000000 Limit 000000017fffffff
Node 1 MemBase 0000000180000000 Limit 000000019fffffff
Node 2 MemBase 00000001a0000000 Limit 00000001bfffffff
Node 3 MemBase 00000001c0000000 Limit 00000001dfffffff
Using node hash shift of 21
Bootmem setup node 0 0000000000000000-000000017fffffff
Bootmem setup node 1 0000000180000000-000000019fffffff
Bootmem setup node 2 00000001a0000000-00000001bfffffff
Bootmem setup node 3 00000001c0000000-00000001dfffffff
ACPI: PM-Timer IO Port: 0x8008
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
Processor #2 15:5 APIC version 16
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)
Processor #3 15:5 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x05] address[0xfa3e0000] gsi_base[24])
IOAPIC[1]: apic_id 5, version 17, address 0xfa3e0000, GSI 24-27
ACPI: IOAPIC (id[0x06] address[0xfa3e1000] gsi_base[28])
IOAPIC[2]: apic_id 6, version 17, address 0xfa3e1000, GSI 28-31
ACPI: IOAPIC (id[0x07] address[0xfa3e2000] gsi_base[32])
IOAPIC[3]: apic_id 7, version 17, address 0xfa3e2000, GSI 32-35
ACPI: IOAPIC (id[0x08] address[0xfa3e4000] gsi_base[36])
IOAPIC[4]: apic_id 8, version 17, address 0xfa3e4000, GSI 36-39
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at e2000000 (gap: e0000000:1ec00000)
Checking aperture...
CPU 0: aperture @ 0 size 32 MB
No AGP bridge found
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 8000000
Built 4 zonelists
Initializing CPU#0
Kernel command line: root=/dev/hda2 vga=0x314 selinux=0 splash=silent console=tty0 console=ttyS0,38400 resume=/dev/hda1 profile=2
kernel profiling enabled (shift: 2)
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 3.579545 MHz PM timer.
time.c: Detected 1398.189 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
Memory: 6110856k/7864320k available (3049k kernel code, 194612k reserved, 1612k data, 244k init)
Calibrating delay using timer specific routine.. 2801.62 BogoMIPS (lpj=5603254)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 0(1) -> Node 0 -> Core 0
mtrr: v2.0 (20020519)
Using local APIC timer interrupts.
Detected 12.483 MHz APIC timer.
setup_APIC_timer
done
Booting processor 1/4 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 2796.59 BogoMIPS (lpj=5593188)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 1(1) -> Node 1 -> Core 0
Opteron MP w/ 1MB stepping 00
setup_APIC_timer
done
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff -1 cycles, maxerr 981 cycles)
Booting processor 2/4 APIC 0x2
Initializing CPU#2
Calibrating delay using timer specific routine.. 2796.59 BogoMIPS (lpj=5593185)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 2(1) -> Node 2 -> Core 0
Opteron MP w/ 1MB stepping 00
setup_APIC_timer
done
CPU 2: Syncing TSC to CPU 0.
CPU 2: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 976 cycles)
Booting processor 3/4 APIC 0x3
Initializing CPU#3
Calibrating delay using timer specific routine.. 2796.59 BogoMIPS (lpj=5593186)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU 3(1) -> Node 3 -> Core 0
Opteron MP w/ 1MB stepping 00
setup_APIC_timer
done
CPU 3: Syncing TSC to CPU 0.
CPU 3: synchronized TSC with CPU 0 (last diff -2 cycles, maxerr 1606 cycles)
Brought up 4 CPUs
Disabling vsyscall due to use of PM timer
time.c: Using PM based timekeeping.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 *5 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 5 *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 5 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 5 10 *11)
ACPI: PCI Root Bridge [PCI1] (0000:08)
PCI: Probing PCI hardware (bus 08)
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ 8000000 size 65536 KB
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
PCI: Bridge: 0000:00:06.0
  IO window: 2000-2fff
  MEM window: fa000000-fa0fffff
  PREFETCH window: e2000000-e20fffff
PCI: Bridge: 0000:09:01.0
  IO window: disabled.
  MEM window: fa400000-faffffff
  PREFETCH window: fc000000-fdffffff
PCI: Bridge: 0000:08:01.0
  IO window: disabled.
  MEM window: fa400000-faffffff
  PREFETCH window: fc000000-fdffffff
PCI: Bridge: 0000:08:02.0
  IO window: 3000-3fff
  MEM window: fb000000-fb0fffff
  PREFETCH window: e2100000-e21fffff
PCI: Bridge: 0000:08:03.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:08:04.0
  IO window: 4000-4fff
  MEM window: fb100000-fb1fffff
  PREFETCH window: e2200000-e22fffff
ACPI: PCI Interrupt 0000:08:04.0[A] -> GSI 36 (level, low) -> IRQ 16
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
audit: initializing netlink socket (disabled)
audit(1127427646.392:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
JFS: nTxBlock = 8192, nTxLock = 65536
Initializing Cryptographic API
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
PCI: MSI quirk detected. pci_msi_quirk set.
vesafb: framebuffer at 0xfc000000, mapped to 0xffffc20000600000, using 1875k, total 16384k
vesafb: mode is 800x600x16, linelength=1600, pages=16
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
mtrr: type mismatch for fc000000,1000000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,800000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,400000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,200000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,100000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,80000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,40000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,20000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,10000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,8000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,4000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,2000 old: write-back new: write-combining
mtrr: type mismatch for fc000000,1000 old: write-back new: write-combining
vesafb: Mode is not VGA compatible
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
Linux agpgart interface v0.101 (c) Dave Jones
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
mice: PS/2 mouse device common for all mice
input: PC Speaker
io scheduler noop registered
input: AT Translated Set 2 keyboard on isa0060/serio0
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 128000K size 1024 blocksize
loop: loaded (max 8 devices)
tg3.c:v3.40 (September 15, 2005)
ACPI: PCI Interrupt 0000:19:02.0[A] -> GSI 38 (level, low) -> IRQ 17
input: PS/2 Generic Mouse on isa0060/serio1
eth0: Tigon3 [partno(3C996B-T) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000BaseT Ethernet 00:04:76:f0:f9:aa
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[0]
eth0: dma_rwctrl[76ff000f]
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:07.1
AMD8111: chipset revision 3
AMD8111: not 100% native mode: will probe irqs later
AMD8111: 0000:00:07.1 (rev 03) UDMA133 controller
    ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x1028-0x102f, BIOS settings: hdc:DMA, hdd:pio

Re: 2.6.14-rc2-mm1 - ide problems ?

[Andrew Morton]

Badari Pulavarty <pbadari@gmail.com> wrote:
>
> My ide-based AMD64 machine doesn't boot 2.6.14-rc2-mm1.
> Known issue ?

Nope.   How does that dmesg output differ from 2.6.14-rc2's?

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Nishanth Aravamudan]

On 23.09.2005 [01:49:26 +0400], Alexey Dobriyan wrote:
> On Thu, Sep 22, 2005 at 11:50:29PM +0400, Alexey Dobriyan wrote:
> > I see regression in tty update speed with ADOM (ncurses based
> > roguelike) [1].
> > 
> > Messages at the top ("goblin hits you") are printed slowly. An eye can
> > notice letter after letter printing.
> > 
> > 2.6.14-rc2 is OK.
> > 
> > I'll try to revert tty-layer-buffering-revamp*.patch pieces and see if
> > it'll change something.
> > 
> > [1] http://adom.de/adom/download/linux/adom-111-elf.tar.gz (binary only)
> 
> Scratch TTY revamp, the sucker is
> fix-sys_poll-large-timeout-handling.patch
> 
> HZ=250 here.

Alexey,

Thanks for the report. I will take a look on my Thinkpad with HZ=250
under -mm2. I have some ideas for debugging it if I see the same
problem.

Thanks,
Nish

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

--"Martin J. Bligh" <mbligh@mbligh.org> wrote (on Thursday, September 22, 2005 13:14:11 -0700):

>>> Plus it panics on boot on Power-4 LPAR
>>> 
>>> Memory: 30962716k/31457280k available (4308k kernel code, 494564k reserved, 1112k data, 253k bss, 420k init)
>>> Mount-cache hash table entries: 256
>>> softlockup thread 0 started up.
>>> Processor 1 found.
>>> softlockup thread 1 started up.
>>> Processor 2 found.
>>> softlockup thread 2 started up.
>>> Processor 3 found.
>>> Brought up 4 CPUs
>>> softlockup thread 3 started up.
>>> NET: Registered protocol family 16
>>> PCI: Probing PCI hardware
>>> IOMMU table initialized, virtual merging disabled
>>> PCI_DMA: iommu_table_setparms: /pci@3fffde0a000/pci@2,2 has missing tce entries !
>>> Kernel panic - not syncing: iommu_init_table: Can't allocate 1729382256943765922 bytes
>>> 
>>>  <7>RTAS: event: 3, Type: Internal Device Failure, Severity: 5
>>> ibm,os-term call failed -1
>> 
>> There are ppc64 IOMMU changes in Linus's tree...
> 
> Thanks. will retest with just linus.patch to confirm

Yeah, is broken there too. Borkage in mainline! ;-)

http://test.kernel.org/13316/debug/console.log

if someone wants to look ...

M.

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Nish Aravamudan]

On 9/22/05, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> On 23.09.2005 [01:49:26 +0400], Alexey Dobriyan wrote:
> > On Thu, Sep 22, 2005 at 11:50:29PM +0400, Alexey Dobriyan wrote:
> > > I see regression in tty update speed with ADOM (ncurses based
> > > roguelike) [1].
> > >
> > > Messages at the top ("goblin hits you") are printed slowly. An eye can
> > > notice letter after letter printing.
> > >
> > > 2.6.14-rc2 is OK.
> > >
> > > I'll try to revert tty-layer-buffering-revamp*.patch pieces and see if
> > > it'll change something.
> > >
> > > [1] http://adom.de/adom/download/linux/adom-111-elf.tar.gz (binary only)
> >
> > Scratch TTY revamp, the sucker is
> > fix-sys_poll-large-timeout-handling.patch
> >
> > HZ=250 here.
>
> Alexey,
>
> Thanks for the report. I will take a look on my Thinkpad with HZ=250
> under -mm2. I have some ideas for debugging it if I see the same
> problem.

I did not see any tty refresh problems on my TP with HZ=250 under
2.6.14-rc2-mm1 (excuse the typo in my previous response) under the
adom binary you sent me. I even played two games just to make sure ;)

Is there any chance you can do an strace of the process while it is
slow to redraw your screen? Just to verify how poll() is being called
[if my patch is the problem, then poll() must be being used somewhat
differently than I expected -- e.g. a dependency on the broken
behavior]. The only thing I can think of right now is that I made
timeout_jiffies unsigned, when schedule_timeout() will treat it as
signed, but I'm not sure if that is the problem.

We may want to contact the adom author eventually to figure out how
poll() is being used in the Linux port, if strace is unable to help
further.

Thanks,
Nish

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Alexey Dobriyan]

On Fri, Sep 23, 2005 at 10:12:11AM -0700, Nish Aravamudan wrote:
> I did not see any tty refresh problems on my TP with HZ=250 under
> 2.6.14-rc2-mm1 (excuse the typo in my previous response) under the
> adom binary you sent me. I even played two games just to make sure ;)

The slowdown is HZ dependent:
* HZ=1000 - game is playable. If I would not know slowdown is there I
  wouldn't notice it.
* HZ=100 - messages at the top are printed r e a l l y  s l o w.
* HZ=250 - somewhere in the middle.

> Is there any chance you can do an strace of the process while it is
> slow to redraw your screen?

Typical pattern is:

rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
write(1, "\33[11;18H\33[37m\33[40m[g] Gnome\r\33[12"..., 58) = 58
rt_sigaction(SIGTSTP, {0xb7f1e578, [], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
write(1, "\33[12;18H\33[37m\33[40m[h] Hurthling\r"..., 62) = 62
rt_sigaction(SIGTSTP, {0xb7f1e578, [], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
poll([{fd=0, events=POLLIN}], 1, 0) = 0
write(1, "\33[13;18H\33[37m\33[40m[i] Orc\r\33[14d\33"..., 56) = 56
rt_sigaction(SIGTSTP, {0xb7f1e578, [], SA_RESTART}, NULL, 8) = 0
rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0

I can send full strace log if needed.

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Nishanth Aravamudan]

On 23.09.2005 [22:42:16 +0400], Alexey Dobriyan wrote:
> On Fri, Sep 23, 2005 at 10:12:11AM -0700, Nish Aravamudan wrote:
> > I did not see any tty refresh problems on my TP with HZ=250 under
> > 2.6.14-rc2-mm1 (excuse the typo in my previous response) under the
> > adom binary you sent me. I even played two games just to make sure ;)
> 
> The slowdown is HZ dependent:
> * HZ=1000 - game is playable. If I would not know slowdown is there I
>   wouldn't notice it.
> * HZ=100 - messages at the top are printed r e a l l y  s l o w.
> * HZ=250 - somewhere in the middle.
> 
> > Is there any chance you can do an strace of the process while it is
> > slow to redraw your screen?
> 
> Typical pattern is:
> 
> rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
> poll([{fd=0, events=POLLIN}], 1, 0) = 0
> poll([{fd=0, events=POLLIN}], 1, 0) = 0
> write(1, "\33[11;18H\33[37m\33[40m[g] Gnome\r\33[12"..., 58) = 58
> rt_sigaction(SIGTSTP, {0xb7f1e578, [], SA_RESTART}, NULL, 8) = 0
> rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
> poll([{fd=0, events=POLLIN}], 1, 0) = 0
> poll([{fd=0, events=POLLIN}], 1, 0) = 0
> write(1, "\33[12;18H\33[37m\33[40m[h] Hurthling\r"..., 62) = 62
> rt_sigaction(SIGTSTP, {0xb7f1e578, [], SA_RESTART}, NULL, 8) = 0
> rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
> poll([{fd=0, events=POLLIN}], 1, 0) = 0
> poll([{fd=0, events=POLLIN}], 1, 0) = 0
> write(1, "\33[13;18H\33[37m\33[40m[i] Orc\r\33[14d\33"..., 56) = 56
> rt_sigaction(SIGTSTP, {0xb7f1e578, [], SA_RESTART}, NULL, 8) = 0
> rt_sigaction(SIGTSTP, {SIG_IGN}, {0xb7f1e578, [], SA_RESTART}, 8) = 0
> 
> I can send full strace log if needed.

Nope, that helped tremendously! I think I know what the issue is (and
why it's HZ dependent).

In the current code, (2.6.13.2, e.g) we allow 0 timeout poll-requests to
be resolved as 0 jiffy requests. But in my patch, those requests become
1 jiffy (which of course depends on HZ and gets quite long if HZ=100)!

Care to try the following patch?

Note: I would be happy to not do the conditional and just have the patch
change the msecs_to_jiffies() line when assigning to timeout_jiffies.
But I figured it would be best to avoid *all* computations if we know
the resulting value is going to be 0. Hence all the tab changing.

Thanks,
Nish

Description: Modifying sys_poll() to handle large timeouts correctly
resulted in 0 being treated just like any other millisecond request,
while the current code treats it as an optimized case. Do the same in
the new code. Most of the code change is tabbing due to the inserted if.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

---

 fs/select.c |   41 +++++++++++++++++++++++++----------------
 1 files changed, 25 insertions(+), 16 deletions(-)

diff -urpN 2.6.14-rc2-mm1/fs/select.c 2.6.14-rc2-mm1-dev/fs/select.c
--- 2.6.14-rc2-mm1/fs/select.c	2005-09-23 11:52:36.000000000 -0700
+++ 2.6.14-rc2-mm1-dev/fs/select.c	2005-09-23 12:04:03.000000000 -0700
@@ -485,26 +485,35 @@ asmlinkage long sys_poll(struct pollfd _
 	if (nfds > max_fdset && nfds > OPEN_MAX)
 		return -EINVAL;
 
-	/*
-	 * We compare HZ with 1000 to work out which side of the
-	 * expression needs conversion.  Because we want to avoid
-	 * converting any value to a numerically higher value, which
-	 * could overflow.
-	 */
+	if (timeout_msecs) {
+		/*
+		 * We compare HZ with 1000 to work out which side of the
+		 * expression needs conversion.  Because we want to
+		 * avoid converting any value to a numerically higher
+		 * value, which could overflow.
+		 */
 #if HZ > 1000
-	overflow = timeout_msecs >= jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT);
+		overflow = timeout_msecs >=
+				jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT);
 #else
-	overflow = msecs_to_jiffies(timeout_msecs) >= MAX_SCHEDULE_TIMEOUT;
+		overflow = msecs_to_jiffies(timeout_msecs) >=
+				MAX_SCHEDULE_TIMEOUT;
 #endif
 
-	/*
-	 * If we would overflow in the conversion or a negative timeout
-	 * is requested, sleep indefinitely.
-	 */
-	if (overflow || timeout_msecs < 0)
-		timeout_jiffies = MAX_SCHEDULE_TIMEOUT;
-	else
-		timeout_jiffies = msecs_to_jiffies(timeout_msecs) + 1;
+		/*
+		 * If we would overflow in the conversion or a negative
+		 * timeout is requested, sleep indefinitely.
+		 */
+		if (overflow || timeout_msecs < 0)
+			timeout_jiffies = MAX_SCHEDULE_TIMEOUT;
+		else
+			timeout_jiffies = msecs_to_jiffies(timeout_msecs) + 1;
+	} else {
+		/*
+		 * 0 millisecond requests become 0 jiffy requests
+		 */
+		timeout_jiffies = 0;
+	}
 
 	poll_initwait(&table);
 

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Alexey Dobriyan]

On Fri, Sep 23, 2005 at 12:07:49PM -0700, Nishanth Aravamudan wrote:
> On 23.09.2005 [22:42:16 +0400], Alexey Dobriyan wrote:
> > poll([{fd=0, events=POLLIN}], 1, 0) = 0

> > I can send full strace log if needed.
> 
> Nope, that helped tremendously! I think I know what the issue is (and
> why it's HZ dependent).
> 
> In the current code, (2.6.13.2, e.g) we allow 0 timeout poll-requests to
> be resolved as 0 jiffy requests. But in my patch, those requests become
> 1 jiffy (which of course depends on HZ and gets quite long if HZ=100)!
> 
> Care to try the following patch?

It works! Now, even with HZ=100, gameplay is smooth.

Andrew, please, apply.

> Description: Modifying sys_poll() to handle large timeouts correctly
> resulted in 0 being treated just like any other millisecond request,
> while the current code treats it as an optimized case. Do the same in
> the new code. Most of the code change is tabbing due to the inserted if.

> diff -urpN 2.6.14-rc2-mm1/fs/select.c 2.6.14-rc2-mm1-dev/fs/select.c
> --- 2.6.14-rc2-mm1/fs/select.c	2005-09-23 11:52:36.000000000 -0700
> +++ 2.6.14-rc2-mm1-dev/fs/select.c	2005-09-23 12:04:03.000000000 -0700
> @@ -485,26 +485,35 @@ asmlinkage long sys_poll(struct pollfd _
>  	if (nfds > max_fdset && nfds > OPEN_MAX)
>  		return -EINVAL;
>  
> -	/*
> -	 * We compare HZ with 1000 to work out which side of the
> -	 * expression needs conversion.  Because we want to avoid
> -	 * converting any value to a numerically higher value, which
> -	 * could overflow.
> -	 */
> +	if (timeout_msecs) {
> +		/*
> +		 * We compare HZ with 1000 to work out which side of the
> +		 * expression needs conversion.  Because we want to
> +		 * avoid converting any value to a numerically higher
> +		 * value, which could overflow.
> +		 */
>  #if HZ > 1000
> -	overflow = timeout_msecs >= jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT);
> +		overflow = timeout_msecs >=
> +				jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT);
>  #else
> -	overflow = msecs_to_jiffies(timeout_msecs) >= MAX_SCHEDULE_TIMEOUT;
> +		overflow = msecs_to_jiffies(timeout_msecs) >=
> +				MAX_SCHEDULE_TIMEOUT;
>  #endif
>  
> -	/*
> -	 * If we would overflow in the conversion or a negative timeout
> -	 * is requested, sleep indefinitely.
> -	 */
> -	if (overflow || timeout_msecs < 0)
> -		timeout_jiffies = MAX_SCHEDULE_TIMEOUT;
> -	else
> -		timeout_jiffies = msecs_to_jiffies(timeout_msecs) + 1;
> +		/*
> +		 * If we would overflow in the conversion or a negative
> +		 * timeout is requested, sleep indefinitely.
> +		 */
> +		if (overflow || timeout_msecs < 0)
> +			timeout_jiffies = MAX_SCHEDULE_TIMEOUT;
> +		else
> +			timeout_jiffies = msecs_to_jiffies(timeout_msecs) + 1;
> +	} else {
> +		/*
> +		 * 0 millisecond requests become 0 jiffy requests
> +		 */
> +		timeout_jiffies = 0;
> +	}
>  
>  	poll_initwait(&table);
>  

Re: tty update speed regression (was: 2.6.14-rc2-mm1)

[Nishanth Aravamudan]

On 23.09.2005 [23:42:53 +0400], Alexey Dobriyan wrote:
> On Fri, Sep 23, 2005 at 12:07:49PM -0700, Nishanth Aravamudan wrote:
> > On 23.09.2005 [22:42:16 +0400], Alexey Dobriyan wrote:
> > > poll([{fd=0, events=POLLIN}], 1, 0) = 0
> 
> > > I can send full strace log if needed.
> > 
> > Nope, that helped tremendously! I think I know what the issue is (and
> > why it's HZ dependent).
> > 
> > In the current code, (2.6.13.2, e.g) we allow 0 timeout poll-requests to
> > be resolved as 0 jiffy requests. But in my patch, those requests become
> > 1 jiffy (which of course depends on HZ and gets quite long if HZ=100)!
> > 
> > Care to try the following patch?
> 
> It works! Now, even with HZ=100, gameplay is smooth.
> 
> Andrew, please, apply.

Great! Thanks for the testing, Alexey.

-Nish

Re: 2.6.14-rc2-mm1

[Mattia Dongili]

On Wed, Sep 21, 2005 at 10:28:39PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/
[...]
> +reiser4-ver_linux-dont-print-reiser4progs-version-if-none-found.patch
> +reiser4-atime-update-fix.patch
> +reiser4-use-try_to_freeze.patch
> 
>  reiser4 fixes

Runs good, except that reiser4 seems to do bad things in do_sendfile.
I have apache2 running here and it refuses to serve my ~/public_html
homepage. /home is running on a reiser4 partition and while apache2
serves good pages from different filesystems, stracing the process while
requesting my homepage, I get:

stat64("/home/mattia/public_html/index.html", {st_mode=S_IFREG|0644, st_size=2315, ...}) = 0
open("/home/mattia/public_html/index.html", O_RDONLY) = 12
setsockopt(11, SOL_TCP, TCP_NODELAY, [0], 4) = 0
setsockopt(11, SOL_TCP, TCP_CORK, [1], 4) = 0
writev(11, [{"HTTP/1.1 200 OK\r\nDate: Sat, 24 S"..., 328}], 1) = 328
sendfile(11, 12, [0], 2315)             = -1 EINVAL (Invalid argument)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
setsockopt(11, SOL_TCP, TCP_CORK, [0], 4) = 0
setsockopt(11, SOL_TCP, TCP_NODELAY, [1], 4) = 0
read(11, 0x82297f0, 8000)               = -1 EAGAIN (Resource temporarily unavailable)
write(10, "127.0.0.1 - - [24/Sep/2005:10:13"..., 95) = 95
close(11)                               = 0
read(5, 0xbfe4c4e3, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
close(12)                               = 0

-- 
mattia
:wq!

Re: 2.6.14-rc2-mm1

[Mattia Dongili]

On Wed, Sep 21, 2005 at 10:28:39PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/

Herm... running almost good :) I just got the below allocation failure
(including /proc/slabinfo and /proc/vmstat, useful? can provide more
info if happens again - ah, exim is just running for the local delivery
purpose only). I did see it previously in .14-rc1-mm1 only but I didn't
find time enough to report it properly.

Linux version 2.6.14-rc2-mm1-1 (mattia@inferi) (gcc version 4.0.1 (Debian 4.0.1-2)) #1 PREEMPT Fri Sep 23 20:56:05 CEST 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
 BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000c0000 - 00000000000d0000 (reserved)
 BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fef0000 (usable)
 BIOS-e820: 000000000fef0000 - 000000000feff000 (ACPI data)
 BIOS-e820: 000000000feff000 - 000000000ff00000 (ACPI NVS)
 BIOS-e820: 000000000ff00000 - 000000000ff80000 (usable)
 BIOS-e820: 000000000ff80000 - 0000000010000000 (reserved)
 BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved)
 BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65408
  DMA zone: 4096 pages, LIFO batch:2
  DMA32 zone: 0 pages, LIFO batch:2
  Normal zone: 61312 pages, LIFO batch:32
  HighMem zone: 0 pages, LIFO batch:2
DMI present.
[...]
exim4: page allocation failure. order:1, mode:0x80000020
 [<c0143698>] __alloc_pages+0x328/0x450
 [<c0147150>] kmem_getpages+0x30/0xa0
 [<c01480cf>] cache_grow+0xbf/0x1f0
 [<c0148446>] cache_alloc_refill+0x246/0x280
 [<c0148793>] __kmalloc+0x73/0x80
 [<c0291cd8>] pskb_expand_head+0x58/0x150
 [<c0297143>] skb_checksum_help+0x103/0x120
 [<d0c6d1cc>] ip_nat_fn+0x1cc/0x240 [iptable_nat]
 [<d0c763e8>] ip_conntrack_in+0x188/0x2c0 [ip_conntrack]
 [<d0c6d45e>] ip_nat_local_fn+0x7e/0xc0 [iptable_nat]
 [<c02b2670>] dst_output+0x0/0x30
 [<c02b2670>] dst_output+0x0/0x30
 [<c02e7c2b>] nf_iterate+0x6b/0xa0
 [<c02b2670>] dst_output+0x0/0x30
 [<c02b2670>] dst_output+0x0/0x30
 [<c02e7cc4>] nf_hook_slow+0x64/0x140
 [<c02b2670>] dst_output+0x0/0x30
 [<c02b2670>] dst_output+0x0/0x30
 [<c02b35ae>] ip_queue_xmit+0x23e/0x550
 [<c02b2670>] dst_output+0x0/0x30
 [<c01e1b9a>] __copy_to_user_ll+0x4a/0x90
 [<c0293a6e>] memcpy_toiovec+0x6e/0x90
 [<c02c4c75>] tcp_cwnd_restart+0x35/0xf0
 [<c02c5276>] tcp_transmit_skb+0x426/0x780
 [<c02c332e>] tcp_rcv_established+0x6e/0x8c0
 [<c02c657d>] tcp_write_xmit+0x12d/0x3d0
 [<c02c6855>] __tcp_push_pending_frames+0x35/0xb0
 [<c02bad3c>] tcp_sendmsg+0xa3c/0xb50
 [<c028c67f>] sock_aio_write+0xcf/0x120
 [<c016029d>] do_sync_write+0xcd/0x130
 [<c0131ed0>] autoremove_wake_function+0x0/0x60
 [<c016047f>] vfs_write+0x17f/0x190
 [<c016055b>] sys_write+0x4b/0x80
 [<c01032a1>] syscall_call+0x7/0xb
Mem-info:
DMA per-cpu:
cpu 0 hot: low 0, high 12, batch 2 used:8
cpu 0 cold: low 0, high 4, batch 1 used:3
DMA32 per-cpu: empty
Normal per-cpu:
cpu 0 hot: low 0, high 192, batch 32 used:14
cpu 0 cold: low 0, high 64, batch 16 used:51
HighMem per-cpu: empty
Free pages:        4112kB (0kB HighMem)
Active:46238 inactive:10857 dirty:16 writeback:0 unstable:0 free:1028 slab:4078 mapped:39343 pagetables:316
DMA free:1224kB min:128kB low:160kB high:192kB active:6812kB inactive:3684kB present:16384kB pages_scanned:36 all_unreclaimable? no
lowmem_reserve[]: 0 0 239 239
DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 239 239
Normal free:2888kB min:1916kB low:2392kB high:2872kB active:178140kB inactive:39744kB present:245248kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 300*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1224kB
DMA32: empty
Normal: 722*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2888kB
HighMem: empty
Swap cache: add 33, delete 33, find 0/0, race 0+0
Free swap  = 248864kB
Total swap = 248996kB
Free swap:       248864kB
65408 pages of RAM
0 pages of HIGHMEM
1529 reserved pages
46307 pages shared
0 pages swap cached
16 pages dirty
0 pages writeback
39343 pages mapped
4078 pages slab
316 pages pagetables


  cat /proc/slabinfo
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nfs_write_data        36     36    448    9    1 : tunables   54   27    0 : slabdata      4      4      0
nfs_read_data         32     36    448    9    1 : tunables   54   27    0 : slabdata      4      4      0
nfs_inode_cache        3     14    560    7    1 : tunables   54   27    0 : slabdata      2      2      0
nfs_page               0      0     64   59    1 : tunables  120   60    0 : slabdata      0      0      0
rpc_buffers            8      8   2048    2    1 : tunables   24   12    0 : slabdata      4      4      0
rpc_tasks              8     20    192   20    1 : tunables  120   60    0 : slabdata      1      1      0
rpc_inode_cache        8      9    416    9    1 : tunables   54   27    0 : slabdata      1      1      0
ip_conntrack_expect      0      0     96   40    1 : tunables  120   60    0 : slabdata      0      0      0
ip_conntrack           1     15    256   15    1 : tunables  120   60    0 : slabdata      1      1      0
scsi_cmd_cache         1     11    352   11    1 : tunables   54   27    0 : slabdata      1      1      0
d_cursor               0      0     64   59    1 : tunables  120   60    0 : slabdata      0      0      0
file_fsdata           71     75    256   15    1 : tunables  120   60    0 : slabdata      5      5      0
dentry_fsdata       2188   3658     64   59    1 : tunables  120   60    0 : slabdata     62     62      0
fq                     0      0     64   59    1 : tunables  120   60    0 : slabdata      0      0      0
jnode               1869   4480     96   40    1 : tunables  120   60    0 : slabdata    112    112      0
txn_handle             0      0     32  113    1 : tunables  120   60    0 : slabdata      0      0      0
txn_atom               1     15    256   15    1 : tunables  120   60    0 : slabdata      1      1      0
plugin_set            73    118     64   59    1 : tunables  120   60    0 : slabdata      2      2      0
znode               4704   7888    224   17    1 : tunables  120   60    0 : slabdata    464    464      0
reiser4_inode       4057   4144    512    7    1 : tunables   54   27    0 : slabdata    592    592      0
sgpool-128            32     32   2048    2    1 : tunables   24   12    0 : slabdata     16     16      0
sgpool-64             32     32   1024    4    1 : tunables   54   27    0 : slabdata      8      8      0
sgpool-32             32     32    512    8    1 : tunables   54   27    0 : slabdata      4      4      0
sgpool-16             32     45    256   15    1 : tunables  120   60    0 : slabdata      3      3      0
sgpool-8              32     60    128   30    1 : tunables  120   60    0 : slabdata      2      2      0
dm_tio                 0      0     16  203    1 : tunables  120   60    0 : slabdata      0      0      0
dm_io                  0      0     16  203    1 : tunables  120   60    0 : slabdata      0      0      0
uhci_urb_priv          1     92     40   92    1 : tunables  120   60    0 : slabdata      1      1      0
UNIX                  77     77    352   11    1 : tunables   54   27    0 : slabdata      7      7      0
tcp_bind_bucket       15    203     16  203    1 : tunables  120   60    0 : slabdata      1      1      0
inet_peer_cache        1     59     64   59    1 : tunables  120   60    0 : slabdata      1      1      0
ip_fib_alias           9    113     32  113    1 : tunables  120   60    0 : slabdata      1      1      0
ip_fib_hash            9    113     32  113    1 : tunables  120   60    0 : slabdata      1      1      0
ip_dst_cache          31     45    256   15    1 : tunables  120   60    0 : slabdata      3      3      0
arp_cache              3     30    128   30    1 : tunables  120   60    0 : slabdata      1      1      0
RAW                    2      9    448    9    1 : tunables   54   27    0 : slabdata      1      1      0
UDP                    8      9    448    9    1 : tunables   54   27    0 : slabdata      1      1      0
tw_sock_TCP            0      0     96   40    1 : tunables  120   60    0 : slabdata      0      0      0
request_sock_TCP       0      0     64   59    1 : tunables  120   60    0 : slabdata      0      0      0
TCP                   15     16    960    4    1 : tunables   54   27    0 : slabdata      4      4      0
cfq_ioc_pool           0      0     48   78    1 : tunables  120   60    0 : slabdata      0      0      0
cfq_pool               0      0     96   40    1 : tunables  120   60    0 : slabdata      0      0      0
crq_pool               0      0     44   84    1 : tunables  120   60    0 : slabdata      0      0      0
deadline_drq           0      0     48   78    1 : tunables  120   60    0 : slabdata      0      0      0
as_arq                24    189     60   63    1 : tunables  120   60    0 : slabdata      3      3      0
mqueue_inode_cache      1      7    512    7    1 : tunables   54   27    0 : slabdata      1      1      0
reiser_inode_cache    622   1450    392   10    1 : tunables   54   27    0 : slabdata    145    145      0
dnotify_cache          0      0     20  169    1 : tunables  120   60    0 : slabdata      0      0      0
eventpoll_pwq          0      0     36  101    1 : tunables  120   60    0 : slabdata      0      0      0
eventpoll_epi          0      0     96   40    1 : tunables  120   60    0 : slabdata      0      0      0
inotify_event_cache      0      0     28  127    1 : tunables  120   60    0 : slabdata      0      0      0
inotify_watch_cache      0      0     36  101    1 : tunables  120   60    0 : slabdata      0      0      0
kioctx                 0      0    160   24    1 : tunables  120   60    0 : slabdata      0      0      0
kiocb                  0      0    128   30    1 : tunables  120   60    0 : slabdata      0      0      0
fasync_cache           2    203     16  203    1 : tunables  120   60    0 : slabdata      1      1      0
shmem_inode_cache    748    756    408    9    1 : tunables   54   27    0 : slabdata     84     84      0
posix_timers_cache      0      0     96   40    1 : tunables  120   60    0 : slabdata      0      0      0
uid_cache              6     59     64   59    1 : tunables  120   60    0 : slabdata      1      1      0
blkdev_ioc            51    127     28  127    1 : tunables  120   60    0 : slabdata      1      1      0
blkdev_queue           2     10    380   10    1 : tunables   54   27    0 : slabdata      1      1      0
blkdev_requests       25     78    152   26    1 : tunables  120   60    0 : slabdata      3      3      0
biovec-(256)         260    260   3072    2    2 : tunables   24   12    0 : slabdata    130    130      0
biovec-128           264    265   1536    5    2 : tunables   24   12    0 : slabdata     53     53      0
biovec-64            272    275    768    5    1 : tunables   54   27    0 : slabdata     55     55      0
biovec-16            272    280    192   20    1 : tunables  120   60    0 : slabdata     14     14      0
biovec-4             272    295     64   59    1 : tunables  120   60    0 : slabdata      5      5      0
biovec-1             279    406     16  203    1 : tunables  120   60    0 : slabdata      2      2      0
bio                  279    354     64   59    1 : tunables  120   60    0 : slabdata      6      6      0
file_lock_cache       21     44     88   44    1 : tunables  120   60    0 : slabdata      1      1      0
sock_inode_cache     110    110    352   11    1 : tunables   54   27    0 : slabdata     10     10      0
skbuff_fclone_cache      0      0    320   12    1 : tunables   54   27    0 : slabdata      0      0      0
skbuff_head_cache    696    696    160   24    1 : tunables  120   60    0 : slabdata     29     29      0
acpi_operand         828    828     40   92    1 : tunables  120   60    0 : slabdata      9      9      0
acpi_parse_ext        61     84     44   84    1 : tunables  120   60    0 : slabdata      1      1      0
acpi_parse            41    127     28  127    1 : tunables  120   60    0 : slabdata      1      1      0
acpi_state            28     78     48   78    1 : tunables  120   60    0 : slabdata      1      1      0
proc_inode_cache     215    360    332   12    1 : tunables   54   27    0 : slabdata     30     30      0
sigqueue               4     26    148   26    1 : tunables  120   60    0 : slabdata      1      1      0
radix_tree_node     3568   4046    276   14    1 : tunables   54   27    0 : slabdata    289    289      0
bdev_cache             7      9    416    9    1 : tunables   54   27    0 : slabdata      1      1      0
sysfs_dir_cache     4059   4140     40   92    1 : tunables  120   60    0 : slabdata     45     45      0
mnt_cache             27     40     96   40    1 : tunables  120   60    0 : slabdata      1      1      0
inode_cache         1113   1272    316   12    1 : tunables   54   27    0 : slabdata    106    106      0
dentry_cache        5085   7569    136   29    1 : tunables  120   60    0 : slabdata    261    261      0
filp                1512   1632    160   24    1 : tunables  120   60    0 : slabdata     68     68      0
names_cache           11     11   4096    1    1 : tunables   24   12    0 : slabdata     11     11      0
idr_layer_cache       93    116    136   29    1 : tunables  120   60    0 : slabdata      4      4      0
buffer_head         3942  20592     48   78    1 : tunables  120   60    0 : slabdata    264    264      0
mm_struct             77     77    576    7    1 : tunables   54   27    0 : slabdata     11     11      0
vm_area_struct      3512   3740     88   44    1 : tunables  120   60    0 : slabdata     85     85      0
fs_cache              77    113     32  113    1 : tunables  120   60    0 : slabdata      1      1      0
files_cache           78     99    448    9    1 : tunables   54   27    0 : slabdata     11     11      0
signal_cache          99     99    352   11    1 : tunables   54   27    0 : slabdata      9      9      0
sighand_cache         84     84   1312    3    1 : tunables   24   12    0 : slabdata     28     28      0
task_struct           93     93   1328    3    1 : tunables   24   12    0 : slabdata     31     31      0
anon_vma            1504   1695      8  339    1 : tunables  120   60    0 : slabdata      5      5      0
pgd                   64     64   4096    1    1 : tunables   24   12    0 : slabdata     64     64      0
size-131072(DMA)       0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
size-131072            0      0 131072    1   32 : tunables    8    4    0 : slabdata      0      0      0
size-65536(DMA)        0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
size-65536             0      0  65536    1   16 : tunables    8    4    0 : slabdata      0      0      0
size-32768(DMA)        0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
size-32768             2      2  32768    1    8 : tunables    8    4    0 : slabdata      2      2      0
size-16384(DMA)        0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
size-16384             0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
size-8192(DMA)         0      0   8192    1    2 : tunables    8    4    0 : slabdata      0      0      0
size-8192             95     95   8192    1    2 : tunables    8    4    0 : slabdata     95     95      0
size-4096(DMA)         0      0   4096    1    1 : tunables   24   12    0 : slabdata      0      0      0
size-4096            100    100   4096    1    1 : tunables   24   12    0 : slabdata    100    100      0
size-2048(DMA)         0      0   2048    2    1 : tunables   24   12    0 : slabdata      0      0      0
size-2048            310    328   2048    2    1 : tunables   24   12    0 : slabdata    164    164      0
size-1024(DMA)         0      0   1024    4    1 : tunables   54   27    0 : slabdata      0      0      0
size-1024            176    176   1024    4    1 : tunables   54   27    0 : slabdata     44     44      0
size-512(DMA)          0      0    512    8    1 : tunables   54   27    0 : slabdata      0      0      0
size-512             624    624    512    8    1 : tunables   54   27    0 : slabdata     78     78      0
size-256(DMA)          0      0    256   15    1 : tunables  120   60    0 : slabdata      0      0      0
size-256             150    150    256   15    1 : tunables  120   60    0 : slabdata     10     10      0
size-128(DMA)          0      0    128   30    1 : tunables  120   60    0 : slabdata      0      0      0
size-128            1702   1800    128   30    1 : tunables  120   60    0 : slabdata     60     60      0
size-64(DMA)           0      0     64   59    1 : tunables  120   60    0 : slabdata      0      0      0
size-32(DMA)           0      0     32  113    1 : tunables  120   60    0 : slabdata      0      0      0
size-64             2641   2891     64   59    1 : tunables  120   60    0 : slabdata     49     49      0
size-32             3020   3616     32  113    1 : tunables  120   60    0 : slabdata     32     32      0
kmem_cache           160    160     96   40    1 : tunables  120   60    0 : slabdata      4      4      0

  and 
  cat /proc/vmstat
nr_dirty 6
nr_writeback 0
nr_unstable 0
nr_page_table_pages 299
nr_mapped 39613
nr_slab 4128
pgpgin 853871
pgpgout 697604
pswpin 0
pswpout 33
pgalloc_high 0
pgalloc_normal 7729542
pgalloc_dma 739299
pgfree 8475900
pgactivate 194732
pgdeactivate 167948
pgfault 4652531
pgmajfault 2200
pgrefill_high 0
pgrefill_normal 921490
pgrefill_dma 53701
pgsteal_high 0
pgsteal_normal 225142
pgsteal_dma 32821
pgscan_kswapd_high 0
pgscan_kswapd_normal 218790
pgscan_kswapd_dma 31262
pgscan_direct_high 0
pgscan_direct_normal 63855
pgscan_direct_dma 10391
pginodesteal 888
slabs_scanned 1641984
kswapd_steal 196892
kswapd_inodesteal 17749
pageoutrun 5595
allocstall 1531
pgrotated 71
nr_bounce 0

-- 
mattia
:wq!

Re: 2.6.14-rc2-mm1

[Andrew Morton]

Mattia Dongili <malattia@linux.it> wrote:
>
>  On Wed, Sep 21, 2005 at 10:28:39PM -0700, Andrew Morton wrote:
>  > 
>  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/
> 
>  Herm... running almost good :) I just got the below allocation failure
>  (including /proc/slabinfo and /proc/vmstat, useful? can provide more
>  info if happens again - ah, exim is just running for the local delivery
>  purpose only). I did see it previously in .14-rc1-mm1 only but I didn't
>  find time enough to report it properly.
> 
> ...
>  exim4: page allocation failure. order:1, mode:0x80000020

Yes, it's expected that
mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch will cause more
fragmentation and will hence cause higher-order allocation attempts to
fail.

I think I'll drop that one.

Re: 2.6.14-rc2-mm1

[Seth, Rohit]

On Sat, Sep 24, 2005 at 11:23:39AM -0700, Andrew Morton wrote:
> > 
> > ...
> >  exim4: page allocation failure. order:1, mode:0x80000020
> 
> Yes, it's expected that
> mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch will cause more
> fragmentation and will hence cause higher-order allocation attempts to
> fail.
> 
> I think I'll drop that one.

Seems like from the log messages that quite a few pages are hanging in the cpu's cold pcp list even with the low memory conditions.  Below is the patch to reduce the higher bound in cold pcp list (...this got increased with my previous change).  

I think we should also drain the CPU's hot and cold pcps for the GFP_KERNEL page requests (in the event the higher order request is not able to get serviced otherwise).  This will still only drains the current CPUs pcps in an MP environment (leaving the other CPUs with their lists intact).  I will send this patch later today.

	[PATCH]: Reduce the high mark in cpu's cold pcp list.

	Signed-off-by: Rohit Seth <rohit.seth@intel.com>


--- linux-2.6.13.old/mm/page_alloc.c	2005-09-26 10:57:07.000000000 -0700
+++ linux-2.6.13.work/mm/page_alloc.c	2005-09-26 10:47:57.000000000 -0700
@@ -1749,7 +1749,7 @@
 	pcp = &p->pcp[1];		/* cold*/
 	pcp->count = 0;
 	pcp->low = 0;
-	pcp->high = 2 * batch;
+	pcp->high = batch / 2;
 	pcp->batch = max(1UL, batch/2);
 	INIT_LIST_HEAD(&pcp->list);
 }

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Reuben Farrelly]

Hi again,

On 22/09/2005 5:28 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/
> 
> - Added git tree `git-sas.patch': Luben Tuikov's SAS driver and its support.
> 
> - Various random other things - nothing major.

Just noticed this oops from about 4am this morning.  This would have been at 
about the time when the normal daily cronjobs are run, but shouldn't have been 
doing much else.


Sep 27 04:04:28 tornado kernel: smbd: page allocation failure. order:1, 
mode:0x80000020
Sep 27 04:04:28 tornado kernel:  [<c0103ad0>] dump_stack+0x17/0x19
Sep 27 04:04:28 tornado kernel:  [<c013f84a>] __alloc_pages+0x2d8/0x3ef
Sep 27 04:04:28 tornado kernel:  [<c0142b32>] kmem_getpages+0x2c/0x91
Sep 27 04:04:28 tornado kernel:  [<c0144136>] cache_grow+0xa2/0x1aa
Sep 27 04:04:28 tornado kernel:  [<c0144810>] cache_alloc_refill+0x279/0x2bb
Sep 27 04:04:28 tornado kernel:  [<c0144da9>] __kmalloc+0xc7/0xe7
Sep 27 04:04:28 tornado kernel:  [<c02ab386>] pskb_expand_head+0x4b/0x11a
Sep 27 04:04:28 tornado kernel:  [<c02afd34>] skb_checksum_help+0xcb/0xe5
Sep 27 04:04:28 tornado kernel:  [<c0302b0d>] ip_nat_fn+0x16d/0x1bf
Sep 27 04:04:28 tornado kernel:  [<c0302cdc>] ip_nat_local_fn+0x57/0x8d
Sep 27 04:04:28 tornado kernel:  [<c03068ef>] nf_iterate+0x59/0x7d
Sep 27 04:04:28 tornado kernel:  [<c030695d>] nf_hook_slow+0x4a/0x109
Sep 27 04:04:28 tornado kernel:  [<c02ca035>] ip_queue_xmit+0x23c/0x4f5
Sep 27 04:04:28 tornado kernel:  [<c02da477>] tcp_transmit_skb+0x3ce/0x713
Sep 27 04:04:29 tornado kernel:  [<c02db53b>] tcp_write_xmit+0x124/0x37b
Sep 27 04:04:29 tornado kernel:  [<c02db7b3>] __tcp_push_pending_frames+0x21/0x70
Sep 27 04:04:29 tornado kernel:  [<c02d0b45>] tcp_sendmsg+0x9cc/0xabc
Sep 27 04:04:29 tornado kernel:  [<c02ed3dd>] inet_sendmsg+0x2e/0x4c
Sep 27 04:04:29 tornado kernel:  [<c02a6691>] sock_sendmsg+0xbf/0xe3
Sep 27 04:04:29 tornado kernel:  [<c02a77be>] sys_sendto+0xa5/0xbe
Sep 27 04:04:29 tornado kernel:  [<c02a780d>] sys_send+0x36/0x38
Sep 27 04:04:29 tornado kernel:  [<c02a7ef7>] sys_socketcall+0x134/0x251
Sep 27 04:04:29 tornado kernel:  [<c0102b5b>] sysenter_past_esp+0x54/0x75
Sep 27 04:04:29 tornado kernel: Mem-info:
Sep 27 04:04:29 tornado kernel: DMA per-cpu:
Sep 27 04:04:29 tornado kernel: cpu 0 hot: low 0, high 12, batch 2 used:10
Sep 27 04:04:29 tornado kernel: cpu 0 cold: low 0, high 4, batch 1 used:3
Sep 27 04:04:29 tornado kernel: cpu 1 hot: low 0, high 12, batch 2 used:10
Sep 27 04:04:29 tornado kernel: cpu 1 cold: low 0, high 4, batch 1 used:3
Sep 27 04:04:29 tornado kernel: DMA32 per-cpu: empty
Sep 27 04:04:30 tornado kernel: Normal per-cpu:
Sep 27 04:04:30 tornado kernel: cpu 0 hot: low 0, high 384, batch 64 used:346
Sep 27 04:04:30 tornado kernel: cpu 0 cold: low 0, high 128, batch 32 used:115
Sep 27 04:04:30 tornado kernel: cpu 1 hot: low 0, high 384, batch 64 used:324
Sep 27 04:04:30 tornado kernel: cpu 1 cold: low 0, high 128, batch 32 used:112
Sep 27 04:04:30 tornado kernel: HighMem per-cpu:
Sep 27 04:04:30 tornado kernel: cpu 0 hot: low 0, high 96, batch 16 used:38
Sep 27 04:04:30 tornado kernel: cpu 0 cold: low 0, high 32, batch 8 used:27
Sep 27 04:04:30 tornado kernel: cpu 1 hot: low 0, high 96, batch 16 used:36
Sep 27 04:04:30 tornado kernel: cpu 1 cold: low 0, high 32, batch 8 used:5
Sep 27 04:04:30 tornado kernel: Free pages:       38404kB (2720kB HighMem)
Sep 27 04:04:31 tornado kernel: Active:139410 inactive:49515 dirty:135 
writeback:1 unstable:0 free:9601 slab:54525 mapped:88304 pagetables:776
Sep 27 04:04:31 tornado kernel: DMA free:5828kB min:68kB low:84kB high:100kB 
active:100kB inactive:944kB present:16384kB pages_scanned:0 all_unreclaimable? no
Sep 27 04:04:31 tornado kernel: lowmem_reserve[]: 0 0 880 1006
Sep 27 04:04:31 tornado kernel: DMA32 free:0kB min:0kB low:0kB high:0kB 
active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Sep 27 04:04:31 tornado kernel: lowmem_reserve[]: 0 0 880 1006
Sep 27 04:04:31 tornado kernel: Normal free:29856kB min:3756kB low:4692kB 
high:5632kB active:446760kB inactive:188768kB present:901120kB pages_scanned:0 
all_unreclaimable? no
Sep 27 04:04:31 tornado kernel: lowmem_reserve[]: 0 0 0 1009
Sep 27 04:04:32 tornado kernel: HighMem free:2720kB min:128kB low:160kB 
high:192kB active:110784kB inactive:8344kB present:129212kB pages_scanned:0 
all_unreclaimable? no
Sep 27 04:04:32 tornado kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 04:04:32 tornado kernel: DMA: 803*4kB 167*8kB 50*16kB 15*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5828kB
Sep 27 04:04:32 tornado kernel: DMA32: empty
Sep 27 04:04:32 tornado kernel: Normal: 6744*4kB 360*8kB 0*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 29856kB
Sep 27 04:04:32 tornado kernel: HighMem: 654*4kB 13*8kB 0*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2720kB
Sep 27 04:04:32 tornado kernel: Swap cache: add 40, delete 40, find 1/2, race 0+0
Sep 27 04:04:32 tornado kernel: Free swap  = 497820kB
Sep 27 04:04:32 tornado kernel: Total swap = 497936kB
Sep 27 04:04:32 tornado kernel: Free swap:       497820kB
Sep 27 04:04:32 tornado kernel: 261679 pages of RAM
Sep 27 04:04:32 tornado kernel: 32303 pages of HIGHMEM
Sep 27 04:04:32 tornado kernel: 3160 reserved pages
Sep 27 04:04:32 tornado kernel: 160186 pages shared
Sep 27 04:04:32 tornado kernel: 0 pages swap cached
Sep 27 04:04:33 tornado kernel: 135 pages dirty
Sep 27 04:04:33 tornado kernel: 1 pages writeback
Sep 27 04:04:33 tornado kernel: 88304 pages mapped
Sep 27 04:04:33 tornado kernel: 54527 pages slab
Sep 27 04:04:33 tornado kernel: 776 pages pagetables
Sep 27 04:04:59 tornado kernel: smtpd: page allocation failure. order:1, 
mode:0x80000020
Sep 27 04:04:59 tornado kernel:  [<c0103ad0>] dump_stack+0x17/0x19
Sep 27 04:04:59 tornado kernel:  [<c013f84a>] __alloc_pages+0x2d8/0x3ef
Sep 27 04:04:59 tornado kernel:  [<c0142b32>] kmem_getpages+0x2c/0x91
Sep 27 04:04:59 tornado kernel:  [<c0144136>] cache_grow+0xa2/0x1aa
Sep 27 04:04:59 tornado kernel:  [<c0144810>] cache_alloc_refill+0x279/0x2bb
Sep 27 04:04:59 tornado kernel:  [<c0144da9>] __kmalloc+0xc7/0xe7
Sep 27 04:04:59 tornado kernel:  [<c02ab386>] pskb_expand_head+0x4b/0x11a
Sep 27 04:04:59 tornado kernel:  [<c02afd34>] skb_checksum_help+0xcb/0xe5
Sep 27 04:04:59 tornado kernel:  [<c0302b0d>] ip_nat_fn+0x16d/0x1bf
Sep 27 04:04:59 tornado kernel:  [<c0302cdc>] ip_nat_local_fn+0x57/0x8d
Sep 27 04:04:59 tornado kernel:  [<c03068ef>] nf_iterate+0x59/0x7d
Sep 27 04:04:59 tornado kernel:  [<c030695d>] nf_hook_slow+0x4a/0x109
Sep 27 04:05:00 tornado kernel:  [<c02ca035>] ip_queue_xmit+0x23c/0x4f5
Sep 27 04:05:00 tornado kernel:  [<c02da477>] tcp_transmit_skb+0x3ce/0x713
Sep 27 04:05:00 tornado kernel:  [<c02db53b>] tcp_write_xmit+0x124/0x37b
Sep 27 04:05:00 tornado kernel:  [<c02db7b3>] __tcp_push_pending_frames+0x21/0x70
Sep 27 04:05:01 tornado kernel:  [<c02d0b45>] tcp_sendmsg+0x9cc/0xabc
Sep 27 04:05:01 tornado kernel:  [<c02ed3dd>] inet_sendmsg+0x2e/0x4c
Sep 27 04:05:01 tornado kernel:  [<c02a69c6>] sock_aio_write+0xbd/0xf6
Sep 27 04:05:01 tornado kernel:  [<c0159767>] do_sync_write+0xbb/0x10a
Sep 27 04:05:01 tornado kernel:  [<c01598f7>] vfs_write+0x141/0x148
Sep 27 04:05:02 tornado kernel:  [<c015999f>] sys_write+0x3d/0x64
Sep 27 04:05:02 tornado kernel:  [<c0102b5b>] sysenter_past_esp+0x54/0x75
Sep 27 04:05:02 tornado kernel: Mem-info:
Sep 27 04:05:02 tornado kernel: DMA per-cpu:
Sep 27 04:05:02 tornado kernel: cpu 0 hot: low 0, high 12, batch 2 used:4
Sep 27 04:05:02 tornado kernel: cpu 0 cold: low 0, high 4, batch 1 used:3
Sep 27 04:05:02 tornado kernel: cpu 1 hot: low 0, high 12, batch 2 used:10
Sep 27 04:05:03 tornado kernel: cpu 1 cold: low 0, high 4, batch 1 used:3
Sep 27 04:05:03 tornado kernel: DMA32 per-cpu: empty
Sep 27 04:05:03 tornado kernel: Normal per-cpu:
Sep 27 04:05:03 tornado kernel: cpu 0 hot: low 0, high 384, batch 64 used:23
Sep 27 04:05:04 tornado kernel: cpu 0 cold: low 0, high 128, batch 32 used:115
Sep 27 04:05:04 tornado kernel: cpu 1 hot: low 0, high 384, batch 64 used:383
Sep 27 04:05:04 tornado kernel: cpu 1 cold: low 0, high 128, batch 32 used:120
Sep 27 04:05:04 tornado kernel: HighMem per-cpu:
Sep 27 04:05:04 tornado kernel: cpu 0 hot: low 0, high 96, batch 16 used:89
Sep 27 04:05:04 tornado kernel: cpu 0 cold: low 0, high 32, batch 8 used:3
Sep 27 04:05:05 tornado kernel: cpu 1 hot: low 0, high 96, batch 16 used:5
Sep 27 04:05:05 tornado kernel: cpu 1 cold: low 0, high 32, batch 8 used:27
Sep 27 04:05:05 tornado kernel: Free pages:       39608kB (2144kB HighMem)
Sep 27 04:05:05 tornado kernel: Active:132565 inactive:56281 dirty:100 
writeback:1 unstable:0 free:9902 slab:54546 mapped:88341 pagetables:776
Sep 27 04:05:05 tornado kernel: DMA free:4704kB min:68kB low:84kB high:100kB 
active:224kB inactive:948kB present:16384kB pages_scanned:0 all_unreclaimable? no
Sep 27 04:05:05 tornado kernel: lowmem_reserve[]: 0 0 880 1006
Sep 27 04:05:05 tornado kernel: DMA32 free:0kB min:0kB low:0kB high:0kB 
active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Sep 27 04:05:05 tornado kernel: lowmem_reserve[]: 0 0 880 1006
Sep 27 04:05:05 tornado kernel: Normal free:32760kB min:3756kB low:4692kB 
high:5632kB active:418168kB inactive:216412kB present:901120kB pages_scanned:0 
all_unreclaimable? no
Sep 27 04:05:05 tornado kernel: lowmem_reserve[]: 0 0 0 1009
Sep 27 04:05:05 tornado kernel: HighMem free:2144kB min:128kB low:160kB 
high:192kB active:111868kB inactive:7764kB present:129212kB pages_scanned:0 
all_unreclaimable? no
Sep 27 04:05:05 tornado kernel: lowmem_reserve[]: 0 0 0 0
Sep 27 04:05:05 tornado kernel: DMA: 936*4kB 108*8kB 6*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4704kB
Sep 27 04:05:05 tornado kernel: DMA32: empty
Sep 27 04:05:05 tornado kernel: Normal: 7484*4kB 349*8kB 2*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 32760kB
Sep 27 04:05:05 tornado kernel: HighMem: 510*4kB 13*8kB 0*16kB 0*32kB 0*64kB 
0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2144kB
Sep 27 04:05:05 tornado kernel: Swap cache: add 40, delete 40, find 1/2, race 0+0
Sep 27 04:05:05 tornado kernel: Free swap  = 497820kB
Sep 27 04:05:05 tornado kernel: Total swap = 497936kB
Sep 27 04:05:05 tornado kernel: Free swap:       497820kB
Sep 27 04:05:05 tornado kernel: 261679 pages of RAM
Sep 27 04:05:05 tornado kernel: 32303 pages of HIGHMEM
Sep 27 04:05:05 tornado kernel: 3160 reserved pages
Sep 27 04:05:06 tornado kernel: 165825 pages shared
Sep 27 04:05:06 tornado kernel: 0 pages swap cached
Sep 27 04:05:06 tornado kernel: 100 pages dirty
Sep 27 04:05:06 tornado kernel: 1 pages writeback
Sep 27 04:05:06 tornado kernel: 88341 pages mapped
Sep 27 04:05:06 tornado kernel: 54546 pages slab
Sep 27 04:05:06 tornado kernel: 776 pages pagetables


reuben

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Andrew Morton]

Reuben Farrelly <reuben-lkml@reub.net> wrote:
>
>  On 22/09/2005 5:28 p.m., Andrew Morton wrote:
>  > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.14-rc2/2.6.14-rc2-mm1/
>  > 
>  > - Added git tree `git-sas.patch': Luben Tuikov's SAS driver and its support.
>  > 
>  > - Various random other things - nothing major.
> 
>  Just noticed this oops from about 4am this morning.  This would have been at 
>  about the time when the normal daily cronjobs are run, but shouldn't have been 
>  doing much else.
> 
> 
>  Sep 27 04:04:28 tornado kernel: smbd: page allocation failure. order:1, 
>  mode:0x80000020
>  Sep 27 04:04:28 tornado kernel:  [<c0103ad0>] dump_stack+0x17/0x19
>  Sep 27 04:04:28 tornado kernel:  [<c013f84a>] __alloc_pages+0x2d8/0x3ef
>  Sep 27 04:04:28 tornado kernel:  [<c0142b32>] kmem_getpages+0x2c/0x91
>  Sep 27 04:04:28 tornado kernel:  [<c0144136>] cache_grow+0xa2/0x1aa
>  Sep 27 04:04:28 tornado kernel:  [<c0144810>] cache_alloc_refill+0x279/0x2bb
>  Sep 27 04:04:28 tornado kernel:  [<c0144da9>] __kmalloc+0xc7/0xe7
>  Sep 27 04:04:28 tornado kernel:  [<c02ab386>] pskb_expand_head+0x4b/0x11a
>  Sep 27 04:04:28 tornado kernel:  [<c02afd34>] skb_checksum_help+0xcb/0xe5
>  Sep 27 04:04:28 tornado kernel:  [<c0302b0d>] ip_nat_fn+0x16d/0x1bf
>  Sep 27 04:04:28 tornado kernel:  [<c0302cdc>] ip_nat_local_fn+0x57/0x8d
>  Sep 27 04:04:28 tornado kernel:  [<c03068ef>] nf_iterate+0x59/0x7d
>  Sep 27 04:04:28 tornado kernel:  [<c030695d>] nf_hook_slow+0x4a/0x109
>  Sep 27 04:04:28 tornado kernel:  [<c02ca035>] ip_queue_xmit+0x23c/0x4f5
>  Sep 27 04:04:28 tornado kernel:  [<c02da477>] tcp_transmit_skb+0x3ce/0x713
>  Sep 27 04:04:29 tornado kernel:  [<c02db53b>] tcp_write_xmit+0x124/0x37b
>  Sep 27 04:04:29 tornado kernel:  [<c02db7b3>] __tcp_push_pending_frames+0x21/0x70
>  Sep 27 04:04:29 tornado kernel:  [<c02d0b45>] tcp_sendmsg+0x9cc/0xabc
>  Sep 27 04:04:29 tornado kernel:  [<c02ed3dd>] inet_sendmsg+0x2e/0x4c
>  Sep 27 04:04:29 tornado kernel:  [<c02a6691>] sock_sendmsg+0xbf/0xe3
>  Sep 27 04:04:29 tornado kernel:  [<c02a77be>] sys_sendto+0xa5/0xbe

No, this is simply a warning - the kernel ran out of 1-order pages in the
page allocator.  There have been several reports of this after
mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch was merged,
which was rather expected.

I've dropped that patch.  Joel Schopp is working on Mel Gorman's patches
which address fragmentation at this level.  If that code gets there then we
can take another look at
mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch.

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

> Seems like from the log messages that quite a few pages are hanging in the cpu's cold pcp list even with the low memory conditions.  Below is the patch to reduce the higher bound in cold pcp list (...this got increased with my previous change).  
> 
> I think we should also drain the CPU's hot and cold pcps for the GFP_KERNEL page requests (in the event the higher order request is not able to get serviced otherwise).  This will still only drains the current CPUs pcps in an MP environment (leaving the other CPUs with their lists intact).  I will send this patch later today.
> 
> 	[PATCH]: Reduce the high mark in cpu's cold pcp list.
> 
> 	Signed-off-by: Rohit Seth <rohit.seth@intel.com>
> 
> 
> --- linux-2.6.13.old/mm/page_alloc.c	2005-09-26 10:57:07.000000000 -0700
> +++ linux-2.6.13.work/mm/page_alloc.c	2005-09-26 10:47:57.000000000 -0700
> @@ -1749,7 +1749,7 @@
>  	pcp = &p->pcp[1];		/* cold*/
>  	pcp->count = 0;
>  	pcp->low = 0;
> -	pcp->high = 2 * batch;
> +	pcp->high = batch / 2;
>  	pcp->batch = max(1UL, batch/2);
>  	INIT_LIST_HEAD(&pcp->list);
>  }
> -

I don't understand. How can you set the high watermark at half the batch
size? Makes no sense to me.

And can you give a stricter definiton of what you mean by "low memory
conditions"? I agree we ought to empty the lists before going OOM or
anything, but not at the slightest feather of pressure ... answer lies
somewhere inbetween ... but where?

M.

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Martin J. Bligh]

> No, this is simply a warning - the kernel ran out of 1-order pages in the
> page allocator.  There have been several reports of this after
> mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch was merged,
> which was rather expected.
> 
> I've dropped that patch.  Joel Schopp is working on Mel Gorman's patches
> which address fragmentation at this level.  If that code gets there then we
> can take another look at
> mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch.

Me no understand. We're going to deliberately cause fragmentation in order
to defragment it again later ???

M.

Re: 2.6.14-rc2-mm1

[Rohit Seth]

On Tue, 2005-09-27 at 11:57 -0700, Martin J. Bligh wrote:
> > Seems like from the log messages that quite a few pages are hanging
> in the cpu's cold pcp list even with the low memory conditions.  Below
> is the patch to reduce the higher bound in cold pcp list (...this got
> increased with my previous change).  
> 
> >  
> > I think we should also drain the CPU's hot and cold pcps for the
> GFP_KERNEL page requests (in the event the higher order request is not
> able to get serviced otherwise).  This will still only drains the
> current CPUs pcps in an MP environment (leaving the other CPUs with
> their lists intact).  I will send this patch later today.
> 
> >  
> >       [PATCH]: Reduce the high mark in cpu's cold pcp list. 
> >  
> >       Signed-off-by: Rohit Seth <rohit.seth@intel.com> 
> >  
> >  
> > --- linux-2.6.13.old/mm/page_alloc.c  2005-09-26 10:57:07.000000000
> -0700 
> > +++ linux-2.6.13.work/mm/page_alloc.c 2005-09-26 10:47:57.000000000
> -0700 
> > @@ -1749,7 +1749,7 @@ 
> >       pcp = &p->pcp[1];               /* cold*/ 
> >       pcp->count = 0; 
> >       pcp->low = 0; 
> > -     pcp->high = 2 * batch; 
> > +     pcp->high = batch / 2; 
> >       pcp->batch = max(1UL, batch/2); 
> >       INIT_LIST_HEAD(&pcp->list); 
> >  } 
> > -
> 
> I don't understand. How can you set the high watermark at half the
> batch size? Makes no sense to me.
> 

The batch size for the cold pcp list is getting initialized to batch/2
in the code snip above.  So, this change is setting the high water mark
for cold list to same as pcp's batch number.

> And can you give a stricter definiton of what you mean by "low memory 
> conditions"? I agree we ought to empty the lists before going OOM or 
> anything, but not at the slightest feather of pressure ... answer lies
> somewhere inbetween ... but where?
> 

In the specific case of dump information that Mattia sent earlier, there
is only 4M of free mem available at the time the order 1 request is
failing.  

In general, I think if a specific higher order ( > 0) request fails that
has GFP_KERNEL set then at least we should drain the pcps.

-rohit

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

>> > --- linux-2.6.13.old/mm/page_alloc.c  2005-09-26 10:57:07.000000000
>> -0700 
>> > +++ linux-2.6.13.work/mm/page_alloc.c 2005-09-26 10:47:57.000000000
>> -0700 
>> > @@ -1749,7 +1749,7 @@ 
>> >       pcp = &p->pcp[1];               /* cold*/ 
>> >       pcp->count = 0; 
>> >       pcp->low = 0; 
>> > -     pcp->high = 2 * batch; 
>> > +     pcp->high = batch / 2; 
>> >       pcp->batch = max(1UL, batch/2); 
>> >       INIT_LIST_HEAD(&pcp->list); 
>> >  } 
>> > -
>> 
>> I don't understand. How can you set the high watermark at half the
>> batch size? Makes no sense to me.
>> 
> 
> The batch size for the cold pcp list is getting initialized to batch/2
> in the code snip above.  So, this change is setting the high water mark
> for cold list to same as pcp's batch number.

I must be being particularly dense today ... but:

 pcp->high = batch / 2; 

Looks like half the batch size to me, not the same? 

>> And can you give a stricter definiton of what you mean by "low memory 
>> conditions"? I agree we ought to empty the lists before going OOM or 
>> anything, but not at the slightest feather of pressure ... answer lies
>> somewhere inbetween ... but where?
>> 
> 
> In the specific case of dump information that Mattia sent earlier, there
> is only 4M of free mem available at the time the order 1 request is
> failing.  
> 
> In general, I think if a specific higher order ( > 0) request fails that
> has GFP_KERNEL set then at least we should drain the pcps.

Mmmm. so every time we fork a process with 8K stacks, or allocate a frame
for jumbo ethernet, or NFS, you want to drain the lists? that seems to
wholly defeat the purpose.

Could you elaborate on what the benefits were from this change in the
first place? Some page colouring thing on ia64? It seems to have way more
downside than upside to me.

M.

Re: 2.6.14-rc2-mm1

[Rohit Seth]

On Tue, 2005-09-27 at 14:18 -0700, Martin J. Bligh wrote:
> >> > --- linux-2.6.13.old/mm/page_alloc.c  2005-09-26 10:57:07.000000000
> >> -0700 
> >> > +++ linux-2.6.13.work/mm/page_alloc.c 2005-09-26 10:47:57.000000000
> >> -0700 
> >> > @@ -1749,7 +1749,7 @@ 
> >> >       pcp = &p->pcp[1];               /* cold*/ 
> >> >       pcp->count = 0; 
> >> >       pcp->low = 0; 
> >> > -     pcp->high = 2 * batch; 
> >> > +     pcp->high = batch / 2; 
> >> >       pcp->batch = max(1UL, batch/2); 
> >> >       INIT_LIST_HEAD(&pcp->list); 
> >> >  } 
> >> > -
> >> 
> >> I don't understand. How can you set the high watermark at half the
> >> batch size? Makes no sense to me.
> >> 
> > 
> > The batch size for the cold pcp list is getting initialized to batch/2
> > in the code snip above.  So, this change is setting the high water mark
> > for cold list to same as pcp's batch number.
> 
> I must be being particularly dense today ... but:
> 
>  pcp->high = batch / 2; 
> 
> Looks like half the batch size to me, not the same? 

pcp->batch = max(1UL, batch/2); is the line of code that is setting the
batch value for the cold pcp list.  batch is just a number that we
counted based on some parameters earlier.


> 
> >> And can you give a stricter definiton of what you mean by "low memory 
> >> conditions"? I agree we ought to empty the lists before going OOM or 
> >> anything, but not at the slightest feather of pressure ... answer lies
> >> somewhere inbetween ... but where?
> >> 
> > 
> > In the specific case of dump information that Mattia sent earlier, there
> > is only 4M of free mem available at the time the order 1 request is
> > failing.  
> > 
> > In general, I think if a specific higher order ( > 0) request fails that
> > has GFP_KERNEL set then at least we should drain the pcps.
> 
> Mmmm. so every time we fork a process with 8K stacks, or allocate a frame
> for jumbo ethernet, or NFS, you want to drain the lists? that seems to
> wholly defeat the purpose.
> 

Not every time there is a request for higher order pages.  That surely
will defeat the purpose of pcps.  But my suggestion is only to drain
when the the global pool is not able to service the request.  In the
pathological case where the higher order and zero order requests are
alternating you could have thrashing in terms of pages moving to pcp for
them to move back to global list.

> Could you elaborate on what the benefits were from this change in the
> first place? Some page colouring thing on ia64? It seems to have way more
> downside than upside to me.

The original change was to try to allocate a higher order page to
service a batch size bulk request.  This was with the hope that better
physical contiguity will spread the data better across big caches.

-rohit

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

>> I must be being particularly dense today ... but:
>> 
>>  pcp->high = batch / 2; 
>> 
>> Looks like half the batch size to me, not the same? 
> 
> pcp->batch = max(1UL, batch/2); is the line of code that is setting the
> batch value for the cold pcp list.  batch is just a number that we
> counted based on some parameters earlier.

Ah, OK, so I am being dense. Fair enough. But if there's a reason to do
that max, perhaps:

pcp->batch = max(1UL, batch/2);
pcp->high = pcp->batch;

would be more appropriate? Tradeoff is more frequent dump / fill against
better frag, I suppose (at least if we don't refill using higher order
allocs ;-)) which seems fair enough.

>> > In general, I think if a specific higher order ( > 0) request fails that
>> > has GFP_KERNEL set then at least we should drain the pcps.
>> 
>> Mmmm. so every time we fork a process with 8K stacks, or allocate a frame
>> for jumbo ethernet, or NFS, you want to drain the lists? that seems to
>> wholly defeat the purpose.
> 
> Not every time there is a request for higher order pages.  That surely
> will defeat the purpose of pcps.  But my suggestion is only to drain
> when the the global pool is not able to service the request.  In the
> pathological case where the higher order and zero order requests are
> alternating you could have thrashing in terms of pages moving to pcp for
> them to move back to global list.

OK, seems fair enough. But there's multiple "harder and harder" attempts
within __alloc_pages to do that ... which one are you going for? just 
before we OOM / fail the alloc? That'd be hard to argue with, though I'm
unsure what the locking is to dump out other CPUs queues - you going to
global IPI and ask them to do it - that'd seem to cause it to race to
refill (as you mention).
 
>> Could you elaborate on what the benefits were from this change in the
>> first place? Some page colouring thing on ia64? It seems to have way more
>> downside than upside to me.
> 
> The original change was to try to allocate a higher order page to
> service a batch size bulk request.  This was with the hope that better
> physical contiguity will spread the data better across big caches.

OK ... but it has an impact on fragmentation. How much benefit are you
getting?

M.

Re: 2.6.14-rc2-mm1

[Rohit Seth]

On Tue, 2005-09-27 at 14:59 -0700, Martin J. Bligh wrote:


> pcp->batch = max(1UL, batch/2);
> pcp->high = pcp->batch;
> 
> would be more appropriate? Tradeoff is more frequent dump / fill against
> better frag, I suppose (at least if we don't refill using higher order
> allocs ;-)) which seems fair enough.
> 

There are couple of small changes including this one that I will be
sending out in this initialization routine.

> > 
> > Not every time there is a request for higher order pages.  That surely
> > will defeat the purpose of pcps.  But my suggestion is only to drain
> > when the the global pool is not able to service the request.  In the
> > pathological case where the higher order and zero order requests are
> > alternating you could have thrashing in terms of pages moving to pcp for
> > them to move back to global list.
> 
> OK, seems fair enough. But there's multiple "harder and harder" attempts
> within __alloc_pages to do that ... which one are you going for? just 
> before we OOM / fail the alloc? That'd be hard to argue with, though I'm
> unsure what the locking is to dump out other CPUs queues - you going to
> global IPI and ask them to do it - that'd seem to cause it to race to
> refill (as you mention).
>  

Thinking of initiating this drain operation after the swapper daemon is
woken up.  hopefully that will allow other possible pages to be put back
on freelist and reduce the possible thrash of pages between freemem pool
and pcps.

As a first step, I will be draining the local cpu's pcp.  IPI or lazy
purging of pcps could be used as a a very last resort to drain other
CPUs pcps for the scnearios where nothing else has worked to get more
pages.  For these extreme low memory conditions I'm not sure if we
should worry about thrashing any more than having free pages lying
around and not getting used. 

> >> Could you elaborate on what the benefits were from this change in the
> >> first place? Some page colouring thing on ia64? It seems to have way more
> >> downside than upside to me.
> > 
> > The original change was to try to allocate a higher order page to
> > service a batch size bulk request.  This was with the hope that better
> > physical contiguity will spread the data better across big caches.
> 
> OK ... but it has an impact on fragmentation. How much benefit are you
> getting?
> 

Benefit is in terms of reduced performance variation (and expected
throughput) of certain workloads from run to run on the same kernel. 

-rohit

Re: 2.6.14-rc2-mm1

[Martin J. Bligh]

>> > Not every time there is a request for higher order pages.  That surely
>> > will defeat the purpose of pcps.  But my suggestion is only to drain
>> > when the the global pool is not able to service the request.  In the
>> > pathological case where the higher order and zero order requests are
>> > alternating you could have thrashing in terms of pages moving to pcp for
>> > them to move back to global list.
>> 
>> OK, seems fair enough. But there's multiple "harder and harder" attempts
>> within __alloc_pages to do that ... which one are you going for? just 
>> before we OOM / fail the alloc? That'd be hard to argue with, though I'm
>> unsure what the locking is to dump out other CPUs queues - you going to
>> global IPI and ask them to do it - that'd seem to cause it to race to
>> refill (as you mention).
>>  
> 
> Thinking of initiating this drain operation after the swapper daemon is
> woken up.  hopefully that will allow other possible pages to be put back
> on freelist and reduce the possible thrash of pages between freemem pool
> and pcps.

OK, but waking up kswapd doesn't indicate a low memory condition.
It's standard procedure .... we'll have to wake it up whenever we dip
below the high watermarks. Perhaps before dropping into direct reclaim
would be more appropriate?
 
> As a first step, I will be draining the local cpu's pcp.  IPI or lazy
> purging of pcps could be used as a a very last resort to drain other
> CPUs pcps for the scnearios where nothing else has worked to get more
> pages.  For these extreme low memory conditions I'm not sure if we
> should worry about thrashing any more than having free pages lying
> around and not getting used. 

Sounds fair.
 
>> >> Could you elaborate on what the benefits were from this change in the
>> >> first place? Some page colouring thing on ia64? It seems to have way more
>> >> downside than upside to me.
>> > 
>> > The original change was to try to allocate a higher order page to
>> > service a batch size bulk request.  This was with the hope that better
>> > physical contiguity will spread the data better across big caches.
>> 
>> OK ... but it has an impact on fragmentation. How much benefit are you
>> getting?
> 
> Benefit is in terms of reduced performance variation (and expected
> throughput) of certain workloads from run to run on the same kernel. 

Mmmm. how much are you talking about in terms of throughput, and on what
platforms? all previous attempts to measure page colouring seemed to 
indicate it did nothing at all - maybe some specific types of h/w are
more susceptible?

M.

Re: 2.6.14-rc2-mm1

[Rohit Seth]

On Tue, 2005-09-27 at 15:49 -0700, Martin J. Bligh wrote:


> > 
> > Thinking of initiating this drain operation after the swapper daemon is
> > woken up.  hopefully that will allow other possible pages to be put back
> > on freelist and reduce the possible thrash of pages between freemem pool
> > and pcps.
> 
> OK, but waking up kswapd doesn't indicate a low memory condition.
> It's standard procedure .... we'll have to wake it up whenever we dip
> below the high watermarks. Perhaps before dropping into direct reclaim
> would be more appropriate?
>  

Agreed.  That is a better place.
 
> >> >> Could you elaborate on what the benefits were from this change in the
> >> >> first place? Some page colouring thing on ia64? It seems to have way more
> >> >> downside than upside to me.
> >> > 
> >> > The original change was to try to allocate a higher order page to
> >> > service a batch size bulk request.  This was with the hope that better
> >> > physical contiguity will spread the data better across big caches.
> >> 
> >> OK ... but it has an impact on fragmentation. How much benefit are you
> >> getting?
> > 
> > Benefit is in terms of reduced performance variation (and expected
> > throughput) of certain workloads from run to run on the same kernel. 
> 
> Mmmm. how much are you talking about in terms of throughput, and on what
> platforms? all previous attempts to measure page colouring seemed to 
> indicate it did nothing at all - maybe some specific types of h/w are
> more susceptible?
> 

In terms of percentages, between 10-15% variation.  Nothing out of
regular about the platforms.  Do you remember what workloads were run in
the previous attempts to see if there is any coloring.  I agree that
with 2.6.x based kernel, there is better handle on the variation (as
compared to 2.4).  And the best results of 2.6 matches the best results
of any coloring patch. 

-rohit
> 

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Paul Jackson]

Martin, responding to Andrew:
> > I've dropped that patch.  Joel Schopp is working on Mel Gorman's patches
> > which address fragmentation at this level.  If that code gets there then we
> > can take another look at
> > mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch.
> 
> Me no understand. We're going to deliberately cause fragmentation in order
> to defragment it again later ???

I thought that the patches of Mel Gorman and Joel Schopp were reducing
fragmentation, not causing it.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Martin J. Bligh]

--Paul Jackson <pj@sgi.com> wrote (on Sunday, October 02, 2005 10:13:19 -0700):

> Martin, responding to Andrew:
>> > I've dropped that patch.  Joel Schopp is working on Mel Gorman's patches
>> > which address fragmentation at this level.  If that code gets there then we
>> > can take another look at
>> > mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch.
>> 
>> Me no understand. We're going to deliberately cause fragmentation in order
>> to defragment it again later ???
> 
> I thought that the patches of Mel Gorman and Joel Schopp were reducing
> fragmentation, not causing it.

They were. but mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk
seems to be going in the opposite direction.

M.

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Rohit Seth]

On Sun, 2005-10-02 at 14:31 -0700, Martin J. Bligh wrote:
> 
> --Paul Jackson <pj@sgi.com> wrote (on Sunday, October 02, 2005 10:13:19 -0700):
> 
> > Martin, responding to Andrew:
> >> > I've dropped that patch.  Joel Schopp is working on Mel Gorman's patches
> >> > which address fragmentation at this level.  If that code gets there then we
> >> > can take another look at
> >> > mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk.patch.
> >> 
> >> Me no understand. We're going to deliberately cause fragmentation in order
> >> to defragment it again later ???
> > 
> > I thought that the patches of Mel Gorman and Joel Schopp were reducing
> > fragmentation, not causing it.
> 
> They were. but mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk
> seems to be going in the opposite direction.

mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk patch tries to
allocate more physical contiguous pages for pcp.  This would cause some
extra fragmentation at the higher orders but has the potential benefit
of spreading more uniformly across caches.  I agree though that for this
scheme to work nicely we should have the capability of draining the pcps
so that higher order requests can be serviced whenever possible.

-rohit

Re: 2.6.14-rc2-mm1 (Oops, possibly Netfilter related?)

[Martin J. Bligh]

> mm-try-to-allocate-higher-order-pages-in-rmqueue_bulk patch tries to
> allocate more physical contiguous pages for pcp.  This would cause some
> extra fragmentation at the higher orders but has the potential benefit
> of spreading more uniformly across caches.  I agree though that for this
> scheme to work nicely we should have the capability of draining the pcps
> so that higher order requests can be serviced whenever possible.

Unfortunately, I don't think it's that simple. We'll end up taking the
higher order elements from the buddy into the caches, and using them
all piecemeal - ie fragmenting it all. 

If we take lists of 0 order pages from the buddy, we're trying to use
whatever dross was left over in there (from a fragmentation point of view)
up first, before breaking into the more precious stuff (phys contig bits).

That was why I wrote it that way in the first place - it wasn't 
accidental ;-)

>From the direction the thread was going in previously, it sounded like
you were finding other ways to alleviate the colouring issue you were
seeing ... I was hoping that would fix it up enough the desire for higher
order allocations would disappear.

To be blunt about it ... making sure that we don't fall over on higher 
order allocs seems to me to be more important than a bit of variability 
in benchmark runs ...

M.

Re: 2.6.14-rc2-mm1

[Carlo Calica]

On 9/27/05, Paul Blazejowski <paulb@blazebox.homeip.net> wrote:
> No 2.6.12 is not OK. I don't think there's any regression between the
> recent kernels. It just does not work on 3 of them i tried so far.
>

Another data point:

I'm unable to reproduce on a PATA install.  Specifically, booting on a
PATA HD with sata_nv as a module.  When booting on a SATA HD with
sata_nv compiled in, I get the race.  Setting irq 1,5 (keyboard and
libata) handlers to cpu0 affinity and X affinity to cpu0 solves the
problem.

I haven't had time to try booting SATA with sata_nv as a module in initrd.

--
Carlo J. Calica

Re: 2.6.14-rc2-mm1

[Paul Blazejowski]

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

On Mon, Sep 26, 2005 at 09:14:02AM +0200, Tim Schmielau wrote:
> On Sun, 25 Sep 2005, Paul Blazejowski wrote:
> 
> > Upon quick testing the latest mm kernel it appears there's some kind of
> > race condition when using dual core cpu esp when using XORG and USB
> > (although PS2 has same issue) kebyboard rate being too fast.
> 
> Does the following patch by John Stultz fix the problem?
> 
> Tim

Tim,

No it does not, from my understanding it only pertains to x86_64 but
currently i run i386 SMP enabled kernel on the dualcore X2 processor.

Also worth noting is that i do not see any failures or errors in dmesg
related to lost timers. Perhaps this is something new? I even run  a
script from the bugzilla and the output matched both cpu's.

Thanks,

	Paul

> 
> 
> From johnstul@us.ibm.com Mon Sep 26 09:04:08 2005
> Date: Mon, 19 Sep 2005 12:16:43 -0700
> From: john stultz <johnstul@us.ibm.com>
> To: Andrew Morton <akpm@osdl.org>
> Cc: lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>
> Subject: [PATCH] x86-64: Fix bad assumption that dualcore cpus have synced
>     TSCs
> 
> Andrew,
> 	This patch should resolve the issue seen in bugme bug #5105, where it
> is assumed that dualcore x86_64 systems have synced TSCs. This is not
> the case, and alternate timesources should be used instead.
> 
> For more details, see:
> http://bugzilla.kernel.org/show_bug.cgi?id=5105
> 
> 
> Please consider for inclusion in your tree.
> 
> thanks
> -john
> 
> diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
> --- a/arch/x86_64/kernel/time.c
> +++ b/arch/x86_64/kernel/time.c
> @@ -959,9 +959,6 @@ static __init int unsynchronized_tsc(voi
>   	   are handled in the OEM check above. */
>   	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
>   		return 0;
> - 	/* All in a single socket - should be synchronized */
> - 	if (cpus_weight(cpu_core_map[0]) == num_online_cpus())
> - 		return 0;
>  #endif
>   	/* Assume multi socket systems are not synchronized */
>   	return num_online_cpus() > 1;
> 
> 
> 

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

Re: 2.6.14-rc2-mm1

[Paul Blazejowski]

[-- Attachment #1.1: Type: text/plain, Size: 994 bytes --]

On Sun, Sep 25, 2005 at 04:44:21PM -0700, Andrew Morton wrote:
> Paul Blazejowski <paulb@blazebox.homeip.net> wrote:
> >
> >  Upon quick testing the latest mm kernel it appears there's some kind of
> >  race condition when using dual core cpu esp when using XORG and USB
> >  (although PS2 has same issue) kebyboard rate being too fast.
> > 
> >  The same behaviour happens on vanilla 2.6.13 kernel. Reporting this also
> >  to XORG list in hopes to help debug this issue.
> 
> Is it possible to narrow this down a bit further?  Was 2.6.12 OK?
> 
> If we can identify two reasonably-close-in-time versions either side of the
> regression then the next step would be to run `dmesg -s 1000000' under both
> kernel versions, then run `diff -u dmesg.good dmesg.bad'.
> 
> 

No 2.6.12 is not OK. I don't think there's any regression between the
recent kernels. It just does not work on 3 of them i tried so far.

I am attatching diff from 2.6.12/2.6.13 against 2.6.14-rc2-mm1.

[-- Attachment #1.2: dm2612-dm2614.diff --]
[-- Type: text/plain, Size: 18155 bytes --]

--- dm2612	2005-09-26 02:02:15.000000000 -0400
+++ dm2614	2005-09-26 01:16:52.000000000 -0400
@@ -1,4 +1,4 @@
-Linux version 2.6.12.6 (root@blaze) (gcc version 3.3.6) #1 SMP Mon Sep 26 01:40:47 EDT 2005
+Linux version 2.6.14-rc2-mm1 (root@blaze) (gcc version 3.3.6) #1 SMP Sun Sep 25 17:03:22 EDT 2005
 BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
@@ -12,9 +12,10 @@
 511MB LOWMEM available.
 found SMP MP-table at 000f5a30
 On node 0 totalpages: 131056
-  DMA zone: 4096 pages, LIFO batch:1
-  Normal zone: 126960 pages, LIFO batch:31
-  HighMem zone: 0 pages, LIFO batch:1
+  DMA zone: 4096 pages, LIFO batch:2
+  DMA32 zone: 0 pages, LIFO batch:2
+  Normal zone: 126960 pages, LIFO batch:64
+  HighMem zone: 0 pages, LIFO batch:2
 DMI 2.3 present.
 ACPI: RSDP (v000 Nvidia                                ) @ 0x000f7dc0
 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
@@ -42,22 +43,22 @@
 ACPI: IRQ15 used by override.
 Enabling APIC mode:  Flat.  Using 1 I/O APICs
 Using ACPI (MADT) for SMP configuration information
-Allocating PCI resources starting at 20000000 (gap: 20000000:c0000000)
+Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
 Built 1 zonelists
-Kernel command line: root=/dev/sda1 ro vmalloc=256M console=ttyS0,57600n8 console=tty0 rootflags=quota elevator=cfq vga=795
 mapped APIC to ffffd000 (fee00000)
 mapped IOAPIC to ffffc000 (fec00000)
 Initializing CPU#0
-CPU 0 irqstacks, hard=c041a000 soft=c0418000
+Kernel command line: root=/dev/sda1 ro vmalloc=256M console=ttyS0,57600n8 console=tty0 rootflags=quota elevator=cfq vga=795
+CPU 0 irqstacks, hard=c043e000 soft=c043c000
 PID hash table entries: 2048 (order: 11, 32768 bytes)
-Detected 2352.374 MHz processor.
+Detected 2352.758 MHz processor.
 Using tsc for high-res timesource
 Console: colour dummy device 80x25
 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 515352k/524224k available (2289k kernel code, 8380k reserved, 617k data, 236k init, 0k highmem)
+Memory: 515152k/524224k available (2390k kernel code, 8560k reserved, 662k data, 232k init, 0k highmem)
 Checking if this processor honours the WP bit even in supervisor mode... Ok.
-Calibrating delay loop... 4653.05 BogoMIPS (lpj=2326528)
+Calibrating delay using timer specific routine.. 4708.36 BogoMIPS (lpj=2354180)
 Mount-cache hash table entries: 512
 CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
 CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
@@ -67,41 +68,37 @@
 CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000010 00000001 00000000 00000003
 Intel machine check architecture supported.
 Intel machine check reporting enabled on CPU#0.
-Enabling fast FPU save and restore... done.
+mtrr: v2.0 (20020519)
+Enabling fast FPU save and restore... <7>spurious 8259A interrupt: IRQ7.
+done.
 Enabling unmasked SIMD FPU exception support... done.
 Checking 'hlt' instruction... OK.
 CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
 Booting processor 1/1 eip 2000
-CPU 1 irqstacks, hard=c041b000 soft=c0419000
+CPU 1 irqstacks, hard=c043f000 soft=c043d000
 Initializing CPU#1
-Calibrating delay loop... 4702.20 BogoMIPS (lpj=2351104)
+Calibrating delay using timer specific routine.. 4704.69 BogoMIPS (lpj=2352349)
 CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
 CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
 CPU: L2 Cache: 512K (64 bytes/line)
-CPU 1(2) -> Core 0
+CPU 1(2) -> Core 1
 CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000010 00000001 00000000 00000003
 Intel machine check architecture supported.
 Intel machine check reporting enabled on CPU#1.
 CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
-Total of 2 processors activated (9355.26 BogoMIPS).
+Total of 2 processors activated (9413.05 BogoMIPS).
 ENABLING IO-APIC IRQs
 ..TIMER: vector=0x31 pin1=0 pin2=-1
 checking TSC synchronization across 2 CPUs: 
 CPU#0 had 0 usecs TSC skew, fixed it up.
 CPU#1 had 0 usecs TSC skew, fixed it up.
 Brought up 2 CPUs
-CPU0 attaching sched-domain:
- domain 0: span 3
-  groups: 1 2
-CPU1 attaching sched-domain:
- domain 0: span 3
-  groups: 2 1
 NET: Registered protocol family 16
+ACPI: bus type pci registered
 PCI: PCI BIOS revision 3.00 entry at 0xf2740, last bus=5
-PCI: Using configuration type 1
-mtrr: v2.0 (20020519)
-ACPI: Subsystem revision 20050309
+PCI: Using MMCONFIG
+ACPI: Subsystem revision 20050902
 ACPI: Interpreter enabled
 ACPI: Using IOAPIC for interrupt routing
 ACPI: PCI Root Bridge [PCI0] (0000:00)
@@ -148,12 +145,37 @@
 SCSI subsystem initialized
 PCI: Using ACPI for IRQ routing
 PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
-pnp: 00:00: ioport range 0x4000-0x407f could not be reserved
-pnp: 00:00: ioport range 0x4080-0x40ff has been reserved
-pnp: 00:00: ioport range 0x4400-0x447f has been reserved
-pnp: 00:00: ioport range 0x4480-0x44ff could not be reserved
-pnp: 00:00: ioport range 0x4800-0x487f has been reserved
-pnp: 00:00: ioport range 0x4880-0x48ff has been reserved
+pnp: 00:01: ioport range 0x4000-0x407f could not be reserved
+pnp: 00:01: ioport range 0x4080-0x40ff has been reserved
+pnp: 00:01: ioport range 0x4400-0x447f has been reserved
+pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved
+pnp: 00:01: ioport range 0x4800-0x487f has been reserved
+pnp: 00:01: ioport range 0x4880-0x48ff has been reserved
+PCI: Bridge: 0000:00:09.0
+  IO window: 8000-afff
+  MEM window: d0000000-d1ffffff
+  PREFETCH window: 30000000-300fffff
+PCI: Bridge: 0000:00:0b.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0c.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0d.0
+  IO window: disabled.
+  MEM window: disabled.
+  PREFETCH window: disabled.
+PCI: Bridge: 0000:00:0e.0
+  IO window: disabled.
+  MEM window: c8000000-cfffffff
+  PREFETCH window: c0000000-c7ffffff
+PCI: Setting latency timer of device 0000:00:09.0 to 64
+PCI: Setting latency timer of device 0000:00:0b.0 to 64
+PCI: Setting latency timer of device 0000:00:0c.0 to 64
+PCI: Setting latency timer of device 0000:00:0d.0 to 64
+PCI: Setting latency timer of device 0000:00:0e.0 to 64
 Total HugeTLB memory allocated, 0
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
@@ -165,17 +187,22 @@
 vesafb: protected mode interface info at c000:d620
 vesafb: scrolling: redraw
 vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
+vesafb: Mode is VGA compatible
 Console: switching to colour frame buffer device 160x64
 fb0: VESA VGA frame buffer device
 ACPI: Power Button (FF) [PWRF]
+ACPI: Power Button (CM) [PWRB]
 ACPI: Fan [FAN] (on)
+ACPI: CPU0 (power states: C1[C1])
+ACPI: CPU1 (power states: C1[C1])
 ACPI: Thermal Zone [THRM] (40 C)
 PNP: No PS/2 controller found. Probing ports directly.
 serio: i8042 AUX port at 0x60,0x64 irq 12
 serio: i8042 KBD port at 0x60,0x64 irq 1
-Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
+Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
+mice: PS/2 mouse device common for all mice
 io scheduler noop registered
 io scheduler anticipatory registered
 io scheduler deadline registered
@@ -194,13 +221,9 @@
 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
 Probing IDE interface ide1...
 Probing IDE interface ide1...
-Probing IDE interface ide2...
-Probing IDE interface ide3...
-Probing IDE interface ide4...
-Probing IDE interface ide5...
 ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
-ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18
-scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
+ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
+scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
         <Adaptec 29160 Ultra160 SCSI adapter>
         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
 
@@ -208,15 +231,14 @@
   Type:   CD-ROM                             ANSI SCSI revision: 02
  target0:0:4: Beginning Domain Validation
  target0:0:4: Domain Validation skipping write tests
-(scsi0:A:4): 20.000MB/s transfers (20.000MHz, offset 16)
+ target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
  target0:0:4: Ending Domain Validation
   Vendor: IBM       Model: IC35L036UWD210-0  Rev: S5CQ
   Type:   Direct-Access                      ANSI SCSI revision: 03
 scsi0:A:6:0: Tagged Queuing enabled.  Depth 32
  target0:0:6: Beginning Domain Validation
-WIDTH IS 1
-(scsi0:A:6): 6.600MB/s transfers (16bit)
-(scsi0:A:6): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
+ target0:0:6: wide asynchronous.
+ target0:0:6: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
  target0:0:6: Ending Domain Validation
 SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
 SCSI device sda: drive cache: write back
@@ -224,22 +246,24 @@
 SCSI device sda: drive cache: write back
  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
 Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
-mice: PS/2 mouse device common for all mice
 device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
 NET: Registered protocol family 2
-IP: routing cache hash table of 4096 buckets, 32Kbytes
+IP route cache hash table entries: 8192 (order: 3, 32768 bytes)
 TCP established hash table entries: 32768 (order: 6, 262144 bytes)
 TCP bind hash table entries: 32768 (order: 6, 262144 bytes)
 TCP: Hash tables configured (established 32768 bind 32768)
+TCP reno registered
+TCP bic registered
 NET: Registered protocol family 1
 NET: Registered protocol family 17
 Starting balanced_irq
+Using IPI Shortcut mode
 BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
 XFS mounting filesystem sda1
 Ending clean XFS mount for filesystem: sda1
 VFS: Mounted root (xfs filesystem) readonly.
-Freeing unused kernel memory: 236k freed
-Adding 506008k swap on /dev/sda7.  Priority:-1 extents:1
+Freeing unused kernel memory: 232k freed
+Adding 506008k swap on /dev/sda7.  Priority:-1 extents:1 across:506008k
 Linux agpgart interface v0.101 (c) Dave Jones
 XFS mounting filesystem sda2
 Ending clean XFS mount for filesystem: sda2
@@ -249,35 +273,35 @@
 Ending clean XFS mount for filesystem: sda5
 XFS mounting filesystem sda6
 Ending clean XFS mount for filesystem: sda6
-forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.32.
+forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.41.
 ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23
-ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 23
+ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 17
 PCI: Setting latency timer of device 0000:00:0a.0 to 64
 eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
 eth0: no link during initialization.
 eth0: link up.
 ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
-ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
-ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
+ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
+ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
 eth1: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
       PrefPort:A  RlmtMode:Check Link State
 ieee1394: Initialized config rom entry `ip1394'
-ohci1394: $Rev: 1250 $ Ben Collins <bcollins@debian.org>
-ACPI: PCI Interrupt 0000:05:07.2[B] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18
-ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18]  MMIO=[d100f000-d100f7ff]  Max Packet=[2048]
+ohci1394: $Rev: 1299 $ Ben Collins <bcollins@debian.org>
+ACPI: PCI Interrupt 0000:05:07.2[B] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
+ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16]  MMIO=[d100f000-d100f7ff]  Max Packet=[2048]
 ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
-ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
-ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[16]  MMIO=[d100d000-d100d7ff]  Max Packet=[2048]
+ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 19
+ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[d100d000-d100d7ff]  Max Packet=[2048]
 gameport: EMU10K1 is pci0000:05:07.1/gameport0, io 0x8400, speed 1193kHz
-ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
+ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
 Installing spdif_bug patch: Audigy 2 Platinum [SB0240P]
-libata version 1.11 loaded.
-sata_nv version 0.6
+libata version 1.12 loaded.
+sata_nv version 0.8
 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
-ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 22
+ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 20
 PCI: Setting latency timer of device 0000:00:07.0 to 64
-ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 22
-ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 22
+ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 20
+ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 20
 ata1: no device found (phy stat 00000000)
 scsi1 : sata_nv
 ata2: no device found (phy stat 00000000)
@@ -289,13 +313,14 @@
 ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
 ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023c0091065c55]
 ata3: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3469 86:3c41 87:4003 88:407f
-ata3: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48
+ata3: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
 nv_sata: Primary device added
 nv_sata: Primary device removed
 nv_sata: Secondary device added
 nv_sata: Secondary device removed
 ata3: dev 0 configured for UDMA/133
 scsi3 : sata_nv
+ieee1394: Host added: ID:BUS[1-00:1023]  GUID[0011d800004f6359]
 ata4: no device found (phy stat 00000000)
 scsi4 : sata_nv
   Vendor: ATA       Model: WDC WD2000JD-00H  Rev: 08.0
@@ -309,35 +334,34 @@
 nv_sata: Secondary device added
 nv_sata: Secondary device removed
  sdb1 sdb2
-ieee1394: Host added: ID:BUS[1-00:1023]  GUID[0011d800004f6359]
 Attached scsi disk sdb at scsi3, channel 0, id 0, lun 0
 PCI: Enabling device 0000:00:04.0 (0000 -> 0003)
 ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 20
-ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 20 (level, low) -> IRQ 20
+ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 20 (level, low) -> IRQ 22
 PCI: Setting latency timer of device 0000:00:04.0 to 64
-intel8x0_measure_ac97_clock: measured 49659 usecs
-intel8x0: clocking to 46738
+intel8x0_measure_ac97_clock: measured 51749 usecs
+intel8x0: clocking to 46867
 usbcore: registered new driver usbfs
 usbcore: registered new driver hub
 ACPI: PCI Interrupt Link [APCL] enabled at IRQ 23
-ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 23
+ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 17
 PCI: Setting latency timer of device 0000:00:02.1 to 64
 ehci_hcd 0000:00:02.1: EHCI Host Controller
 ehci_hcd 0000:00:02.1: debug port 1
 ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
-ehci_hcd 0000:00:02.1: irq 23, io mem 0xfeb00000
+ehci_hcd 0000:00:02.1: irq 17, io mem 0xfeb00000
 PCI: cache line size of 64 is not supported by device 0000:00:02.1
 ehci_hcd 0000:00:02.1: park 0
 ehci_hcd 0000:00:02.1: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 10 ports detected
-ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
+ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
 ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22
-ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, low) -> IRQ 22
+ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, low) -> IRQ 20
 PCI: Setting latency timer of device 0000:00:02.0 to 64
 ohci_hcd 0000:00:02.0: OHCI Host Controller
 ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
-ohci_hcd 0000:00:02.0: irq 22, io mem 0xd2004000
+ohci_hcd 0000:00:02.0: irq 20, io mem 0xd2004000
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 10 ports detected
 usb 1-2: new high speed USB device using ehci_hcd and address 2
@@ -356,11 +380,13 @@
 input: USB HID v1.10 Keyboard [Microsoft Natural Keyboard Pro] on usb-0000:00:02.0-3.1
 input: USB HID v1.10 Device [Microsoft Natural Keyboard Pro] on usb-0000:00:02.0-3.1
 usbcore: registered new driver usbhid
-drivers/usb/input/hid-core.c: v2.01:USB HID core driver
+drivers/usb/input/hid-core.c: v2.6:USB HID core driver
 Real Time Clock Driver v1.12
 Floppy drive(s): fd0 is 1.44M
 FDC 0 is a post-1991 82077
 parport: PnPBIOS parport detected.
 parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
-gameport: NS558 PnP Gameport is pnp00:0b/gameport0, io 0x201, speed 917kHz
-USB Universal Host Controller Interface driver v2.2
+gameport: NS558 PnP Gameport is pnp00:0b/gameport0, io 0x201, speed 903kHz
+USB Universal Host Controller Interface driver v2.3
+NET: Registered protocol family 10
+IPv6 over IPv4 tunneling driver

[-- Attachment #1.3: dm2613-dm2614.diff --]
[-- Type: text/plain, Size: 14861 bytes --]

--- dm2613	2005-09-26 01:55:34.000000000 -0400
+++ dm2614	2005-09-26 01:16:52.000000000 -0400
@@ -1,4 +1,4 @@
-Linux version 2.6.13.1 (root@blaze) (gcc version 3.3.6) #2 SMP Mon Sep 12 13:29:14 EDT 2005
+Linux version 2.6.14-rc2-mm1 (root@blaze) (gcc version 3.3.6) #1 SMP Sun Sep 25 17:03:22 EDT 2005
 BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
@@ -12,9 +12,10 @@
 511MB LOWMEM available.
 found SMP MP-table at 000f5a30
 On node 0 totalpages: 131056
-  DMA zone: 4096 pages, LIFO batch:1
-  Normal zone: 126960 pages, LIFO batch:31
-  HighMem zone: 0 pages, LIFO batch:1
+  DMA zone: 4096 pages, LIFO batch:2
+  DMA32 zone: 0 pages, LIFO batch:2
+  Normal zone: 126960 pages, LIFO batch:64
+  HighMem zone: 0 pages, LIFO batch:2
 DMI 2.3 present.
 ACPI: RSDP (v000 Nvidia                                ) @ 0x000f7dc0
 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
@@ -42,22 +43,22 @@
 ACPI: IRQ15 used by override.
 Enabling APIC mode:  Flat.  Using 1 I/O APICs
 Using ACPI (MADT) for SMP configuration information
-Allocating PCI resources starting at 20000000 (gap: 20000000:c0000000)
+Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
 Built 1 zonelists
-Kernel command line: root=/dev/sda1 ro vmalloc=256M console=ttyS0,57600n8 console=tty0 rootflags=quota elevator=cfq vga=795
 mapped APIC to ffffd000 (fee00000)
 mapped IOAPIC to ffffc000 (fec00000)
 Initializing CPU#0
-CPU 0 irqstacks, hard=c0469000 soft=c0467000
+Kernel command line: root=/dev/sda1 ro vmalloc=256M console=ttyS0,57600n8 console=tty0 rootflags=quota elevator=cfq vga=795
+CPU 0 irqstacks, hard=c043e000 soft=c043c000
 PID hash table entries: 2048 (order: 11, 32768 bytes)
-Detected 2352.785 MHz processor.
+Detected 2352.758 MHz processor.
 Using tsc for high-res timesource
 Console: colour dummy device 80x25
 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 514984k/524224k available (2353k kernel code, 8756k reserved, 877k data, 228k init, 0k highmem)
+Memory: 515152k/524224k available (2390k kernel code, 8560k reserved, 662k data, 232k init, 0k highmem)
 Checking if this processor honours the WP bit even in supervisor mode... Ok.
-Calibrating delay using timer specific routine.. 4708.36 BogoMIPS (lpj=2354181)
+Calibrating delay using timer specific routine.. 4708.36 BogoMIPS (lpj=2354180)
 Mount-cache hash table entries: 512
 CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
 CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
@@ -68,14 +69,15 @@
 Intel machine check architecture supported.
 Intel machine check reporting enabled on CPU#0.
 mtrr: v2.0 (20020519)
-Enabling fast FPU save and restore... done.
+Enabling fast FPU save and restore... <7>spurious 8259A interrupt: IRQ7.
+done.
 Enabling unmasked SIMD FPU exception support... done.
 Checking 'hlt' instruction... OK.
 CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
 Booting processor 1/1 eip 2000
-CPU 1 irqstacks, hard=c046a000 soft=c0468000
+CPU 1 irqstacks, hard=c043f000 soft=c043d000
 Initializing CPU#1
-Calibrating delay using timer specific routine.. 4704.68 BogoMIPS (lpj=2352342)
+Calibrating delay using timer specific routine.. 4704.69 BogoMIPS (lpj=2352349)
 CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
 CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
@@ -85,7 +87,7 @@
 Intel machine check architecture supported.
 Intel machine check reporting enabled on CPU#1.
 CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
-Total of 2 processors activated (9413.04 BogoMIPS).
+Total of 2 processors activated (9413.05 BogoMIPS).
 ENABLING IO-APIC IRQs
 ..TIMER: vector=0x31 pin1=0 pin2=-1
 checking TSC synchronization across 2 CPUs: 
@@ -95,13 +97,12 @@
 NET: Registered protocol family 16
 ACPI: bus type pci registered
 PCI: PCI BIOS revision 3.00 entry at 0xf2740, last bus=5
-PCI: Using configuration type 1
-ACPI: Subsystem revision 20050408
+PCI: Using MMCONFIG
+ACPI: Subsystem revision 20050902
 ACPI: Interpreter enabled
 ACPI: Using IOAPIC for interrupt routing
 ACPI: PCI Root Bridge [PCI0] (0000:00)
 PCI: Probing PCI hardware (bus 00)
-ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
 PCI: Transparent bridge - 0000:00:09.0
 Boot video device is 0000:01:00.0
 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
@@ -144,16 +145,16 @@
 SCSI subsystem initialized
 PCI: Using ACPI for IRQ routing
 PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
-pnp: 00:00: ioport range 0x4000-0x407f could not be reserved
-pnp: 00:00: ioport range 0x4080-0x40ff has been reserved
-pnp: 00:00: ioport range 0x4400-0x447f has been reserved
-pnp: 00:00: ioport range 0x4480-0x44ff could not be reserved
-pnp: 00:00: ioport range 0x4800-0x487f has been reserved
-pnp: 00:00: ioport range 0x4880-0x48ff has been reserved
+pnp: 00:01: ioport range 0x4000-0x407f could not be reserved
+pnp: 00:01: ioport range 0x4080-0x40ff has been reserved
+pnp: 00:01: ioport range 0x4400-0x447f has been reserved
+pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved
+pnp: 00:01: ioport range 0x4800-0x487f has been reserved
+pnp: 00:01: ioport range 0x4880-0x48ff has been reserved
 PCI: Bridge: 0000:00:09.0
   IO window: 8000-afff
   MEM window: d0000000-d1ffffff
-  PREFETCH window: 20000000-200fffff
+  PREFETCH window: 30000000-300fffff
 PCI: Bridge: 0000:00:0b.0
   IO window: disabled.
   MEM window: disabled.
@@ -175,7 +176,6 @@
 PCI: Setting latency timer of device 0000:00:0c.0 to 64
 PCI: Setting latency timer of device 0000:00:0d.0 to 64
 PCI: Setting latency timer of device 0000:00:0e.0 to 64
-Machine check exception polling timer started.
 Total HugeTLB memory allocated, 0
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
@@ -187,6 +187,7 @@
 vesafb: protected mode interface info at c000:d620
 vesafb: scrolling: redraw
 vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
+vesafb: Mode is VGA compatible
 Console: switching to colour frame buffer device 160x64
 fb0: VESA VGA frame buffer device
 ACPI: Power Button (FF) [PWRF]
@@ -201,7 +202,10 @@
 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
 ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
+mice: PS/2 mouse device common for all mice
 io scheduler noop registered
+io scheduler anticipatory registered
+io scheduler deadline registered
 io scheduler cfq registered (default)
 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
@@ -219,20 +223,18 @@
 Probing IDE interface ide1...
 ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
 ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
-scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
+scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
         <Adaptec 29160 Ultra160 SCSI adapter>
         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
 
   Vendor: PLEXTOR   Model: CD-R   PX-W1210S  Rev: 1.06
   Type:   CD-ROM                             ANSI SCSI revision: 02
- target0:0:4: asynchronous.
  target0:0:4: Beginning Domain Validation
  target0:0:4: Domain Validation skipping write tests
  target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
  target0:0:4: Ending Domain Validation
   Vendor: IBM       Model: IC35L036UWD210-0  Rev: S5CQ
   Type:   Direct-Access                      ANSI SCSI revision: 03
- target0:0:6: asynchronous.
 scsi0:A:6:0: Tagged Queuing enabled.  Depth 32
  target0:0:6: Beginning Domain Validation
  target0:0:6: wide asynchronous.
@@ -244,12 +246,11 @@
 SCSI device sda: drive cache: write back
  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
 Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
-mice: PS/2 mouse device common for all mice
 device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
 NET: Registered protocol family 2
 IP route cache hash table entries: 8192 (order: 3, 32768 bytes)
-TCP established hash table entries: 32768 (order: 7, 524288 bytes)
-TCP bind hash table entries: 32768 (order: 6, 393216 bytes)
+TCP established hash table entries: 32768 (order: 6, 262144 bytes)
+TCP bind hash table entries: 32768 (order: 6, 262144 bytes)
 TCP: Hash tables configured (established 32768 bind 32768)
 TCP reno registered
 TCP bic registered
@@ -257,13 +258,12 @@
 NET: Registered protocol family 17
 Starting balanced_irq
 Using IPI Shortcut mode
-swsusp: Suspend partition has wrong signature?
 BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
 XFS mounting filesystem sda1
 Ending clean XFS mount for filesystem: sda1
 VFS: Mounted root (xfs filesystem) readonly.
-Freeing unused kernel memory: 228k freed
-Adding 506008k swap on /dev/sda7.  Priority:-1 extents:1
+Freeing unused kernel memory: 232k freed
+Adding 506008k swap on /dev/sda7.  Priority:-1 extents:1 across:506008k
 Linux agpgart interface v0.101 (c) Dave Jones
 XFS mounting filesystem sda2
 Ending clean XFS mount for filesystem: sda2
@@ -273,7 +273,7 @@
 Ending clean XFS mount for filesystem: sda5
 XFS mounting filesystem sda6
 Ending clean XFS mount for filesystem: sda6
-forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.35.
+forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.41.
 ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23
 ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 17
 PCI: Setting latency timer of device 0000:00:0a.0 to 64
@@ -285,10 +285,6 @@
 ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
 eth1: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
       PrefPort:A  RlmtMode:Check Link State
-nvidia: module license 'NVIDIA' taints kernel.
-ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
-PCI: Setting latency timer of device 0000:01:00.0 to 64
-NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module  1.0-7676  Fri Jul 29 12:58:54 PDT 2005
 ieee1394: Initialized config rom entry `ip1394'
 ohci1394: $Rev: 1299 $ Ben Collins <bcollins@debian.org>
 ACPI: PCI Interrupt 0000:05:07.2[B] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
@@ -300,7 +296,7 @@
 ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
 Installing spdif_bug patch: Audigy 2 Platinum [SB0240P]
 libata version 1.12 loaded.
-sata_nv version 0.6
+sata_nv version 0.8
 ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
 ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 20
 PCI: Setting latency timer of device 0000:00:07.0 to 64
@@ -317,18 +313,18 @@
 ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
 ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023c0091065c55]
 ata3: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3469 86:3c41 87:4003 88:407f
-ata3: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48
+ata3: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
 nv_sata: Primary device added
 nv_sata: Primary device removed
 nv_sata: Secondary device added
 nv_sata: Secondary device removed
 ata3: dev 0 configured for UDMA/133
 scsi3 : sata_nv
+ieee1394: Host added: ID:BUS[1-00:1023]  GUID[0011d800004f6359]
 ata4: no device found (phy stat 00000000)
 scsi4 : sata_nv
   Vendor: ATA       Model: WDC WD2000JD-00H  Rev: 08.0
   Type:   Direct-Access                      ANSI SCSI revision: 05
-ieee1394: Host added: ID:BUS[1-00:1023]  GUID[0011d800004f6359]
 SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
 SCSI device sdb: drive cache: write back
 SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
@@ -343,14 +339,14 @@
 ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 20
 ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 20 (level, low) -> IRQ 22
 PCI: Setting latency timer of device 0000:00:04.0 to 64
-intel8x0_measure_ac97_clock: measured 50740 usecs
-intel8x0: clocking to 46837
+intel8x0_measure_ac97_clock: measured 51749 usecs
+intel8x0: clocking to 46867
 usbcore: registered new driver usbfs
 usbcore: registered new driver hub
 ACPI: PCI Interrupt Link [APCL] enabled at IRQ 23
 ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 17
 PCI: Setting latency timer of device 0000:00:02.1 to 64
-ehci_hcd 0000:00:02.1: nVidia Corporation CK804 USB Controller
+ehci_hcd 0000:00:02.1: EHCI Host Controller
 ehci_hcd 0000:00:02.1: debug port 1
 ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
 ehci_hcd 0000:00:02.1: irq 17, io mem 0xfeb00000
@@ -363,12 +359,12 @@
 ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22
 ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, low) -> IRQ 20
 PCI: Setting latency timer of device 0000:00:02.0 to 64
-ohci_hcd 0000:00:02.0: nVidia Corporation CK804 USB Controller
+ohci_hcd 0000:00:02.0: OHCI Host Controller
 ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
 ohci_hcd 0000:00:02.0: irq 20, io mem 0xd2004000
-usb 1-2: new high speed USB device using ehci_hcd and address 2
 hub 2-0:1.0: USB hub found
 hub 2-0:1.0: 10 ports detected
+usb 1-2: new high speed USB device using ehci_hcd and address 2
 hub 1-2:1.0: USB hub found
 hub 1-2:1.0: 4 ports detected
 i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
@@ -384,11 +380,13 @@
 input: USB HID v1.10 Keyboard [Microsoft Natural Keyboard Pro] on usb-0000:00:02.0-3.1
 input: USB HID v1.10 Device [Microsoft Natural Keyboard Pro] on usb-0000:00:02.0-3.1
 usbcore: registered new driver usbhid
-drivers/usb/input/hid-core.c: v2.01:USB HID core driver
+drivers/usb/input/hid-core.c: v2.6:USB HID core driver
 Real Time Clock Driver v1.12
 Floppy drive(s): fd0 is 1.44M
 FDC 0 is a post-1991 82077
 parport: PnPBIOS parport detected.
 parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
-gameport: NS558 PnP Gameport is pnp00:0b/gameport0, io 0x201, speed 917kHz
+gameport: NS558 PnP Gameport is pnp00:0b/gameport0, io 0x201, speed 903kHz
 USB Universal Host Controller Interface driver v2.3
+NET: Registered protocol family 10
+IPv6 over IPv4 tunneling driver

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

Re: 2.6.14-rc2-mm1

[Tim Schmielau]

On Sun, 25 Sep 2005, Paul Blazejowski wrote:

> Upon quick testing the latest mm kernel it appears there's some kind of
> race condition when using dual core cpu esp when using XORG and USB
> (although PS2 has same issue) kebyboard rate being too fast.

Does the following patch by John Stultz fix the problem?

Tim


>From johnstul@us.ibm.com Mon Sep 26 09:04:08 2005
Date: Mon, 19 Sep 2005 12:16:43 -0700
From: john stultz <johnstul@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: lkml <linux-kernel@vger.kernel.org>, Andi Kleen <ak@suse.de>
Subject: [PATCH] x86-64: Fix bad assumption that dualcore cpus have synced
    TSCs

Andrew,
	This patch should resolve the issue seen in bugme bug #5105, where it
is assumed that dualcore x86_64 systems have synced TSCs. This is not
the case, and alternate timesources should be used instead.

For more details, see:
http://bugzilla.kernel.org/show_bug.cgi?id=5105


Please consider for inclusion in your tree.

thanks
-john

diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c
--- a/arch/x86_64/kernel/time.c
+++ b/arch/x86_64/kernel/time.c
@@ -959,9 +959,6 @@ static __init int unsynchronized_tsc(voi
  	   are handled in the OEM check above. */
  	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
  		return 0;
- 	/* All in a single socket - should be synchronized */
- 	if (cpus_weight(cpu_core_map[0]) == num_online_cpus())
- 		return 0;
 #endif
  	/* Assume multi socket systems are not synchronized */
  	return num_online_cpus() > 1;

Re: 2.6.14-rc2-mm1

[Carlo Calica]

I had the same problem with 2.6.12.  I'll run some tests with older kernels.


On 9/25/05, Andrew Morton <akpm@osdl.org> wrote:
> Paul Blazejowski <paulb@blazebox.homeip.net> wrote:
> >
> >  Upon quick testing the latest mm kernel it appears there's some kind of
> >  race condition when using dual core cpu esp when using XORG and USB
> >  (although PS2 has same issue) kebyboard rate being too fast.
> >
> >  The same behaviour happens on vanilla 2.6.13 kernel. Reporting this also
> >  to XORG list in hopes to help debug this issue.
>
> Is it possible to narrow this down a bit further?  Was 2.6.12 OK?
>
> If we can identify two reasonably-close-in-time versions either side of the
> regression then the next step would be to run `dmesg -s 1000000' under both
> kernel versions, then run `diff -u dmesg.good dmesg.bad'.
>
>


--
Carlo J. Calica

Re: 2.6.14-rc2-mm1

[Andrew Morton]

Paul Blazejowski <paulb@blazebox.homeip.net> wrote:
>
>  Upon quick testing the latest mm kernel it appears there's some kind of
>  race condition when using dual core cpu esp when using XORG and USB
>  (although PS2 has same issue) kebyboard rate being too fast.
> 
>  The same behaviour happens on vanilla 2.6.13 kernel. Reporting this also
>  to XORG list in hopes to help debug this issue.

Is it possible to narrow this down a bit further?  Was 2.6.12 OK?

If we can identify two reasonably-close-in-time versions either side of the
regression then the next step would be to run `dmesg -s 1000000' under both
kernel versions, then run `diff -u dmesg.good dmesg.bad'.

Re: 2.6.14-rc2-mm1

[Paul Blazejowski]

[-- Attachment #1.1: Type: text/plain, Size: 1720 bytes --]

Folks,

Upon quick testing the latest mm kernel it appears there's some kind of
race condition when using dual core cpu esp when using XORG and USB
(although PS2 has same issue) kebyboard rate being too fast.

The same behaviour happens on vanilla 2.6.13 kernel. Reporting this also
to XORG list in hopes to help debug this issue.

The platform is nForce4 SLI from ASUS (A8N-SLI Premium) with dual core
X2 Athlon 3800+ processor.

XORG version is 6.8.2 under Slackware 10.2.

uname -a reports: Linux blaze 2.6.14-rc2-mm1 #1 SMP Sun Sep 25 17:03:22
EDT 2005 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
AuthenticAMD GNU/Linux

kernel config, dmesg output and lspci -vvv will be attached below.

I have confirmed this with another fellow who is using the same setup
and is having the same issue. Also worth noting is that the SATA
performance is very poor, the hdparm results give ~33mb/s where on
nforce2 previously the rates would be in ~58mb/s range. In comparison
SCSI rates are in ~52mb/s range. This both happens on sata_nv and
sata_sil controllers on this mainboard.

One of the workarounds for me is to turn the keyboard rate in
gnome-keybaord tools which helps. Also when browsing websites the USB
mouse has problems with scrolling and the window painting seems very
slow, like when typing www. in url bar can take up to 10 seconds before
the bar shows previously entered urls. Playing mp3 makes the music
skip very badly. I had not tried to use UP kernel but from the
reports i've read the issue is gone when using X. As noted here
http://lists.freedesktop.org/archives/xorg/2005-September/010148.html

I can help debugging this and if more info is needed please CC the
responses.

Best Regards,

Paul B.

[-- Attachment #1.2: config.gz --]
[-- Type: application/x-gunzip, Size: 9034 bytes --]

[-- Attachment #1.3: dm-mm.txt --]
[-- Type: text/plain, Size: 19836 bytes --]

Linux version 2.6.14-rc2-mm1 (root@blaze) (gcc version 3.3.6) #1 SMP Sun Sep 25 17:03:22 EDT 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
 BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000f5a30
On node 0 totalpages: 131056
  DMA zone: 4096 pages, LIFO batch:2
  DMA32 zone: 0 pages, LIFO batch:2
  Normal zone: 126960 pages, LIFO batch:64
  HighMem zone: 0 pages, LIFO batch:2
DMI 2.3 present.
ACPI: RSDP (v000 Nvidia                                ) @ 0x000f7dc0
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff3040
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff30c0
ACPI: SRAT (v001 AMD    HAMMER   0x00000001 AMD  0x00000001) @ 0x1fff9900
ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff9a00
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x1fff9840
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x00000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
Built 1 zonelists
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
Kernel command line: root=/dev/sda1 ro vmalloc=256M console=ttyS0,57600n8 console=tty0 rootflags=quota elevator=cfq vga=795
CPU 0 irqstacks, hard=c043e000 soft=c043c000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 2352.758 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 515152k/524224k available (2390k kernel code, 8560k reserved, 662k data, 232k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 4708.36 BogoMIPS (lpj=2354180)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0(2) -> Core 0
CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000010 00000001 00000000 00000003
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
Enabling fast FPU save and restore... <7>spurious 8259A interrupt: IRQ7.
done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Booting processor 1/1 eip 2000
CPU 1 irqstacks, hard=c043f000 soft=c043d000
Initializing CPU#1
Calibrating delay using timer specific routine.. 4704.69 BogoMIPS (lpj=2352349)
CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: After vendor identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1(2) -> Core 1
CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000010 00000001 00000000 00000003
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Total of 2 processors activated (9413.05 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=0 pin2=-1
checking TSC synchronization across 2 CPUs: 
CPU#0 had 0 usecs TSC skew, fixed it up.
CPU#1 had 0 usecs TSC skew, fixed it up.
Brought up 2 CPUs
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 3.00 entry at 0xf2740, last bus=5
PCI: Using MMCONFIG
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:09.0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 7 9 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 14 devices
SCSI subsystem initialized
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:01: ioport range 0x4000-0x407f could not be reserved
pnp: 00:01: ioport range 0x4080-0x40ff has been reserved
pnp: 00:01: ioport range 0x4400-0x447f has been reserved
pnp: 00:01: ioport range 0x4480-0x44ff could not be reserved
pnp: 00:01: ioport range 0x4800-0x487f has been reserved
pnp: 00:01: ioport range 0x4880-0x48ff has been reserved
PCI: Bridge: 0000:00:09.0
  IO window: 8000-afff
  MEM window: d0000000-d1ffffff
  PREFETCH window: 30000000-300fffff
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: disabled.
  MEM window: c8000000-cfffffff
  PREFETCH window: c0000000-c7ffffff
PCI: Setting latency timer of device 0000:00:09.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SGI XFS with ACLs, realtime, large block numbers, no debug enabled
SGI XFS Quota Management subsystem
Initializing Cryptographic API
vesafb: framebuffer at 0xc0000000, mapped to 0xe0880000, using 10240k, total 131072k
vesafb: mode is 1280x1024x32, linelength=5120, pages=0
vesafb: protected mode interface info at c000:d620
vesafb: scrolling: redraw
vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: CPU0 (power states: C1[C1])
ACPI: CPU1 (power states: C1[C1])
ACPI: Thermal Zone [THRM] (40 C)
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
mice: PS/2 mouse device common for all mice
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
NFORCE-CK804: chipset revision 242
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Probing IDE interface ide1...
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

  Vendor: PLEXTOR   Model: CD-R   PX-W1210S  Rev: 1.06
  Type:   CD-ROM                             ANSI SCSI revision: 02
 target0:0:4: Beginning Domain Validation
 target0:0:4: Domain Validation skipping write tests
 target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
 target0:0:4: Ending Domain Validation
  Vendor: IBM       Model: IC35L036UWD210-0  Rev: S5CQ
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0:A:6:0: Tagged Queuing enabled.  Depth 32
 target0:0:6: Beginning Domain Validation
 target0:0:6: wide asynchronous.
 target0:0:6: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
 target0:0:6: Ending Domain Validation
SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 71687340 512-byte hdwr sectors (36704 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
NET: Registered protocol family 2
IP route cache hash table entries: 8192 (order: 3, 32768 bytes)
TCP established hash table entries: 32768 (order: 6, 262144 bytes)
TCP bind hash table entries: 32768 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Starting balanced_irq
Using IPI Shortcut mode
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
XFS mounting filesystem sda1
Ending clean XFS mount for filesystem: sda1
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 232k freed
Adding 506008k swap on /dev/sda7.  Priority:-1 extents:1 across:506008k
Linux agpgart interface v0.101 (c) Dave Jones
XFS mounting filesystem sda2
Ending clean XFS mount for filesystem: sda2
XFS mounting filesystem sda3
Ending clean XFS mount for filesystem: sda3
XFS mounting filesystem sda5
Ending clean XFS mount for filesystem: sda5
XFS mounting filesystem sda6
Ending clean XFS mount for filesystem: sda6
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.41.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:0a.0 to 64
eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
eth0: no link during initialization.
eth0: link up.
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
ACPI: PCI Interrupt 0000:05:0c.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
eth1: Yukon Gigabit Ethernet 10/100/1000Base-T Adapter
      PrefPort:A  RlmtMode:Check Link State
ieee1394: Initialized config rom entry `ip1394'
ohci1394: $Rev: 1299 $ Ben Collins <bcollins@debian.org>
ACPI: PCI Interrupt 0000:05:07.2[B] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 16
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[16]  MMIO=[d100f000-d100f7ff]  Max Packet=[2048]
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 19
ohci1394: fw-host1: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[d100d000-d100d7ff]  Max Packet=[2048]
gameport: EMU10K1 is pci0000:05:07.1/gameport0, io 0x8400, speed 1193kHz
ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 18
Installing spdif_bug patch: Audigy 2 Platinum [SB0240P]
libata version 1.12 loaded.
sata_nv version 0.8
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:07.0 to 64
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD800 irq 20
ata2: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD808 irq 20
ata1: no device found (phy stat 00000000)
scsi1 : sata_nv
ata2: no device found (phy stat 00000000)
scsi2 : sata_nv
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 21 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 21
ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 21
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023c0091065c55]
ata3: dev 0 cfg 49:2f00 82:346b 83:7f61 84:4003 85:3469 86:3c41 87:4003 88:407f
ata3: dev 0 ATA-6, max UDMA/133, 390721968 sectors: LBA48
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
ata3: dev 0 configured for UDMA/133
scsi3 : sata_nv
ieee1394: Host added: ID:BUS[1-00:1023]  GUID[0011d800004f6359]
ata4: no device found (phy stat 00000000)
scsi4 : sata_nv
  Vendor: ATA       Model: WDC WD2000JD-00H  Rev: 08.0
  Type:   Direct-Access                      ANSI SCSI revision: 05
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdb: drive cache: write back
 sdb:<4>nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device added
nv_sata: Secondary device removed
 sdb1 sdb2
Attached scsi disk sdb at scsi3, channel 0, id 0, lun 0
PCI: Enabling device 0000:00:04.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCJ] -> GSI 20 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:04.0 to 64
intel8x0_measure_ac97_clock: measured 51749 usecs
intel8x0: clocking to 46867
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: debug port 1
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: irq 17, io mem 0xfeb00000
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: park 0
ehci_hcd 0000:00:02.1: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 20, io mem 0xd2004000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
usb 1-2: new high speed USB device using ehci_hcd and address 2
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
i2c_adapter i2c-0: nForce2 SMBus adapter at 0x4c00
i2c_adapter i2c-1: nForce2 SMBus adapter at 0x4c40
ohci_hcd 0000:00:02.0: wakeup
usb 2-3: new full speed USB device using ohci_hcd and address 2
hub 2-3:1.0: USB hub found
hub 2-3:1.0: 3 ports detected
usb 2-4: new low speed USB device using ohci_hcd and address 3
usb 2-3.1: new low speed USB device using ohci_hcd and address 4
usbcore: registered new driver hiddev
input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:02.0-4
input: USB HID v1.10 Keyboard [Microsoft Natural Keyboard Pro] on usb-0000:00:02.0-3.1
input: USB HID v1.10 Device [Microsoft Natural Keyboard Pro] on usb-0000:00:02.0-3.1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Real Time Clock Driver v1.12
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
gameport: NS558 PnP Gameport is pnp00:0b/gameport0, io 0x201, speed 903kHz
USB Universal Host Controller Interface driver v2.3
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver

[-- Attachment #1.4: pciout.txt --]
[-- Type: text/plain, Size: 16645 bytes --]

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [44] #08 [01e0]
	Capabilities: [e0] #08 [a801]

00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at e400 [size=32]
	Region 4: I/O ports at 4c00 [size=64]
	Region 5: I/O ports at 4c40 [size=64]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 20
	Region 0: Memory at d2004000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 17
	Region 0: Memory at feb00000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [44] #0a [2098]
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (500ns min, 1250ns max)
	Interrupt: pin A routed to IRQ 22
	Region 0: I/O ports at dc00 [size=256]
	Region 1: I/O ports at 1000 [size=256]
	Region 2: Memory at d2003000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP])
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Region 4: I/O ports at f000 [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO])
	Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 20
	Region 0: I/O ports at 09f0 [size=8]
	Region 1: I/O ports at 0bf0 [size=4]
	Region 2: I/O ports at 0970 [size=8]
	Region 3: I/O ports at 0b70 [size=4]
	Region 4: I/O ports at d800 [size=16]
	Region 5: Memory at d2002000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO])
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 21
	Region 0: I/O ports at 09e0 [size=8]
	Region 1: I/O ports at 0be0 [size=4]
	Region 2: I/O ports at 0960 [size=8]
	Region 3: I/O ports at 0b60 [size=4]
	Region 4: I/O ports at c400 [size=16]
	Region 5: Memory at d2001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=128
	I/O behind bridge: 00008000-0000afff
	Memory behind bridge: d0000000-d1ffffff
	Prefetchable memory behind bridge: 30000000-300fffff
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at d2000000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at b000 [size=8]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, cache line size 08
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, cache line size 08
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, cache line size 08
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, cache line size 08
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: c8000000-cfffffff
	Prefetchable memory behind bridge: 00000000c0000000-00000000c7f00000
	BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [58] #08 [a800]
	Capabilities: [80] #10 [0141]

01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 GT] (rev a2) (prog-if 00 [VGA])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at c8000000 (32-bit, non-prefetchable) [size=64M]
	Region 1: Memory at c0000000 (64-bit, prefetchable) [size=128M]
	Region 3: Memory at cc000000 (64-bit, non-prefetchable) [size=16M]
	Expansion ROM at cd000000 [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [78] #10 [0001]

05:07.0 Multimedia audio controller: Creative Labs SB Audigy (rev 04)
	Subsystem: Creative Labs: Unknown device 1002
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 18
	Region 0: I/O ports at 8000 [size=64]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

05:07.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 04)
	Subsystem: Creative Labs: Unknown device 0060
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 0: I/O ports at 8400 [size=8]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

05:07.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port (rev 04) (prog-if 10 [OHCI])
	Subsystem: Creative Labs SB Audigy FireWire Port
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 1000ns max), cache line size 08
	Interrupt: pin B routed to IRQ 16
	Region 0: Memory at d100f000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at d1000000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

05:08.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
	Subsystem: Adaptec 29160 Ultra160 SCSI Controller
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (10000ns min, 6250ns max), cache line size 08
	Interrupt: pin A routed to IRQ 16
	BIST result: 00
	Region 0: I/O ports at 8800 [disabled] [size=256]
	Region 1: Memory at d100e000 (64-bit, non-prefetchable) [size=4K]
	Expansion ROM at 30080000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

05:0a.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
	Subsystem: ASUSTeK Computer Inc.: Unknown device 8167
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32, cache line size 08
	Interrupt: pin A routed to IRQ 3
	Region 0: I/O ports at 8c00 [size=8]
	Region 1: I/O ports at 9000 [size=4]
	Region 2: I/O ports at 9400 [size=8]
	Region 3: I/O ports at 9800 [size=4]
	Region 4: I/O ports at 9c00 [size=16]
	Region 5: Memory at d100c000 (32-bit, non-prefetchable) [size=1K]
	Expansion ROM at 30000000 [disabled] [size=512K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-

05:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
	Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 1000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 19
	Region 0: Memory at d100d000 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at d1004000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

05:0c.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
	Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus)
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (5750ns min, 7750ns max), cache line size 08
	Interrupt: pin A routed to IRQ 18
	Region 0: Memory at d1008000 (32-bit, non-prefetchable) [size=16K]
	Region 1: I/O ports at a000 [size=256]
	Expansion ROM at 300a0000 [disabled] [size=128K]
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data


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