linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.5.74-mm1
@ 2003-07-03  9:37 Andrew Morton
  2003-07-03 10:37 ` 2.5.74-mm1 Wiktor Wodecki
                   ` (9 more replies)
  0 siblings, 10 replies; 147+ messages in thread
From: Andrew Morton @ 2003-07-03  9:37 UTC (permalink / raw)
  To: linux-kernel, linux-mm



ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/

. Mainly a resync with various things and people.  Plus a few fixlets.

. I dropped out a few patches which weren't really proving useful.

. Included Con's CPU scheduler changes.  Feedback on the effectiveness of
  this and the usual benchmarks would be interesting.

  Changes to the CPU scheduler tend to cause surprising and subtle problems
  in areas where you least expect it, and these do take a long time to
  materialise.  Alterations in there need to be made carefully and cautiously.
  We shall see...




Changes since 2.5.73-mm3:


 linus.patch

 Latest Linus tree

-move_vma-VM_LOCKED-fix.patch
-e100-use-after-free-fix.patch
-3-unmap-page-debugging.patch
-VM_RESERVED-check.patch
-numa-memory-reporting-fix-2.patch
-ramfs-use-generic_file_llseek.patch
-inode_change_ok-remove-lock_kernel.patch
-nommu-vmtruncate-no_lock_kernel.patch
-proc-lock_kernel-removal.patch
-fops-flush-no-lock_kernel.patch
-block_llseek-no-lock_kernel.patch
-TC35815-config-fix.patch
-CLONE_DETACHED-exit-fix.patch
-security_vm_enough_memory.patch
-rename-timer-A1.patch
-lost-tick-speedstep-fix-A1.patch
-lost-tick-corner-fix-A0.patch
-lowmem_page_address-cleanup.patch
-ext2_new_inode-race-fix.patch
-double-mmdrop-fix.patch
-cciss-hang-fix.patch
-journal_release_buffer-race-fix.patch

 Merged

-HZ-100.patch

 Go back to 1000 Hz

+misc8.patch

 Misc fixes

-irqreturn-snd-via-fix.patch
-config-PAGE_OFFSET.patch
-lru_cache_add-check.patch
-skip-apic-ids-on-boot.patch
-bio-debug-trap.patch
-sound-irq-hack.patch

 Dropped.

+linux-isp-2-fix-again.patch

 Fix non-modular feral driver

+xattr-cleanup.patch
+xattr-sharing.patch
+xattr-just-replace.patch
+xattr-fine-grained-locking-prep.patch
+xattr-fine-grained-locking.patch

 Finer-grained locking in the ext2 and ext3 extended attribute code.

-as-double-free-and-debug.patch
-as-fix-seek-estimation.patch
-as-fix-seeky-loads.patch

 Folded into as-iosched.patch

-blk-fair-batches-2.patch

 Folded into blk-fair-batches.patch

+nbd-docco-update.patch

 NBD documentation

+cpumask_t-1.patch

 Support up to 255 CPUs

-div64-cleanup.patch

 Waiting for an update

+apci-nmi-watchdog-fix.patch

 ACPI triggers the NMI watchdog during poweroff.   Fix.

+fnup-stats.patch

 Some debug stuff which wasn't supposed to be here.

+bootmem-fixes.patch

 Minor bootmem fixes

+jiffies-include-fixes.patch

 Build fix

+epoll-optimisations.patch

 eventpoll warmups

+o1-interactivity.patch

 Con's scheduler tweaks

+fix-user-leak.patch

 Fix a possible memory leak

+mtd-build-fix.patch

 Build fix





All 116 patches:


linus.patch

mm.patch
  add -mmN to EXTRAVERSION

kgdb-ga.patch
  kgdb stub for ia32 (George Anzinger's one)

kgdb-use-ggdb.patch

kgdb-ga-docco-fixes.patch
  kgdb doc. edits/corrections

misc8.patch
  misc fixes

config_spinline.patch
  uninline spinlocks for profiling accuracy.

ppc64-pci-update.patch

ppc64-reloc_hide.patch

ppc64-semaphore-reimplementation.patch
  ppc64: use the ia32 semaphore implementation

sym-do-160.patch
  make the SYM driver do 160 MB/sec

x86_64-fixes.patch
  x86_64 fixes

delay-ksoftirqd-fallback.patch
  Try harded in IRQ context before falling back to ksoftirqd

fb-image-depth-fix.patch
  fbdev image depth fix

ds-09-vicam-usercopy-fix.patch
  vicam usercopy fix

buffer-debug.patch
  buffer.c debugging

ipcsem-speedup.patch
  ipc semaphore optimization

rcu-stats.patch
  RCU statistics reporting

mtrr-hang-fix.patch
  Fix mtrr-related hang

reslabify-pgds-and-pmds.patch
  re-slabify i386 pgd's and pmd's

intel8x0-cleanup.patch
  intel8x0 cleanups

bio-too-big-fix.patch
  Fix raid "bio too big" failures

linux-isp-2.patch

linux-isp-2-fix-again.patch
  lost feral fix

list_del-debug.patch
  list_del debug check

airo-schedule-fix.patch
  airo.c: don't sleep in atomic regions

xattr-cleanup.patch
  xattr: cleanups

xattr-sharing.patch
  xattr: blockdev inode selection fix

xattr-just-replace.patch
  xattr: update-in-place optimisation

xattr-fine-grained-locking-prep.patch
  xattrr: preparation for fine-grained locking

xattr-fine-grained-locking.patch
  xattr: fine-grained locking

resurrect-batch_requests.patch
  bring back the batch_requests function

kblockd.patch
  Create `kblockd' workqueue

cfq-infrastructure.patch

elevator-completion-api.patch
  elevator completion API

as-iosched.patch
  anticipatory I/O scheduler
  AS: pgbench improvement
  AS: discrete read fifo batches
  AS sync/async batches
  AS: hash removal fix
  AS jumbo patch (for SCSI and TCQ)
  AS: fix stupid thinko
  AS: no batch-antic-limit
  AS: autotune write batches
  AS: divide by zero fix
  AS: more HZ != 1000 fixes
  AS: update_write_batch tuning
  AS locking
  AS HZ fixes
  AS: fix a leak + more debugging
  AS: maybe repair performance drop of random read O_DIRECT
  AS: fix IBM's seek load

unplug-use-kblockd.patch
  Use kblockd for running request queues

per-queue-nr_requests.patch
  per queue nr_requests

blk-invert-watermarks.patch
  blk_congestion_wait threshold cleanup

blk-as-hint.patch
  blk-as-hint

get_request_wait-oom-fix.patch
  handle OOM in get_request_wait().

blk-fair-batches.patch
  blk-fair-batches
  blk fair batches #2

generic-io-contexts.patch
  generic io contexts

blk-request-batching.patch
  block request batching

get_io_context-fix.patch
  get_io_context fixes

blk-allocation-commentary.patch
  block allocation comments

blk-batching-throttle-fix.patch
  blk batch requests fix

blk-batching-cleanups.patch
  block batching cleanups

print-build-options-on-oops.patch
  print a few config options on oops

mmap-prefault.patch
  prefault of executable mmaps

show_task-free-stack-fix.patch
  show_task() fix and cleanup

put_task_struct-debug.patch

ia32-mknod64.patch
  mknod64 for ia32

ext2-64-bit-special-inodes.patch
  ext2: support for 64-bit device nodes

ext3-64-bit-special-inodes.patch
  ext3: support for 64-bit device nodes

64-bit-dev_t-kdev_t.patch
  64-bit dev_t and kdev_t

oops-dump-preceding-code.patch
  i386 oops output: dump preceding code

lockmeter.patch

invalidate_mmap_range.patch
  Interface to invalidate regions of mmaps

aio-mm-refcounting-fix.patch
  fix /proc mm_struct refcounting bug

aio-01-retry.patch
  AIO: Core retry infrastructure

io_submit_one-EINVAL-fix.patch
  Fix aio process hang on EINVAL

aio-02-lockpage_wq.patch
  AIO: Async page wait

aio-03-fs_read.patch
  AIO: Filesystem aio read

aio-04-buffer_wq.patch
  AIO: Async buffer wait

aio-05-fs_write.patch
  AIO: Filesystem aio write

aio-05-fs_write-fix.patch

aio-06-bread_wq.patch
  AIO: Async block read

aio-06-bread_wq-fix.patch

aio-07-ext2getblk_wq.patch
  AIO: Async get block for ext2

O_SYNC-speedup-2.patch
  speed up O_SYNC writes

aio-09-o_sync.patch
  aio O_SYNC

aio-10-BUG-fix.patch
  AIO: fix a BUG

aio-11-workqueue-flush.patch
  AIO: flush workqueues before destroying ioctx'es

aio-12-readahead.patch
  AIO: readahead fixes

aio-dio-no-readahead.patch
  aio O_DIRECT no readahead

lock_buffer_wq-fix.patch
  lock_buffer_wq fix

unuse_mm-locked.patch
  AIO: hold the context lock across unuse_mm

aio-take-task_lock.patch
  From: Suparna Bhattacharya <suparna@in.ibm.com>
  Subject: Re: 2.5.72-mm1 - Under heavy testing with AIO,.. vmstat seems to blow the kernel

vfsmount_lock.patch
  From: Maneesh Soni <maneesh@in.ibm.com>
  Subject: [patch 1/2] vfsmount_lock

sched-hot-balancing-fix.patch
  fix for CPU scheduler load distribution

truncate-pagefault-race-fix.patch
  Fix vmtruncate race and distributed filesystem race

truncate-pagefault-race-fix-fix.patch
  Make sure truncate fix has no race

sleepometer.patch
  sleep instrumentation

time-goes-backwards.patch
  demonstrate do_gettimeofday() going backwards

printk-oops-mangle-fix.patch
  disentangle printk's whilst oopsing on SMP

20-odirect_enable.patch

21-odirect_cruft.patch

22-read_proc.patch

23-write_proc.patch

24-commit_proc.patch

25-odirect.patch

nfs-O_DIRECT-always-enabled.patch
  Force CONFIG_NFS_DIRECTIO

seqcount-locking.patch
  i_size atomic access: infrastructure

i_size-atomic-access.patch
  i_size atomic access

aha152x-oops-fix.patch
  aha152X oops fixes

nbd-cleanups.patch
  NBD: cosmetic cleanups

nbd-enhanced-diagnostics.patch
  nbd: enhanced diagnostics support

nbd-remove-blksize-bits.patch
  nbd: remove unneeded blksize_bits field

nbd-kobject-oops-fix.patch
  nbd: initialise the embedded kobject

nbd-paranioa-cleanups.patch
  nbd: cleanup PARANOIA usage & code

nbd-locking-fixes.patch
  nbd: fix locking issues with ioctl UI

nbd-ioctl-compat.patch
  nbd: add compatibility with previous ioctl user interface

nbd-docco-update.patch
  NBD documentation update

cpumask_t-1.patch

acpismp-fix.patch
  ACPI_HT_ONLY acpismp=force

oomkill-if-free-swap.patch
  Don't skip oomkilling if there's free swap

exec_mmap-is-the-point-of-no-return.patch
  after exec_mmap(), exec cannot fail

apci-nmi-watchdog-fix.patch
  ACPI poweroff trigers the NMI watchdog

fnup-stats.patch

bootmem-fixes.patch
  bootmem.c cleanups

jiffies-include-fixes.patch
  jiffies include fixes

epoll-optimisations.patch
  epoll: microoptimisations

o1-interactivity.patch
  CPU scheduler interactivity patch

fix-user-leak.patch
  fix current->user->__count leak for processes

mtd-build-fix.patch
  MTD build fix for old gcc's




^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
@ 2003-07-03 10:37 ` Wiktor Wodecki
  2003-07-03 11:06   ` 2.5.74-mm1 Russell King
  2003-07-03 11:27   ` pcmcia problem [was: Re: 2.5.74-mm1] Wiktor Wodecki
  2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
                   ` (8 subsequent siblings)
  9 siblings, 2 replies; 147+ messages in thread
From: Wiktor Wodecki @ 2003-07-03 10:37 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel


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

On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/

On my thinkpad T20 it boots up fine, however when I insert my ne2000
pcmcia card it instantly freezes. No Ooops or log message at all.
2.5.73-mm1 did fine.

00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 03)
00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
00:03.0 Communication controller: Lucent Microelectronics WinModem 56k
(rev 01)
00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24
[CrystalClear SoundFusion Audio Accelerator] (rev 01)
00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev
11)


-- 
Regards,

Wiktor Wodecki

[-- Attachment #1.2: config --]
[-- Type: text/plain, Size: 25745 bytes --]

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_EMBEDDED is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_SMP is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_EDD=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y

#
# ACPI Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_HT_ONLY is not set
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
CONFIG_CPU_FREQ_TABLE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_YENTA=y
CONFIG_CARDBUS=y
CONFIG_I82092=y
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=y

#
# Generic Driver Options
#
# CONFIG_FW_LOADER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_NAMES=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDE_TCQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI device support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_FERAL_ISP is not set

#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
# CONFIG_IP_NF_MATCH_TOS is not set
CONFIG_IP_NF_MATCH_RECENT=y
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
# CONFIG_IP_NF_MATCH_AH_ESP is not set
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_TCPMSS is not set
# CONFIG_IP_NF_MATCH_HELPER is not set
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_UNCLEAN=y
# CONFIG_IP_NF_MATCH_OWNER is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
# CONFIG_IP_NF_ARP_MANGLE is not set
# CONFIG_IPV6 is not set
# CONFIG_XFRM_USER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_CSZ=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_SLIP=y
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices (depends on LLC=y)
#
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_FMVJ18X is not set
CONFIG_PCMCIA_PCNET=m
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_PCMCIA_AXNET is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
CONFIG_IRDA=y

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=y
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
# CONFIG_IRDA_CACHE_LAST_LSAP is not set
# CONFIG_IRDA_FAST_RR is not set
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=y

#
# Dongle support
#
# CONFIG_DONGLE is not set

#
# Old SIR device drivers
#
# CONFIG_IRTTY_OLD is not set
CONFIG_IRPORT_SIR=y

#
# Old Serial dongle support
#
# CONFIG_DONGLE_OLD is not set

#
# FIR device drivers
#
# CONFIG_USB_IRDA is not set
# CONFIG_NSC_FIR is not set
# CONFIG_WINBOND_FIR is not set
# CONFIG_TOSHIBA_OLD is not set
# CONFIG_TOSHIBA_FIR is not set
# CONFIG_SMC_IRCC_OLD is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
# CONFIG_SERIAL_8250_CS is not set
# CONFIG_SERIAL_8250_ACPI is not set
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
# CONFIG_I2C is not set

#
# I2C Hardware Sensors Mainboard support
#

#
# I2C Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set

#
# Mice
#
CONFIG_BUSMOUSE=y
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_SEQUENCER=y
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_AZT3328 is not set
CONFIG_SND_CS46XX=y
# CONFIG_SND_CS46XX_NEW_DSP is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
# CONFIG_SND_USB_AUDIO is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_VXP440 is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=y

#
# USB Device Class drivers
#
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_MIDI is not set
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
CONFIG_USB_STORAGE_HP8200e=y
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
# CONFIG_HID_PID is not set
# CONFIG_LOGITECH_FF is not set
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# CONFIG_USB_AX8817X is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GADGET is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_SPINLINE is not set
# CONFIG_KALLSYMS is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_KGDB is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_SLEEPOMETER is not set

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_BIOS_REBOOT=y

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

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile)
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
  2003-07-03 10:37 ` 2.5.74-mm1 Wiktor Wodecki
@ 2003-07-03 10:45 ` Dumitru Ciobarcianu
  2003-07-03 11:07   ` William Lee Irwin III
  2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
                   ` (7 subsequent siblings)
  9 siblings, 1 reply; 147+ messages in thread
From: Dumitru Ciobarcianu @ 2003-07-03 10:45 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm


Here are the errors:

  CC      arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In function `cpufreq_p4_setdc':
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:67: error: incompatible types in assignment
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:78: error: incompatible type for argument 2 of `set_cpus_allowed'
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:90: error: incompatible type for argument 2 of `set_cpus_allowed'
arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:131: error: incompatible type for argument 2 of `set_cpus_allowed'
make[3]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Error 1
make[2]: *** [arch/i386/kernel/cpu/cpufreq] Error 2
make[1]: *** [arch/i386/kernel/cpu] Error 2
make: *** [arch/i386/kernel] Error 2





^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 10:37 ` 2.5.74-mm1 Wiktor Wodecki
@ 2003-07-03 11:06   ` Russell King
  2003-07-03 14:15     ` 2.5.74-mm1 Russell King
  2003-07-03 11:27   ` pcmcia problem [was: Re: 2.5.74-mm1] Wiktor Wodecki
  1 sibling, 1 reply; 147+ messages in thread
From: Russell King @ 2003-07-03 11:06 UTC (permalink / raw)
  To: Wiktor Wodecki; +Cc: Andrew Morton, linux-kernel

On Thu, Jul 03, 2003 at 12:37:03PM +0200, Wiktor Wodecki wrote:
> On my thinkpad T20 it boots up fine, however when I insert my ne2000
> pcmcia card it instantly freezes. No Ooops or log message at all.
> 2.5.73-mm1 did fine.

Grr.

Can you try taking off each patch in reverse order at:

	http://patches.arm.linux.org.uk/pcmcia/pcmcia-event-20030623-*

and seeing which one caused your problem?

Thanks.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile)
  2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
@ 2003-07-03 11:07   ` William Lee Irwin III
  2003-07-03 11:17     ` Dumitru Ciobarcianu
  0 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-03 11:07 UTC (permalink / raw)
  To: Dumitru Ciobarcianu; +Cc: Andrew Morton, linux-kernel, linux-mm

On Thu, Jul 03, 2003 at 01:45:41PM +0300, Dumitru Ciobarcianu wrote:
> Here are the errors:
>   CC      arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In function `cpufreq_p4_setdc':
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:67: error: incompatible types in assignment
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:78: error: incompatible type for argument 2 of `set_cpus_allowed'
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:90: error: incompatible type for argument 2 of `set_cpus_allowed'
> arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:131: error: incompatible type for argument 2 of `set_cpus_allowed'
> make[3]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Error 1
> make[2]: *** [arch/i386/kernel/cpu/cpufreq] Error 2
> make[1]: *** [arch/i386/kernel/cpu] Error 2
> make: *** [arch/i386/kernel] Error 2

Would something like this help?

-- wli

===== arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 1.16 vs edited =====
--- 1.16/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	Mon May 12 21:23:13 2003
+++ edited/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	Thu Jul  3 04:07:01 2003
@@ -53,10 +53,9 @@
 static int cpufreq_p4_setdc(unsigned int cpu, unsigned int newstate)
 {
 	u32 l, h;
-	unsigned long cpus_allowed;
+	cpumask_t cpus_allowed, affected_cpu_map;
 	struct cpufreq_freqs freqs;
 	int hyperthreading = 0;
-	int affected_cpu_map = 0;
 	int sibling = 0;
 
 	if (!cpu_online(cpu) || (newstate > DC_DISABLE) || 
@@ -67,16 +66,17 @@
 	cpus_allowed = current->cpus_allowed;
 
 	/* only run on CPU to be set, or on its sibling */
-	affected_cpu_map = 1 << cpu;
+	affected_cpu_map = cpumask_of_cpu(cpu);
 #ifdef CONFIG_X86_HT
 	hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
 	if (hyperthreading) {
 		sibling = cpu_sibling_map[cpu];
-		affected_cpu_map |= (1 << sibling);
+		cpu_set(sibling, affected_cpu_map);
 	}
 #endif
 	set_cpus_allowed(current, affected_cpu_map);
 	BUG_ON(!(affected_cpu_map & (1 << smp_processor_id())));
+	BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
 
 	/* get current state */
 	rdmsr(MSR_IA32_THERM_CONTROL, l, h);

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile)
  2003-07-03 11:07   ` William Lee Irwin III
@ 2003-07-03 11:17     ` Dumitru Ciobarcianu
  2003-07-03 11:20       ` William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Dumitru Ciobarcianu @ 2003-07-03 11:17 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm


I had to mannually change the file (the patch was giving rejects), but
it compiles now.

Thanks

//Cioby



On Thu, 2003-07-03 at 14:07, William Lee Irwin III wrote:
> On Thu, Jul 03, 2003 at 01:45:41PM +0300, Dumitru Ciobarcianu wrote:
> > Here are the errors:
> >   CC      arch/i386/kernel/cpu/cpufreq/p4-clockmod.o
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c: In function `cpufreq_p4_setdc':
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:67: error: incompatible types in assignment
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:78: error: incompatible type for argument 2 of `set_cpus_allowed'
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:90: error: incompatible type for argument 2 of `set_cpus_allowed'
> > arch/i386/kernel/cpu/cpufreq/p4-clockmod.c:131: error: incompatible type for argument 2 of `set_cpus_allowed'
> > make[3]: *** [arch/i386/kernel/cpu/cpufreq/p4-clockmod.o] Error 1
> > make[2]: *** [arch/i386/kernel/cpu/cpufreq] Error 2
> > make[1]: *** [arch/i386/kernel/cpu] Error 2
> > make: *** [arch/i386/kernel] Error 2
> 
> Would something like this help?
> 
> -- wli
> 
> ===== arch/i386/kernel/cpu/cpufreq/p4-clockmod.c 1.16 vs edited =====
> --- 1.16/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	Mon May 12 21:23:13 2003
> +++ edited/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	Thu Jul  3 04:07:01 2003
> @@ -53,10 +53,9 @@
>  static int cpufreq_p4_setdc(unsigned int cpu, unsigned int newstate)
>  {
>  	u32 l, h;
> -	unsigned long cpus_allowed;
> +	cpumask_t cpus_allowed, affected_cpu_map;
>  	struct cpufreq_freqs freqs;
>  	int hyperthreading = 0;
> -	int affected_cpu_map = 0;
>  	int sibling = 0;
>  
>  	if (!cpu_online(cpu) || (newstate > DC_DISABLE) || 
> @@ -67,16 +66,17 @@
>  	cpus_allowed = current->cpus_allowed;
>  
>  	/* only run on CPU to be set, or on its sibling */
> -	affected_cpu_map = 1 << cpu;
> +	affected_cpu_map = cpumask_of_cpu(cpu);
>  #ifdef CONFIG_X86_HT
>  	hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
>  	if (hyperthreading) {
>  		sibling = cpu_sibling_map[cpu];
> -		affected_cpu_map |= (1 << sibling);
> +		cpu_set(sibling, affected_cpu_map);
>  	}
>  #endif
>  	set_cpus_allowed(current, affected_cpu_map);
>  	BUG_ON(!(affected_cpu_map & (1 << smp_processor_id())));
> +	BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
>  
>  	/* get current state */
>  	rdmsr(MSR_IA32_THERM_CONTROL, l, h);
-- 
Cioby


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile)
  2003-07-03 11:17     ` Dumitru Ciobarcianu
@ 2003-07-03 11:20       ` William Lee Irwin III
  2003-07-03 11:32         ` 2.5.74-mm1 (p4-clockmod does not compile) PATCH Dumitru Ciobarcianu
  2003-07-07  5:24         ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
  0 siblings, 2 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-03 11:20 UTC (permalink / raw)
  To: Dumitru Ciobarcianu; +Cc: Andrew Morton, linux-kernel, linux-mm

On Thu, Jul 03, 2003 at 02:17:48PM +0300, Dumitru Ciobarcianu wrote:
> I had to mannually change the file (the patch was giving rejects), but
> it compiles now.

Great! Could you send back the diff? (or alternatively, the file
contents if you didn't preserve the old contents) so I can send the
proper diff upstream?


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* pcmcia problem [was: Re: 2.5.74-mm1]
  2003-07-03 10:37 ` 2.5.74-mm1 Wiktor Wodecki
  2003-07-03 11:06   ` 2.5.74-mm1 Russell King
@ 2003-07-03 11:27   ` Wiktor Wodecki
  1 sibling, 0 replies; 147+ messages in thread
From: Wiktor Wodecki @ 2003-07-03 11:27 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

correction, this happens on plain 2.5.74, too

On Thu, Jul 03, 2003 at 12:37:03PM +0200, Wiktor Wodecki wrote:
> On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
> 
> On my thinkpad T20 it boots up fine, however when I insert my ne2000
> pcmcia card it instantly freezes. No Ooops or log message at all.
> 2.5.73-mm1 did fine.
> 
> 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
> (rev 03)
> 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
> (rev 03)
> 00:02.0 CardBus bridge: Texas Instruments PCI1450 (rev 03)
> 00:02.1 CardBus bridge: Texas Instruments PCI1450 (rev 03)
> 00:03.0 Communication controller: Lucent Microelectronics WinModem 56k
> (rev 01)
> 00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24
> [CrystalClear SoundFusion Audio Accelerator] (rev 01)
> 00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
> 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
> 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
> 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
> 01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev
> 11)
> 
> 
> -- 
> Regards,
> 
> Wiktor Wodecki

> #
> # Automatically generated make config: don't edit
> #
> CONFIG_X86=y
> CONFIG_MMU=y
> CONFIG_UID16=y
> CONFIG_GENERIC_ISA_DMA=y
> 
> #
> # Code maturity level options
> #
> CONFIG_EXPERIMENTAL=y
> 
> #
> # General setup
> #
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> # CONFIG_BSD_PROCESS_ACCT is not set
> CONFIG_SYSCTL=y
> CONFIG_LOG_BUF_SHIFT=14
> # CONFIG_EMBEDDED is not set
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> 
> #
> # Loadable module support
> #
> CONFIG_MODULES=y
> CONFIG_MODULE_UNLOAD=y
> # CONFIG_MODULE_FORCE_UNLOAD is not set
> CONFIG_OBSOLETE_MODPARM=y
> # CONFIG_MODVERSIONS is not set
> CONFIG_KMOD=y
> 
> #
> # Processor type and features
> #
> CONFIG_X86_PC=y
> # CONFIG_X86_VOYAGER is not set
> # CONFIG_X86_NUMAQ is not set
> # CONFIG_X86_SUMMIT is not set
> # CONFIG_X86_BIGSMP is not set
> # CONFIG_X86_VISWS is not set
> # CONFIG_X86_GENERICARCH is not set
> # CONFIG_X86_ES7000 is not set
> # CONFIG_M386 is not set
> # CONFIG_M486 is not set
> # CONFIG_M586 is not set
> # CONFIG_M586TSC is not set
> # CONFIG_M586MMX is not set
> # CONFIG_M686 is not set
> # CONFIG_MPENTIUMII is not set
> CONFIG_MPENTIUMIII=y
> # CONFIG_MPENTIUM4 is not set
> # CONFIG_MK6 is not set
> # CONFIG_MK7 is not set
> # CONFIG_MK8 is not set
> # CONFIG_MELAN is not set
> # CONFIG_MCRUSOE is not set
> # CONFIG_MWINCHIPC6 is not set
> # CONFIG_MWINCHIP2 is not set
> # CONFIG_MWINCHIP3D is not set
> # CONFIG_MCYRIXIII is not set
> # CONFIG_MVIAC3_2 is not set
> # CONFIG_X86_GENERIC is not set
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_XADD=y
> CONFIG_X86_L1_CACHE_SHIFT=5
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> CONFIG_X86_GOOD_APIC=y
> CONFIG_X86_INTEL_USERCOPY=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> # CONFIG_HUGETLB_PAGE is not set
> # CONFIG_SMP is not set
> CONFIG_PREEMPT=y
> CONFIG_X86_UP_APIC=y
> CONFIG_X86_UP_IOAPIC=y
> CONFIG_X86_LOCAL_APIC=y
> CONFIG_X86_IO_APIC=y
> CONFIG_X86_TSC=y
> CONFIG_X86_MCE=y
> CONFIG_X86_MCE_NONFATAL=y
> # CONFIG_X86_MCE_P4THERMAL is not set
> # CONFIG_TOSHIBA is not set
> # CONFIG_I8K is not set
> CONFIG_MICROCODE=y
> CONFIG_X86_MSR=y
> CONFIG_X86_CPUID=y
> CONFIG_EDD=y
> CONFIG_NOHIGHMEM=y
> # CONFIG_HIGHMEM4G is not set
> # CONFIG_HIGHMEM64G is not set
> # CONFIG_MATH_EMULATION is not set
> CONFIG_MTRR=y
> CONFIG_HAVE_DEC_LOCK=y
> 
> #
> # Power management options (ACPI, APM)
> #
> CONFIG_PM=y
> CONFIG_SOFTWARE_SUSPEND=y
> 
> #
> # ACPI Support
> #
> CONFIG_ACPI=y
> # CONFIG_ACPI_HT_ONLY is not set
> CONFIG_ACPI_BOOT=y
> CONFIG_ACPI_SLEEP=y
> CONFIG_ACPI_SLEEP_PROC_FS=y
> CONFIG_ACPI_AC=y
> CONFIG_ACPI_BATTERY=y
> CONFIG_ACPI_BUTTON=y
> CONFIG_ACPI_FAN=y
> CONFIG_ACPI_PROCESSOR=y
> CONFIG_ACPI_THERMAL=y
> # CONFIG_ACPI_ASUS is not set
> # CONFIG_ACPI_TOSHIBA is not set
> # CONFIG_ACPI_DEBUG is not set
> CONFIG_ACPI_BUS=y
> CONFIG_ACPI_INTERPRETER=y
> CONFIG_ACPI_EC=y
> CONFIG_ACPI_POWER=y
> CONFIG_ACPI_PCI=y
> CONFIG_ACPI_SYSTEM=y
> # CONFIG_APM is not set
> 
> #
> # CPU Frequency scaling
> #
> CONFIG_CPU_FREQ=y
> # CONFIG_CPU_FREQ_PROC_INTF is not set
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
> # CONFIG_CPU_FREQ_24_API is not set
> CONFIG_CPU_FREQ_TABLE=y
> 
> #
> # CPUFreq processor drivers
> #
> CONFIG_X86_ACPI_CPUFREQ=y
> # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
> # CONFIG_X86_POWERNOW_K6 is not set
> # CONFIG_X86_POWERNOW_K7 is not set
> # CONFIG_X86_GX_SUSPMOD is not set
> CONFIG_X86_SPEEDSTEP_ICH=y
> CONFIG_X86_SPEEDSTEP_CENTRINO=y
> CONFIG_X86_SPEEDSTEP_LIB=y
> # CONFIG_X86_P4_CLOCKMOD is not set
> # CONFIG_X86_LONGRUN is not set
> # CONFIG_X86_LONGHAUL is not set
> 
> #
> # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
> #
> CONFIG_PCI=y
> # CONFIG_PCI_GOBIOS is not set
> # CONFIG_PCI_GODIRECT is not set
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> # CONFIG_PCI_LEGACY_PROC is not set
> CONFIG_PCI_NAMES=y
> CONFIG_ISA=y
> # CONFIG_EISA is not set
> # CONFIG_MCA is not set
> # CONFIG_SCx200 is not set
> CONFIG_HOTPLUG=y
> 
> #
> # PCMCIA/CardBus support
> #
> CONFIG_PCMCIA=y
> CONFIG_YENTA=y
> CONFIG_CARDBUS=y
> CONFIG_I82092=y
> # CONFIG_I82365 is not set
> # CONFIG_TCIC is not set
> CONFIG_PCMCIA_PROBE=y
> 
> #
> # PCI Hotplug Support
> #
> # CONFIG_HOTPLUG_PCI is not set
> 
> #
> # Executable file formats
> #
> CONFIG_KCORE_ELF=y
> # CONFIG_KCORE_AOUT is not set
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_AOUT=m
> CONFIG_BINFMT_MISC=y
> 
> #
> # Generic Driver Options
> #
> # CONFIG_FW_LOADER is not set
> 
> #
> # Memory Technology Devices (MTD)
> #
> # CONFIG_MTD is not set
> 
> #
> # Parallel port support
> #
> # CONFIG_PARPORT is not set
> 
> #
> # Plug and Play support
> #
> CONFIG_PNP=y
> CONFIG_PNP_NAMES=y
> # CONFIG_PNP_DEBUG is not set
> 
> #
> # Protocols
> #
> CONFIG_ISAPNP=y
> CONFIG_PNPBIOS=y
> 
> #
> # Block devices
> #
> CONFIG_BLK_DEV_FD=m
> # CONFIG_BLK_DEV_XD is not set
> # CONFIG_BLK_CPQ_DA is not set
> # CONFIG_BLK_CPQ_CISS_DA is not set
> # CONFIG_BLK_DEV_DAC960 is not set
> # CONFIG_BLK_DEV_UMEM is not set
> CONFIG_BLK_DEV_LOOP=m
> # CONFIG_BLK_DEV_NBD is not set
> # CONFIG_BLK_DEV_RAM is not set
> # CONFIG_BLK_DEV_INITRD is not set
> # CONFIG_LBD is not set
> 
> #
> # ATA/ATAPI/MFM/RLL support
> #
> CONFIG_IDE=y
> 
> #
> # IDE, ATA and ATAPI Block devices
> #
> CONFIG_BLK_DEV_IDE=y
> 
> #
> # Please see Documentation/ide.txt for help/info on IDE drives
> #
> # CONFIG_BLK_DEV_HD_IDE is not set
> # CONFIG_BLK_DEV_HD is not set
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> # CONFIG_IDEDISK_STROKE is not set
> CONFIG_BLK_DEV_IDECS=m
> CONFIG_BLK_DEV_IDECD=m
> # CONFIG_BLK_DEV_IDEFLOPPY is not set
> # CONFIG_BLK_DEV_IDESCSI is not set
> # CONFIG_IDE_TASK_IOCTL is not set
> CONFIG_IDE_TASKFILE_IO=y
> 
> #
> # IDE chipset support/bugfixes
> #
> # CONFIG_BLK_DEV_CMD640 is not set
> # CONFIG_BLK_DEV_IDEPNP is not set
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_BLK_DEV_GENERIC=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_IDE_TCQ is not set
> # CONFIG_BLK_DEV_OFFBOARD is not set
> # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_IDEDMA_ONLYDISK=y
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_IDEDMA_PCI_WIP is not set
> CONFIG_BLK_DEV_ADMA=y
> # CONFIG_BLK_DEV_AEC62XX is not set
> # CONFIG_BLK_DEV_ALI15X3 is not set
> # CONFIG_BLK_DEV_AMD74XX is not set
> # CONFIG_BLK_DEV_CMD64X is not set
> # CONFIG_BLK_DEV_TRIFLEX is not set
> # CONFIG_BLK_DEV_CY82C693 is not set
> # CONFIG_BLK_DEV_CS5520 is not set
> # CONFIG_BLK_DEV_HPT34X is not set
> # CONFIG_BLK_DEV_HPT366 is not set
> # CONFIG_BLK_DEV_SC1200 is not set
> CONFIG_BLK_DEV_PIIX=y
> # CONFIG_BLK_DEV_NS87415 is not set
> # CONFIG_BLK_DEV_OPTI621 is not set
> # CONFIG_BLK_DEV_PDC202XX_OLD is not set
> # CONFIG_BLK_DEV_PDC202XX_NEW is not set
> # CONFIG_BLK_DEV_RZ1000 is not set
> # CONFIG_BLK_DEV_SVWKS is not set
> # CONFIG_BLK_DEV_SIIMAGE is not set
> # CONFIG_BLK_DEV_SIS5513 is not set
> # CONFIG_BLK_DEV_SLC90E66 is not set
> # CONFIG_BLK_DEV_TRM290 is not set
> # CONFIG_BLK_DEV_VIA82CXXX is not set
> # CONFIG_IDE_CHIPSETS is not set
> CONFIG_IDEDMA_AUTO=y
> # CONFIG_IDEDMA_IVB is not set
> CONFIG_BLK_DEV_IDE_MODES=y
> 
> #
> # SCSI device support
> #
> CONFIG_SCSI=m
> 
> #
> # SCSI support type (disk, tape, CD-ROM)
> #
> CONFIG_BLK_DEV_SD=m
> CONFIG_CHR_DEV_ST=m
> # CONFIG_CHR_DEV_OSST is not set
> CONFIG_BLK_DEV_SR=m
> # CONFIG_BLK_DEV_SR_VENDOR is not set
> CONFIG_CHR_DEV_SG=m
> 
> #
> # Some SCSI devices (e.g. CD jukebox) support multiple LUNs
> #
> CONFIG_SCSI_MULTI_LUN=y
> CONFIG_SCSI_REPORT_LUNS=y
> # CONFIG_SCSI_CONSTANTS is not set
> # CONFIG_SCSI_LOGGING is not set
> 
> #
> # SCSI low-level drivers
> #
> # CONFIG_BLK_DEV_3W_XXXX_RAID is not set
> # CONFIG_SCSI_7000FASST is not set
> # CONFIG_SCSI_ACARD is not set
> # CONFIG_SCSI_AHA152X is not set
> # CONFIG_SCSI_AHA1542 is not set
> # CONFIG_SCSI_AACRAID is not set
> # CONFIG_SCSI_AIC7XXX is not set
> # CONFIG_SCSI_AIC7XXX_OLD is not set
> # CONFIG_SCSI_AIC79XX is not set
> # CONFIG_SCSI_DPT_I2O is not set
> # CONFIG_SCSI_ADVANSYS is not set
> # CONFIG_SCSI_IN2000 is not set
> # CONFIG_SCSI_AM53C974 is not set
> # CONFIG_SCSI_MEGARAID is not set
> # CONFIG_SCSI_BUSLOGIC is not set
> # CONFIG_SCSI_CPQFCTS is not set
> # CONFIG_SCSI_DMX3191D is not set
> # CONFIG_SCSI_DTC3280 is not set
> # CONFIG_SCSI_EATA is not set
> # CONFIG_SCSI_EATA_PIO is not set
> # CONFIG_SCSI_FUTURE_DOMAIN is not set
> # CONFIG_SCSI_GDTH is not set
> # CONFIG_SCSI_GENERIC_NCR5380 is not set
> # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
> # CONFIG_SCSI_IPS is not set
> # CONFIG_SCSI_INITIO is not set
> # CONFIG_SCSI_INIA100 is not set
> # CONFIG_SCSI_NCR53C406A is not set
> # CONFIG_SCSI_SYM53C8XX_2 is not set
> # CONFIG_SCSI_SYM53C8XX is not set
> # CONFIG_SCSI_PAS16 is not set
> # CONFIG_SCSI_PCI2000 is not set
> # CONFIG_SCSI_PCI2220I is not set
> # CONFIG_SCSI_PSI240I is not set
> # CONFIG_SCSI_QLOGIC_FAS is not set
> # CONFIG_SCSI_QLOGIC_ISP is not set
> # CONFIG_SCSI_QLOGIC_FC is not set
> # CONFIG_SCSI_QLOGIC_1280 is not set
> # CONFIG_SCSI_SEAGATE is not set
> # CONFIG_SCSI_SYM53C416 is not set
> # CONFIG_SCSI_DC395x is not set
> # CONFIG_SCSI_DC390T is not set
> # CONFIG_SCSI_T128 is not set
> # CONFIG_SCSI_U14_34F is not set
> # CONFIG_SCSI_ULTRASTOR is not set
> # CONFIG_SCSI_NSP32 is not set
> # CONFIG_SCSI_DEBUG is not set
> # CONFIG_SCSI_FERAL_ISP is not set
> 
> #
> # PCMCIA SCSI adapter support
> #
> # CONFIG_PCMCIA_AHA152X is not set
> # CONFIG_PCMCIA_FDOMAIN is not set
> # CONFIG_PCMCIA_NINJA_SCSI is not set
> # CONFIG_PCMCIA_QLOGIC is not set
> 
> #
> # Old CD-ROM drivers (not SCSI, not IDE)
> #
> # CONFIG_CD_NO_IDESCSI is not set
> 
> #
> # Multi-device support (RAID and LVM)
> #
> # CONFIG_MD is not set
> 
> #
> # Fusion MPT device support
> #
> # CONFIG_FUSION is not set
> 
> #
> # IEEE 1394 (FireWire) support (EXPERIMENTAL)
> #
> # CONFIG_IEEE1394 is not set
> 
> #
> # I2O device support
> #
> # CONFIG_I2O is not set
> 
> #
> # Networking support
> #
> CONFIG_NET=y
> 
> #
> # Networking options
> #
> CONFIG_PACKET=y
> CONFIG_PACKET_MMAP=y
> CONFIG_NETLINK_DEV=m
> CONFIG_NETFILTER=y
> # CONFIG_NETFILTER_DEBUG is not set
> CONFIG_UNIX=y
> # CONFIG_NET_KEY is not set
> CONFIG_INET=y
> CONFIG_IP_MULTICAST=y
> # CONFIG_IP_ADVANCED_ROUTER is not set
> # CONFIG_IP_PNP is not set
> # CONFIG_NET_IPIP is not set
> # CONFIG_NET_IPGRE is not set
> # CONFIG_IP_MROUTE is not set
> # CONFIG_ARPD is not set
> CONFIG_INET_ECN=y
> CONFIG_SYN_COOKIES=y
> # CONFIG_INET_AH is not set
> # CONFIG_INET_ESP is not set
> # CONFIG_INET_IPCOMP is not set
> 
> #
> # IP: Netfilter Configuration
> #
> CONFIG_IP_NF_CONNTRACK=y
> CONFIG_IP_NF_FTP=y
> CONFIG_IP_NF_IRC=y
> # CONFIG_IP_NF_TFTP is not set
> # CONFIG_IP_NF_AMANDA is not set
> CONFIG_IP_NF_QUEUE=m
> CONFIG_IP_NF_IPTABLES=y
> CONFIG_IP_NF_MATCH_LIMIT=m
> CONFIG_IP_NF_MATCH_MAC=y
> CONFIG_IP_NF_MATCH_PKTTYPE=y
> CONFIG_IP_NF_MATCH_MARK=y
> CONFIG_IP_NF_MATCH_MULTIPORT=y
> # CONFIG_IP_NF_MATCH_TOS is not set
> CONFIG_IP_NF_MATCH_RECENT=y
> # CONFIG_IP_NF_MATCH_ECN is not set
> # CONFIG_IP_NF_MATCH_DSCP is not set
> # CONFIG_IP_NF_MATCH_AH_ESP is not set
> # CONFIG_IP_NF_MATCH_LENGTH is not set
> # CONFIG_IP_NF_MATCH_TTL is not set
> # CONFIG_IP_NF_MATCH_TCPMSS is not set
> # CONFIG_IP_NF_MATCH_HELPER is not set
> CONFIG_IP_NF_MATCH_STATE=y
> CONFIG_IP_NF_MATCH_CONNTRACK=y
> CONFIG_IP_NF_MATCH_UNCLEAN=y
> # CONFIG_IP_NF_MATCH_OWNER is not set
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_REJECT=y
> CONFIG_IP_NF_TARGET_MIRROR=m
> CONFIG_IP_NF_NAT=m
> CONFIG_IP_NF_NAT_NEEDED=y
> CONFIG_IP_NF_TARGET_MASQUERADE=m
> CONFIG_IP_NF_TARGET_REDIRECT=m
> # CONFIG_IP_NF_NAT_LOCAL is not set
> CONFIG_IP_NF_NAT_SNMP_BASIC=m
> CONFIG_IP_NF_NAT_IRC=m
> CONFIG_IP_NF_NAT_FTP=m
> CONFIG_IP_NF_MANGLE=y
> CONFIG_IP_NF_TARGET_TOS=y
> CONFIG_IP_NF_TARGET_ECN=y
> CONFIG_IP_NF_TARGET_DSCP=m
> CONFIG_IP_NF_TARGET_MARK=y
> CONFIG_IP_NF_TARGET_LOG=y
> CONFIG_IP_NF_TARGET_ULOG=m
> CONFIG_IP_NF_TARGET_TCPMSS=m
> CONFIG_IP_NF_ARPTABLES=m
> CONFIG_IP_NF_ARPFILTER=m
> # CONFIG_IP_NF_ARP_MANGLE is not set
> # CONFIG_IPV6 is not set
> # CONFIG_XFRM_USER is not set
> 
> #
> # SCTP Configuration (EXPERIMENTAL)
> #
> CONFIG_IPV6_SCTP__=y
> # CONFIG_IP_SCTP is not set
> # CONFIG_ATM is not set
> # CONFIG_VLAN_8021Q is not set
> # CONFIG_LLC is not set
> # CONFIG_DECNET is not set
> # CONFIG_BRIDGE is not set
> # CONFIG_X25 is not set
> # CONFIG_LAPB is not set
> # CONFIG_NET_DIVERT is not set
> # CONFIG_ECONET is not set
> # CONFIG_WAN_ROUTER is not set
> # CONFIG_NET_FASTROUTE is not set
> # CONFIG_NET_HW_FLOWCONTROL is not set
> 
> #
> # QoS and/or fair queueing
> #
> CONFIG_NET_SCHED=y
> CONFIG_NET_SCH_CBQ=y
> CONFIG_NET_SCH_HTB=y
> CONFIG_NET_SCH_CSZ=y
> CONFIG_NET_SCH_PRIO=y
> CONFIG_NET_SCH_RED=y
> CONFIG_NET_SCH_SFQ=y
> CONFIG_NET_SCH_TEQL=y
> CONFIG_NET_SCH_TBF=m
> CONFIG_NET_SCH_GRED=m
> CONFIG_NET_SCH_DSMARK=m
> # CONFIG_NET_SCH_INGRESS is not set
> CONFIG_NET_QOS=y
> CONFIG_NET_ESTIMATOR=y
> CONFIG_NET_CLS=y
> CONFIG_NET_CLS_TCINDEX=y
> CONFIG_NET_CLS_ROUTE4=y
> CONFIG_NET_CLS_ROUTE=y
> CONFIG_NET_CLS_FW=y
> CONFIG_NET_CLS_U32=y
> CONFIG_NET_CLS_RSVP=m
> CONFIG_NET_CLS_RSVP6=m
> CONFIG_NET_CLS_POLICE=y
> 
> #
> # Network testing
> #
> # CONFIG_NET_PKTGEN is not set
> CONFIG_NETDEVICES=y
> 
> #
> # ARCnet devices
> #
> # CONFIG_ARCNET is not set
> # CONFIG_DUMMY is not set
> # CONFIG_BONDING is not set
> # CONFIG_EQUALIZER is not set
> # CONFIG_TUN is not set
> # CONFIG_ETHERTAP is not set
> # CONFIG_NET_SB1000 is not set
> 
> #
> # Ethernet (10 or 100Mbit)
> #
> # CONFIG_NET_ETHERNET is not set
> 
> #
> # Ethernet (1000 Mbit)
> #
> # CONFIG_ACENIC is not set
> # CONFIG_DL2K is not set
> # CONFIG_E1000 is not set
> # CONFIG_NS83820 is not set
> # CONFIG_HAMACHI is not set
> # CONFIG_YELLOWFIN is not set
> # CONFIG_R8169 is not set
> # CONFIG_SK98LIN is not set
> # CONFIG_TIGON3 is not set
> 
> #
> # Ethernet (10000 Mbit)
> #
> # CONFIG_IXGB is not set
> # CONFIG_FDDI is not set
> # CONFIG_HIPPI is not set
> CONFIG_PPP=m
> CONFIG_PPP_MULTILINK=y
> CONFIG_PPP_FILTER=y
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_SYNC_TTY=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_BSDCOMP=m
> CONFIG_PPPOE=m
> CONFIG_SLIP=y
> CONFIG_SLIP_COMPRESSED=y
> CONFIG_SLIP_SMART=y
> CONFIG_SLIP_MODE_SLIP6=y
> 
> #
> # Wireless LAN (non-hamradio)
> #
> # CONFIG_NET_RADIO is not set
> 
> #
> # Token Ring devices (depends on LLC=y)
> #
> # CONFIG_NET_FC is not set
> # CONFIG_RCPCI is not set
> # CONFIG_SHAPER is not set
> 
> #
> # Wan interfaces
> #
> # CONFIG_WAN is not set
> 
> #
> # PCMCIA network device support
> #
> CONFIG_NET_PCMCIA=y
> # CONFIG_PCMCIA_3C589 is not set
> # CONFIG_PCMCIA_3C574 is not set
> # CONFIG_PCMCIA_FMVJ18X is not set
> CONFIG_PCMCIA_PCNET=m
> # CONFIG_PCMCIA_NMCLAN is not set
> # CONFIG_PCMCIA_SMC91C92 is not set
> # CONFIG_PCMCIA_XIRC2PS is not set
> # CONFIG_PCMCIA_AXNET is not set
> 
> #
> # Amateur Radio support
> #
> # CONFIG_HAMRADIO is not set
> 
> #
> # IrDA (infrared) support
> #
> CONFIG_IRDA=y
> 
> #
> # IrDA protocols
> #
> CONFIG_IRLAN=m
> CONFIG_IRNET=m
> CONFIG_IRCOMM=y
> # CONFIG_IRDA_ULTRA is not set
> 
> #
> # IrDA options
> #
> # CONFIG_IRDA_CACHE_LAST_LSAP is not set
> # CONFIG_IRDA_FAST_RR is not set
> # CONFIG_IRDA_DEBUG is not set
> 
> #
> # Infrared-port device drivers
> #
> 
> #
> # SIR device drivers
> #
> CONFIG_IRTTY_SIR=y
> 
> #
> # Dongle support
> #
> # CONFIG_DONGLE is not set
> 
> #
> # Old SIR device drivers
> #
> # CONFIG_IRTTY_OLD is not set
> CONFIG_IRPORT_SIR=y
> 
> #
> # Old Serial dongle support
> #
> # CONFIG_DONGLE_OLD is not set
> 
> #
> # FIR device drivers
> #
> # CONFIG_USB_IRDA is not set
> # CONFIG_NSC_FIR is not set
> # CONFIG_WINBOND_FIR is not set
> # CONFIG_TOSHIBA_OLD is not set
> # CONFIG_TOSHIBA_FIR is not set
> # CONFIG_SMC_IRCC_OLD is not set
> # CONFIG_SMC_IRCC_FIR is not set
> # CONFIG_ALI_FIR is not set
> # CONFIG_VLSI_FIR is not set
> 
> #
> # ISDN subsystem
> #
> # CONFIG_ISDN_BOOL is not set
> 
> #
> # Telephony Support
> #
> # CONFIG_PHONE is not set
> 
> #
> # Input device support
> #
> CONFIG_INPUT=y
> 
> #
> # Userland interfaces
> #
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_PSAUX=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
> # CONFIG_INPUT_JOYDEV is not set
> # CONFIG_INPUT_TSDEV is not set
> # CONFIG_INPUT_EVDEV is not set
> # CONFIG_INPUT_EVBUG is not set
> 
> #
> # Input I/O drivers
> #
> # CONFIG_GAMEPORT is not set
> CONFIG_SOUND_GAMEPORT=y
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> # CONFIG_SERIO_SERPORT is not set
> # CONFIG_SERIO_CT82C710 is not set
> # CONFIG_SERIO_PCIPS2 is not set
> 
> #
> # Input Device Drivers
> #
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> # CONFIG_KEYBOARD_SUNKBD is not set
> # CONFIG_KEYBOARD_XTKBD is not set
> # CONFIG_KEYBOARD_NEWTON is not set
> CONFIG_INPUT_MOUSE=y
> CONFIG_MOUSE_PS2=y
> # CONFIG_MOUSE_SERIAL is not set
> # CONFIG_MOUSE_INPORT is not set
> # CONFIG_MOUSE_LOGIBM is not set
> # CONFIG_MOUSE_PC110PAD is not set
> # CONFIG_INPUT_JOYSTICK is not set
> # CONFIG_INPUT_TOUCHSCREEN is not set
> # CONFIG_INPUT_MISC is not set
> 
> #
> # Character devices
> #
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> # CONFIG_SERIAL_NONSTANDARD is not set
> 
> #
> # Serial drivers
> #
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> # CONFIG_SERIAL_8250_CS is not set
> # CONFIG_SERIAL_8250_ACPI is not set
> # CONFIG_SERIAL_8250_EXTENDED is not set
> 
> #
> # Non-8250 serial port support
> #
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_UNIX98_PTY_COUNT=256
> 
> #
> # I2C support
> #
> # CONFIG_I2C is not set
> 
> #
> # I2C Hardware Sensors Mainboard support
> #
> 
> #
> # I2C Hardware Sensors Chip support
> #
> # CONFIG_I2C_SENSOR is not set
> 
> #
> # Mice
> #
> CONFIG_BUSMOUSE=y
> # CONFIG_QIC02_TAPE is not set
> 
> #
> # IPMI
> #
> # CONFIG_IPMI_HANDLER is not set
> 
> #
> # Watchdog Cards
> #
> # CONFIG_WATCHDOG is not set
> # CONFIG_HW_RANDOM is not set
> # CONFIG_NVRAM is not set
> CONFIG_RTC=y
> # CONFIG_DTLK is not set
> # CONFIG_R3964 is not set
> # CONFIG_APPLICOM is not set
> # CONFIG_SONYPI is not set
> 
> #
> # Ftape, the floppy tape device driver
> #
> # CONFIG_FTAPE is not set
> # CONFIG_AGP is not set
> # CONFIG_DRM is not set
> 
> #
> # PCMCIA character devices
> #
> # CONFIG_SYNCLINK_CS is not set
> # CONFIG_MWAVE is not set
> # CONFIG_RAW_DRIVER is not set
> # CONFIG_HANGCHECK_TIMER is not set
> 
> #
> # Multimedia devices
> #
> # CONFIG_VIDEO_DEV is not set
> 
> #
> # Digital Video Broadcasting Devices
> #
> # CONFIG_DVB is not set
> 
> #
> # File systems
> #
> CONFIG_EXT2_FS=y
> # CONFIG_EXT2_FS_XATTR is not set
> CONFIG_EXT3_FS=y
> # CONFIG_EXT3_FS_XATTR is not set
> CONFIG_JBD=y
> # CONFIG_JBD_DEBUG is not set
> # CONFIG_REISERFS_FS is not set
> # CONFIG_JFS_FS is not set
> # CONFIG_XFS_FS is not set
> # CONFIG_MINIX_FS is not set
> # CONFIG_ROMFS_FS is not set
> # CONFIG_QUOTA is not set
> # CONFIG_AUTOFS_FS is not set
> CONFIG_AUTOFS4_FS=y
> 
> #
> # CD-ROM/DVD Filesystems
> #
> CONFIG_ISO9660_FS=m
> CONFIG_JOLIET=y
> CONFIG_ZISOFS=y
> CONFIG_ZISOFS_FS=m
> CONFIG_UDF_FS=m
> 
> #
> # DOS/FAT/NT Filesystems
> #
> CONFIG_FAT_FS=m
> CONFIG_MSDOS_FS=m
> CONFIG_VFAT_FS=m
> CONFIG_NTFS_FS=m
> # CONFIG_NTFS_DEBUG is not set
> # CONFIG_NTFS_RW is not set
> 
> #
> # Pseudo filesystems
> #
> CONFIG_PROC_FS=y
> # CONFIG_DEVFS_FS is not set
> CONFIG_DEVPTS_FS=y
> # CONFIG_DEVPTS_FS_XATTR is not set
> CONFIG_TMPFS=y
> CONFIG_RAMFS=y
> 
> #
> # Miscellaneous filesystems
> #
> # CONFIG_ADFS_FS is not set
> # CONFIG_AFFS_FS is not set
> # CONFIG_HFS_FS is not set
> # CONFIG_BEFS_FS is not set
> # CONFIG_BFS_FS is not set
> # CONFIG_EFS_FS is not set
> # CONFIG_CRAMFS is not set
> # CONFIG_VXFS_FS is not set
> # CONFIG_HPFS_FS is not set
> # CONFIG_QNX4FS_FS is not set
> # CONFIG_SYSV_FS is not set
> # CONFIG_UFS_FS is not set
> 
> #
> # Network File Systems
> #
> CONFIG_NFS_FS=m
> CONFIG_NFS_V3=y
> CONFIG_NFS_V4=y
> CONFIG_NFS_DIRECTIO=y
> CONFIG_NFSD=m
> CONFIG_NFSD_V3=y
> CONFIG_NFSD_V4=y
> CONFIG_NFSD_TCP=y
> CONFIG_LOCKD=m
> CONFIG_LOCKD_V4=y
> CONFIG_EXPORTFS=m
> CONFIG_SUNRPC=m
> CONFIG_SUNRPC_GSS=m
> CONFIG_SMB_FS=m
> CONFIG_SMB_NLS_DEFAULT=y
> CONFIG_SMB_NLS_REMOTE="cp437"
> CONFIG_CIFS=m
> # CONFIG_NCP_FS is not set
> # CONFIG_CODA_FS is not set
> # CONFIG_INTERMEZZO_FS is not set
> # CONFIG_AFS_FS is not set
> 
> #
> # Partition Types
> #
> # CONFIG_PARTITION_ADVANCED is not set
> CONFIG_MSDOS_PARTITION=y
> CONFIG_SMB_NLS=y
> CONFIG_NLS=y
> 
> #
> # Native Language Support
> #
> CONFIG_NLS_DEFAULT="iso8859-15"
> CONFIG_NLS_CODEPAGE_437=y
> # CONFIG_NLS_CODEPAGE_737 is not set
> # CONFIG_NLS_CODEPAGE_775 is not set
> CONFIG_NLS_CODEPAGE_850=y
> # CONFIG_NLS_CODEPAGE_852 is not set
> # CONFIG_NLS_CODEPAGE_855 is not set
> # CONFIG_NLS_CODEPAGE_857 is not set
> # CONFIG_NLS_CODEPAGE_860 is not set
> # CONFIG_NLS_CODEPAGE_861 is not set
> # CONFIG_NLS_CODEPAGE_862 is not set
> # CONFIG_NLS_CODEPAGE_863 is not set
> # CONFIG_NLS_CODEPAGE_864 is not set
> # CONFIG_NLS_CODEPAGE_865 is not set
> # CONFIG_NLS_CODEPAGE_866 is not set
> # CONFIG_NLS_CODEPAGE_869 is not set
> # CONFIG_NLS_CODEPAGE_936 is not set
> # CONFIG_NLS_CODEPAGE_950 is not set
> # CONFIG_NLS_CODEPAGE_932 is not set
> # CONFIG_NLS_CODEPAGE_949 is not set
> # CONFIG_NLS_CODEPAGE_874 is not set
> # CONFIG_NLS_ISO8859_8 is not set
> # CONFIG_NLS_CODEPAGE_1250 is not set
> # CONFIG_NLS_CODEPAGE_1251 is not set
> CONFIG_NLS_ISO8859_1=y
> # CONFIG_NLS_ISO8859_2 is not set
> # CONFIG_NLS_ISO8859_3 is not set
> # CONFIG_NLS_ISO8859_4 is not set
> # CONFIG_NLS_ISO8859_5 is not set
> # CONFIG_NLS_ISO8859_6 is not set
> # CONFIG_NLS_ISO8859_7 is not set
> # CONFIG_NLS_ISO8859_9 is not set
> # CONFIG_NLS_ISO8859_13 is not set
> # CONFIG_NLS_ISO8859_14 is not set
> CONFIG_NLS_ISO8859_15=y
> # CONFIG_NLS_KOI8_R is not set
> # CONFIG_NLS_KOI8_U is not set
> CONFIG_NLS_UTF8=y
> 
> #
> # Graphics support
> #
> # CONFIG_FB is not set
> CONFIG_VIDEO_SELECT=y
> 
> #
> # Console display driver support
> #
> CONFIG_VGA_CONSOLE=y
> # CONFIG_MDA_CONSOLE is not set
> CONFIG_DUMMY_CONSOLE=y
> 
> #
> # Sound
> #
> CONFIG_SOUND=y
> 
> #
> # Advanced Linux Sound Architecture
> #
> CONFIG_SND=y
> CONFIG_SND_SEQUENCER=y
> # CONFIG_SND_SEQ_DUMMY is not set
> CONFIG_SND_OSSEMUL=y
> CONFIG_SND_MIXER_OSS=y
> CONFIG_SND_PCM_OSS=y
> CONFIG_SND_SEQUENCER_OSS=y
> CONFIG_SND_RTCTIMER=y
> # CONFIG_SND_VERBOSE_PRINTK is not set
> # CONFIG_SND_DEBUG is not set
> 
> #
> # Generic devices
> #
> # CONFIG_SND_DUMMY is not set
> # CONFIG_SND_VIRMIDI is not set
> # CONFIG_SND_MTPAV is not set
> # CONFIG_SND_SERIAL_U16550 is not set
> # CONFIG_SND_MPU401 is not set
> 
> #
> # ISA devices
> #
> # CONFIG_SND_AD1816A is not set
> # CONFIG_SND_AD1848 is not set
> # CONFIG_SND_CS4231 is not set
> # CONFIG_SND_CS4232 is not set
> # CONFIG_SND_CS4236 is not set
> # CONFIG_SND_ES968 is not set
> # CONFIG_SND_ES1688 is not set
> # CONFIG_SND_ES18XX is not set
> # CONFIG_SND_GUSCLASSIC is not set
> # CONFIG_SND_GUSEXTREME is not set
> # CONFIG_SND_GUSMAX is not set
> # CONFIG_SND_INTERWAVE is not set
> # CONFIG_SND_INTERWAVE_STB is not set
> # CONFIG_SND_OPTI92X_AD1848 is not set
> # CONFIG_SND_OPTI92X_CS4231 is not set
> # CONFIG_SND_OPTI93X is not set
> # CONFIG_SND_SB8 is not set
> # CONFIG_SND_SB16 is not set
> # CONFIG_SND_SBAWE is not set
> # CONFIG_SND_WAVEFRONT is not set
> # CONFIG_SND_ALS100 is not set
> # CONFIG_SND_AZT2320 is not set
> # CONFIG_SND_CMI8330 is not set
> # CONFIG_SND_DT019X is not set
> # CONFIG_SND_OPL3SA2 is not set
> # CONFIG_SND_SGALAXY is not set
> # CONFIG_SND_SSCAPE is not set
> 
> #
> # PCI devices
> #
> # CONFIG_SND_ALI5451 is not set
> # CONFIG_SND_AZT3328 is not set
> CONFIG_SND_CS46XX=y
> # CONFIG_SND_CS46XX_NEW_DSP is not set
> # CONFIG_SND_CS4281 is not set
> # CONFIG_SND_EMU10K1 is not set
> # CONFIG_SND_KORG1212 is not set
> # CONFIG_SND_NM256 is not set
> # CONFIG_SND_RME32 is not set
> # CONFIG_SND_RME96 is not set
> # CONFIG_SND_RME9652 is not set
> # CONFIG_SND_HDSP is not set
> # CONFIG_SND_TRIDENT is not set
> # CONFIG_SND_YMFPCI is not set
> # CONFIG_SND_ALS4000 is not set
> # CONFIG_SND_CMIPCI is not set
> # CONFIG_SND_ENS1370 is not set
> # CONFIG_SND_ENS1371 is not set
> # CONFIG_SND_ES1938 is not set
> # CONFIG_SND_ES1968 is not set
> # CONFIG_SND_MAESTRO3 is not set
> # CONFIG_SND_FM801 is not set
> # CONFIG_SND_ICE1712 is not set
> # CONFIG_SND_ICE1724 is not set
> # CONFIG_SND_INTEL8X0 is not set
> # CONFIG_SND_SONICVIBES is not set
> # CONFIG_SND_VIA82XX is not set
> # CONFIG_SND_VX222 is not set
> 
> #
> # ALSA USB devices
> #
> # CONFIG_SND_USB_AUDIO is not set
> 
> #
> # PCMCIA devices
> #
> # CONFIG_SND_VXPOCKET is not set
> # CONFIG_SND_VXP440 is not set
> 
> #
> # Open Sound System
> #
> # CONFIG_SOUND_PRIME is not set
> 
> #
> # USB support
> #
> CONFIG_USB=y
> # CONFIG_USB_DEBUG is not set
> 
> #
> # Miscellaneous USB options
> #
> CONFIG_USB_DEVICEFS=y
> CONFIG_USB_BANDWIDTH=y
> CONFIG_USB_DYNAMIC_MINORS=y
> 
> #
> # USB Host Controller Drivers
> #
> CONFIG_USB_EHCI_HCD=m
> # CONFIG_USB_OHCI_HCD is not set
> CONFIG_USB_UHCI_HCD=y
> 
> #
> # USB Device Class drivers
> #
> # CONFIG_USB_AUDIO is not set
> # CONFIG_USB_BLUETOOTH_TTY is not set
> # CONFIG_USB_MIDI is not set
> CONFIG_USB_ACM=m
> CONFIG_USB_PRINTER=m
> CONFIG_USB_STORAGE=m
> # CONFIG_USB_STORAGE_DEBUG is not set
> # CONFIG_USB_STORAGE_DATAFAB is not set
> # CONFIG_USB_STORAGE_FREECOM is not set
> # CONFIG_USB_STORAGE_ISD200 is not set
> # CONFIG_USB_STORAGE_DPCM is not set
> CONFIG_USB_STORAGE_HP8200e=y
> # CONFIG_USB_STORAGE_SDDR09 is not set
> # CONFIG_USB_STORAGE_SDDR55 is not set
> # CONFIG_USB_STORAGE_JUMPSHOT is not set
> 
> #
> # USB Human Interface Devices (HID)
> #
> CONFIG_USB_HID=m
> CONFIG_USB_HIDINPUT=y
> CONFIG_HID_FF=y
> # CONFIG_HID_PID is not set
> # CONFIG_LOGITECH_FF is not set
> # CONFIG_THRUSTMASTER_FF is not set
> CONFIG_USB_HIDDEV=y
> 
> #
> # USB HID Boot Protocol drivers
> #
> # CONFIG_USB_KBD is not set
> # CONFIG_USB_MOUSE is not set
> # CONFIG_USB_AIPTEK is not set
> # CONFIG_USB_WACOM is not set
> # CONFIG_USB_KBTAB is not set
> # CONFIG_USB_POWERMATE is not set
> # CONFIG_USB_XPAD is not set
> 
> #
> # USB Imaging devices
> #
> # CONFIG_USB_MDC800 is not set
> # CONFIG_USB_SCANNER is not set
> # CONFIG_USB_MICROTEK is not set
> # CONFIG_USB_HPUSBSCSI is not set
> 
> #
> # USB Multimedia devices
> #
> # CONFIG_USB_DABUSB is not set
> 
> #
> # Video4Linux support is needed for USB Multimedia device support
> #
> 
> #
> # USB Network adaptors
> #
> # CONFIG_USB_AX8817X is not set
> # CONFIG_USB_CATC is not set
> # CONFIG_USB_KAWETH is not set
> # CONFIG_USB_PEGASUS is not set
> # CONFIG_USB_RTL8150 is not set
> # CONFIG_USB_USBNET is not set
> 
> #
> # USB port drivers
> #
> 
> #
> # USB Serial Converter support
> #
> # CONFIG_USB_SERIAL is not set
> 
> #
> # USB Miscellaneous drivers
> #
> # CONFIG_USB_TIGL is not set
> # CONFIG_USB_AUERSWALD is not set
> # CONFIG_USB_RIO500 is not set
> # CONFIG_USB_BRLVGER is not set
> # CONFIG_USB_LCD is not set
> # CONFIG_USB_TEST is not set
> # CONFIG_USB_GADGET is not set
> 
> #
> # Bluetooth support
> #
> # CONFIG_BT is not set
> 
> #
> # Profiling support
> #
> # CONFIG_PROFILING is not set
> 
> #
> # Kernel hacking
> #
> CONFIG_DEBUG_KERNEL=y
> # CONFIG_DEBUG_STACKOVERFLOW is not set
> # CONFIG_DEBUG_SLAB is not set
> # CONFIG_DEBUG_IOVIRT is not set
> CONFIG_MAGIC_SYSRQ=y
> # CONFIG_DEBUG_SPINLOCK is not set
> # CONFIG_DEBUG_PAGEALLOC is not set
> # CONFIG_SPINLINE is not set
> # CONFIG_KALLSYMS is not set
> # CONFIG_DEBUG_SPINLOCK_SLEEP is not set
> # CONFIG_KGDB is not set
> CONFIG_DEBUG_INFO=y
> # CONFIG_FRAME_POINTER is not set
> CONFIG_X86_EXTRA_IRQS=y
> CONFIG_X86_FIND_SMP_CONFIG=y
> CONFIG_X86_MPPARSE=y
> # CONFIG_SLEEPOMETER is not set
> 
> #
> # Security options
> #
> # CONFIG_SECURITY is not set
> 
> #
> # Cryptographic options
> #
> # CONFIG_CRYPTO is not set
> 
> #
> # Library routines
> #
> # CONFIG_CRC32 is not set
> CONFIG_ZLIB_INFLATE=m
> CONFIG_ZLIB_DEFLATE=m
> CONFIG_X86_BIOS_REBOOT=y




-- 
Regards,

Wiktor Wodecki

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

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile) PATCH
  2003-07-03 11:20       ` William Lee Irwin III
@ 2003-07-03 11:32         ` Dumitru Ciobarcianu
  2003-07-07  5:24         ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
  1 sibling, 0 replies; 147+ messages in thread
From: Dumitru Ciobarcianu @ 2003-07-03 11:32 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm

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

On Thu, 2003-07-03 at 14:20, William Lee Irwin III wrote:
> Great! Could you send back the diff? (or alternatively, the file
> contents if you didn't preserve the old contents) so I can send the
> proper diff upstream?

I have attached the patch since evolution seems to really want to break
the patch if I do an "Insert text file" :(

-- 
Cioby

[-- Attachment #2: p4-clockmod.patch --]
[-- Type: text/plain, Size: 1237 bytes --]

--- /usr/src/linux-2.5.74/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c.original	2003-07-03 14:12:35.000000000 +0300
+++ /usr/src/linux-2.5.74/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c	2003-07-03 14:28:10.000000000 +0300
@@ -53,10 +53,9 @@
 static int cpufreq_p4_setdc(unsigned int cpu, unsigned int newstate)
 {
 	u32 l, h;
-	unsigned long cpus_allowed;
+	cpumask_t cpus_allowed, affected_cpu_map;
 	struct cpufreq_freqs freqs;
 	int hyperthreading = 0;
-	int affected_cpu_map = 0;
 	int sibling = 0;
 
 	if (!cpu_online(cpu) || (newstate > DC_DISABLE) || 
@@ -67,16 +66,16 @@
 	cpus_allowed = current->cpus_allowed;
 
 	/* only run on CPU to be set, or on its sibling */
-	affected_cpu_map = 1 << cpu;
+       affected_cpu_map = cpumask_of_cpu(cpu);
 #ifdef CONFIG_X86_HT
 	hyperthreading = ((cpu_has_ht) && (smp_num_siblings == 2));
 	if (hyperthreading) {
 		sibling = cpu_sibling_map[cpu];
-		affected_cpu_map |= (1 << sibling);
+                cpu_set(sibling, affected_cpu_map);
 	}
 #endif
 	set_cpus_allowed(current, affected_cpu_map);
-	BUG_ON(!(affected_cpu_map & (1 << smp_processor_id())));
+        BUG_ON(!cpu_isset(smp_processor_id(), affected_cpu_map));
 
 	/* get current state */
 	rdmsr(MSR_IA32_THERM_CONTROL, l, h);

^ permalink raw reply	[flat|nested] 147+ messages in thread

* o1-interactivity.patch (was Re: 2.5.74-mm1)
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
  2003-07-03 10:37 ` 2.5.74-mm1 Wiktor Wodecki
  2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
@ 2003-07-03 13:15 ` Sean Neakums
  2003-07-03 13:30   ` Con Kolivas
  2003-07-03 16:02 ` 2.5.74-mm1 Felipe Alfaro Solana
                   ` (6 subsequent siblings)
  9 siblings, 1 reply; 147+ messages in thread
From: Sean Neakums @ 2003-07-03 13:15 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm

Andrew Morton <akpm@osdl.org> writes:

> . Included Con's CPU scheduler changes.  Feedback on the effectiveness of
>   this and the usual benchmarks would be interesting.

I find that this patch makes X really choppy when Mozilla Firebird is
loading a page (which it does through an ssh tunnel here).  Both the X
pointer and the spinner in the tab that is loading stop and start, for
up to a second at a time.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: o1-interactivity.patch (was Re: 2.5.74-mm1)
  2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
@ 2003-07-03 13:30   ` Con Kolivas
  0 siblings, 0 replies; 147+ messages in thread
From: Con Kolivas @ 2003-07-03 13:30 UTC (permalink / raw)
  To: Sean Neakums, Andrew Morton; +Cc: linux-kernel, linux-mm

On Thu, 3 Jul 2003 23:15, Sean Neakums wrote:
> Andrew Morton <akpm@osdl.org> writes:
> > . Included Con's CPU scheduler changes.  Feedback on the effectiveness of
> >   this and the usual benchmarks would be interesting.
>
> I find that this patch makes X really choppy when Mozilla Firebird is
> loading a page (which it does through an ssh tunnel here).  Both the X
> pointer and the spinner in the tab that is loading stop and start, for
> up to a second at a time.

Thanks for the feedback. I know about and am working on this one. No mention 
of the rest of the performance?

Con


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 11:06   ` 2.5.74-mm1 Russell King
@ 2003-07-03 14:15     ` Russell King
  2003-07-03 16:05       ` 2.5.74-mm1 Patrick Mochel
                         ` (3 more replies)
  0 siblings, 4 replies; 147+ messages in thread
From: Russell King @ 2003-07-03 14:15 UTC (permalink / raw)
  To: linux-kernel; +Cc: Wiktor Wodecki, Andrew Morton

On Thu, Jul 03, 2003 at 12:06:26PM +0100, Russell King wrote:
> On Thu, Jul 03, 2003 at 12:37:03PM +0200, Wiktor Wodecki wrote:
> > On my thinkpad T20 it boots up fine, however when I insert my ne2000
> > pcmcia card it instantly freezes. No Ooops or log message at all.
> > 2.5.73-mm1 did fine.
> 
> Grr.
> 
> Can you try taking off each patch in reverse order at:
> 
> 	http://patches.arm.linux.org.uk/pcmcia/pcmcia-event-20030623-*
> 
> and seeing which one caused your problem?

Ok, Wiktor has tried removing these 6 patches, and his problem persists.
According to bk revtool, these 6 patches are the only changes which
went in for to pcmcia from .73 to .74.

If anyone else is having similar problems, they need to report them so
we can obtain more data points - I suspect some other change in some other
subsystem broke PCMCIA for Wiktor.

Wiktor - short of anyone else responding, you could try reversing each
of the nightly -bk patches from .74 to .73 and work out which set of
changes broke it.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (2 preceding siblings ...)
  2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
@ 2003-07-03 16:02 ` Felipe Alfaro Solana
  2003-07-03 18:11 ` 2.5.74-mm1 Pasi Savolainen
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 147+ messages in thread
From: Felipe Alfaro Solana @ 2003-07-03 16:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: LKML, linux-mm

On Thu, 2003-07-03 at 11:37, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
> 
> . Included Con's CPU scheduler changes.  Feedback on the effectiveness of
>   this and the usual benchmarks would be interesting.
> 
>   Changes to the CPU scheduler tend to cause surprising and subtle problems
>   in areas where you least expect it, and these do take a long time to
>   materialise.  Alterations in there need to be made carefully and cautiously.
>   We shall see...

Currently testing all the new things...

>From what I've seen until date, the new scheduler patches are very, very
promising. I like them very much, but I still prefer Mike+Ingo combo
patch a little bit more for my laptop.

Will keep you informed if I see something strange ;-)


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 14:15     ` 2.5.74-mm1 Russell King
@ 2003-07-03 16:05       ` Patrick Mochel
  2003-07-03 16:19         ` 2.5.74-mm1 Russell King
  2003-07-03 16:47       ` 2.5.74-mm1 Wiktor Wodecki
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 147+ messages in thread
From: Patrick Mochel @ 2003-07-03 16:05 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel, Wiktor Wodecki, Andrew Morton


Hi Russell, 

> If anyone else is having similar problems, they need to report them so
> we can obtain more data points - I suspect some other change in some other
> subsystem broke PCMCIA for Wiktor.

I have a T20 and a NE2k network card and have been experiencing a similar 
hang when I start cardmgr. I did some playing around with it and found 
some inconsistencies. 

At first, I had it in Slot 1, and it hung when probing the first range of 
addresses. I moved it to Slot 0, and it was able to probe and bring the 
interface up (though it did complain heavily about dropping packets). 

After a few reboots, it started hanging during the address probe (in Slot 
0). I tried disabling various memory regions to probe in 
/etc/pcmcia/config.opts, and had luck initially, but it now has decided to 
not work at all. 

I also have a Cisco/Aironet 340 802.11b card that is having problems. When 
in Slot 0, cardmgr can idenitfy the card, and the driver initalizes the 
card properly, but I cannot obtain an IP address (but does not hang). In 
Slot 1, the system hangs while trying to obtain an IP address. 

Any ideas?



	-pat


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 16:05       ` 2.5.74-mm1 Patrick Mochel
@ 2003-07-03 16:19         ` Russell King
  2003-07-03 16:24           ` 2.5.74-mm1 Patrick Mochel
  0 siblings, 1 reply; 147+ messages in thread
From: Russell King @ 2003-07-03 16:19 UTC (permalink / raw)
  To: Patrick Mochel; +Cc: linux-kernel, Wiktor Wodecki, Andrew Morton

On Thu, Jul 03, 2003 at 09:05:40AM -0700, Patrick Mochel wrote:
> Any ideas?

Hi Pat,

Do you know which kernel version first exhibited these problems?  Was
.73 ok for you?

Thanks.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 16:19         ` 2.5.74-mm1 Russell King
@ 2003-07-03 16:24           ` Patrick Mochel
  0 siblings, 0 replies; 147+ messages in thread
From: Patrick Mochel @ 2003-07-03 16:24 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel, Wiktor Wodecki, Andrew Morton


> Do you know which kernel version first exhibited these problems?  Was
> .73 ok for you?

I actually just got the laptop 2 days ago, so the first I tried was 
equivalent to probably 2.5.73-bk9.


	-pat


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 14:15     ` 2.5.74-mm1 Russell King
  2003-07-03 16:05       ` 2.5.74-mm1 Patrick Mochel
@ 2003-07-03 16:47       ` Wiktor Wodecki
  2003-07-03 18:43       ` 2.5.74-mm1 Serge Eric Thiam
  2003-07-03 21:49       ` 2.5.74-mm1 Wiktor Wodecki
  3 siblings, 0 replies; 147+ messages in thread
From: Wiktor Wodecki @ 2003-07-03 16:47 UTC (permalink / raw)
  To: linux-kernel, Andrew Morton

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

On Thu, Jul 03, 2003 at 03:15:29PM +0100, Russell King wrote:
> Wiktor - short of anyone else responding, you could try reversing each
> of the nightly -bk patches from .74 to .73 and work out which set of
> changes broke it.

I have a 2.5.73-bk7 around and it doesn't work with this one. I'm out now
so I cannot look for other bk snapshots. Could someone please send me the
other ones since they seem to be gone from the server and I don't feel
like widdling with the bk tool right now. Thanks.

-- 
Regards,

Wiktor Wodecki

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

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (3 preceding siblings ...)
  2003-07-03 16:02 ` 2.5.74-mm1 Felipe Alfaro Solana
@ 2003-07-03 18:11 ` Pasi Savolainen
  2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 147+ messages in thread
From: Pasi Savolainen @ 2003-07-03 18:11 UTC (permalink / raw)
  To: linux-kernel; +Cc: linux-mm

* Andrew Morton <akpm@osdl.org>:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
> 

Has -mm had some monotonic clock patches at around 2.5.72-mm3?
2.5.74-mm1 seems to produce non-monotonic gettimeofday.
(tested with http://www.swcp.com/~hudson/gettimeofday.c)
'lag' is sporadic and may take several iterations to come up.


Machine is 2xK7 with a ACPI C2 sleep driver (TSC's get unsynched).
2.5.72-mm3 didn't show these.

-- 
   Psi -- <http://www.iki.fi/pasi.savolainen>


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 14:15     ` 2.5.74-mm1 Russell King
  2003-07-03 16:05       ` 2.5.74-mm1 Patrick Mochel
  2003-07-03 16:47       ` 2.5.74-mm1 Wiktor Wodecki
@ 2003-07-03 18:43       ` Serge Eric Thiam
  2003-07-03 21:49       ` 2.5.74-mm1 Wiktor Wodecki
  3 siblings, 0 replies; 147+ messages in thread
From: Serge Eric Thiam @ 2003-07-03 18:43 UTC (permalink / raw)
  To: linux-kernel; +Cc: Wiktor Wodecki, Andrew Morton

* Russell King [Thu, Jul 03, 2003 at 03:15:29PM +0100]
> On Thu, Jul 03, 2003 at 12:06:26PM +0100, Russell King wrote:
> > On Thu, Jul 03, 2003 at 12:37:03PM +0200, Wiktor Wodecki wrote:
> > > On my thinkpad T20 it boots up fine, however when I insert my ne2000
> > > pcmcia card it instantly freezes. No Ooops or log message at all.
> > > 2.5.73-mm1 did fine.
> > 
> > Grr.
> > 
> > Can you try taking off each patch in reverse order at:
> > 
> > 	http://patches.arm.linux.org.uk/pcmcia/pcmcia-event-20030623-*
> > 
> > and seeing which one caused your problem?
> 
> Ok, Wiktor has tried removing these 6 patches, and his problem persists.
> According to bk revtool, these 6 patches are the only changes which
> went in for to pcmcia from .73 to .74.
> 
> If anyone else is having similar problems, they need to report them so
> we can obtain more data points - I suspect some other change in some other
> subsystem broke PCMCIA for Wiktor.
> 
> Wiktor - short of anyone else responding, you could try reversing each
> of the nightly -bk patches from .74 to .73 and work out which set of
> changes broke it.
I've been having this same problem with my 3c574 NIC since 2.5.73-mm1.
vanilla-2.5.73 and 2.5.72-mm2 was ok. Never tried 2.5.72-mm3. works
fine. I haven tried vanilla-2.5.74 nor 2.5.74-mm1 yet.

Hope this helps, 

regards

-Eric-
-- 
#!/usr/bin/perl
my @email = qw(serge-eric thiam gmx net);
printf("%s.%s@%s.%s\n", $email[0], $email[1], $email[2], $email[3]);

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (4 preceding siblings ...)
  2003-07-03 18:11 ` 2.5.74-mm1 Pasi Savolainen
@ 2003-07-03 20:25 ` William Lee Irwin III
  2003-07-03 20:48   ` 2.5.74-mm1 William Lee Irwin III
  2003-07-04  8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
                   ` (3 subsequent siblings)
  9 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-03 20:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm

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

On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
> . Mainly a resync with various things and people.  Plus a few fixlets.
> . I dropped out a few patches which weren't really proving useful.
> . Included Con's CPU scheduler changes.  Feedback on the effectiveness of
>   this and the usual benchmarks would be interesting.
>   Changes to the CPU scheduler tend to cause surprising and subtle problems
>   in areas where you least expect it, and these do take a long time to
>   materialise.  Alterations in there need to be made carefully and cautiously.
>   We shall see...

Here's a resync of highpmd, the big PAE resource scalability patch that
saves 12KB per process of lowmem. It adds pmd accessors analogous to
pte_offset_map() etc., i.e. pmd_offset_map(), pmd_unmap(), etc.


-- wli

[-- Attachment #2: highpmd-2.5.74-mm2-1.bz2 --]
[-- Type: application/octet-stream, Size: 14196 bytes --]

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-03 20:48   ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-03 20:48 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel, linux-mm

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

On Thu, Jul 03, 2003 at 01:25:37PM -0700, William Lee Irwin III wrote:
> Here's a resync of highpmd, the big PAE resource scalability patch that
> saves 12KB per process of lowmem. It adds pmd accessors analogous to
> pte_offset_map() etc., i.e. pmd_offset_map(), pmd_unmap(), etc.

And here's a resync of the right version of the thing:


-- wli

[-- Attachment #2: highpmd-2.5.74-mm1-1.bz2 --]
[-- Type: application/octet-stream, Size: 15616 bytes --]

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 14:15     ` 2.5.74-mm1 Russell King
                         ` (2 preceding siblings ...)
  2003-07-03 18:43       ` 2.5.74-mm1 Serge Eric Thiam
@ 2003-07-03 21:49       ` Wiktor Wodecki
  2003-07-03 21:53         ` 2.5.74-mm1 Russell King
  2003-07-03 22:14         ` 2.5.74-mm1 Russell King
  3 siblings, 2 replies; 147+ messages in thread
From: Wiktor Wodecki @ 2003-07-03 21:49 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel

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

On Thu, Jul 03, 2003 at 03:15:29PM +0100, Russell King wrote:
> Ok, Wiktor has tried removing these 6 patches, and his problem persists.
> According to bk revtool, these 6 patches are the only changes which
> went in for to pcmcia from .73 to .74.
> 
> If anyone else is having similar problems, they need to report them so
> we can obtain more data points - I suspect some other change in some other
> subsystem broke PCMCIA for Wiktor.
> 
> Wiktor - short of anyone else responding, you could try reversing each
> of the nightly -bk patches from .74 to .73 and work out which set of
> changes broke it.

it broke with the 2.5.73-rc2 patch. I assume it was:

ChangeSet@1.1348.20.5, 2003-06-23 23:52:55+01:00,
rmk@flint.arm.linux.org.uk
  [SERIAL] 8250_cs update - incorporate pcmcia-cs 3.1.34 serial_cs fixes

-- 
Regards,

Wiktor Wodecki

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

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 21:49       ` 2.5.74-mm1 Wiktor Wodecki
@ 2003-07-03 21:53         ` Russell King
  2003-07-03 22:12           ` 2.5.74-mm1 Patrick Mochel
  2003-07-03 22:14         ` 2.5.74-mm1 Russell King
  1 sibling, 1 reply; 147+ messages in thread
From: Russell King @ 2003-07-03 21:53 UTC (permalink / raw)
  To: Johoho; +Cc: linux-kernel

On Thu, Jul 03, 2003 at 11:49:21PM +0200, Wiktor Wodecki wrote:
> On Thu, Jul 03, 2003 at 03:15:29PM +0100, Russell King wrote:
> > Ok, Wiktor has tried removing these 6 patches, and his problem persists.
> > According to bk revtool, these 6 patches are the only changes which
> > went in for to pcmcia from .73 to .74.
> > 
> > If anyone else is having similar problems, they need to report them so
> > we can obtain more data points - I suspect some other change in some other
> > subsystem broke PCMCIA for Wiktor.
> > 
> > Wiktor - short of anyone else responding, you could try reversing each
> > of the nightly -bk patches from .74 to .73 and work out which set of
> > changes broke it.
> 
> it broke with the 2.5.73-rc2 patch. I assume it was:
> 
> ChangeSet@1.1348.20.5, 2003-06-23 23:52:55+01:00,
> rmk@flint.arm.linux.org.uk
>   [SERIAL] 8250_cs update - incorporate pcmcia-cs 3.1.34 serial_cs fixes

-rc2 or -bk2?

Hmm.  That's actually the 3rd of a set of 3 csets which only touch
8250_cs.c.  If you aren't using a card with a serial port built in
(eg, modem) then these csets shouldn't make any difference to you.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 21:53         ` 2.5.74-mm1 Russell King
@ 2003-07-03 22:12           ` Patrick Mochel
  0 siblings, 0 replies; 147+ messages in thread
From: Patrick Mochel @ 2003-07-03 22:12 UTC (permalink / raw)
  To: Russell King; +Cc: Johoho, linux-kernel


> > ChangeSet@1.1348.20.5, 2003-06-23 23:52:55+01:00,
> > rmk@flint.arm.linux.org.uk
> >   [SERIAL] 8250_cs update - incorporate pcmcia-cs 3.1.34 serial_cs fixes
> 
> -rc2 or -bk2?
> 
> Hmm.  That's actually the 3rd of a set of 3 csets which only touch
> 8250_cs.c.  If you aren't using a card with a serial port built in
> (eg, modem) then these csets shouldn't make any difference to you.

Actually, at least in my case, mine is a combo modem/network card: D-Link 
DMF-560TXD. Sorry, shoulda mentioned that in the first place. 

I didn't initially have CONFIG_SERIAL_8250_CS enabled, but enabling it
doesn't change behavior.


	-pat


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 21:49       ` 2.5.74-mm1 Wiktor Wodecki
  2003-07-03 21:53         ` 2.5.74-mm1 Russell King
@ 2003-07-03 22:14         ` Russell King
  2003-07-04  8:00           ` 2.5.74-mm1 Wiktor Wodecki
  1 sibling, 1 reply; 147+ messages in thread
From: Russell King @ 2003-07-03 22:14 UTC (permalink / raw)
  To: Johoho; +Cc: linux-kernel

On Thu, Jul 03, 2003 at 11:49:21PM +0200, Wiktor Wodecki wrote:
> On Thu, Jul 03, 2003 at 03:15:29PM +0100, Russell King wrote:
> > Ok, Wiktor has tried removing these 6 patches, and his problem persists.
> > According to bk revtool, these 6 patches are the only changes which
> > went in for to pcmcia from .73 to .74.
> > 
> > If anyone else is having similar problems, they need to report them so
> > we can obtain more data points - I suspect some other change in some other
> > subsystem broke PCMCIA for Wiktor.
> > 
> > Wiktor - short of anyone else responding, you could try reversing each
> > of the nightly -bk patches from .74 to .73 and work out which set of
> > changes broke it.
> 
> it broke with the 2.5.73-rc2 patch. I assume it was:

Ok, looking at the -bk1-bk2 incremental patch, there's a couple of
possibilities:

- changes to the x86 PCI code
- changes to yenta_socket.c to add different overrides
- add burst support to yenta_socket.c for TI bridges
- add ISA interrupt routing work-around for TI bridges

I think the number one suspect is probably the final one.  Could you try
reversing this patch please?

diff -urN linux-2.5.73-bk1/drivers/pcmcia/ti113x.h linux-2.5.73-bk2/drivers/pcmcia/ti113x.h
--- linux-2.5.73-bk1/drivers/pcmcia/ti113x.h	2003-06-22 11:32:41.000000000 -0700
+++ linux-2.5.73-bk2/drivers/pcmcia/ti113x.h	2003-06-24 13:06:59.000000000 -0700
@@ -175,6 +175,27 @@
 	new = reg & ~I365_INTR_ENA;
 	if (new != reg)
 		exca_writeb(socket, I365_INTCTL, new);
+
+	/*
+	 * If ISA interrupts don't work, then fall back to routing card
+	 * interrupts to the PCI interrupt of the socket.
+	 */
+	if (!socket->socket.irq_mask) {
+		int irqmux, devctl;
+
+		printk (KERN_INFO "ti113x: Routing card interrupts to PCI\n");
+
+		devctl = config_readb(socket, TI113X_DEVICE_CONTROL);
+		devctl &= ~TI113X_DCR_IMODE_MASK;
+
+		irqmux = config_readl(socket, TI122X_IRQMUX);
+		irqmux = (irqmux & ~0x0f) | 0x02; /* route INTA */
+		irqmux = (irqmux & ~0xf0) | 0x20; /* route INTB */
+
+		config_writel(socket, TI122X_IRQMUX, irqmux);
+		config_writeb(socket, TI113X_DEVICE_CONTROL, devctl);
+	}
+
 	socket->socket.ss_entry->init = ti_init;
 	return 0;
 }



-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 22:14         ` 2.5.74-mm1 Russell King
@ 2003-07-04  8:00           ` Wiktor Wodecki
  0 siblings, 0 replies; 147+ messages in thread
From: Wiktor Wodecki @ 2003-07-04  8:00 UTC (permalink / raw)
  To: Russell King; +Cc: linux-kernel

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

On Thu, Jul 03, 2003 at 11:14:01PM +0100, Russell King wrote:
> On Thu, Jul 03, 2003 at 11:49:21PM +0200, Wiktor Wodecki wrote:
> > On Thu, Jul 03, 2003 at 03:15:29PM +0100, Russell King wrote:
> > > Ok, Wiktor has tried removing these 6 patches, and his problem persists.
> > > According to bk revtool, these 6 patches are the only changes which
> > > went in for to pcmcia from .73 to .74.
> > > 
> > > If anyone else is having similar problems, they need to report them so
> > > we can obtain more data points - I suspect some other change in some other
> > > subsystem broke PCMCIA for Wiktor.
> > > 
> > > Wiktor - short of anyone else responding, you could try reversing each
> > > of the nightly -bk patches from .74 to .73 and work out which set of
> > > changes broke it.
> > 
> > it broke with the 2.5.73-rc2 patch. I assume it was:
> 
> Ok, looking at the -bk1-bk2 incremental patch, there's a couple of
> possibilities:
> 
> - changes to the x86 PCI code
> - changes to yenta_socket.c to add different overrides
> - add burst support to yenta_socket.c for TI bridges
> - add ISA interrupt routing work-around for TI bridges
> 
> I think the number one suspect is probably the final one.  Could you try
> reversing this patch please?

gotcha, with this one reverted 2.5.73-bk2 boots up fine

> 
> diff -urN linux-2.5.73-bk1/drivers/pcmcia/ti113x.h linux-2.5.73-bk2/drivers/pcmcia/ti113x.h
> --- linux-2.5.73-bk1/drivers/pcmcia/ti113x.h	2003-06-22 11:32:41.000000000 -0700
> +++ linux-2.5.73-bk2/drivers/pcmcia/ti113x.h	2003-06-24 13:06:59.000000000 -0700
> @@ -175,6 +175,27 @@
>  	new = reg & ~I365_INTR_ENA;
>  	if (new != reg)
>  		exca_writeb(socket, I365_INTCTL, new);
> +
> +	/*
> +	 * If ISA interrupts don't work, then fall back to routing card
> +	 * interrupts to the PCI interrupt of the socket.
> +	 */
> +	if (!socket->socket.irq_mask) {
> +		int irqmux, devctl;
> +
> +		printk (KERN_INFO "ti113x: Routing card interrupts to PCI\n");
> +
> +		devctl = config_readb(socket, TI113X_DEVICE_CONTROL);
> +		devctl &= ~TI113X_DCR_IMODE_MASK;
> +
> +		irqmux = config_readl(socket, TI122X_IRQMUX);
> +		irqmux = (irqmux & ~0x0f) | 0x02; /* route INTA */
> +		irqmux = (irqmux & ~0xf0) | 0x20; /* route INTB */
> +
> +		config_writel(socket, TI122X_IRQMUX, irqmux);
> +		config_writeb(socket, TI113X_DEVICE_CONTROL, devctl);
> +	}
> +
>  	socket->socket.ss_entry->init = ti_init;
>  	return 0;
>  }
> 
> 
> 
> -- 
> Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>              http://www.arm.linux.org.uk/personal/aboutme.html

-- 
Regards,

Wiktor Wodecki

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

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04  8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
@ 2003-07-04  8:53   ` William Lee Irwin III
  2003-07-04  9:35   ` William Lee Irwin III
  1 sibling, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04  8:53 UTC (permalink / raw)
  To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 10:55:37AM +0200, Helge Hafting wrote:
> 2.5.74-mm1 dies very early during bootup due to some APIC trouble:
> (written down by hand)
> Posix conformance testing by UNIFIX
> enabled Extint on cpu #0
> ESR before enabling vector 00000000
> ESR after enabling vector 00000000
> Enabling IP-APIC IRQs
> BIOS bug, IO-APIC #0 ID2 is already used!...
> kernel panic: Max APIC ID exceeded!

Okay, fixing.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (5 preceding siblings ...)
  2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-04  8:55 ` Helge Hafting
  2003-07-04  8:53   ` William Lee Irwin III
  2003-07-04  9:35   ` William Lee Irwin III
  2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
                   ` (2 subsequent siblings)
  9 siblings, 2 replies; 147+ messages in thread
From: Helge Hafting @ 2003-07-04  8:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm

2.5.74-mm1 dies very early during bootup due to some APIC trouble:
(written down by hand)
Posix conformance testing by UNIFIX
enabled Extint on cpu #0
ESR before enabling vector 00000000
ESR after enabling vector 00000000
Enabling IP-APIC IRQs
BIOS bug, IO-APIC #0 ID2 is already used!...
kernel panic: Max APIC ID exceeded!



Here is the corresponding log for 2.5.73mm3
(pasted from dmesg)
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
  IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-11, 2-17, 2-19 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 22.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00178014
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0014
.... register #02: 02000000
.......     : arbitration: 02
.... IRQ redirection table:
  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
  00 000 00  1    0    0   0   0    0    0    00
  01 001 01  0    0    0   0   0    1    1    39
  02 001 01  0    0    0   0   0    1    1    31
  03 001 01  0    0    0   0   0    1    1    41
  04 001 01  0    0    0   0   0    1    1    49
  05 000 00  1    0    0   0   0    0    0    00
  06 001 01  0    0    0   0   0    1    1    51
  07 001 01  0    0    0   0   0    1    1    59
  08 001 01  0    0    0   0   0    1    1    61
  09 000 00  1    0    0   0   0    0    0    00
  0a 001 01  0    0    0   0   0    1    1    69
  0b 000 00  1    0    0   0   0    0    0    00
  0c 001 01  0    0    0   0   0    1    1    71
  0d 001 01  0    0    0   0   0    1    1    79
  0e 001 01  0    0    0   0   0    1    1    81
  0f 001 01  0    0    0   0   0    1    1    89
  10 001 01  1    1    0   1   0    1    1    91
  11 000 00  1    0    0   0   0    0    0    00
  12 001 01  1    1    0   1   0    1    1    99
  13 000 00  1    0    0   0   0    0    0    00
  14 001 01  1    1    0   1   0    1    1    A1
  15 001 01  1    1    0   1   0    1    1    A9
  16 001 01  1    1    0   1   0    1    1    B1
  17 001 01  1    1    0   1   0    1    1    B9

IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ10 -> 0:10
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2390.3168 MHz.
..... host bus clock speed is 132.7952 MHz.
mtrr: v2.0 (20020519)


Seems the kernel wants to use APIC ID2, but
2.5.74 claims the BIOS used it up?



Some more APIC related info from 2.5.73mm3 dmesg:
511MB LOWMEM available.
found SMP MP-table at 000f5670
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 131056
   DMA zone: 4096 pages, LIFO batch:1
   Normal zone: 126960 pages, LIFO batch:16
   HighMem zone: 0 pages, LIFO batch:1
Intel MultiProcessor Specification v1.4
     Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 15:2 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Processors: 1


lspci output, in case it matters:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS645DX Host & 
Memory & AGP Controller
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual 
PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 04)
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] 
SiS7012 PCI Audio Accelerator (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB 
Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB 
Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB 
Controller (rev 0f)
00:03.3 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0
00:0b.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] 
(rev 78)
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY 
[Radeon 7000/VE]

This is a desktop P4 with 512M. The kernel is a UP kernel.

Helge Hafting


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04  8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
  2003-07-04  8:53   ` William Lee Irwin III
@ 2003-07-04  9:35   ` William Lee Irwin III
  2003-07-04  9:50     ` William Lee Irwin III
  1 sibling, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04  9:35 UTC (permalink / raw)
  To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 10:55:37AM +0200, Helge Hafting wrote:
> 2.5.74-mm1 dies very early during bootup due to some APIC trouble:
> (written down by hand)
> Posix conformance testing by UNIFIX
> enabled Extint on cpu #0
> ESR before enabling vector 00000000
> ESR after enabling vector 00000000
> Enabling IP-APIC IRQs
> BIOS bug, IO-APIC #0 ID2 is already used!...
> kernel panic: Max APIC ID exceeded!

Okay, now for the "final solution" wrt. sparse physical APIC ID's
in addition to what I hope is a fix for your bug. This uses a separate
bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
APIC ID bitmaps.

\begin{cross-fingers}


-- wli


diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/apic.c virgin_cpu-2.5.74-2/arch/i386/kernel/apic.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/apic.c	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/apic.c	2003-07-04 02:29:01.000000000 -0700
@@ -1137,7 +1137,7 @@ int __init APIC_init_uniprocessor (void)
 
 	connect_bsp_APIC();
 
-	phys_cpu_present_map = cpumask_of_cpu(boot_cpu_physical_apicid);
+	phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
 
 	setup_local_APIC();
 
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/io_apic.c virgin_cpu-2.5.74-2/arch/i386/kernel/io_apic.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/io_apic.c	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/io_apic.c	2003-07-04 02:29:01.000000000 -0700
@@ -1600,7 +1600,7 @@ void disable_IO_APIC(void)
 static void __init setup_ioapic_ids_from_mpc(void)
 {
 	union IO_APIC_reg_00 reg_00;
-	cpumask_t phys_id_present_map;
+	physid_mask_t phys_id_present_map;
 	int apic;
 	int i;
 	unsigned char old_id;
@@ -1614,8 +1614,7 @@ static void __init setup_ioapic_ids_from
 	 * This is broken; anything with a real cpu count has to
 	 * circumvent this idiocy regardless.
 	 */
-	phys_id_present_map =
-		ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+	phys_id_present_map = ioapic_phys_id_map(phys_cpu_present_map);
 
 	/*
 	 * Set the IOAPIC ID to the value stored in the MPC table.
@@ -1646,20 +1645,20 @@ static void __init setup_ioapic_ids_from
 					mp_ioapics[apic].mpc_apicid)) {
 			printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n",
 				apic, mp_ioapics[apic].mpc_apicid);
-			for (i = 0; i < 0xf; i++)
-				if (!cpu_isset(i, phys_id_present_map))
+			for (i = 0; i < APIC_BROADCAST_ID; i++)
+				if (!physid_isset(i, phys_id_present_map))
 					break;
-			if (i >= 0xf)
+			if (i >= APIC_BROADCAST_ID)
 				panic("Max APIC ID exceeded!\n");
 			printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n",
 				i);
-			cpu_set(i, phys_id_present_map);
+			physid_set(i, phys_id_present_map);
 			mp_ioapics[apic].mpc_apicid = i;
 		} else {
-			cpumask_t tmp;
+			physid_mask_t tmp;
 			tmp = apicid_to_cpu_present(mp_ioapics[apic].mpc_apicid);
 			printk("Setting %d in the phys_id_present_map\n", mp_ioapics[apic].mpc_apicid);
-			cpus_or(phys_id_present_map, phys_id_present_map, tmp);
+			physids_or(phys_id_present_map, phys_id_present_map, tmp);
 		}
 
 
@@ -2230,8 +2229,8 @@ late_initcall(io_apic_bug_finalize);
 int __init io_apic_get_unique_id (int ioapic, int apic_id)
 {
 	union IO_APIC_reg_00 reg_00;
-	static cpumask_t apic_id_map = CPU_MASK_NONE;
-	cpumask_t tmp;
+	static physid_mask_t apic_id_map = CPU_MASK_NONE;
+	physid_mask_t tmp;
 	unsigned long flags;
 	int i = 0;
 
@@ -2244,8 +2243,8 @@ int __init io_apic_get_unique_id (int io
 	 *      advantage of new APIC bus architecture.
 	 */
 
-	if (cpus_empty(apic_id_map))
-		apic_id_map = ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+	if (physids_empty(apic_id_map))
+		apic_id_map = ioapic_phys_id_map(phys_cpu_present_map);
 
 	spin_lock_irqsave(&ioapic_lock, flags);
 	reg_00.raw = io_apic_read(ioapic, 0);
@@ -2278,7 +2277,7 @@ int __init io_apic_get_unique_id (int io
 	} 
 
 	tmp = apicid_to_cpu_present(apic_id);
-	cpus_or(apic_id_map, apic_id_map, tmp);
+	physids_or(apic_id_map, apic_id_map, tmp);
 
 	if (reg_00.bits.ID != apic_id) {
 		reg_00.bits.ID = apic_id;
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/mpparse.c virgin_cpu-2.5.74-2/arch/i386/kernel/mpparse.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/mpparse.c	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/mpparse.c	2003-07-04 02:29:01.000000000 -0700
@@ -71,7 +71,7 @@ unsigned int boot_cpu_logical_apicid = -
 static unsigned int __initdata num_processors;
 
 /* Bitmask of physically existing CPUs */
-cpumask_t phys_cpu_present_map;
+physid_mask_t phys_cpu_present_map;
 
 u8 bios_cpu_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
 
@@ -106,7 +106,7 @@ static struct mpc_config_translation *tr
 void __init MP_processor_info (struct mpc_config_processor *m)
 {
  	int ver, apicid;
-	cpumask_t tmp;
+	physid_mask_t tmp;
  	
 	if (!(m->mpc_cpuflag & CPU_ENABLED))
 		return;
@@ -178,7 +178,7 @@ void __init MP_processor_info (struct mp
 	ver = m->mpc_apicver;
 
 	tmp = apicid_to_cpu_present(apicid);
-	cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
+	physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
 	
 	/*
 	 * Validate version
diff -prauN virgin_cpu-2.5.74-1/arch/i386/kernel/smpboot.c virgin_cpu-2.5.74-2/arch/i386/kernel/smpboot.c
--- virgin_cpu-2.5.74-1/arch/i386/kernel/smpboot.c	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/arch/i386/kernel/smpboot.c	2003-07-04 02:31:37.000000000 -0700
@@ -957,7 +957,7 @@ static void __init smp_boot_cpus(unsigne
 	if (!smp_found_config) {
 		printk(KERN_NOTICE "SMP motherboard not detected.\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		if (APIC_init_uniprocessor())
 			printk(KERN_NOTICE "Local APIC not detected."
 					   " Using dummy APIC emulation.\n");
@@ -984,7 +984,7 @@ static void __init smp_boot_cpus(unsigne
 			boot_cpu_physical_apicid);
 		printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your hw vendor)\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		return;
 	}
 
@@ -997,7 +997,7 @@ static void __init smp_boot_cpus(unsigne
 		smp_found_config = 0;
 		printk(KERN_INFO "SMP mode deactivated, forcing use of dummy APIC emulation.\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		return;
 	}
 
@@ -1020,7 +1020,7 @@ static void __init smp_boot_cpus(unsigne
 	Dprintk("CPU present map: %lx\n", cpus_coerce(phys_cpu_present_map));
 
 	kicked = 1;
-	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
+	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
 		apicid = cpu_present_to_apicid(bit);
 		/*
 		 * Don't even attempt to start the boot CPU!
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/genapic.h virgin_cpu-2.5.74-2/include/asm-i386/genapic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/genapic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/genapic.h	2003-07-04 02:29:01.000000000 -0700
@@ -27,18 +27,18 @@ struct genapic { 
 	int int_dest_mode; 
 	int apic_broadcast_id; 
 	int esr_disable;
-	unsigned long (*check_apicid_used)(cpumask_const_t bitmap, int apicid); 
+	unsigned long (*check_apicid_used)(physid_mask_t bitmap, int apicid); 
 	unsigned long (*check_apicid_present)(int apicid); 
 	int no_balance_irq;
 	void (*init_apic_ldr)(void);
-	cpumask_t (*ioapic_phys_id_map)(cpumask_const_t map); 
+	physid_mask_t (*ioapic_phys_id_map)(cpumask_const_t map); 
 
 	void (*clustered_apic_check)(void);
 	int (*multi_timer_check)(int apic, int irq);
 	int (*apicid_to_node)(int logical_apicid); 
 	int (*cpu_to_logical_apicid)(int cpu);
 	int (*cpu_present_to_apicid)(int mps_cpu);
-	cpumask_t (*apicid_to_cpu_present)(int phys_apicid); 
+	physid_mask_t (*apicid_to_cpu_present)(int phys_apicid); 
 	int (*mpc_apic_id)(struct mpc_config_processor *m, 
 			   struct mpc_config_translation *t); 
 	void (*setup_portio_remap)(void); 
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-bigsmp/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:29:01.000000000 -0700
@@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE dest_LowestPrio
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
-#define APIC_BROADCAST_ID     (0x0f)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid) 
+#define APIC_BROADCAST_ID     (0xff)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid) 
 {
 	return 0;
 }
 
 static inline unsigned long check_apicid_present(int bit) 
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 #define apicid_cluster(apicid) (apicid & 0xF0)
@@ -89,9 +89,9 @@ static inline int cpu_present_to_apicid(
 	return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	return cpumask_of_cpu(phys_apicid);
+	return physid_mask_of_physid(phys_apicid);
 }
 
 extern volatile u8 cpu_2_logical_apicid[];
@@ -112,10 +112,10 @@ static inline int mpc_apic_id(struct mpc
 	return m->mpc_apicid;
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0xFUL);
+	return physids_promote(0xFUL);
 }
 
 #define WAKE_SECONDARY_VIA_INIT
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-default/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-default/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-default/mach_apic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-default/mach_apic.h	2003-07-04 02:29:01.000000000 -0700
@@ -21,16 +21,20 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE dest_LowestPrio
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
+/*
+ * this isn't really broadcast, just a (potentially inaccurate) upper
+ * bound for valid physical APIC id's
+ */
 #define APIC_BROADCAST_ID      0x0F
 
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
-	return cpu_isset_const(apicid, bitmap);
+	return physid_isset(apicid, bitmap);
 }
 
 static inline unsigned long check_apicid_present(int bit)
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 /*
@@ -50,11 +54,9 @@ static inline void init_apic_ldr(void)
 	apic_write_around(APIC_LDR, val);
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
-	cpumask_t ret;
-	cpus_copy_const(ret, phys_map);
-	return ret;
+	return phys_map;
 }
 
 static inline void clustered_apic_check(void)
@@ -84,9 +86,9 @@ static inline int cpu_present_to_apicid(
 	return  mps_cpu;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	return cpumask_of_cpu(phys_apicid);
+	return physid_mask_of_physid(phys_apicid);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
@@ -106,12 +108,12 @@ static inline void setup_portio_remap(vo
 
 static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
 {
-	return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+	return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
 }
 
 static inline int apic_id_registered(void)
 {
-	return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+	return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
 }
 
 static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-es7000/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-es7000/mach_apic.h	2003-07-04 02:29:01.000000000 -0700
@@ -40,13 +40,13 @@ static inline cpumask_t target_cpus(void
 
 #define APIC_BROADCAST_ID	(0xff)
 
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid) 
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid) 
 { 
 	return 0;
 } 
 static inline unsigned long check_apicid_present(int bit) 
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 #define apicid_cluster(apicid) (apicid & 0xF0)
@@ -110,12 +110,12 @@ static inline int cpu_present_to_apicid(
 		return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	static int cpu = 0;
-	cpumask_t mask;
-	mask = cpumask_of_cpu(cpu);
-	++cpu;
+	static int id = 0;
+	physid_mask_t mask;
+	mask = physid_mask_of_physid(id);
+	++id;
 	return mask;
 }
 
@@ -136,10 +136,10 @@ static inline int mpc_apic_id(struct mpc
 	return (m->mpc_apicid);
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0xff);
+	return physids_promote(0xff);
 }
 
 
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-numaq/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-numaq/mach_apic.h	2003-07-04 02:29:01.000000000 -0700
@@ -21,8 +21,8 @@ static inline cpumask_t target_cpus(void
 #define INT_DEST_MODE 0     /* physical delivery on LOCAL quad */
  
 #define APIC_BROADCAST_ID      0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
 #define apicid_cluster(apicid) (apicid & 0xF0)
 
 static inline int apic_id_registered(void)
@@ -50,10 +50,10 @@ static inline int multi_timer_check(int 
 	return apic != 0 && irq == 0;
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* We don't have a good way to do this yet - hack */
-	return cpus_promote(0xFUL);
+	return physids_promote(0xFUL);
 }
 
 /* Mapping from cpu number to logical apicid */
@@ -78,12 +78,12 @@ static inline int apicid_to_node(int log
 	return logical_apicid >> 4;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
 {
 	int node = apicid_to_node(logical_apicid);
 	int cpu = __ffs(logical_apicid & 0xf);
 
-	return cpumask_of_cpu(cpu + 4*node);
+	return physid_mask_of_physid(cpu + 4*node);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-summit/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-summit/mach_apic.h	2003-07-04 02:29:01.000000000 -0700
@@ -28,8 +28,8 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE (dest_Fixed)
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
-#define APIC_BROADCAST_ID     (0x0F)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid) 
+#define APIC_BROADCAST_ID     (0xFF)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid) 
 {
 	return 0;
 } 
@@ -88,15 +88,15 @@ static inline int cpu_present_to_apicid(
 	return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_id_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_id_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0x0F);
+	return physids_promote(0x0F);
 }
 
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
-	return cpumask_of_cpu(0);
+	return physid_mask_of_physid(0);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h virgin_cpu-2.5.74-2/include/asm-i386/mach-visws/mach_apic.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mach-visws/mach_apic.h	2003-07-04 02:29:01.000000000 -0700
@@ -16,12 +16,12 @@
 #endif
 
 #define APIC_BROADCAST_ID      0x0F
-#define check_apicid_used(bitmap, apicid)	cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit)		cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid)	physid_isset(apicid, bitmap)
+#define check_apicid_present(bit)		physid_isset(bit, phys_cpu_present_map)
 
 static inline int apic_id_registered(void)
 {
-	return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+	return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
 }
 
 /*
@@ -60,9 +60,9 @@ static inline int cpu_present_to_apicid(
 	return mps_cpu;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
-	return cpumask_of_cpu(apicid);
+	return physid_mask_of_physid(apicid);
 }
 
 #define WAKE_SECONDARY_VIA_INIT
@@ -77,7 +77,7 @@ static inline void enable_apic_mode(void
 
 static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
 {
-	return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+	return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
 }
 
 static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/mpspec.h virgin_cpu-2.5.74-2/include/asm-i386/mpspec.h
--- virgin_cpu-2.5.74-1/include/asm-i386/mpspec.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/mpspec.h	2003-07-04 02:29:01.000000000 -0700
@@ -12,7 +12,6 @@ extern int quad_local_to_mp_bus_id [NR_C
 extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
 
 extern unsigned int boot_cpu_physical_apicid;
-extern cpumask_t phys_cpu_present_map;
 extern int smp_found_config;
 extern void find_smp_config (void);
 extern void get_smp_config (void);
@@ -42,5 +41,49 @@ extern void mp_config_ioapic_for_sci(int
 extern void mp_parse_prt (void);
 #endif /*CONFIG_ACPI_BOOT*/
 
+#define PHYSID_ARRAY_SIZE	BITS_TO_LONGS(MAX_APICS)
+
+struct physid_mask
+{
+	unsigned long mask[PHYSID_ARRAY_SIZE];
+};
+
+typedef struct physid_mask physid_mask_t;
+
+#define physid_set(physid, map)			set_bit(physid, (map).mask)
+#define physid_clear(physid, map)		clear_bit(physid, (map).mask)
+#define physid_isset(physid, map)		test_bit(physid, (map).mask)
+#define physid_test_and_set(physid, map)	test_and_set_bit(physid, (map).mask)
+
+#define physids_and(dst, src1, src2)		bitmap_and((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_or(dst, src1, src2)		bitmap_or((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_clear(map)			bitmap_clear((map).mask, MAX_APICS)
+#define physids_complement(map)			bitmap_complement((map).mask, MAX_APICS)
+#define physids_empty(map)			bitmap_empty((map).mask, MAX_APICS)
+#define physids_equal(map1, map2)		bitmap_equal((map1).mask, (map2).mask, MAX_APICS)
+#define physids_weight(map)			bitmap_weight((map).mask, MAX_APICS)
+#define physids_shift_right(d, s, n)		bitmap_shift_right((d).mask, (s).mask, n, MAX_APICS)
+#define physids_shift_left(d, s, n)		bitmap_shift_left((d).mask, (s).mask, n, MAX_APICS)
+#define physids_coerce(map)			((map).mask[0])
+
+#define physids_promote(physids)						\
+	({									\
+		physid_mask_t __physid_mask = PHYSID_MASK_NONE;			\
+		__physid_mask.mask[0] = physids;				\
+		__physid_mask;							\
+	})
+
+#define physid_mask_of_physid(physid)						\
+	({									\
+		physid_mask_t __physid_mask = PHYSID_MASK_NONE;			\
+		physid_set(physid, __physid_mask);				\
+		__physid_mask;							\
+	})
+
+#define PHYSID_MASK_ALL		{ {[0 ... PHYSID_ARRAY_SIZE-1] = ~0UL} }
+#define PHYSID_MASK_NONE	{ {[0 ... PHYSID_ARRAY_SIZE-1] = 0UL} }
+
+extern physid_mask_t phys_cpu_present_map;
+
 #endif
 
diff -prauN virgin_cpu-2.5.74-1/include/asm-i386/smp.h virgin_cpu-2.5.74-2/include/asm-i386/smp.h
--- virgin_cpu-2.5.74-1/include/asm-i386/smp.h	2003-07-04 02:27:26.000000000 -0700
+++ virgin_cpu-2.5.74-2/include/asm-i386/smp.h	2003-07-04 02:29:01.000000000 -0700
@@ -32,7 +32,7 @@
  */
  
 extern void smp_alloc_memory(void);
-extern cpumask_t phys_cpu_present_map;
+extern physid_mask_t phys_cpu_present_map;
 extern int pic_mode;
 extern int smp_num_siblings;
 extern int cpu_sibling_map[];

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04  9:35   ` William Lee Irwin III
@ 2003-07-04  9:50     ` William Lee Irwin III
  2003-07-04 10:02       ` William Lee Irwin III
  2003-07-04 15:41       ` Martin J. Bligh
  0 siblings, 2 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04  9:50 UTC (permalink / raw)
  To: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
> Okay, now for the "final solution" wrt. sparse physical APIC ID's
> in addition to what I hope is a fix for your bug. This uses a separate
> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
> APIC ID bitmaps.
> \begin{cross-fingers}

This time diffed against the right tree:


diff -prauN mm1-2.5.74-1/arch/i386/kernel/apic.c physid-2.5.74-1/arch/i386/kernel/apic.c
--- mm1-2.5.74-1/arch/i386/kernel/apic.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/apic.c	2003-07-04 02:45:17.000000000 -0700
@@ -1137,7 +1137,7 @@ int __init APIC_init_uniprocessor (void)
 
 	connect_bsp_APIC();
 
-	phys_cpu_present_map = cpumask_of_cpu(boot_cpu_physical_apicid);
+	phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
 
 	setup_local_APIC();
 
diff -prauN mm1-2.5.74-1/arch/i386/kernel/io_apic.c physid-2.5.74-1/arch/i386/kernel/io_apic.c
--- mm1-2.5.74-1/arch/i386/kernel/io_apic.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/io_apic.c	2003-07-04 02:45:17.000000000 -0700
@@ -1601,7 +1601,7 @@ void disable_IO_APIC(void)
 static void __init setup_ioapic_ids_from_mpc(void)
 {
 	union IO_APIC_reg_00 reg_00;
-	cpumask_t phys_id_present_map;
+	physid_mask_t phys_id_present_map;
 	int apic;
 	int i;
 	unsigned char old_id;
@@ -1615,8 +1615,7 @@ static void __init setup_ioapic_ids_from
 	 * This is broken; anything with a real cpu count has to
 	 * circumvent this idiocy regardless.
 	 */
-	phys_id_present_map =
-		ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+	phys_id_present_map = ioapic_phys_id_map(phys_cpu_present_map);
 
 	/*
 	 * Set the IOAPIC ID to the value stored in the MPC table.
@@ -1647,20 +1646,20 @@ static void __init setup_ioapic_ids_from
 					mp_ioapics[apic].mpc_apicid)) {
 			printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n",
 				apic, mp_ioapics[apic].mpc_apicid);
-			for (i = 0; i < 0xf; i++)
-				if (!cpu_isset(i, phys_id_present_map))
+			for (i = 0; i < APIC_BROADCAST_ID; i++)
+				if (!physid_isset(i, phys_id_present_map))
 					break;
-			if (i >= 0xf)
+			if (i >= APIC_BROADCAST_ID)
 				panic("Max APIC ID exceeded!\n");
 			printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n",
 				i);
-			cpu_set(i, phys_id_present_map);
+			physid_set(i, phys_id_present_map);
 			mp_ioapics[apic].mpc_apicid = i;
 		} else {
-			cpumask_t tmp;
+			physid_mask_t tmp;
 			tmp = apicid_to_cpu_present(mp_ioapics[apic].mpc_apicid);
 			printk("Setting %d in the phys_id_present_map\n", mp_ioapics[apic].mpc_apicid);
-			cpus_or(phys_id_present_map, phys_id_present_map, tmp);
+			physids_or(phys_id_present_map, phys_id_present_map, tmp);
 		}
 
 
@@ -2230,8 +2229,8 @@ late_initcall(io_apic_bug_finalize);
 int __init io_apic_get_unique_id (int ioapic, int apic_id)
 {
 	union IO_APIC_reg_00 reg_00;
-	static cpumask_t apic_id_map = CPU_MASK_NONE;
-	cpumask_t tmp;
+	static physid_mask_t apic_id_map = CPU_MASK_NONE;
+	physid_mask_t tmp;
 	unsigned long flags;
 	int i = 0;
 
@@ -2244,8 +2243,8 @@ int __init io_apic_get_unique_id (int io
 	 *      advantage of new APIC bus architecture.
 	 */
 
-	if (cpus_empty(apic_id_map))
-		apic_id_map = ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+	if (physids_empty(apic_id_map))
+		apic_id_map = ioapic_phys_id_map(phys_cpu_present_map);
 
 	spin_lock_irqsave(&ioapic_lock, flags);
 	reg_00.raw = io_apic_read(ioapic, 0);
@@ -2278,7 +2277,7 @@ int __init io_apic_get_unique_id (int io
 	} 
 
 	tmp = apicid_to_cpu_present(apic_id);
-	cpus_or(apic_id_map, apic_id_map, tmp);
+	physids_or(apic_id_map, apic_id_map, tmp);
 
 	if (reg_00.bits.ID != apic_id) {
 		reg_00.bits.ID = apic_id;
diff -prauN mm1-2.5.74-1/arch/i386/kernel/mpparse.c physid-2.5.74-1/arch/i386/kernel/mpparse.c
--- mm1-2.5.74-1/arch/i386/kernel/mpparse.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/mpparse.c	2003-07-04 02:45:17.000000000 -0700
@@ -71,7 +71,7 @@ unsigned int boot_cpu_logical_apicid = -
 static unsigned int __initdata num_processors;
 
 /* Bitmask of physically existing CPUs */
-cpumask_t phys_cpu_present_map;
+physid_mask_t phys_cpu_present_map;
 
 u8 bios_cpu_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
 
@@ -106,7 +106,7 @@ static struct mpc_config_translation *tr
 void __init MP_processor_info (struct mpc_config_processor *m)
 {
  	int ver, apicid;
-	cpumask_t tmp;
+	physid_mask_t tmp;
  	
 	if (!(m->mpc_cpuflag & CPU_ENABLED))
 		return;
@@ -178,7 +178,7 @@ void __init MP_processor_info (struct mp
 	ver = m->mpc_apicver;
 
 	tmp = apicid_to_cpu_present(apicid);
-	cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
+	physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
 	
 	/*
 	 * Validate version
diff -prauN mm1-2.5.74-1/arch/i386/kernel/smpboot.c physid-2.5.74-1/arch/i386/kernel/smpboot.c
--- mm1-2.5.74-1/arch/i386/kernel/smpboot.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/smpboot.c	2003-07-04 02:45:17.000000000 -0700
@@ -957,7 +957,7 @@ static void __init smp_boot_cpus(unsigne
 	if (!smp_found_config) {
 		printk(KERN_NOTICE "SMP motherboard not detected.\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		if (APIC_init_uniprocessor())
 			printk(KERN_NOTICE "Local APIC not detected."
 					   " Using dummy APIC emulation.\n");
@@ -984,7 +984,7 @@ static void __init smp_boot_cpus(unsigne
 			boot_cpu_physical_apicid);
 		printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your hw vendor)\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		return;
 	}
 
@@ -997,7 +997,7 @@ static void __init smp_boot_cpus(unsigne
 		smp_found_config = 0;
 		printk(KERN_INFO "SMP mode deactivated, forcing use of dummy APIC emulation.\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		return;
 	}
 
@@ -1020,7 +1020,7 @@ static void __init smp_boot_cpus(unsigne
 	Dprintk("CPU present map: %lx\n", cpus_coerce(phys_cpu_present_map));
 
 	kicked = 1;
-	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
+	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
 		apicid = cpu_present_to_apicid(bit);
 		/*
 		 * Don't even attempt to start the boot CPU!
diff -prauN mm1-2.5.74-1/include/asm-i386/genapic.h physid-2.5.74-1/include/asm-i386/genapic.h
--- mm1-2.5.74-1/include/asm-i386/genapic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/genapic.h	2003-07-04 02:48:52.000000000 -0700
@@ -27,18 +27,18 @@ struct genapic { 
 	int int_dest_mode; 
 	int apic_broadcast_id; 
 	int esr_disable;
-	unsigned long (*check_apicid_used)(cpumask_const_t bitmap, int apicid);
+	unsigned long (*check_apicid_used)(physid_mask_t bitmap, int apicid);
 	unsigned long (*check_apicid_present)(int apicid); 
 	int no_balance_irq;
 	void (*init_apic_ldr)(void);
-	cpumask_t (*ioapic_phys_id_map)(cpumask_const_t map);
+	physid_mask_t (*ioapic_phys_id_map)(physid_mask_t map);
 
 	void (*clustered_apic_check)(void);
 	int (*multi_timer_check)(int apic, int irq);
 	int (*apicid_to_node)(int logical_apicid); 
 	int (*cpu_to_logical_apicid)(int cpu);
 	int (*cpu_present_to_apicid)(int mps_cpu);
-	cpumask_t (*apicid_to_cpu_present)(int phys_apicid);
+	physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
 	int (*mpc_apic_id)(struct mpc_config_processor *m, 
 			   struct mpc_config_translation *t); 
 	void (*setup_portio_remap)(void); 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:47:45.000000000 -0700
@@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE dest_LowestPrio
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
-#define APIC_BROADCAST_ID     (0x0f)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID     (0xff)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
 	return 0;
 }
 
 static inline unsigned long check_apicid_present(int bit) 
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 #define apicid_cluster(apicid) (apicid & 0xF0)
@@ -89,9 +89,9 @@ static inline int cpu_present_to_apicid(
 	return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	return cpumask_of_cpu(phys_apicid);
+	return physid_mask_of_physid(phys_apicid);
 }
 
 extern volatile u8 cpu_2_logical_apicid[];
@@ -112,10 +112,10 @@ static inline int mpc_apic_id(struct mpc
 	return m->mpc_apicid;
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0xFUL);
+	return physids_promote(0xFUL);
 }
 
 #define WAKE_SECONDARY_VIA_INIT
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h	2003-07-04 02:45:17.000000000 -0700
@@ -21,16 +21,20 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE dest_LowestPrio
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
+/*
+ * this isn't really broadcast, just a (potentially inaccurate) upper
+ * bound for valid physical APIC id's
+ */
 #define APIC_BROADCAST_ID      0x0F
 
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
-	return cpu_isset_const(apicid, bitmap);
+	return physid_isset(apicid, bitmap);
 }
 
 static inline unsigned long check_apicid_present(int bit)
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 /*
@@ -50,11 +54,9 @@ static inline void init_apic_ldr(void)
 	apic_write_around(APIC_LDR, val);
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
-	cpumask_t ret;
-	cpus_copy_const(ret, phys_map);
-	return ret;
+	return phys_map;
 }
 
 static inline void clustered_apic_check(void)
@@ -84,9 +86,9 @@ static inline int cpu_present_to_apicid(
 	return  mps_cpu;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	return cpumask_of_cpu(phys_apicid);
+	return physid_mask_of_physid(phys_apicid);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
@@ -106,12 +108,12 @@ static inline void setup_portio_remap(vo
 
 static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
 {
-	return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+	return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
 }
 
 static inline int apic_id_registered(void)
 {
-	return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+	return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
 }
 
 static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h	2003-07-04 02:46:36.000000000 -0700
@@ -40,13 +40,13 @@ static inline cpumask_t target_cpus(void
 
 #define APIC_BROADCAST_ID	(0xff)
 
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 { 
 	return 0;
 } 
 static inline unsigned long check_apicid_present(int bit) 
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 #define apicid_cluster(apicid) (apicid & 0xF0)
@@ -110,12 +110,12 @@ static inline int cpu_present_to_apicid(
 		return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	static int cpu = 0;
-	cpumask_t mask;
-	mask = cpumask_of_cpu(cpu);
-	++cpu;
+	static int id = 0;
+	physid_mask_t mask;
+	mask = physid_mask_of_physid(id);
+	++id;
 	return mask;
 }
 
@@ -136,10 +136,10 @@ static inline int mpc_apic_id(struct mpc
 	return (m->mpc_apicid);
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0xff);
+	return physids_promote(0xff);
 }
 
 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	2003-07-04 02:45:17.000000000 -0700
@@ -21,8 +21,8 @@ static inline cpumask_t target_cpus(void
 #define INT_DEST_MODE 0     /* physical delivery on LOCAL quad */
  
 #define APIC_BROADCAST_ID      0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
 #define apicid_cluster(apicid) (apicid & 0xF0)
 
 static inline int apic_id_registered(void)
@@ -50,10 +50,10 @@ static inline int multi_timer_check(int 
 	return apic != 0 && irq == 0;
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* We don't have a good way to do this yet - hack */
-	return cpus_promote(0xFUL);
+	return physids_promote(0xFUL);
 }
 
 /* Mapping from cpu number to logical apicid */
@@ -78,12 +78,12 @@ static inline int apicid_to_node(int log
 	return logical_apicid >> 4;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
 {
 	int node = apicid_to_node(logical_apicid);
 	int cpu = __ffs(logical_apicid & 0xf);
 
-	return cpumask_of_cpu(cpu + 4*node);
+	return physid_mask_of_physid(cpu + 4*node);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h	2003-07-04 02:47:00.000000000 -0700
@@ -28,8 +28,8 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE (dest_Fixed)
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
-#define APIC_BROADCAST_ID     (0x0F)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID     (0xFF)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
 	return 0;
 } 
@@ -88,15 +88,15 @@ static inline int cpu_present_to_apicid(
 	return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_id_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_id_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0x0F);
+	return physids_promote(0x0F);
 }
 
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
-	return cpumask_of_cpu(0);
+	return physid_mask_of_physid(0);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h	2003-07-04 02:45:17.000000000 -0700
@@ -16,12 +16,12 @@
 #endif
 
 #define APIC_BROADCAST_ID      0x0F
-#define check_apicid_used(bitmap, apicid)	cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit)		cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid)	physid_isset(apicid, bitmap)
+#define check_apicid_present(bit)		physid_isset(bit, phys_cpu_present_map)
 
 static inline int apic_id_registered(void)
 {
-	return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+	return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
 }
 
 /*
@@ -60,9 +60,9 @@ static inline int cpu_present_to_apicid(
 	return mps_cpu;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
-	return cpumask_of_cpu(apicid);
+	return physid_mask_of_physid(apicid);
 }
 
 #define WAKE_SECONDARY_VIA_INIT
@@ -77,7 +77,7 @@ static inline void enable_apic_mode(void
 
 static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
 {
-	return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+	return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
 }
 
 static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mpspec.h physid-2.5.74-1/include/asm-i386/mpspec.h
--- mm1-2.5.74-1/include/asm-i386/mpspec.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mpspec.h	2003-07-04 02:45:17.000000000 -0700
@@ -12,7 +12,6 @@ extern int quad_local_to_mp_bus_id [NR_C
 extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
 
 extern unsigned int boot_cpu_physical_apicid;
-extern cpumask_t phys_cpu_present_map;
 extern int smp_found_config;
 extern void find_smp_config (void);
 extern void get_smp_config (void);
@@ -42,5 +41,49 @@ extern void mp_config_ioapic_for_sci(int
 extern void mp_parse_prt (void);
 #endif /*CONFIG_ACPI_BOOT*/
 
+#define PHYSID_ARRAY_SIZE	BITS_TO_LONGS(MAX_APICS)
+
+struct physid_mask
+{
+	unsigned long mask[PHYSID_ARRAY_SIZE];
+};
+
+typedef struct physid_mask physid_mask_t;
+
+#define physid_set(physid, map)			set_bit(physid, (map).mask)
+#define physid_clear(physid, map)		clear_bit(physid, (map).mask)
+#define physid_isset(physid, map)		test_bit(physid, (map).mask)
+#define physid_test_and_set(physid, map)	test_and_set_bit(physid, (map).mask)
+
+#define physids_and(dst, src1, src2)		bitmap_and((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_or(dst, src1, src2)		bitmap_or((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_clear(map)			bitmap_clear((map).mask, MAX_APICS)
+#define physids_complement(map)			bitmap_complement((map).mask, MAX_APICS)
+#define physids_empty(map)			bitmap_empty((map).mask, MAX_APICS)
+#define physids_equal(map1, map2)		bitmap_equal((map1).mask, (map2).mask, MAX_APICS)
+#define physids_weight(map)			bitmap_weight((map).mask, MAX_APICS)
+#define physids_shift_right(d, s, n)		bitmap_shift_right((d).mask, (s).mask, n, MAX_APICS)
+#define physids_shift_left(d, s, n)		bitmap_shift_left((d).mask, (s).mask, n, MAX_APICS)
+#define physids_coerce(map)			((map).mask[0])
+
+#define physids_promote(physids)						\
+	({									\
+		physid_mask_t __physid_mask = PHYSID_MASK_NONE;			\
+		__physid_mask.mask[0] = physids;				\
+		__physid_mask;							\
+	})
+
+#define physid_mask_of_physid(physid)						\
+	({									\
+		physid_mask_t __physid_mask = PHYSID_MASK_NONE;			\
+		physid_set(physid, __physid_mask);				\
+		__physid_mask;							\
+	})
+
+#define PHYSID_MASK_ALL		{ {[0 ... PHYSID_ARRAY_SIZE-1] = ~0UL} }
+#define PHYSID_MASK_NONE	{ {[0 ... PHYSID_ARRAY_SIZE-1] = 0UL} }
+
+extern physid_mask_t phys_cpu_present_map;
+
 #endif
 
diff -prauN mm1-2.5.74-1/include/asm-i386/smp.h physid-2.5.74-1/include/asm-i386/smp.h
--- mm1-2.5.74-1/include/asm-i386/smp.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/smp.h	2003-07-04 02:45:17.000000000 -0700
@@ -32,7 +32,7 @@
  */
  
 extern void smp_alloc_memory(void);
-extern cpumask_t phys_cpu_present_map;
+extern physid_mask_t phys_cpu_present_map;
 extern int pic_mode;
 extern int smp_num_siblings;
 extern int cpu_sibling_map[];

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04  9:50     ` William Lee Irwin III
@ 2003-07-04 10:02       ` William Lee Irwin III
  2003-07-04 10:07         ` William Lee Irwin III
  2003-07-04 15:41       ` Martin J. Bligh
  1 sibling, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 10:02 UTC (permalink / raw)
  To: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 02:50:04AM -0700, William Lee Irwin III wrote:
> This time diffed against the right tree:

And this time with a one-line typo fixed (it seemed to compile anyway):
s/CPU_MASK_NONE/PHYSID_MASK_NONE/ somewhere in io_apic.c where a physid
mask was being initialized.


diff -prauN mm1-2.5.74-1/arch/i386/kernel/apic.c physid-2.5.74-1/arch/i386/kernel/apic.c
--- mm1-2.5.74-1/arch/i386/kernel/apic.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/apic.c	2003-07-04 02:45:17.000000000 -0700
@@ -1137,7 +1137,7 @@ int __init APIC_init_uniprocessor (void)
 
 	connect_bsp_APIC();
 
-	phys_cpu_present_map = cpumask_of_cpu(boot_cpu_physical_apicid);
+	phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
 
 	setup_local_APIC();
 
diff -prauN mm1-2.5.74-1/arch/i386/kernel/io_apic.c physid-2.5.74-1/arch/i386/kernel/io_apic.c
--- mm1-2.5.74-1/arch/i386/kernel/io_apic.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/io_apic.c	2003-07-04 02:53:32.000000000 -0700
@@ -1601,7 +1601,7 @@ void disable_IO_APIC(void)
 static void __init setup_ioapic_ids_from_mpc(void)
 {
 	union IO_APIC_reg_00 reg_00;
-	cpumask_t phys_id_present_map;
+	physid_mask_t phys_id_present_map;
 	int apic;
 	int i;
 	unsigned char old_id;
@@ -1615,8 +1615,7 @@ static void __init setup_ioapic_ids_from
 	 * This is broken; anything with a real cpu count has to
 	 * circumvent this idiocy regardless.
 	 */
-	phys_id_present_map =
-		ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+	phys_id_present_map = ioapic_phys_id_map(phys_cpu_present_map);
 
 	/*
 	 * Set the IOAPIC ID to the value stored in the MPC table.
@@ -1647,20 +1646,20 @@ static void __init setup_ioapic_ids_from
 					mp_ioapics[apic].mpc_apicid)) {
 			printk(KERN_ERR "BIOS bug, IO-APIC#%d ID %d is already used!...\n",
 				apic, mp_ioapics[apic].mpc_apicid);
-			for (i = 0; i < 0xf; i++)
-				if (!cpu_isset(i, phys_id_present_map))
+			for (i = 0; i < APIC_BROADCAST_ID; i++)
+				if (!physid_isset(i, phys_id_present_map))
 					break;
-			if (i >= 0xf)
+			if (i >= APIC_BROADCAST_ID)
 				panic("Max APIC ID exceeded!\n");
 			printk(KERN_ERR "... fixing up to %d. (tell your hw vendor)\n",
 				i);
-			cpu_set(i, phys_id_present_map);
+			physid_set(i, phys_id_present_map);
 			mp_ioapics[apic].mpc_apicid = i;
 		} else {
-			cpumask_t tmp;
+			physid_mask_t tmp;
 			tmp = apicid_to_cpu_present(mp_ioapics[apic].mpc_apicid);
 			printk("Setting %d in the phys_id_present_map\n", mp_ioapics[apic].mpc_apicid);
-			cpus_or(phys_id_present_map, phys_id_present_map, tmp);
+			physids_or(phys_id_present_map, phys_id_present_map, tmp);
 		}
 
 
@@ -2230,8 +2229,8 @@ late_initcall(io_apic_bug_finalize);
 int __init io_apic_get_unique_id (int ioapic, int apic_id)
 {
 	union IO_APIC_reg_00 reg_00;
-	static cpumask_t apic_id_map = CPU_MASK_NONE;
-	cpumask_t tmp;
+	static physid_mask_t apic_id_map = PHYSID_MASK_NONE;
+	physid_mask_t tmp;
 	unsigned long flags;
 	int i = 0;
 
@@ -2244,8 +2243,8 @@ int __init io_apic_get_unique_id (int io
 	 *      advantage of new APIC bus architecture.
 	 */
 
-	if (cpus_empty(apic_id_map))
-		apic_id_map = ioapic_phys_id_map(mk_cpumask_const(phys_cpu_present_map));
+	if (physids_empty(apic_id_map))
+		apic_id_map = ioapic_phys_id_map(phys_cpu_present_map);
 
 	spin_lock_irqsave(&ioapic_lock, flags);
 	reg_00.raw = io_apic_read(ioapic, 0);
@@ -2278,7 +2277,7 @@ int __init io_apic_get_unique_id (int io
 	} 
 
 	tmp = apicid_to_cpu_present(apic_id);
-	cpus_or(apic_id_map, apic_id_map, tmp);
+	physids_or(apic_id_map, apic_id_map, tmp);
 
 	if (reg_00.bits.ID != apic_id) {
 		reg_00.bits.ID = apic_id;
diff -prauN mm1-2.5.74-1/arch/i386/kernel/mpparse.c physid-2.5.74-1/arch/i386/kernel/mpparse.c
--- mm1-2.5.74-1/arch/i386/kernel/mpparse.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/mpparse.c	2003-07-04 02:45:17.000000000 -0700
@@ -71,7 +71,7 @@ unsigned int boot_cpu_logical_apicid = -
 static unsigned int __initdata num_processors;
 
 /* Bitmask of physically existing CPUs */
-cpumask_t phys_cpu_present_map;
+physid_mask_t phys_cpu_present_map;
 
 u8 bios_cpu_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
 
@@ -106,7 +106,7 @@ static struct mpc_config_translation *tr
 void __init MP_processor_info (struct mpc_config_processor *m)
 {
  	int ver, apicid;
-	cpumask_t tmp;
+	physid_mask_t tmp;
  	
 	if (!(m->mpc_cpuflag & CPU_ENABLED))
 		return;
@@ -178,7 +178,7 @@ void __init MP_processor_info (struct mp
 	ver = m->mpc_apicver;
 
 	tmp = apicid_to_cpu_present(apicid);
-	cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
+	physids_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
 	
 	/*
 	 * Validate version
diff -prauN mm1-2.5.74-1/arch/i386/kernel/smpboot.c physid-2.5.74-1/arch/i386/kernel/smpboot.c
--- mm1-2.5.74-1/arch/i386/kernel/smpboot.c	2003-07-03 12:23:55.000000000 -0700
+++ physid-2.5.74-1/arch/i386/kernel/smpboot.c	2003-07-04 02:45:17.000000000 -0700
@@ -957,7 +957,7 @@ static void __init smp_boot_cpus(unsigne
 	if (!smp_found_config) {
 		printk(KERN_NOTICE "SMP motherboard not detected.\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		if (APIC_init_uniprocessor())
 			printk(KERN_NOTICE "Local APIC not detected."
 					   " Using dummy APIC emulation.\n");
@@ -984,7 +984,7 @@ static void __init smp_boot_cpus(unsigne
 			boot_cpu_physical_apicid);
 		printk(KERN_ERR "... forcing use of dummy APIC emulation. (tell your hw vendor)\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		return;
 	}
 
@@ -997,7 +997,7 @@ static void __init smp_boot_cpus(unsigne
 		smp_found_config = 0;
 		printk(KERN_INFO "SMP mode deactivated, forcing use of dummy APIC emulation.\n");
 		smpboot_clear_io_apic_irqs();
-		phys_cpu_present_map = cpumask_of_cpu(0);
+		phys_cpu_present_map = physid_mask_of_physid(0);
 		return;
 	}
 
@@ -1020,7 +1020,7 @@ static void __init smp_boot_cpus(unsigne
 	Dprintk("CPU present map: %lx\n", cpus_coerce(phys_cpu_present_map));
 
 	kicked = 1;
-	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
+	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
 		apicid = cpu_present_to_apicid(bit);
 		/*
 		 * Don't even attempt to start the boot CPU!
diff -prauN mm1-2.5.74-1/include/asm-i386/genapic.h physid-2.5.74-1/include/asm-i386/genapic.h
--- mm1-2.5.74-1/include/asm-i386/genapic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/genapic.h	2003-07-04 02:48:52.000000000 -0700
@@ -27,18 +27,18 @@ struct genapic { 
 	int int_dest_mode; 
 	int apic_broadcast_id; 
 	int esr_disable;
-	unsigned long (*check_apicid_used)(cpumask_const_t bitmap, int apicid);
+	unsigned long (*check_apicid_used)(physid_mask_t bitmap, int apicid);
 	unsigned long (*check_apicid_present)(int apicid); 
 	int no_balance_irq;
 	void (*init_apic_ldr)(void);
-	cpumask_t (*ioapic_phys_id_map)(cpumask_const_t map);
+	physid_mask_t (*ioapic_phys_id_map)(physid_mask_t map);
 
 	void (*clustered_apic_check)(void);
 	int (*multi_timer_check)(int apic, int irq);
 	int (*apicid_to_node)(int logical_apicid); 
 	int (*cpu_to_logical_apicid)(int cpu);
 	int (*cpu_present_to_apicid)(int mps_cpu);
-	cpumask_t (*apicid_to_cpu_present)(int phys_apicid);
+	physid_mask_t (*apicid_to_cpu_present)(int phys_apicid);
 	int (*mpc_apic_id)(struct mpc_config_processor *m, 
 			   struct mpc_config_translation *t); 
 	void (*setup_portio_remap)(void); 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:47:45.000000000 -0700
@@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE dest_LowestPrio
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
-#define APIC_BROADCAST_ID     (0x0f)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID     (0xff)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
 	return 0;
 }
 
 static inline unsigned long check_apicid_present(int bit) 
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 #define apicid_cluster(apicid) (apicid & 0xF0)
@@ -89,9 +89,9 @@ static inline int cpu_present_to_apicid(
 	return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	return cpumask_of_cpu(phys_apicid);
+	return physid_mask_of_physid(phys_apicid);
 }
 
 extern volatile u8 cpu_2_logical_apicid[];
@@ -112,10 +112,10 @@ static inline int mpc_apic_id(struct mpc
 	return m->mpc_apicid;
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0xFUL);
+	return physids_promote(0xFUL);
 }
 
 #define WAKE_SECONDARY_VIA_INIT
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-default/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-default/mach_apic.h	2003-07-04 02:45:17.000000000 -0700
@@ -21,16 +21,20 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE dest_LowestPrio
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
+/*
+ * this isn't really broadcast, just a (potentially inaccurate) upper
+ * bound for valid physical APIC id's
+ */
 #define APIC_BROADCAST_ID      0x0F
 
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
-	return cpu_isset_const(apicid, bitmap);
+	return physid_isset(apicid, bitmap);
 }
 
 static inline unsigned long check_apicid_present(int bit)
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 /*
@@ -50,11 +54,9 @@ static inline void init_apic_ldr(void)
 	apic_write_around(APIC_LDR, val);
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
-	cpumask_t ret;
-	cpus_copy_const(ret, phys_map);
-	return ret;
+	return phys_map;
 }
 
 static inline void clustered_apic_check(void)
@@ -84,9 +86,9 @@ static inline int cpu_present_to_apicid(
 	return  mps_cpu;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	return cpumask_of_cpu(phys_apicid);
+	return physid_mask_of_physid(phys_apicid);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
@@ -106,12 +108,12 @@ static inline void setup_portio_remap(vo
 
 static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
 {
-	return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+	return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
 }
 
 static inline int apic_id_registered(void)
 {
-	return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+	return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
 }
 
 static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-es7000/mach_apic.h	2003-07-04 02:46:36.000000000 -0700
@@ -40,13 +40,13 @@ static inline cpumask_t target_cpus(void
 
 #define APIC_BROADCAST_ID	(0xff)
 
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 { 
 	return 0;
 } 
 static inline unsigned long check_apicid_present(int bit) 
 {
-	return cpu_isset(bit, phys_cpu_present_map);
+	return physid_isset(bit, phys_cpu_present_map);
 }
 
 #define apicid_cluster(apicid) (apicid & 0xF0)
@@ -110,12 +110,12 @@ static inline int cpu_present_to_apicid(
 		return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int phys_apicid)
 {
-	static int cpu = 0;
-	cpumask_t mask;
-	mask = cpumask_of_cpu(cpu);
-	++cpu;
+	static int id = 0;
+	physid_mask_t mask;
+	mask = physid_mask_of_physid(id);
+	++id;
 	return mask;
 }
 
@@ -136,10 +136,10 @@ static inline int mpc_apic_id(struct mpc
 	return (m->mpc_apicid);
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0xff);
+	return physids_promote(0xff);
 }
 
 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	2003-07-04 02:45:17.000000000 -0700
@@ -21,8 +21,8 @@ static inline cpumask_t target_cpus(void
 #define INT_DEST_MODE 0     /* physical delivery on LOCAL quad */
  
 #define APIC_BROADCAST_ID      0x0F
-#define check_apicid_used(bitmap, apicid) cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit) cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid) physid_isset(apicid, bitmap)
+#define check_apicid_present(bit) physid_isset(bit, phys_cpu_present_map)
 #define apicid_cluster(apicid) (apicid & 0xF0)
 
 static inline int apic_id_registered(void)
@@ -50,10 +50,10 @@ static inline int multi_timer_check(int 
 	return apic != 0 && irq == 0;
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_map)
 {
 	/* We don't have a good way to do this yet - hack */
-	return cpus_promote(0xFUL);
+	return physids_promote(0xFUL);
 }
 
 /* Mapping from cpu number to logical apicid */
@@ -78,12 +78,12 @@ static inline int apicid_to_node(int log
 	return logical_apicid >> 4;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
+static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
 {
 	int node = apicid_to_node(logical_apicid);
 	int cpu = __ffs(logical_apicid & 0xf);
 
-	return cpumask_of_cpu(cpu + 4*node);
+	return physid_mask_of_physid(cpu + 4*node);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-summit/mach_apic.h	2003-07-04 02:47:00.000000000 -0700
@@ -28,8 +28,8 @@ static inline cpumask_t target_cpus(void
 #define INT_DELIVERY_MODE (dest_Fixed)
 #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
 
-#define APIC_BROADCAST_ID     (0x0F)
-static inline unsigned long check_apicid_used(cpumask_const_t bitmap, int apicid)
+#define APIC_BROADCAST_ID     (0xFF)
+static inline unsigned long check_apicid_used(physid_mask_t bitmap, int apicid)
 {
 	return 0;
 } 
@@ -88,15 +88,15 @@ static inline int cpu_present_to_apicid(
 	return (int) bios_cpu_apicid[mps_cpu];
 }
 
-static inline cpumask_t ioapic_phys_id_map(cpumask_const_t phys_id_map)
+static inline physid_mask_t ioapic_phys_id_map(physid_mask_t phys_id_map)
 {
 	/* For clustered we don't have a good way to do this yet - hack */
-	return cpus_promote(0x0F);
+	return physids_promote(0x0F);
 }
 
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
-	return cpumask_of_cpu(0);
+	return physid_mask_of_physid(0);
 }
 
 static inline int mpc_apic_id(struct mpc_config_processor *m, 
diff -prauN mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h
--- mm1-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mach-visws/mach_apic.h	2003-07-04 02:45:17.000000000 -0700
@@ -16,12 +16,12 @@
 #endif
 
 #define APIC_BROADCAST_ID      0x0F
-#define check_apicid_used(bitmap, apicid)	cpu_isset_const(apicid, bitmap)
-#define check_apicid_present(bit)		cpu_isset(bit, phys_cpu_present_map)
+#define check_apicid_used(bitmap, apicid)	physid_isset(apicid, bitmap)
+#define check_apicid_present(bit)		physid_isset(bit, phys_cpu_present_map)
 
 static inline int apic_id_registered(void)
 {
-	return cpu_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
+	return physid_isset(GET_APIC_ID(apic_read(APIC_ID)), phys_cpu_present_map);
 }
 
 /*
@@ -60,9 +60,9 @@ static inline int cpu_present_to_apicid(
 	return mps_cpu;
 }
 
-static inline cpumask_t apicid_to_cpu_present(int apicid)
+static inline physid_mask_t apicid_to_cpu_present(int apicid)
 {
-	return cpumask_of_cpu(apicid);
+	return physid_mask_of_physid(apicid);
 }
 
 #define WAKE_SECONDARY_VIA_INIT
@@ -77,7 +77,7 @@ static inline void enable_apic_mode(void
 
 static inline int check_phys_apicid_present(int boot_cpu_physical_apicid)
 {
-	return cpu_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
+	return physid_isset(boot_cpu_physical_apicid, phys_cpu_present_map);
 }
 
 static inline unsigned int cpu_mask_to_apicid(cpumask_const_t cpumask)
diff -prauN mm1-2.5.74-1/include/asm-i386/mpspec.h physid-2.5.74-1/include/asm-i386/mpspec.h
--- mm1-2.5.74-1/include/asm-i386/mpspec.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/mpspec.h	2003-07-04 02:45:17.000000000 -0700
@@ -12,7 +12,6 @@ extern int quad_local_to_mp_bus_id [NR_C
 extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
 
 extern unsigned int boot_cpu_physical_apicid;
-extern cpumask_t phys_cpu_present_map;
 extern int smp_found_config;
 extern void find_smp_config (void);
 extern void get_smp_config (void);
@@ -42,5 +41,49 @@ extern void mp_config_ioapic_for_sci(int
 extern void mp_parse_prt (void);
 #endif /*CONFIG_ACPI_BOOT*/
 
+#define PHYSID_ARRAY_SIZE	BITS_TO_LONGS(MAX_APICS)
+
+struct physid_mask
+{
+	unsigned long mask[PHYSID_ARRAY_SIZE];
+};
+
+typedef struct physid_mask physid_mask_t;
+
+#define physid_set(physid, map)			set_bit(physid, (map).mask)
+#define physid_clear(physid, map)		clear_bit(physid, (map).mask)
+#define physid_isset(physid, map)		test_bit(physid, (map).mask)
+#define physid_test_and_set(physid, map)	test_and_set_bit(physid, (map).mask)
+
+#define physids_and(dst, src1, src2)		bitmap_and((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_or(dst, src1, src2)		bitmap_or((dst).mask, (src1).mask, (src2).mask, MAX_APICS)
+#define physids_clear(map)			bitmap_clear((map).mask, MAX_APICS)
+#define physids_complement(map)			bitmap_complement((map).mask, MAX_APICS)
+#define physids_empty(map)			bitmap_empty((map).mask, MAX_APICS)
+#define physids_equal(map1, map2)		bitmap_equal((map1).mask, (map2).mask, MAX_APICS)
+#define physids_weight(map)			bitmap_weight((map).mask, MAX_APICS)
+#define physids_shift_right(d, s, n)		bitmap_shift_right((d).mask, (s).mask, n, MAX_APICS)
+#define physids_shift_left(d, s, n)		bitmap_shift_left((d).mask, (s).mask, n, MAX_APICS)
+#define physids_coerce(map)			((map).mask[0])
+
+#define physids_promote(physids)						\
+	({									\
+		physid_mask_t __physid_mask = PHYSID_MASK_NONE;			\
+		__physid_mask.mask[0] = physids;				\
+		__physid_mask;							\
+	})
+
+#define physid_mask_of_physid(physid)						\
+	({									\
+		physid_mask_t __physid_mask = PHYSID_MASK_NONE;			\
+		physid_set(physid, __physid_mask);				\
+		__physid_mask;							\
+	})
+
+#define PHYSID_MASK_ALL		{ {[0 ... PHYSID_ARRAY_SIZE-1] = ~0UL} }
+#define PHYSID_MASK_NONE	{ {[0 ... PHYSID_ARRAY_SIZE-1] = 0UL} }
+
+extern physid_mask_t phys_cpu_present_map;
+
 #endif
 
diff -prauN mm1-2.5.74-1/include/asm-i386/smp.h physid-2.5.74-1/include/asm-i386/smp.h
--- mm1-2.5.74-1/include/asm-i386/smp.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-1/include/asm-i386/smp.h	2003-07-04 02:45:17.000000000 -0700
@@ -32,7 +32,7 @@
  */
  
 extern void smp_alloc_memory(void);
-extern cpumask_t phys_cpu_present_map;
+extern physid_mask_t phys_cpu_present_map;
 extern int pic_mode;
 extern int smp_num_siblings;
 extern int cpu_sibling_map[];

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 10:02       ` William Lee Irwin III
@ 2003-07-04 10:07         ` William Lee Irwin III
  2003-07-04 11:12           ` Helge Hafting
  0 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 10:07 UTC (permalink / raw)
  To: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 02:50:04AM -0700, William Lee Irwin III wrote:
>> This time diffed against the right tree:

On Fri, Jul 04, 2003 at 03:02:17AM -0700, William Lee Irwin III wrote:
> And this time with a one-line typo fixed (it seemed to compile anyway):
> s/CPU_MASK_NONE/PHYSID_MASK_NONE/ somewhere in io_apic.c where a physid
> mask was being initialized.

Unrelated tangent:

Nuke cpumask_arith.h; it's unused as of the requested updates to use
strong typing for all arches.


-- wli


diff -prauN physid-2.5.74-1/include/asm-generic/cpumask_arith.h physid-2.5.74-2/include/asm-generic/cpumask_arith.h
--- physid-2.5.74-1/include/asm-generic/cpumask_arith.h	2003-07-03 12:23:56.000000000 -0700
+++ physid-2.5.74-2/include/asm-generic/cpumask_arith.h	1969-12-31 16:00:00.000000000 -0800
@@ -1,61 +0,0 @@
-#ifndef __ASM_GENERIC_CPUMASK_ARITH_H
-#define __ASM_GENERIC_CPUMASK_ARITH_H
-
-#define cpu_set(cpu, map)				\
-	do {						\
-		map |= ((cpumask_t)1) << (cpu);		\
-	} while (0)
-#define cpu_clear(cpu, map)				\
-	do {						\
-		map &= ~(((cpumask_t)1) << (cpu));	\
-	} while (0)
-#define cpu_isset(cpu, map)				\
-	((map) & (((cpumask_t)1) << (cpu)))
-#define cpu_test_and_set(cpu, map)			\
-	test_and_set_bit(cpu, (unsigned long *)(&(map)))
-
-#define cpus_and(dst,src1,src2)		do { dst = (src1) & (src2); } while (0)
-#define cpus_or(dst,src1,src2)		do { dst = (src1) | (src2); } while (0)
-#define cpus_clear(map)			do { map = 0; } while (0)
-#define cpus_complement(map)		do { map = ~(map); } while (0)
-#define cpus_equal(map1, map2)		((map1) == (map2))
-#define cpus_empty(map)			((map) == 0)
-
-#if BITS_PER_LONG == 32
-#if NR_CPUS <= 32
-#define cpus_weight(map)		hweight32(map)
-#else
-#define cpus_weight(map)				\
-({							\
-	u32 *__map = (u32 *)(&(map));			\
-	hweight32(__map[0]) + hweight32(__map[1]);	\
-})
-#endif
-#elif BITS_PER_LONG == 64
-#define cpus_weight(map)		hweight64(map)
-#endif
-
-#define cpus_shift_right(dst, src, n)	do { dst = (src) >> (n); } while (0)
-#define cpus_shift_left(dst, src, n)	do { dst = (src) >> (n); } while (0)
-
-#define any_online_cpu(map)		(!cpus_empty(map))
-
-
-#define CPU_MASK_ALL	(~((cpumask_t)0) >> (8*sizeof(cpumask_t) - NR_CPUS))
-#define CPU_MASK_NONE	((cpumask_t)0)
-
-/* only ever use this for things that are _never_ used on large boxen */
-#define cpus_coerce(map)		((unsigned long)(map))
-#define cpus_promote(map)		({ map; })
-#define cpumask_of_cpu(cpu)		({ ((cpumask_t)1) << (cpu); })
-
-#ifdef CONFIG_SMP
-#define first_cpu(map)			__ffs(map)
-#define next_cpu(cpu, map)				\
-	__ffs((map) & ~(((cpumask_t)1 << (cpu)) - 1))
-#else
-#define first_cpu(map)			0
-#define next_cpu(cpu, map)		1
-#endif /* CONFIG_SMP */
-
-#endif /* __ASM_GENERIC_CPUMASK_ARITH_H */

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 11:12           ` Helge Hafting
@ 2003-07-04 11:10             ` William Lee Irwin III
  2003-07-04 12:50             ` Vincent Hanquez
  1 sibling, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 11:10 UTC (permalink / raw)
  To: Helge Hafting; +Cc: Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 01:12:12PM +0200, Helge Hafting wrote:
> I applied both of your recent patches, and the patched
> 2.5.74-mm1 kernel came up fine. :-)

Terrific!

Sorry about the confusion at first. I apparently made a boo boo when
sizing the physid maps as NR_CPUS bits.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 10:07         ` William Lee Irwin III
@ 2003-07-04 11:12           ` Helge Hafting
  2003-07-04 11:10             ` William Lee Irwin III
  2003-07-04 12:50             ` Vincent Hanquez
  0 siblings, 2 replies; 147+ messages in thread
From: Helge Hafting @ 2003-07-04 11:12 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Andrew Morton, linux-kernel, linux-mm

I applied both of your recent patches, and the patched
2.5.74-mm1 kernel came up fine. :-)


ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
  IO-APIC (apicid-pin) 2-0, 2-5, 2-9, 2-11, 2-17, 2-19 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 22.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................


Helge Hafting


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 11:12           ` Helge Hafting
  2003-07-04 11:10             ` William Lee Irwin III
@ 2003-07-04 12:50             ` Vincent Hanquez
  1 sibling, 0 replies; 147+ messages in thread
From: Vincent Hanquez @ 2003-07-04 12:50 UTC (permalink / raw)
  To: Helge Hafting; +Cc: William Lee Irwin III, linux-kernel

On Fri, Jul 04, 2003 at 01:12:12PM +0200, Helge Hafting wrote:
> I applied both of your recent patches, and the patched
> 2.5.74-mm1 kernel came up fine. :-)

theses patchs fix the problem for me too.

-- 
Tab

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04  9:50     ` William Lee Irwin III
  2003-07-04 10:02       ` William Lee Irwin III
@ 2003-07-04 15:41       ` Martin J. Bligh
  2003-07-04 15:47         ` Zwane Mwaikambo
  2003-07-04 18:26         ` William Lee Irwin III
  1 sibling, 2 replies; 147+ messages in thread
From: Martin J. Bligh @ 2003-07-04 15:41 UTC (permalink / raw)
  To: William Lee Irwin III, Helge Hafting, Andrew Morton,
	linux-kernel, linux-mm

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> Okay, now for the "final solution" wrt. sparse physical APIC ID's
>> in addition to what I hope is a fix for your bug. This uses a separate
>> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
>> APIC ID bitmaps.
>> \begin{cross-fingers}

Is it really necessary to turn half the apic code upside down in order
to fix this? What's the actual bugfix that's buried in this cleanup?

Despite the fact you seem to have gone out of your way to make this
hard to review, there are a few things I can see that strike me as odd.
Not necessarily wrong, but requiring more explanation.

> -			if (i >= 0xf)
> +			if (i >= APIC_BROADCAST_ID)

Is that always correct? it's not equivalent.

> -	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
> +	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {

Is that the actual one-line bugfix this is all about?

> diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
> --- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
> +++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:47:45.000000000 -0700
> @@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
>  #define INT_DELIVERY_MODE dest_LowestPrio
>  #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
>  
> -#define APIC_BROADCAST_ID     (0x0f)
> +#define APIC_BROADCAST_ID     (0xff)

So ... you've tested that change on a bigsmp machine, right? 
At least, provide some reasoning here. Like this comment further down the
patch ...

> +/*
> + * this isn't really broadcast, just a (potentially inaccurate) upper
> + * bound for valid physical APIC id's
> + */

Which makes the change just look wrong to me. If you're thinking 
"physical clustered mode" that terminology just utterly confusing crap, 
and the change is wrong, as far as I can see. 

> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	
> 2003-07-04 02:45:17.000000000 -0700
>
> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>  {
>  	int node = apicid_to_node(logical_apicid);
>  	int cpu = __ffs(logical_apicid & 0xf);
>  
> -	return cpumask_of_cpu(cpu + 4*node);
> +	return physid_mask_of_physid(cpu + 4*node);
>  }

Hmmmm. What are you using physical apicids here for? They seem
irrelevant to this function. 

M.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 15:41       ` Martin J. Bligh
@ 2003-07-04 15:47         ` Zwane Mwaikambo
  2003-07-04 16:18           ` Martin J. Bligh
  2003-07-04 18:29           ` William Lee Irwin III
  2003-07-04 18:26         ` William Lee Irwin III
  1 sibling, 2 replies; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04 15:47 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: William Lee Irwin III, Helge Hafting, Andrew Morton,
	linux-kernel, linux-mm

On Fri, 4 Jul 2003, Martin J. Bligh wrote:

> Is it really necessary to turn half the apic code upside down in order
> to fix this? What's the actual bugfix that's buried in this cleanup?

The way i see it is that you can't use NR_CPUS to determine the upper 
bound on APIC IDs. e.g. my 3way is normally configured with NR_CPUS = 3 
but has APIC IDs of 0, 3 and 4. We need to make a distinction.

> Despite the fact you seem to have gone out of your way to make this
> hard to review, there are a few things I can see that strike me as odd.
> Not necessarily wrong, but requiring more explanation.
> 
> > -			if (i >= 0xf)
> > +			if (i >= APIC_BROADCAST_ID)
> 
> Is that always correct? it's not equivalent.

Well we really want APIC_MAX_ID (or whatever it's called)

> > -	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
> > +	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
> 
> Is that the actual one-line bugfix this is all about?

No, the problem is no space for physical ids in cpumask bitmaps, this 
could manifest itself later on unless we fix it now.

> > -#define APIC_BROADCAST_ID     (0x0f)
> > +#define APIC_BROADCAST_ID     (0xff)
> 
> So ... you've tested that change on a bigsmp machine, right? 
> At least, provide some reasoning here. Like this comment further down the
> patch ...

That one is slightly worrying, yes.

> > + * this isn't really broadcast, just a (potentially inaccurate) upper
> > + * bound for valid physical APIC id's
> 
> Which makes the change just look wrong to me. If you're thinking 
> "physical clustered mode" that terminology just utterly confusing crap, 
> and the change is wrong, as far as I can see. 
> 
> > +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	
> > 2003-07-04 02:45:17.000000000 -0700
> >
> > -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
> > +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
> >  {
> >  	int node = apicid_to_node(logical_apicid);
> >  	int cpu = __ffs(logical_apicid & 0xf);
> >  
> > -	return cpumask_of_cpu(cpu + 4*node);
> > +	return physid_mask_of_physid(cpu + 4*node);
> >  }
> 
> Hmmmm. What are you using physical apicids here for? They seem
> irrelevant to this function. 

Urgh, it's really hard to determine what these functions really want half 
the time. But that change does look wrong.

	Zwane
-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 16:18           ` Martin J. Bligh
@ 2003-07-04 16:16             ` Zwane Mwaikambo
  2003-07-04 18:31             ` William Lee Irwin III
                               ` (2 subsequent siblings)
  3 siblings, 0 replies; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04 16:16 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: William Lee Irwin III, Helge Hafting, Andrew Morton,
	linux-kernel, linux-mm

On Fri, 4 Jul 2003, Martin J. Bligh wrote:

> > No, the problem is no space for physical ids in cpumask bitmaps, this 
> > could manifest itself later on unless we fix it now.
> 
> Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
> NR_CPUS is low enough? If so, I can see more point to the patch, but
> it still seems like violent overkill. Stopping it doing that would
> probably fix it ... I can't imagine it buys you much.

Hmm i hope not, Bill can you verify that? Looking at the source it doesn't 
appear to be so;

#define BITS_TO_LONGS(bits) \
	(((bits)+BITS_PER_LONG-1)/BITS_PER_LONG)
#define DECLARE_BITMAP(name,bits) \
	unsigned long name[BITS_TO_LONGS(bits)]

> phys_cpu_present_map started off as an unsigned long, and I reused it
> in a fairly twisted way for NUMA-Q. As it's an array that's bounded
> by apic space, using the bios_cpu_apicid method that summit uses
> would be a much cleaner fix, and just leave the old one as a long
> bitmask like it used to be - which is fine for non- clustered apic
> systems, and saves inventing a whole new data type. See the
> cpu_present_to_apicid abstraction.

Thanks i'll have a look.

-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 15:47         ` Zwane Mwaikambo
@ 2003-07-04 16:18           ` Martin J. Bligh
  2003-07-04 16:16             ` Zwane Mwaikambo
                               ` (3 more replies)
  2003-07-04 18:29           ` William Lee Irwin III
  1 sibling, 4 replies; 147+ messages in thread
From: Martin J. Bligh @ 2003-07-04 16:18 UTC (permalink / raw)
  To: Zwane Mwaikambo
  Cc: William Lee Irwin III, Helge Hafting, Andrew Morton,
	linux-kernel, linux-mm

> On Fri, 4 Jul 2003, Martin J. Bligh wrote:
> 
>> Is it really necessary to turn half the apic code upside down in order
>> to fix this? What's the actual bugfix that's buried in this cleanup?
> 
> The way i see it is that you can't use NR_CPUS to determine the upper 
> bound on APIC IDs. e.g. my 3way is normally configured with NR_CPUS = 3 
> but has APIC IDs of 0, 3 and 4. We need to make a distinction.

Fair enough. But that would seem to be a simpler operation than this patch.

>> > -			if (i >= 0xf)
>> > +			if (i >= APIC_BROADCAST_ID)
>> 
>> Is that always correct? it's not equivalent.
> 
> Well we really want APIC_MAX_ID (or whatever it's called)

Indeed. maybe MAX_PHYS_APIC_ID or something (it's different for logical).
We break it out in subarch, but it's the same everywhere, which seems
utterly useless - is probably historical cruft that needs to die.
But that sounds like a separate issue, and a separate patch to me.

>> > -	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
>> > +	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
>> 
>> Is that the actual one-line bugfix this is all about?
> 
> No, the problem is no space for physical ids in cpumask bitmaps, this 
> could manifest itself later on unless we fix it now.

Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
NR_CPUS is low enough? If so, I can see more point to the patch, but
it still seems like violent overkill. Stopping it doing that would
probably fix it ... I can't imagine it buys you much.

phys_cpu_present_map started off as an unsigned long, and I reused it
in a fairly twisted way for NUMA-Q. As it's an array that's bounded
by apic space, using the bios_cpu_apicid method that summit uses
would be a much cleaner fix, and just leave the old one as a long
bitmask like it used to be - which is fine for non- clustered apic
systems, and saves inventing a whole new data type. See the
cpu_present_to_apicid abstraction.

>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function. 
> 
> Urgh, it's really hard to determine what these functions really want half 
> the time. But that change does look wrong.

Yeah, things taking logical apicids, and turning them into cpu numbers
presumably shouldn't have to touch that.

M.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 15:41       ` Martin J. Bligh
  2003-07-04 15:47         ` Zwane Mwaikambo
@ 2003-07-04 18:26         ` William Lee Irwin III
  2003-07-04 19:38           ` Martin J. Bligh
  1 sibling, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:26 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> Okay, now for the "final solution" wrt. sparse physical APIC ID's
>>> in addition to what I hope is a fix for your bug. This uses a separate
>>> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
>>> APIC ID bitmaps.
>>> \begin{cross-fingers}

On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Is it really necessary to turn half the apic code upside down in order
> to fix this? What's the actual bugfix that's buried in this cleanup?
> Despite the fact you seem to have gone out of your way to make this
> hard to review, there are a few things I can see that strike me as odd.
> Not necessarily wrong, but requiring more explanation.

It's not a cleanup, and it doesn't touch trailing whitespace etc.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> -			if (i >= 0xf)
>> +			if (i >= APIC_BROADCAST_ID)

On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Is that always correct? it's not equivalent.

It is.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> -	for (bit = 0; kicked < NR_CPUS && bit < 8*sizeof(cpumask_t); bit++) {
>> +	for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {

On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Is that the actual one-line bugfix this is all about?

No.

On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
>> --- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
>> +++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:47:45.000000000 -0700
>> @@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
>>  #define INT_DELIVERY_MODE dest_LowestPrio
>>  #define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
>> -#define APIC_BROADCAST_ID     (0x0f)
>> +#define APIC_BROADCAST_ID     (0xff)

On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> So ... you've tested that change on a bigsmp machine, right? 
> At least, provide some reasoning here. Like this comment further down the
> patch ...

APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
is used in the code. That actually was commented in the patch.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> +/*
>> + * this isn't really broadcast, just a (potentially inaccurate) upper
>> + * bound for valid physical APIC id's
>> + */

On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Which makes the change just look wrong to me. If you're thinking 
> "physical clustered mode" that terminology just utterly confusing crap, 
> and the change is wrong, as far as I can see. 

The change is correct, and I am not thinking of any such thing.
APIC_BROADCAST_ID's sole usage is for terminating loops over physical
APIC ID's while setting the physical APIC ID's of IO-APIC's.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	
>> 2003-07-04 02:45:17.000000000 -0700
>>
>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>>  {
>>  	int node = apicid_to_node(logical_apicid);
>>  	int cpu = __ffs(logical_apicid & 0xf);
>>  
>> -	return cpumask_of_cpu(cpu + 4*node);
>> +	return physid_mask_of_physid(cpu + 4*node);
>>  }

On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
> Hmmmm. What are you using physical apicids here for? They seem
> irrelevant to this function. 

Look at where it's used.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 15:47         ` Zwane Mwaikambo
  2003-07-04 16:18           ` Martin J. Bligh
@ 2003-07-04 18:29           ` William Lee Irwin III
  1 sibling, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:29 UTC (permalink / raw)
  To: Zwane Mwaikambo
  Cc: Martin J. Bligh, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

At some point in the past, I wrote:
>>> -#define APIC_BROADCAST_ID     (0x0f)
>>> +#define APIC_BROADCAST_ID     (0xff)

On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>> So ... you've tested that change on a bigsmp machine, right? 
>> At least, provide some reasoning here. Like this comment further down the
>> patch ...

On Fri, Jul 04, 2003 at 11:47:03AM -0400, Zwane Mwaikambo wrote:
> That one is slightly worrying, yes.

It is not. It's a bound on physical APIC ID's. bigsmp is xAPIC-based.


At some point in the past, I wrote:
>>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	
>>> 2003-07-04 02:45:17.000000000 -0700
>>>
>>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>>>  {
>>>  	int node = apicid_to_node(logical_apicid);
>>>  	int cpu = __ffs(logical_apicid & 0xf);
>>>  
>>> -	return cpumask_of_cpu(cpu + 4*node);
>>> +	return physid_mask_of_physid(cpu + 4*node);
>>>  }

On Fri, 4 Jul 2003, Martin J. Bligh wrote:
>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function. 

On Fri, Jul 04, 2003 at 11:47:03AM -0400, Zwane Mwaikambo wrote:
> Urgh, it's really hard to determine what these functions really want half 
> the time. But that change does look wrong.

It's fine. It's used to generate a bitmask that's or'd with
phys_cpu_present_map.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 16:18           ` Martin J. Bligh
  2003-07-04 16:16             ` Zwane Mwaikambo
@ 2003-07-04 18:31             ` William Lee Irwin III
  2003-07-04 19:20               ` Martin J. Bligh
  2003-07-04 18:32             ` William Lee Irwin III
  2003-07-04 18:36             ` William Lee Irwin III
  3 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:31 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Yeah, things taking logical apicids, and turning them into cpu numbers
> presumably shouldn't have to touch that.

The bitmap is wider than the function wants. The change is fine, despite
your abuse of phys_cpu_present_map.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 16:18           ` Martin J. Bligh
  2003-07-04 16:16             ` Zwane Mwaikambo
  2003-07-04 18:31             ` William Lee Irwin III
@ 2003-07-04 18:32             ` William Lee Irwin III
  2003-07-04 18:36             ` William Lee Irwin III
  3 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:32 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
> NR_CPUS is low enough? If so, I can see more point to the patch, but
> it still seems like violent overkill. Stopping it doing that would
> probably fix it ... I can't imagine it buys you much.

Step off it. This is not overkill. This is correct.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 16:18           ` Martin J. Bligh
                               ` (2 preceding siblings ...)
  2003-07-04 18:32             ` William Lee Irwin III
@ 2003-07-04 18:36             ` William Lee Irwin III
  3 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 18:36 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

At some point in the past, zwane wrote:
>> The way i see it is that you can't use NR_CPUS to determine the upper 
>> bound on APIC IDs. e.g. my 3way is normally configured with NR_CPUS = 3 
>> but has APIC IDs of 0, 3 and 4. We need to make a distinction.

On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Fair enough. But that would seem to be a simpler operation than this patch.

It is not a simpler operation. It is the patch.

On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> We break it out in subarch, but it's the same everywhere, which seems
> utterly useless - is probably historical cruft that needs to die.
> But that sounds like a separate issue, and a separate patch to me.

The change is correct. Let it stand.


On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Ugh, are you saying the cpumask stuff shrinks masks to < 32 bits if
> NR_CPUS is low enough? If so, I can see more point to the patch, but
> it still seems like violent overkill. Stopping it doing that would
> probably fix it ... I can't imagine it buys you much.

This change is also correct. Let it stand.


On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> phys_cpu_present_map started off as an unsigned long, and I reused it
> in a fairly twisted way for NUMA-Q. As it's an array that's bounded
> by apic space, using the bios_cpu_apicid method that summit uses
> would be a much cleaner fix, and just leave the old one as a long
> bitmask like it used to be - which is fine for non- clustered apic
> systems, and saves inventing a whole new data type. See the
> cpu_present_to_apicid abstraction.

The precise thing this does is making phys_cpu_present_map an array
bounded by the APIC space. The change is correct. Let it stand.


At some point in the past, zwane wrote:
>> Urgh, it's really hard to determine what these functions really want half 
>> the time. But that change does look wrong.

On Fri, Jul 04, 2003 at 09:18:12AM -0700, Martin J. Bligh wrote:
> Yeah, things taking logical apicids, and turning them into cpu numbers
> presumably shouldn't have to touch that.

The cpu bitmasks change width with NR_CPUS. The APIC ID spaces do not.
They must hence be bitmasks of separate widths. Hence the change is
correct. Let it stand.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 18:31             ` William Lee Irwin III
@ 2003-07-04 19:20               ` Martin J. Bligh
  2003-07-04 19:31                 ` William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Martin J. Bligh @ 2003-07-04 19:20 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

>> Yeah, things taking logical apicids, and turning them into cpu numbers
>> presumably shouldn't have to touch that.
> 
> The bitmap is wider than the function wants. The change is fine, despite
> your abuse of phys_cpu_present_map.

I'm happy to remove the abuse of phys_cpu_present_map, seeing as we now
have a reason to do so. That would actually seem a much cleaner solution
to these problems than creating a whole new data type, which still doesn't
represent what it claims to


M.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 19:20               ` Martin J. Bligh
@ 2003-07-04 19:31                 ` William Lee Irwin III
  2003-07-04 19:53                   ` Martin J. Bligh
  0 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 19:31 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

At some point in the past, I wrote:
>> The bitmap is wider than the function wants. The change is fine, despite
>> your abuse of phys_cpu_present_map.

On Fri, Jul 04, 2003 at 12:20:02PM -0700, Martin J. Bligh wrote:
> I'm happy to remove the abuse of phys_cpu_present_map, seeing as we now
> have a reason to do so. That would actually seem a much cleaner solution
> to these problems than creating a whole new data type, which still doesn't
> represent what it claims to

Dirtier, but possibly lower line count.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 18:26         ` William Lee Irwin III
@ 2003-07-04 19:38           ` Martin J. Bligh
  2003-07-04 20:07             ` William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Martin J. Bligh @ 2003-07-04 19:38 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>>> Okay, now for the "final solution" wrt. sparse physical APIC ID's
>>>> in addition to what I hope is a fix for your bug. This uses a separate
>>>> bitmap type (of a NR_CPUS -independent width MAX_APICS) for physical
>>>> APIC ID bitmaps.
>>>> \begin{cross-fingers}
> 
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Is it really necessary to turn half the apic code upside down in order
>> to fix this? What's the actual bugfix that's buried in this cleanup?
>> Despite the fact you seem to have gone out of your way to make this
>> hard to review, there are a few things I can see that strike me as odd.
>> Not necessarily wrong, but requiring more explanation.
> 
> It's not a cleanup, and it doesn't touch trailing whitespace etc.

Maybe not, but it looks like one. Maybe if you actually explain
what you're trying to fix, and why?

I think this kind of change deserves a better explanation that 
"I'm right" ... that's my main objection.

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> -			if (i >= 0xf)
>>> +			if (i >= APIC_BROADCAST_ID)
> 
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Is that always correct? it's not equivalent.
> 
> It is.

Explain. Not obvious to the casual observer.

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> diff -prauN mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h
>>> --- mm1-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-03 12:23:56.000000000 -0700
>>> +++ physid-2.5.74-1/include/asm-i386/mach-bigsmp/mach_apic.h	2003-07-04 02:47:45.000000000 -0700
>>> @@ -29,15 +29,15 @@ static inline cpumask_t target_cpus(void
>>>  # define INT_DELIVERY_MODE dest_LowestPrio
>>>  # define INT_DEST_MODE 1     /* logical delivery broadcast to all procs */
>>> -#define APIC_BROADCAST_ID     (0x0f)
>>> +#define APIC_BROADCAST_ID     (0xff)
> 
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> So ... you've tested that change on a bigsmp machine, right? 
>> At least, provide some reasoning here. Like this comment further down the
>> patch ...
> 
> APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
> is used in the code. That actually was commented in the patch.

I find it odd that this worked before then. Also seems to be a separate
issue from the rest of the patch. Is quite probably correct, is just
non-obvious in the context of the rest of the patch.

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> +/*
>>> + * this isn't really broadcast, just a (potentially inaccurate) upper
>>> + * bound for valid physical APIC id's
>>> + */
> 
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Which makes the change just look wrong to me. If you're thinking 
>> "physical clustered mode" that terminology just utterly confusing crap, 
>> and the change is wrong, as far as I can see. 
> 
> The change is correct, and I am not thinking of any such thing.
> APIC_BROADCAST_ID's sole usage is for terminating loops over physical
> APIC ID's while setting the physical APIC ID's of IO-APIC's.

Why is Summit 0xF, and bigsmp 0xFF then?

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> +++ physid-2.5.74-1/include/asm-i386/mach-numaq/mach_apic.h	
>>> 2003-07-04 02:45:17.000000000 -0700
>>> 
>>> -static inline cpumask_t apicid_to_cpu_present(int logical_apicid)
>>> +static inline physid_mask_t apicid_to_cpu_present(int logical_apicid)
>>>  {
>>>  	int node = apicid_to_node(logical_apicid);
>>>  	int cpu = __ffs(logical_apicid & 0xf);
>>>  
>>> -	return cpumask_of_cpu(cpu + 4*node);
>>> +	return physid_mask_of_physid(cpu + 4*node);
>>>  }
> 
> On Fri, Jul 04, 2003 at 08:41:38AM -0700, Martin J. Bligh wrote:
>> Hmmmm. What are you using physical apicids here for? They seem
>> irrelevant to this function. 
> 
> Look at where it's used.

I did. Still unclear why you think this is correct, or what physical
apicids have to do with a function that maps from apicids to  the
phys_cpu_present_map, which is a compact mapping of logical apicids
for NUMA-Q.

Sorry, but this needs more explanation.

M.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 19:31                 ` William Lee Irwin III
@ 2003-07-04 19:53                   ` Martin J. Bligh
  2003-07-04 20:17                     ` William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Martin J. Bligh @ 2003-07-04 19:53 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

--William Lee Irwin III <wli@holomorphy.com> wrote (on Friday, July 04, 2003 12:31:35 -0700):

> At some point in the past, I wrote:
>>> The bitmap is wider than the function wants. The change is fine, despite
>>> your abuse of phys_cpu_present_map.
> 
> On Fri, Jul 04, 2003 at 12:20:02PM -0700, Martin J. Bligh wrote:
>> I'm happy to remove the abuse of phys_cpu_present_map, seeing as we now
>> have a reason to do so. That would actually seem a much cleaner solution
>> to these problems than creating a whole new data type, which still doesn't
>> represent what it claims to
> 
> Dirtier, but possibly lower line count.

I disagree with the "dirtier" bit, but still. I'd rather have this sort
of stuff put into subarch, where most people don't have to look at it.

More to the point, the changes would be confined to the big-iron arches,
and have less chance of breaking anyone else for things they don't
care about, nor do them any benefit. Touching this code is fragile as
hell, so if it can be confined, it should be ...

It'd also remove the long-standing abuse of phys_cpu_present_map, which
would probably make the rest of the code clearer.

M.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 19:38           ` Martin J. Bligh
@ 2003-07-04 20:07             ` William Lee Irwin III
  2003-07-04 20:37               ` Martin J. Bligh
  0 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 20:07 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> It's not a cleanup, and it doesn't touch trailing whitespace etc.

On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> Maybe not, but it looks like one. Maybe if you actually explain
> what you're trying to fix, and why?
> I think this kind of change deserves a better explanation that 
> "I'm right" ... that's my main objection.

I'll try to be more verbose, then.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> It is.

On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> Explain. Not obvious to the casual observer.

The function assigns physical APIC ID's to IO-APIC's. The loop is
intended to iterate over the physical APIC ID space. 0xf is an
inaccurate description of the upper bound on the physical APIC ID space.
APIC_BROADCAST_ID is a more accurate upper bound.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
>> is used in the code. That actually was commented in the patch.

On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> I find it odd that this worked before then. Also seems to be a separate
> issue from the rest of the patch. Is quite probably correct, is just
> non-obvious in the context of the rest of the patch.

I audited not only for usage of limited-width bitmaps for APIC ID
spaces, but also improper bounds on iterations over APIC ID spaces.
Things ran out of APIC ID's when phys_cpu_present_map was NR_CPUS
wide. This patch makes the limits accurate to the hardware with
the brute-force application of bitmaps. The semantic impact of
dropping in a bitmap is very low. The issue that arose was that it
wasn't wide enough, which was obvious enough to spot as a thinko
without even testing.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> The change is correct, and I am not thinking of any such thing.
>> APIC_BROADCAST_ID's sole usage is for terminating loops over physical
>> APIC ID's while setting the physical APIC ID's of IO-APIC's.

On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> Why is Summit 0xF, and bigsmp 0xFF then?

Summit (and all other xAPIC-based subarches) should be 0xFF; I missed
it in the sweep.


On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>> Look at where it's used.

On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
> I did. Still unclear why you think this is correct, or what physical
> apicids have to do with a function that maps from apicids to  the
> phys_cpu_present_map, which is a compact mapping of logical apicids
> for NUMA-Q.
> Sorry, but this needs more explanation.

The bitmap width is sufficient. NUMA-Q abuses what everything else
uses for physical APIC ID's (partly because of the BIOS). It so happens
that the array is MAX_APICS wide, which suffices for NUMA-Q (and
anything else that cares to use it).

No. This was not written for or around NUMA-Q; it's meant for the
io_apic.c loops and sparse physid wakeup on non-NUMA-Q machines.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 19:53                   ` Martin J. Bligh
@ 2003-07-04 20:17                     ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 20:17 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Zwane Mwaikambo, Helge Hafting, Andrew Morton, linux-kernel, linux-mm

William Lee Irwin III <wli@holomorphy.com> wrote (on Friday, July 04, 2003 12:31:35 -0700):
>> Dirtier, but possibly lower line count.

On Fri, Jul 04, 2003 at 12:53:54PM -0700, Martin J. Bligh wrote:
> I disagree with the "dirtier" bit, but still. I'd rather have this sort
> of stuff put into subarch, where most people don't have to look at it.
> More to the point, the changes would be confined to the big-iron arches,
> and have less chance of breaking anyone else for things they don't
> care about, nor do them any benefit. Touching this code is fragile as
> hell, so if it can be confined, it should be ...
> It'd also remove the long-standing abuse of phys_cpu_present_map, which
> would probably make the rest of the code clearer.

That's a change with deeper semantic implications as it's relying on
different information.

The phys_cpu_present_map bits were to divorce its width from NR_CPUS
in a portable way. Shifting to bios_cpu_map[] should only change cpu
wakeup. IO-APIC physid reassignment code still needs a variable-width
map (I suppose you could use integers) of some kind.

-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works.
  2003-07-04 20:07             ` William Lee Irwin III
@ 2003-07-04 20:37               ` Martin J. Bligh
  0 siblings, 0 replies; 147+ messages in thread
From: Martin J. Bligh @ 2003-07-04 20:37 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Helge Hafting, Andrew Morton, linux-kernel, linux-mm

>> Maybe not, but it looks like one. Maybe if you actually explain
>> what you're trying to fix, and why?
>> I think this kind of change deserves a better explanation that 
>> "I'm right" ... that's my main objection.
> 
> I'll try to be more verbose, then.

Thanks ... will help a lot ;-)

> On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
>> Explain. Not obvious to the casual observer.
> 
> The function assigns physical APIC ID's to IO-APIC's. The loop is
> intended to iterate over the physical APIC ID space. 0xf is an
> inaccurate description of the upper bound on the physical APIC ID space.
> APIC_BROADCAST_ID is a more accurate upper bound.

OK, you're right. Is just confusing because it works as it is right 
now ... even on a 32x system - however, that's only because Summit
doesn't actually run that region of code, and NUMA-Q ignores it.

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> APIC_BROADCAST_ID is an upper bound on valid physical APIC ID's as it
>>> is used in the code. That actually was commented in the patch.
> 
> On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
>> I find it odd that this worked before then. Also seems to be a separate
>> issue from the rest of the patch. Is quite probably correct, is just
>> non-obvious in the context of the rest of the patch.
> 
> I audited not only for usage of limited-width bitmaps for APIC ID
> spaces, but also improper bounds on iterations over APIC ID spaces.
> Things ran out of APIC ID's when phys_cpu_present_map was NR_CPUS
> wide. This patch makes the limits accurate to the hardware with
> the brute-force application of bitmaps. The semantic impact of
> dropping in a bitmap is very low. The issue that arose was that it
> wasn't wide enough, which was obvious enough to spot as a thinko
> without even testing.
>
>> Why is Summit 0xF, and bigsmp 0xFF then?
> 
> Summit (and all other xAPIC-based subarches) should be 0xFF; I missed
> it in the sweep.

OK. Makes more sense now if both are that way.

> On Fri, Jul 04, 2003 at 02:35:31AM -0700, William Lee Irwin III wrote:
>>> Look at where it's used.
> 
> On Fri, Jul 04, 2003 at 12:38:19PM -0700, Martin J. Bligh wrote:
>> I did. Still unclear why you think this is correct, or what physical
>> apicids have to do with a function that maps from apicids to  the
>> phys_cpu_present_map, which is a compact mapping of logical apicids
>> for NUMA-Q.
>> Sorry, but this needs more explanation.
> 
> The bitmap width is sufficient. NUMA-Q abuses what everything else
> uses for physical APIC ID's (partly because of the BIOS). It so happens
> that the array is MAX_APICS wide, which suffices for NUMA-Q (and
> anything else that cares to use it).
> 
> No. This was not written for or around NUMA-Q; it's meant for the
> io_apic.c loops and sparse physid wakeup on non-NUMA-Q machines.

OK, maybe this is just an extension of my earlier abuse - in which 
case, let's just remove it. Was bad enough before, but now even I 
can't understand it, and I wrote the damned thing.

So yes, it looks correct. I'll see if I can see a neat way to bury this
under the existing abstractions like Summit does ... I'm not sure it's
a good idea to have two different methods for this; that whole area of
code is getting horribly complicated ...

Thanks very much for the explanations,

M.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (6 preceding siblings ...)
  2003-07-04  8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
@ 2003-07-04 21:07 ` William Lee Irwin III
  2003-07-05  1:15   ` 2.5.74-mm1 Andrew Morton
  2003-07-05  0:16 ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 13:38 ` OOPS: 2.5.74-mm2 Maciej Soltysiak
  9 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 21:07 UTC (permalink / raw)
  To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm

On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/

anton saw the OOM killer try to kill pdflush, causing tons of spurious
wakeups. This should avoid picking kernel threads in select_bad_process().


-- wli


===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c	Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c	Fri Jul  4 14:03:32 2003
@@ -123,7 +123,7 @@
 	struct task_struct *chosen = NULL;
 
 	do_each_thread(g, p)
-		if (p->pid) {
+		if (p->pid && p->mm) {
 			int points = badness(p);
 			if (points > maxpoints) {
 				chosen = p;

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (7 preceding siblings ...)
  2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05  0:16 ` Daniel Phillips
  2003-07-05 15:28   ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 13:38 ` OOPS: 2.5.74-mm2 Maciej Soltysiak
  9 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05  0:16 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel, linux-mm

On Thursday 03 July 2003 11:37, Andrew Morton wrote:
> . Included Con's CPU scheduler changes.  Feedback on the effectiveness of
>   this and the usual benchmarks would be interesting.
>
>   Changes to the CPU scheduler tend to cause surprising and subtle problems
>   in areas where you least expect it, and these do take a long time to
>   materialise.  Alterations in there need to be made carefully and
>   cautiously. We shall see...

It now tolerates window dragging on this unaccelerated moderately high 
resolution VGA without any sound dropouts.  There are still dropouts while 
scrolling in Mozilla, so it acts much like 2.5.73+Con's patch, as expected. 

I had 2.5.74 freeze up a couple of times yesterday, resulting in a totally 
dead, unpingable system, so now I'm running 2.5.74-mm1 with kgdb and hoping 
to catch one of those beasts in the wild.  The most recent incident occurred 
while switching from X to text console, which did not complete, leaving me 
with no debugging data whatsover.  That was with sound running.  Switching to 
the text console always results in a massive sound skip, so there is a clue.  
XFree is running generic VGA, so I don't seriously suspect the driver, and 
even so, it should not be able to kill the system completely dead.

System details are as I reported earlier:

   AMD K7 1666 (actual) MHz, 512 MB, VIA VTxxx chipset.  Video hardware is
   S3 ProSavage K4M266, unaccelerated VGA mode, 1280x1024x16.  Software is
   2.5.73+Gnome+Metacity+ALSA+Zinf.  Running UP, no preempt.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05  1:15   ` Andrew Morton
  2003-07-05  5:21     ` 2.5.74-mm1 Anton Blanchard
  2003-07-05 10:44     ` 2.5.74-mm1 William Lee Irwin III
  0 siblings, 2 replies; 147+ messages in thread
From: Andrew Morton @ 2003-07-05  1:15 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: anton, linux-kernel, linux-mm

William Lee Irwin III <wli@holomorphy.com> wrote:
>
> On Thu, Jul 03, 2003 at 02:37:14AM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.74/2.5.74-mm1/
> 
> anton saw the OOM killer try to kill pdflush, causing tons of spurious
> wakeups. This should avoid picking kernel threads in select_bad_process().
> 
> 
> -- wli
> 
> 
> ===== mm/oom_kill.c 1.23 vs edited =====
> --- 1.23/mm/oom_kill.c	Wed Apr 23 03:15:53 2003
> +++ edited/mm/oom_kill.c	Fri Jul  4 14:03:32 2003
> @@ -123,7 +123,7 @@
>  	struct task_struct *chosen = NULL;
>  
>  	do_each_thread(g, p)
> -		if (p->pid) {
> +		if (p->pid && p->mm) {
>  			int points = badness(p);
>  			if (points > maxpoints) {
>  				chosen = p;

Look at select_bad_process(), and the ->mm test in badness().  pdflush
can never be chosen.

Nevertheless, there have been several report where kernel threads _are_ 
being hit my the oom killer.  Any idea why that is?


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05  1:15   ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05  5:21     ` Anton Blanchard
  2003-07-05 11:18       ` 2.5.74-mm1 William Lee Irwin III
  2003-07-05 10:44     ` 2.5.74-mm1 William Lee Irwin III
  1 sibling, 1 reply; 147+ messages in thread
From: Anton Blanchard @ 2003-07-05  5:21 UTC (permalink / raw)
  To: Andrew Morton; +Cc: William Lee Irwin III, linux-kernel, linux-mm


> Look at select_bad_process(), and the ->mm test in badness().  pdflush
> can never be chosen.
> 
> Nevertheless, there have been several report where kernel threads _are_ 
> being hit my the oom killer.  Any idea why that is?

Milton and I were just looking at this and it seems there is no locking
to prevent p->mm ending up NULL due to exit. And if p->mm does end up
NULL, you go off and kill all your kernel threads :)

Anton

	read_lock(&tasklist_lock);
	p = select_bad_process();

...

        oom_kill_task(p);
        /*
         * kill all processes that share the ->mm (i.e. all threads),
         * but are in a different thread group
         */
        do_each_thread(g, q)
                if (q->mm == p->mm && q->tgid != p->tgid)
                        oom_kill_task(q);
        while_each_thread(g, q);

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05  1:15   ` 2.5.74-mm1 Andrew Morton
  2003-07-05  5:21     ` 2.5.74-mm1 Anton Blanchard
@ 2003-07-05 10:44     ` William Lee Irwin III
  2003-07-05 18:43       ` 2.5.74-mm1 Andrew Morton
  1 sibling, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-05 10:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm

On Fri, Jul 04, 2003 at 06:15:39PM -0700, Andrew Morton wrote:
> Look at select_bad_process(), and the ->mm test in badness().  pdflush
> can never be chosen.
> Nevertheless, there have been several report where kernel threads _are_ 
> being hit my the oom killer.  Any idea why that is?

The badness() check isn't good enough. If badness() returns 0 for all
processes with pid's > 0 and the first one seen is a kernel thread the
kernel thread will be chosen. In principle, one could merely retarget
chosen with points >= maxpoints, but that's trivially defeated by
kernel threads landing at the highest pid for whatever reason.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05  5:21     ` 2.5.74-mm1 Anton Blanchard
@ 2003-07-05 11:18       ` William Lee Irwin III
  2003-07-05 11:46         ` 2.5.74-mm1 William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-05 11:18 UTC (permalink / raw)
  To: Anton Blanchard; +Cc: Andrew Morton, linux-kernel, linux-mm

At some point in the past, akpm wrote:
>> Look at select_bad_process(), and the ->mm test in badness().  pdflush
>> can never be chosen.
>> Nevertheless, there have been several report where kernel threads _are_ 
>> being hit my the oom killer.  Any idea why that is?

On Sat, Jul 05, 2003 at 03:21:02PM +1000, Anton Blanchard wrote:
> Milton and I were just looking at this and it seems there is no locking
> to prevent p->mm ending up NULL due to exit. And if p->mm does end up
> NULL, you go off and kill all your kernel threads :)

How about this, then? I think it's still racy against something doing
daemonize(), though (i.e. if q does daemonize() it shoots it regardless).


===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c	Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c	Sat Jul  5 04:15:25 2003
@@ -123,7 +123,7 @@
 	struct task_struct *chosen = NULL;
 
 	do_each_thread(g, p)
-		if (p->pid) {
+		if (p->pid && p->mm) {
 			int points = badness(p);
 			if (points > maxpoints) {
 				chosen = p;
@@ -141,7 +141,7 @@
  * CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
  * we select a process with CAP_SYS_RAW_IO set).
  */
-void oom_kill_task(struct task_struct *p)
+static void __oom_kill_task(task_t *p)
 {
 	printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm);
 
@@ -161,6 +161,15 @@
 	}
 }
 
+static struct mm_struct *oom_kill_task(task_t *p)
+{
+	struct mm_struct *mm = get_task_mm(p);
+	if (!mm || mm == &init_mm)
+		return NULL;
+	__oom_kill_task(p);
+}
+
+
 /**
  * oom_kill - kill the "best" process when we run out of memory
  *
@@ -171,9 +180,11 @@
  */
 static void oom_kill(void)
 {
+	struct mm_struct *mm;
 	struct task_struct *g, *p, *q;
 	
 	read_lock(&tasklist_lock);
+retry:
 	p = select_bad_process();
 
 	/* Found nothing?!?! Either we hang forever, or we panic. */
@@ -182,17 +193,20 @@
 		panic("Out of memory and no killable processes...\n");
 	}
 
-	oom_kill_task(p);
+	mm = oom_kill_task(p);
+	if (!mm)
+		goto retry;
 	/*
 	 * kill all processes that share the ->mm (i.e. all threads),
 	 * but are in a different thread group
 	 */
 	do_each_thread(g, q)
-		if (q->mm == p->mm && q->tgid != p->tgid)
-			oom_kill_task(q);
+		if (q->mm == mm && q->tgid != p->tgid)
+			__oom_kill_task(q);
 	while_each_thread(g, q);
 
 	read_unlock(&tasklist_lock);
+	mmput(mm);
 
 	/*
 	 * Make kswapd go out of the way, so "p" has a good chance of

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 11:18       ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 11:46         ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-05 11:46 UTC (permalink / raw)
  To: Anton Blanchard, Andrew Morton, linux-kernel, linux-mm

On Sat, Jul 05, 2003 at 04:18:44AM -0700, William Lee Irwin III wrote:
> How about this, then? I think it's still racy against something doing
> daemonize(), though (i.e. if q does daemonize() it shoots it regardless).

Take 2:


===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c	Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c	Sat Jul  5 04:46:17 2003
@@ -123,7 +123,7 @@
 	struct task_struct *chosen = NULL;
 
 	do_each_thread(g, p)
-		if (p->pid) {
+		if (p->pid && p->mm) {
 			int points = badness(p);
 			if (points > maxpoints) {
 				chosen = p;
@@ -141,7 +141,7 @@
  * CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
  * we select a process with CAP_SYS_RAW_IO set).
  */
-void oom_kill_task(struct task_struct *p)
+static void __oom_kill_task(task_t *p)
 {
 	printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm);
 
@@ -161,6 +161,16 @@
 	}
 }
 
+static struct mm_struct *oom_kill_task(task_t *p)
+{
+	struct mm_struct *mm = get_task_mm(p);
+	if (!mm || mm == &init_mm)
+		return NULL;
+	__oom_kill_task(p);
+	return mm;
+}
+
+
 /**
  * oom_kill - kill the "best" process when we run out of memory
  *
@@ -171,9 +181,11 @@
  */
 static void oom_kill(void)
 {
+	struct mm_struct *mm;
 	struct task_struct *g, *p, *q;
 	
 	read_lock(&tasklist_lock);
+retry:
 	p = select_bad_process();
 
 	/* Found nothing?!?! Either we hang forever, or we panic. */
@@ -182,17 +194,20 @@
 		panic("Out of memory and no killable processes...\n");
 	}
 
-	oom_kill_task(p);
+	mm = oom_kill_task(p);
+	if (!mm)
+		goto retry;
 	/*
 	 * kill all processes that share the ->mm (i.e. all threads),
 	 * but are in a different thread group
 	 */
 	do_each_thread(g, q)
-		if (q->mm == p->mm && q->tgid != p->tgid)
-			oom_kill_task(q);
+		if (q->mm == mm && q->tgid != p->tgid)
+			__oom_kill_task(q);
 	while_each_thread(g, q);
 
 	read_unlock(&tasklist_lock);
+	mmput(mm);
 
 	/*
 	 * Make kswapd go out of the way, so "p" has a good chance of

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05  0:16 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-05 15:28   ` Daniel Phillips
  2003-07-05 16:01     ` 2.5.74-mm1 Con Kolivas
                       ` (2 more replies)
  0 siblings, 3 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05 15:28 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel, linux-mm

On Saturday 05 July 2003 02:16, Daniel Phillips wrote:
> It now tolerates window dragging on this unaccelerated moderately high
> resolution VGA without any sound dropouts.  There are still dropouts while
> scrolling in Mozilla, so it acts much like 2.5.73+Con's patch, as expected.

Update: dropouts still do occur while moving windows, but rarely.  When they 
do occur, they are severe.  A debian dist-upgrade just caused a dropout - and 
another just now, about 3 seconds long.  I feel that tweaking is only going 
to get us so far with this.  The situation re scheduling in 2.5 feels much as 
the vm situation did in 2.3, in other words, we're halfway down a long twisty 
road that ends with something that works, after having tried and failed at 
many flavors of tweaking and tuning.  Ultimately the problem will be solved 
by redesign, and probably not just limited to kernel code.

> I had 2.5.74 freeze up a couple of times yesterday, resulting in a totally
> dead, unpingable system, so now I'm running 2.5.74-mm1 with kgdb and hoping
> to catch one of those beasts in the wild.

Update: this is easily repeatable.  A few quick switches between X and text 
mode triggers the freeze reliably.  On two occasions, I had a lockup while 
just doing an innocent window operation.  It also happens in 2.4, so it isn't 
a 2.5 problem per se.  Is it a pure hardware problem?  It's always easy to 
take that position.  I can only guess at the moment.  Kgdb is no help in 
diagnosing, as the kgdb stub also goes comatose, or at least the serial link 
does.  No lockups have occurred so far when I was not interacting with the 
system via the keyboard or mouse.  Suggestions?

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 15:28   ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-05 16:01     ` Con Kolivas
  2003-07-05 17:47       ` 2.5.74-mm1 Daniel Phillips
  2003-07-05 19:14     ` 2.5.74-mm1 Andrew Morton
  2003-07-05 19:40     ` 2.5.74-mm1 Diego Calleja García
  2 siblings, 1 reply; 147+ messages in thread
From: Con Kolivas @ 2003-07-05 16:01 UTC (permalink / raw)
  To: Daniel Phillips, Andrew Morton, linux-kernel, linux-mm

On Sun, 6 Jul 2003 01:28, Daniel Phillips wrote:
> On Saturday 05 July 2003 02:16, Daniel Phillips wrote:
> > It now tolerates window dragging on this unaccelerated moderately high
> > resolution VGA without any sound dropouts.  There are still dropouts
> > while scrolling in Mozilla, so it acts much like 2.5.73+Con's patch, as
> > expected.
>
> Update: dropouts still do occur while moving windows, but rarely.  When
> they do occur, they are severe.  A debian dist-upgrade just caused a
> dropout - and another just now, about 3 seconds long.  I feel that tweaking
> is only going to get us so far with this.  The situation re scheduling in
> 2.5 feels much as the vm situation did in 2.3, in other words, we're
> halfway down a long twisty road that ends with something that works, after
> having tried and failed at many flavors of tweaking and tuning.  Ultimately
> the problem will be solved by redesign, and probably not just limited to
> kernel code.

Have you taken the next twist in the road? I posted a second patch which 
should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in case, 
here is a link to it.

http://kernel.kolivas.org/2.5/

it's called patch-O2int-0307041440

It makes significant headway in smoothing the corner cases. I need testing at 
each point before I can post another update, and am doing much less frequent 
smaller updates now, with the aim of having no more than one patch for each 
-mm, so I can have a decent sized audience for each change.

Andrew can you please apply this one on top in the next -mm if you are to 
continue testing this patch series.

Con


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 16:01     ` 2.5.74-mm1 Con Kolivas
@ 2003-07-05 17:47       ` Daniel Phillips
  2003-07-06  3:41         ` 2.5.74-mm1 Con Kolivas
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05 17:47 UTC (permalink / raw)
  To: Con Kolivas, Andrew Morton, linux-kernel, linux-mm

On Saturday 05 July 2003 18:01, Con Kolivas wrote:
> Have you taken the next twist in the road? I posted a second patch which
> should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in
> case, here is a link to it.
>
> http://kernel.kolivas.org/2.5/
>
> it's called patch-O2int-0307041440

This one is a regression.  Window dragging now causes the same kind of 
dropouts as I saw on 2.5.73 mainline.  But see below.

> It makes significant headway in smoothing the corner cases. I need testing
> at each point before I can post another update, and am doing much less
> frequent smaller updates now, with the aim of having no more than one patch
> for each -mm, so I can have a decent sized audience for each change.
>
> Andrew can you please apply this one on top in the next -mm if you are to
> continue testing this patch series.

Well...

It should help you to know that up till now I've been running Zinf at priority 
0 (of -20..19).  I just changed change that to -10, and all the dropouts went 
away.  Duh.  The thing is, Zinf is a (soft) realtime application, or at least 
the sound servicing part of it is.  It's hard to see how the kernel can ever 
figure that out automagically - it has to be told.  So I told it.

My only reservation is that nice is not a very (ahem) nice way of doing this.  
We really want Zinf to take care of that itself.  Zinf knows it has a 
realtime component and it knows which component that is, so it needs to tell 
the kernel, presumeably via setpriority (nice is just a frontend to 
setpriority).  Blindly choosing some higher priority to run at is certainly 
crude, but for now it solves the problem, so I won't have to apologize to my 
wife about destroying her audio experience with the latest, greatest kernel.

Not having to worry about detecting and babying along the realtime sound 
thread should make your job considerably easier.  OK, looking at the Zinf 
code I see that it does know about thread priority, via pthreads.  It's 
either not working, or it's not set to sensible defaults.  I'm looking into 
that.

Now, just so this doesn't get too easy for you, I have a nice little opengl 
application here:

  http://nl.linux.org/~phillips/world.tgz
  (3D engine - see screenshots on the same page)

The "bounce" demo is suitable for testing how steady the framerate is.  It's 
working pretty well since 2.4.73, if you leave the window in one place, but 
scheduling gets challenging (i.e., sucks) when you drag the 3D window around.  
How should we fix that?  It's my code so I'm willing to add whatever priority 
control is appropriate.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 10:44     ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 18:43       ` Andrew Morton
  2003-07-05 21:17         ` 2.5.74-mm1 William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Andrew Morton @ 2003-07-05 18:43 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: anton, linux-kernel, linux-mm

William Lee Irwin III <wli@holomorphy.com> wrote:
>
> The badness() check isn't good enough. If badness() returns 0 for all
>  processes with pid's > 0 and the first one seen is a kernel thread the
>  kernel thread will be chosen.

Are we looking at the same code? 

static struct task_struct * select_bad_process(void)
{
	int maxpoints = 0;
	struct task_struct *g, *p;
	struct task_struct *chosen = NULL;

	do_each_thread(g, p)
		if (p->pid) {
			int points = badness(p);
			if (points > maxpoints) {
				chosen = p;
				maxpoints = points;
			}
			if (p->flags & PF_SWAPOFF)
				return p;
		}
	while_each_thread(g, p);
	return chosen;
}

if badness() returns zero for everything, this returns NULL and
the kernel panics.



^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 15:28   ` 2.5.74-mm1 Daniel Phillips
  2003-07-05 16:01     ` 2.5.74-mm1 Con Kolivas
@ 2003-07-05 19:14     ` Andrew Morton
  2003-07-05 21:09       ` 2.5.74-mm1 Daniel Phillips
  2003-07-06  0:10       ` 2.5.74-mm1 Daniel Phillips
  2003-07-05 19:40     ` 2.5.74-mm1 Diego Calleja García
  2 siblings, 2 replies; 147+ messages in thread
From: Andrew Morton @ 2003-07-05 19:14 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: linux-kernel, linux-mm

Daniel Phillips <phillips@arcor.de> wrote:
>
> The situation re scheduling in 2.5 feels much as 
> the vm situation did in 2.3

I've been trying to avoid thinking about that comparison.

I don't think it's really, really bad at present.  Just "should be a bit
better".

> Kgdb is no help in 
> diagnosing, as the kgdb stub also goes comatose, or at least the serial link 
> does.  No lockups have occurred so far when I was not interacting with the 
> system via the keyboard or mouse.  Suggestions?

Enable IO APIC, Local APIC, nmi watchdog.  Use serial console, see if you
can get a sysrq trace out of it.  That's `^A F T' in minicom.

I mean, it _has_ to be either stuck with interrupts on, or stuck with them off.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 15:28   ` 2.5.74-mm1 Daniel Phillips
  2003-07-05 16:01     ` 2.5.74-mm1 Con Kolivas
  2003-07-05 19:14     ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 19:40     ` Diego Calleja García
  2003-07-05 19:48       ` 2.5.74-mm1 Davide Libenzi
  2003-07-05 21:22       ` 2.5.74-mm1 Daniel Phillips
  2 siblings, 2 replies; 147+ messages in thread
From: Diego Calleja García @ 2003-07-05 19:40 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: akpm, linux-kernel


> to get us so far with this.  The situation re scheduling in 2.5 feels
> much as the vm situation did in 2.3, in other words, we're halfway down a
> long twisty road that ends with something that works, after having tried
> and failed at many flavors of tweaking and tuning.  Ultimately the
> problem will be solved by redesign, and probably not just limited to
> kernel code.

I never run 2.3, but 2.5 behaviour has been much better in the past. I used
to run make -j25 and mp3 didn't skip, X and all apps were still very
reponsive.

That was a lot of releases ago, before the so called linus' "interactivity"
patch. IMHO the behaviour in those releases was great; i think the
scheduler just needs a bit of tweaking from the Ingo's hand :)

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 19:40     ` 2.5.74-mm1 Diego Calleja García
@ 2003-07-05 19:48       ` Davide Libenzi
  2003-07-05 21:22       ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 0 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-05 19:48 UTC (permalink / raw)
  To: Diego Calleja García
  Cc: Daniel Phillips, Andrew Morton, Linux Kernel Mailing List

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 782 bytes --]

On Sat, 5 Jul 2003, Diego Calleja [ISO-8859-15] García wrote:

>
> > to get us so far with this.  The situation re scheduling in 2.5 feels
> > much as the vm situation did in 2.3, in other words, we're halfway down a
> > long twisty road that ends with something that works, after having tried
> > and failed at many flavors of tweaking and tuning.  Ultimately the
> > problem will be solved by redesign, and probably not just limited to
> > kernel code.
>
> I never run 2.3, but 2.5 behaviour has been much better in the past. I used
> to run make -j25 and mp3 didn't skip, X and all apps were still very
> reponsive.

The first releases we shoot out were very good indeed. Now I believe
something got lost in the "evolution". Let's wait Ingo to come back
from Mars :)


- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 19:14     ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 21:09       ` Daniel Phillips
  2003-07-05 21:44         ` 2.5.74-mm1 Jamie Lokier
  2003-07-05 22:11         ` 2.5.74-mm1 Diego Calleja García
  2003-07-06  0:10       ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 2 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05 21:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm

On Saturday 05 July 2003 21:14, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> > The situation re scheduling in 2.5 feels much as
> > the vm situation did in 2.3
>
> I've been trying to avoid thinking about that comparison.
>
> I don't think it's really, really bad at present.  Just "should be a bit
> better".

Ever since I -niced Zinf a coupld of hours ago I haven't had a problem.  This 
is a fine way to handle the problem.  We're not dealing with an "interactive 
scheduling" problem here, it's simply realtime scheduling and needs to be 
treated as such.

Unfortunately, negative priority requires root privilege, at least on Debian.  
That's dumb.  By default, the root privilege requirement should kick in at 
something like -5 or -10, so  ordinary users can set priorities higher than 
the default, as well as lower.  For the millions of desktop users out there, 
sound ought to work by default, not be broken by default.

The "better" mechanism for sound scheduling is SCHED_RR, which requires root 
privilege for some reason that isn't clear to me.  Or maybe there once was a 
good reason, back in the days of the dinosaurs.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 18:43       ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 21:17         ` William Lee Irwin III
  2003-07-05 21:27           ` 2.5.74-mm1 Andrew Morton
  0 siblings, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-05 21:17 UTC (permalink / raw)
  To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm

On Sat, Jul 05, 2003 at 11:43:08AM -0700, Andrew Morton wrote:
> if badness() returns zero for everything, this returns NULL and
> the kernel panics.

Sorry, that was one hell of an oversight wrt. the initival value.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 19:40     ` 2.5.74-mm1 Diego Calleja García
  2003-07-05 19:48       ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-05 21:22       ` Daniel Phillips
  1 sibling, 0 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05 21:22 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: akpm, linux-kernel

On Saturday 05 July 2003 21:40, Diego Calleja García wrote:
> > to get us so far with this.  The situation re scheduling in 2.5 feels
> > much as the vm situation did in 2.3, in other words, we're halfway down a
> > long twisty road that ends with something that works, after having tried
> > and failed at many flavors of tweaking and tuning.  Ultimately the
> > problem will be solved by redesign, and probably not just limited to
> > kernel code.
>
> I never run 2.3, but 2.5 behaviour has been much better in the past. I used
> to run make -j25 and mp3 didn't skip, X and all apps were still very
> reponsive.
>
> That was a lot of releases ago, before the so called linus' "interactivity"
> patch. IMHO the behaviour in those releases was great; i think the
> scheduler just needs a bit of tweaking from the Ingo's hand :)

It is good, so long as the sound process runs at a higher-than-default 
priority.  Trying to get sound to run skiplessly at the same priority as a 
normal process is just a waste of time.  If it happens to work in some kernel 
versions or hardware configurations, it's an accident.

Though I've admittedly only done a small of testing, I haven't seen a glitch 
recently.  I'm a happy camper.  (Right now I'm running make -j25, apt-get 
installing OpenOffice and listening to Bolero.)

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 21:17         ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-05 21:27           ` Andrew Morton
  2003-07-05 22:03             ` 2.5.74-mm1 William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Andrew Morton @ 2003-07-05 21:27 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: anton, linux-kernel, linux-mm

William Lee Irwin III <wli@holomorphy.com> wrote:
>
> On Sat, Jul 05, 2003 at 11:43:08AM -0700, Andrew Morton wrote:
> > if badness() returns zero for everything, this returns NULL and
> > the kernel panics.
> 
> Sorry, that was one hell of an oversight wrt. the initival value.

You made me read that code about 20 times ;)

Still.  Do we think we know what the actual bug is?  That tasklist_lock
doesn't pin tsk->mm?

If so then let's get that patch of yours happening, but please enhance it to

a) detect the situation where the mm went away, and tell us that it was
   fixed up.  Sufficient to confirm your theory.

b) put in an explicit check for a kill of an mm-less process.  print a
   warning, skip the process.



^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 21:09       ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-05 21:44         ` Jamie Lokier
  2003-07-05 22:10           ` 2.5.74-mm1 Daniel Phillips
  2003-07-05 22:11         ` 2.5.74-mm1 Diego Calleja García
  1 sibling, 1 reply; 147+ messages in thread
From: Jamie Lokier @ 2003-07-05 21:44 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Andrew Morton, linux-kernel, linux-mm

Daniel Phillips wrote:
> Unfortunately, negative priority requires root privilege, at least
> on Debian.
>
> That's dumb.  By default, the root privilege requirement should kick
> in at something like -5 or -10, so ordinary users can set priorities
> higher than the default, as well as lower.  For the millions of
> desktop users out there, sound ought to work by default, not be
> broken by default.

The security problem, on a multi-user box, is that negative priority
apps can easily take all of the CPU and effectively lock up the box.

Something I've often thought would fix this is to allow normal users
to set negative priority which is limited to using X% of the CPU -
i.e. those tasks would have their priority raised if they spent more
than a small proportion of their time using the CPU.

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 21:27           ` 2.5.74-mm1 Andrew Morton
@ 2003-07-05 22:03             ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-05 22:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: anton, linux-kernel, linux-mm

William Lee Irwin III <wli@holomorphy.com> wrote:
>> Sorry, that was one hell of an oversight wrt. the initival value.

On Sat, Jul 05, 2003 at 02:27:52PM -0700, Andrew Morton wrote:
> You made me read that code about 20 times ;)
> Still.  Do we think we know what the actual bug is?  That tasklist_lock
> doesn't pin tsk->mm?
> If so then let's get that patch of yours happening, but please enhance it to
> a) detect the situation where the mm went away, and tell us that it was
>    fixed up.  Sufficient to confirm your theory.
> b) put in an explicit check for a kill of an mm-less process.  print a
>    warning, skip the process.

exit_mm() is excluded by the task_lock(), so p->mm (or any of the
others) can vanish at any time (the callers don't hold the tasklist_lock
either). So did you have in mind something like this?


-- wli


===== mm/oom_kill.c 1.23 vs edited =====
--- 1.23/mm/oom_kill.c	Wed Apr 23 03:15:53 2003
+++ edited/mm/oom_kill.c	Sat Jul  5 15:00:15 2003
@@ -141,8 +141,16 @@
  * CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
  * we select a process with CAP_SYS_RAW_IO set).
  */
-void oom_kill_task(struct task_struct *p)
+static void __oom_kill_task(task_t *p)
 {
+	task_lock(p);
+	if (!p->mm || p->mm == &init_mm) {
+		WARN_ON(1);
+		printk(KERN_WARNING "tried to kill an mm-less task!\n");
+		task_unlock(p);
+		return;
+	}
+	task_unlock(p);
 	printk(KERN_ERR "Out of Memory: Killed process %d (%s).\n", p->pid, p->comm);
 
 	/*
@@ -161,6 +169,16 @@
 	}
 }
 
+static struct mm_struct *oom_kill_task(task_t *p)
+{
+	struct mm_struct *mm = get_task_mm(p);
+	if (!mm || mm == &init_mm)
+		return NULL;
+	__oom_kill_task(p);
+	return mm;
+}
+
+
 /**
  * oom_kill - kill the "best" process when we run out of memory
  *
@@ -171,9 +189,11 @@
  */
 static void oom_kill(void)
 {
+	struct mm_struct *mm;
 	struct task_struct *g, *p, *q;
 	
 	read_lock(&tasklist_lock);
+retry:
 	p = select_bad_process();
 
 	/* Found nothing?!?! Either we hang forever, or we panic. */
@@ -182,17 +202,21 @@
 		panic("Out of memory and no killable processes...\n");
 	}
 
-	oom_kill_task(p);
+	mm = oom_kill_task(p);
+	if (!mm)
+		goto retry;
 	/*
 	 * kill all processes that share the ->mm (i.e. all threads),
 	 * but are in a different thread group
 	 */
 	do_each_thread(g, q)
-		if (q->mm == p->mm && q->tgid != p->tgid)
-			oom_kill_task(q);
+		if (q->mm == mm && q->tgid != p->tgid)
+			__oom_kill_task(q);
 	while_each_thread(g, q);
-
+	if (!p->mm)
+		printk(KERN_INFO "Fixed up OOM kill of mm-less task\n");
 	read_unlock(&tasklist_lock);
+	mmput(mm);
 
 	/*
 	 * Make kswapd go out of the way, so "p" has a good chance of

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 21:44         ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-05 22:10           ` Daniel Phillips
  2003-07-06  1:28             ` 2.5.74-mm1 Jamie Lokier
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05 22:10 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Andrew Morton, linux-kernel, linux-mm

On Saturday 05 July 2003 23:44, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > Unfortunately, negative priority requires root privilege, at least
> > on Debian.
> >
> > That's dumb.  By default, the root privilege requirement should kick
> > in at something like -5 or -10, so ordinary users can set priorities
> > higher than the default, as well as lower.  For the millions of
> > desktop users out there, sound ought to work by default, not be
> > broken by default.
>
> The security problem, on a multi-user box, is that negative priority
> apps can easily take all of the CPU and effectively lock up the box.

I don't see that: the solution is to set the niceness any essential process 
more negative than is possible for a normal user, which is just what we have 
now.  The stupid thing is the making the most negative possible and the 
default niceness the same.  What are you going to do if you have one 
application you want to take priority, re-nice the other 50?

An alternate solution is to allow the user to specify the default niceness.  
For all I know, there is such a way.  If not, there ought to be, and it 
should be higher than the superuser cutoff by default.  Then the sound app 
will come along and grab the highest priority it can, and it will actually 
succeed in obtaining a higher priority than garden variety processes, which 
is not what happens now.

> Something I've often thought would fix this is to allow normal users
> to set negative priority which is limited to using X% of the CPU -
> i.e. those tasks would have their priority raised if they spent more
> than a small proportion of their time using the CPU.

That's essentially SCHED_RR.  As I mentioned above, it's not clear to me why 
SCHED_RR requires superuser privilege, since the amount of CPU you can burn 
that way is bounded.  Well, the total of all SCHED_RR processes would need to 
be bounded as well, which is straightforward.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 21:09       ` 2.5.74-mm1 Daniel Phillips
  2003-07-05 21:44         ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-05 22:11         ` Diego Calleja García
  2003-07-05 23:31           ` 2.5.74-mm1 Daniel Phillips
  2003-07-06  2:29           ` 2.5.74-mm1 Davide Libenzi
  1 sibling, 2 replies; 147+ messages in thread
From: Diego Calleja García @ 2003-07-05 22:11 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: linux-kernel

El Sat, 5 Jul 2003 23:09:12 +0200 Daniel Phillips <phillips@arcor.de>
escribió:

> The "better" mechanism for sound scheduling is SCHED_RR, which requires
> root privilege for some reason that isn't clear to me.  Or maybe there
> once was a good reason, back in the days of the dinosaurs.

I don't think mp3 playing needs nothing special.

Mp3 decoding on today's computers taks insignificant amounts of cpu time.
Having mp3 skips even in light loads in a 2x800 box seems just
unacceptable. 
If you allow users using SCHED_RR, every app will end using it.
But you can renice all other apps at +5. 

Scheduler's behaviour has been much better in the past, i don't
think it requires anything special, just fixing the bug.

But if you want to hear mp3 under crazy loads; perhaps you'd want to use
the SCHED_RR part. 
Personally I'd like to be able to hear mp3 always, no matter if there's a
heavy load in the machine. Mp3 playing is _important_ for me, i don't care
about the rest :) (xmms supports realtime, but you need root)

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 22:11         ` 2.5.74-mm1 Diego Calleja García
@ 2003-07-05 23:31           ` Daniel Phillips
  2003-07-06  0:23             ` 2.5.74-mm1 Diego Calleja García
  2003-07-06  2:29           ` 2.5.74-mm1 Davide Libenzi
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-05 23:31 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: linux-kernel

On Sunday 06 July 2003 00:11, Diego Calleja García wrote:
> El Sat, 5 Jul 2003 23:09:12 +0200 Daniel Phillips <phillips@arcor.de>
> > The "better" mechanism for sound scheduling is SCHED_RR, which requires
> > root privilege for some reason that isn't clear to me.  Or maybe there
> > once was a good reason, back in the days of the dinosaurs.
>
> I don't think mp3 playing needs nothing special.

It does.  It requires realtime scheduling.  That is special.  Without realtime 
scheduling, the mp3 player will sometimes miss its deadline for filling the 
next chunk of buffer.

> (xmms supports realtime, but you need root)

Needing root in order to play your mp3 without skipping is stupid and 
unnecessary.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 19:14     ` 2.5.74-mm1 Andrew Morton
  2003-07-05 21:09       ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  0:10       ` Daniel Phillips
  2003-07-06  0:10         ` 2.5.74-mm1 Davide Libenzi
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-06  0:10 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm

On Saturday 05 July 2003 21:14, Andrew Morton wrote:
> Daniel Phillips <phillips@arcor.de> wrote:
> > Kgdb is no help in
> > diagnosing, as the kgdb stub also goes comatose, or at least the serial
> > link does.  No lockups have occurred so far when I was not interacting
> > with the system via the keyboard or mouse.  Suggestions?
>
> Enable IO APIC, Local APIC, nmi watchdog.  Use serial console, see if you
> can get a sysrq trace out of it.  That's `^A F T' in minicom.

OK, tried that.  Still very dead.

> I mean, it _has_ to be either stuck with interrupts on, or stuck with them
> off.

Interesting data: it always hangs on the 4th iteration of Ctrl-Alt-F7, 
Ctrl-Alt-F2.  This smells like a bios stack overflow.  I think I'd better go 
poke at the vendor at this point, no?

I do feel Linux is exonerated, but then this just shows why we need to keep on 
moving, right on into the bios.

Regards,

Daniel




^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  0:10       ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  0:10         ` Davide Libenzi
  0 siblings, 0 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-06  0:10 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Andrew Morton, Linux Kernel Mailing List, linux-mm

On Sun, 6 Jul 2003, Daniel Phillips wrote:

> On Saturday 05 July 2003 21:14, Andrew Morton wrote:
> > Daniel Phillips <phillips@arcor.de> wrote:
> > > Kgdb is no help in
> > > diagnosing, as the kgdb stub also goes comatose, or at least the serial
> > > link does.  No lockups have occurred so far when I was not interacting
> > > with the system via the keyboard or mouse.  Suggestions?
> >
> > Enable IO APIC, Local APIC, nmi watchdog.  Use serial console, see if you
> > can get a sysrq trace out of it.  That's `^A F T' in minicom.
>
> OK, tried that.  Still very dead.

Last resort, LKCD ;)



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 23:31           ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  0:23             ` Diego Calleja García
  2003-07-06 22:59               ` 2.5.74-mm1 Jamie Lokier
  0 siblings, 1 reply; 147+ messages in thread
From: Diego Calleja García @ 2003-07-06  0:23 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: linux-kernel

El Sun, 6 Jul 2003 01:31:02 +0200 Daniel Phillips <phillips@arcor.de>
escribió:

> It does.  It requires realtime scheduling.  That is special.  Without
> realtime scheduling, the mp3 player will sometimes miss its deadline for
> filling the next chunk of buffer.

It'll do if you're running oracle at the same time.

Desktop users shouldn't notice skips.




Diego Calleja

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 22:10           ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  1:28             ` Jamie Lokier
  2003-07-06  2:14               ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 1 reply; 147+ messages in thread
From: Jamie Lokier @ 2003-07-06  1:28 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Andrew Morton, linux-kernel, linux-mm

Daniel Phillips wrote:
> What are you going to do if you have one 
> application you want to take priority, re-nice the other 50?

Is that effective?  It might be just the trick.

> > Something I've often thought would fix this is to allow normal users
> > to set negative priority which is limited to using X% of the CPU -
> > i.e. those tasks would have their priority raised if they spent more
> > than a small proportion of their time using the CPU.
> 
> That's essentially SCHED_RR.  As I mentioned above, it's not clear
> to me why SCHED_RR requires superuser privilege, since the amount of
> CPU you can burn that way is bounded.  Well, the total of all
> SCHED_RR processes would need to be bounded as well, which is
> straightforward.

Your last point is most important.  At the moment, a SCHED_RR process
with a bug will basically lock up the machine, which is totally
inappropriate for a user app.

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  1:28             ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-06  2:14               ` Daniel Phillips
  2003-07-06  2:21                 ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 10:00                 ` 2.5.74-mm1 Mel Gorman
  0 siblings, 2 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-06  2:14 UTC (permalink / raw)
  To: Jamie Lokier; +Cc: Andrew Morton, linux-kernel, linux-mm

On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > What are you going to do if you have one
> > application you want to take priority, re-nice the other 50?
>
> Is that effective?  It might be just the trick.

Point.

> > > Something I've often thought would fix this is to allow normal users
> > > to set negative priority which is limited to using X% of the CPU -
> > > i.e. those tasks would have their priority raised if they spent more
> > > than a small proportion of their time using the CPU.
> >
> > That's essentially SCHED_RR.  As I mentioned above, it's not clear
> > to me why SCHED_RR requires superuser privilege, since the amount of
> > CPU you can burn that way is bounded.  Well, the total of all
> > SCHED_RR processes would need to be bounded as well, which is
> > straightforward.
>
> Your last point is most important.  At the moment, a SCHED_RR process
> with a bug will basically lock up the machine, which is totally
> inappropriate for a user app.

How does the lockup come about?  As defined, a single SCHED_RR process could 
lock up only its own slice of CPU, as far as I can see.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  2:14               ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  2:21                 ` Davide Libenzi
  2003-07-06 13:54                   ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 10:00                 ` 2.5.74-mm1 Mel Gorman
  1 sibling, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-06  2:21 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List, linux-mm

On Sun, 6 Jul 2003, Daniel Phillips wrote:

> On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> >
> > Your last point is most important.  At the moment, a SCHED_RR process
> > with a bug will basically lock up the machine, which is totally
> > inappropriate for a user app.
>
> How does the lockup come about?  As defined, a single SCHED_RR process could
> lock up only its own slice of CPU, as far as I can see.

They're de-queued and re-queue in the active array w/out having dynamic
priority adjustment (like POSIX states). This means that any task with
lower priority will starve if the RR task will not release the CPU.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 22:11         ` 2.5.74-mm1 Diego Calleja García
  2003-07-05 23:31           ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  2:29           ` Davide Libenzi
  1 sibling, 0 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-06  2:29 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: Daniel Phillips, Linux Kernel Mailing List

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 851 bytes --]

On Sun, 6 Jul 2003, Diego Calleja [ISO-8859-15] García wrote:

> El Sat, 5 Jul 2003 23:09:12 +0200 Daniel Phillips <phillips@arcor.de>
> escribió:
>
> > The "better" mechanism for sound scheduling is SCHED_RR, which requires
> > root privilege for some reason that isn't clear to me.  Or maybe there
> > once was a good reason, back in the days of the dinosaurs.
>
> I don't think mp3 playing needs nothing special.
>
> Mp3 decoding on today's computers taks insignificant amounts of cpu time.
> Having mp3 skips even in light loads in a 2x800 box seems just
> unacceptable.

It is not a problem of CPU time spent, it is a timing problem. Many sound
players do use to feed the sound card with write()s that are typically
8-16Kb and it is sufficent 100-200ms of CPU black-out (at 44100 16bit) to
have a buffer under-run and an audio skip.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-05 17:47       ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-06  3:41         ` Con Kolivas
  2003-07-06 18:50           ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 1 reply; 147+ messages in thread
From: Con Kolivas @ 2003-07-06  3:41 UTC (permalink / raw)
  To: Daniel Phillips, Andrew Morton, linux-kernel, linux-mm

On Sun, 6 Jul 2003 03:47, Daniel Phillips wrote:
> On Saturday 05 July 2003 18:01, Con Kolivas wrote:
> > Have you taken the next twist in the road? I posted a second patch which
> > should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in
> > case, here is a link to it.
> >
> > http://kernel.kolivas.org/2.5/
> >
> > it's called patch-O2int-0307041440
>
> This one is a regression.  Window dragging now causes the same kind of
> dropouts as I saw on 2.5.73 mainline.  But see below.

X is still getting sustained priority in this one; This version addressed 
other more important issues. The next version may help when I've made it. 

>
> > It makes significant headway in smoothing the corner cases. I need
> > testing at each point before I can post another update, and am doing much
> > less frequent smaller updates now, with the aim of having no more than
> > one patch for each -mm, so I can have a decent sized audience for each
> > change.
> >
> > Andrew can you please apply this one on top in the next -mm if you are to
> > continue testing this patch series.
>
> Well...
>
> It should help you to know that up till now I've been running Zinf at
> priority 0 (of -20..19).  I just changed change that to -10, and all the
> dropouts went away.  Duh.  The thing is, Zinf is a (soft) realtime
> application, or at least the sound servicing part of it is.  It's hard to
> see how the kernel can ever figure that out automagically - it has to be
> told.  So I told it.
>
> My only reservation is that nice is not a very (ahem) nice way of doing
> this. We really want Zinf to take care of that itself.  Zinf knows it has a
> realtime component and it knows which component that is, so it needs to
> tell the kernel, presumeably via setpriority (nice is just a frontend to
> setpriority).  Blindly choosing some higher priority to run at is certainly
> crude, but for now it solves the problem, so I won't have to apologize to
> my wife about destroying her audio experience with the latest, greatest
> kernel.
>
> Not having to worry about detecting and babying along the realtime sound
> thread should make your job considerably easier.  OK, looking at the Zinf
> code I see that it does know about thread priority, via pthreads.  It's
> either not working, or it's not set to sensible defaults.  I'm looking into
> that.

Well if it gets real time scheduling all that goes away.. But of course that 
would mean it needs root or equivalent user access. Even the lowest priority 
real time apps get scheduled ahead of any nice priority boosted or 
interactive boosted normal scheduling apps. However I'm going to give X less 
buffer in the next version so it should get better without RT scheduling. 

WRT the other lkml threads, audio should work without skips on normal desktop 
loads without priority changes, without root privileges and without RT 
scheduling. Therefore I am still considering it a regression.

>
> Now, just so this doesn't get too easy for you, I have a nice little opengl
> application here:
>
>   http://nl.linux.org/~phillips/world.tgz
>   (3D engine - see screenshots on the same page)
>
> The "bounce" demo is suitable for testing how steady the framerate is. 
> It's working pretty well since 2.4.73, if you leave the window in one
> place, but scheduling gets challenging (i.e., sucks) when you drag the 3D
> window around. How should we fix that?  It's my code so I'm willing to add
> whatever priority control is appropriate.

I assume you're not asking for the scheduler to be tweaked for this. You want 
the 3d rendering to occur regardless of what is happening anywhere else? If 
it doesn't use much cpu time but wakes lots then in it's current form the 
scheduler will happily put this equal sharing with everything at nice 0. X 
intermittently gets cpu hungry so will make this slow down at the moment 
during those bursts. Your app will go ahead of everything else at a priority 
of -3. 

If it is cpu hungry, it will need at least -8 to get in on the act, and -13 to 
be ahead of everyone (not really recommended though).

Con


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  2:21                 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-06 13:54                   ` Daniel Phillips
  0 siblings, 0 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-06 13:54 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List, linux-mm

On Sunday 06 July 2003 04:21, Davide Libenzi wrote:
> On Sun, 6 Jul 2003, Daniel Phillips wrote:
> > On Sunday 06 July 2003 03:28, Jamie Lokier wrote:
> > > Your last point is most important.  At the moment, a SCHED_RR process
> > > with a bug will basically lock up the machine, which is totally
> > > inappropriate for a user app.
> >
> > How does the lockup come about?  As defined, a single SCHED_RR process
> > could lock up only its own slice of CPU, as far as I can see.
>
> They're de-queued and re-queue in the active array w/out having dynamic
> priority adjustment (like POSIX states). This means that any task with
> lower priority will starve if the RR task will not release the CPU.

OK, I see, I didn't pay close enough attention to the "it will be put at the 
end of the list _for its priority_" part.

So SCHED_RR is broken by design, too bad.  Now, how would SCHED_RR_NOTBROKEN 
work?

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  3:41         ` 2.5.74-mm1 Con Kolivas
@ 2003-07-06 18:50           ` Daniel Phillips
  0 siblings, 0 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-06 18:50 UTC (permalink / raw)
  To: Con Kolivas, Andrew Morton, linux-kernel, linux-mm

On Sunday 06 July 2003 05:41, Con Kolivas wrote:
> On Sun, 6 Jul 2003 03:47, Daniel Phillips wrote:
> > Not having to worry about detecting and babying along the realtime sound
> > thread should make your job considerably easier.  OK, looking at the Zinf
> > code I see that it does know about thread priority, via pthreads.  It's
> > either not working, or it's not set to sensible defaults.  I'm looking
> > into that.
>
> Well if it gets real time scheduling all that goes away.. But of course
> that would mean it needs root or equivalent user access.

We need to do something about that, apparently.  OK, in another thread it's 
been pointed out that SCHED_RR is broken for this, but nice=-something is 
still an option.

> Even the lowest
> priority real time apps get scheduled ahead of any nice priority boosted or
> interactive boosted normal scheduling apps. However I'm going to give X
> less buffer in the next version so it should get better without RT
> scheduling.
>
> WRT the other lkml threads, audio should work without skips on normal
> desktop loads without priority changes, without root privileges and without
> RT scheduling. Therefore I am still considering it a regression.

Given that my sound is now working better for me than it ever has on any 
version of Linux, I wouldn't be so fast to call it a regression.  The active 
ingredient is a priori priority assignment.  With your patch, nice=-2 gives  
solid, reliable sound playing under all conditions I've thought to try.  
Without your patch, nice=-10 is insufficient.  So you're on to something 
good, it seems.

> > Now, just so this doesn't get too easy for you, I have a nice little
> > opengl application here:
> >
> >   http://nl.linux.org/~phillips/world.tgz
> >   (3D engine - see screenshots on the same page)
> >
> > The "bounce" demo is suitable for testing how steady the framerate is.
> > It's working pretty well since 2.4.73, if you leave the window in one
> > place, but scheduling gets challenging (i.e., sucks) when you drag the 3D
> > window around. How should we fix that?  It's my code so I'm willing to
> > add whatever priority control is appropriate.
>
> I assume you're not asking for the scheduler to be tweaked for this. You
> want the 3d rendering to occur regardless of what is happening anywhere
> else?

I don't know what's required, this is just the next problem on my list after 
sound scheduling, which as far as I'm concerned isn't particularly 
interesting any more (except for the missing formal analysis) because we've 
got solutions on the table.

What I want is a reasonably steady frame rate, even when the window is being 
dragged.  After that, being greedy, I'll want a steady rate under lots of 
other challenging conditions as well.  (Note there's a tweakable option in 
the source to emit ms/frame.)

> If it doesn't use much cpu time but wakes lots then in it's current
> form the scheduler will happily put this equal sharing with everything at
> nice 0. X intermittently gets cpu hungry so will make this slow down at the
> moment during those bursts. Your app will go ahead of everything else at a
> priority of -3.

So why is -1 or -2 not sufficient?

> If it is cpu hungry, it will need at least -8 to get in on the act, and -13
> to be ahead of everyone (not really recommended though).

Being a 3D renderer, of course it's cpu hungry.  It's also a very common type 
of interactive application.  As with sound, interactive 3D applications on 
Linux should work by default, not be broken by default.  If that means fixing  
applications, so be it, let's do that to avoid going overboard with kernel 
scheduling policy.

As I noted before, your patch is small, that's great.  Now the thing is to 
really get the goodness out of it, and avoid building in too much automagic 
where it isn't appropriate.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  0:23             ` 2.5.74-mm1 Diego Calleja García
@ 2003-07-06 22:59               ` Jamie Lokier
  0 siblings, 0 replies; 147+ messages in thread
From: Jamie Lokier @ 2003-07-06 22:59 UTC (permalink / raw)
  To: Diego Calleja García; +Cc: Daniel Phillips, linux-kernel

Diego Calleja García wrote:
> It'll do if you're running oracle at the same time.
> 
> Desktop users shouldn't notice skips.

Fwiw, sometimes desktop users run Oracle.

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile)
  2003-07-03 11:20       ` William Lee Irwin III
  2003-07-03 11:32         ` 2.5.74-mm1 (p4-clockmod does not compile) PATCH Dumitru Ciobarcianu
@ 2003-07-07  5:24         ` Zwane Mwaikambo
  2003-07-07  5:47           ` William Lee Irwin III
  1 sibling, 1 reply; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-07  5:24 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Dumitru Ciobarcianu, Andrew Morton, linux-kernel, linux-mm

On Thu, 3 Jul 2003, William Lee Irwin III wrote:

> On Thu, Jul 03, 2003 at 02:17:48PM +0300, Dumitru Ciobarcianu wrote:
> > I had to mannually change the file (the patch was giving rejects), but
> > it compiles now.
> 
> Great! Could you send back the diff? (or alternatively, the file
> contents if you didn't preserve the old contents) so I can send the
> proper diff upstream?

Didn't -mm get something for this?

-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1 (p4-clockmod does not compile)
  2003-07-07  5:24         ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
@ 2003-07-07  5:47           ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-07  5:47 UTC (permalink / raw)
  To: Zwane Mwaikambo
  Cc: Dumitru Ciobarcianu, Andrew Morton, linux-kernel, linux-mm

On Thu, 3 Jul 2003, William Lee Irwin III wrote:
>> Great! Could you send back the diff? (or alternatively, the file
>> contents if you didn't preserve the old contents) so I can send the
>> proper diff upstream?

On Mon, Jul 07, 2003 at 01:24:26AM -0400, Zwane Mwaikambo wrote:
> Didn't -mm get something for this?

That's a very mysterious resend of a message that's several days old.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-06  2:14               ` 2.5.74-mm1 Daniel Phillips
  2003-07-06  2:21                 ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 10:00                 ` Mel Gorman
  2003-07-07 12:24                   ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 1 reply; 147+ messages in thread
From: Mel Gorman @ 2003-07-07 10:00 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Sun, 6 Jul 2003, Daniel Phillips wrote:

> > > What are you going to do if you have one
> > > application you want to take priority, re-nice the other 50?
> >
> > Is that effective?  It might be just the trick.
>
> Point.
>

Alternatively, how about using PAM to grant the CAP_SYS_NICE capability to
known interactive users that require it. Presumably the number of users
that require it is very small (in the case of the music player, only one)
so it wouldn't be a major security issue.

There is something along these lines at http://www.pamcap.org but it
requires some patching to the kernel (only available against 2.4.18
currently) to inherit capabilities across exec and, from what I gather at
a quick glance, to allow capabilities to be set for a process group.

-- 
Mel Gorman

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 10:00                 ` 2.5.74-mm1 Mel Gorman
@ 2003-07-07 12:24                   ` Daniel Phillips
  2003-07-07 13:09                     ` 2.5.74-mm1 Alex Riesen
                                       ` (2 more replies)
  0 siblings, 3 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-07 12:24 UTC (permalink / raw)
  To: Mel Gorman
  Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Monday 07 July 2003 12:00, Mel Gorman wrote:
> On Sun, 6 Jul 2003, Daniel Phillips wrote:
> > > > What are you going to do if you have one
> > > > application you want to take priority, re-nice the other 50?
> > >
> > > Is that effective?  It might be just the trick.
> >
> > Point.
>
> Alternatively, how about using PAM to grant the CAP_SYS_NICE capability to
> known interactive users that require it. Presumably the number of users
> that require it is very small (in the case of the music player, only one)
> so it wouldn't be a major security issue.

And set up distros to grant it by default.  Yes.

The problem I see is that it lets user space priorities invade the range of 
priorities used by root processes.  What's really needed is a range of 
negative priorities available to normal users that are not normally used by 
root.

In retrospect, the idea of renicing all the applications but the realtime one  
doesn't work, because it doesn't take care of applications started 
afterwards. 

> There is something along these lines at http://www.pamcap.org but it
> requires some patching to the kernel (only available against 2.4.18
> currently) to inherit capabilities across exec and, from what I gather at
> a quick glance, to allow capabilities to be set for a process group.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 12:24                   ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 13:09                     ` Alex Riesen
  2003-07-07 14:33                       ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 13:16                     ` 2.5.74-mm1 Mel Gorman
       [not found]                     ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
  2 siblings, 1 reply; 147+ messages in thread
From: Alex Riesen @ 2003-07-07 13:09 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

Daniel Phillips, Mon, Jul 07, 2003 14:24:06 +0200:
> > Alternatively, how about using PAM to grant the CAP_SYS_NICE capability to
> > known interactive users that require it. Presumably the number of users
> > that require it is very small (in the case of the music player, only one)
> > so it wouldn't be a major security issue.
> 
> And set up distros to grant it by default.  Yes.
> 
> The problem I see is that it lets user space priorities invade the range of 
> priorities used by root processes.  What's really needed is a range of 
> negative priorities available to normal users that are not normally used by 
> root.
> 
> In retrospect, the idea of renicing all the applications but the
> realtime one  doesn't work, because it doesn't take care of
> applications started afterwards. 
> 

start login niced to -X ?


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 12:24                   ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 13:09                     ` 2.5.74-mm1 Alex Riesen
@ 2003-07-07 13:16                     ` Mel Gorman
  2003-07-07 14:47                       ` 2.5.74-mm1 Davide Libenzi
       [not found]                     ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
  2 siblings, 1 reply; 147+ messages in thread
From: Mel Gorman @ 2003-07-07 13:16 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Mon, 7 Jul 2003, Daniel Phillips wrote:

> And set up distros to grant it by default.  Yes.
>
> The problem I see is that it lets user space priorities invade the range of
> priorities used by root processes.

That is the main drawback all right but it could be addressed by having a
CAP_SYS_USERNICE capability which allows a user to renice only their own
processes to a highest priority of -5, or some other reasonable value
that wouldn't interfere with root processes. This capability would only be
for applications like music players which need to give hints to the
scheduler.

This would make it a bit Linux specific but as the pam module (currently
vapour I know) is the only piece of code that would be aware of the
distinction, it should not be much of a problem.

-- 
Mel Gorman

^ permalink raw reply	[flat|nested] 147+ messages in thread

* OOPS: 2.5.74-mm2
  2003-07-03  9:37 2.5.74-mm1 Andrew Morton
                   ` (8 preceding siblings ...)
  2003-07-05  0:16 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 13:38 ` Maciej Soltysiak
  9 siblings, 0 replies; 147+ messages in thread
From: Maciej Soltysiak @ 2003-07-07 13:38 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-mm

Hi,

2.5.74-mm2 oopses here just after booting. I get these dumps.
Once they stoped, i pressed alt+ctl+del (noted in the dump below) and they
started again, and the computer stopeed rebooting.

Regards,
Maciej

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
CPU:    0
EIP:    0060:[schedule+143/1022]    Not tainted VLI
EFLAGS: 00010097
EIP is at schedule+0x8f/0x3fe
eax: 00000001   ebx: d9bcb940   ecx: d9bcb960   edx: ffffffff
esi: 00000000   edi: c04558a0   ebp: d9b39ee0   esp: d9b39eb8
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: d9ebd980 c1403dc8 c1403dc8 00000000 40174560 d9ebd980 d9bec3c0 d9c06e6c
       d9c06e00 d9b39f08 00000001 c015a837 00000000 d9bcb940 c011a7f9 d9b39f14
       d9b39f14 d9ebd980 d9ebd9a0 d9bec3c0 00000000 d9bcb940 c011a7f9 d9b80f40
Call Trace:
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
 <6>note: bash[462] exited with preempt_count 2
bad: scheduling while atomic!
Call Trace:
 [schedule+1017/1022] schedule+0x3f9/0x3fe
 [generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [vgacon_cursor+236/478] vgacon_cursor+0xec/0x1de
 [set_cursor+117/142] set_cursor+0x75/0x8e
 [vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
 [generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
 [ext3_file_write+68/194] ext3_file_write+0x44/0xc2
 [do_sync_write+182/227] do_sync_write+0xb6/0xe3
 [mempool_free+81/177] mempool_free+0x51/0xb1
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [check_free_space+225/364] check_free_space+0xe1/0x16c
 [poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
 [vt_console_print+521/747] vt_console_print+0x209/0x2eb
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_acct_process+637/653] do_acct_process+0x27d/0x28d
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [acct_process+72/132] acct_process+0x48/0x84
 [do_exit+135/1102] do_exit+0x87/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#2]
PREEMPT
CPU:    0
EIP:    0060:[schedule+143/1022]    Not tainted VLI
EFLAGS: 00010006
EIP is at schedule+0x8f/0x3fe
eax: 00000008   ebx: d9bcb940   ecx: d9bcb960   edx: ffffffff
esi: 00000000   edi: c04558a0   ebp: d9b39d88   esp: d9b39d60
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: 00000020 00000009 d9bcb990 dbdc7b80 d9bcb9e0 00000286 dbdc7b80 dbfeea60
       00000002 00000000 d9bcb940 c011e785 d9bcb940 dbcdaae0 000001ce 00000002
       d9b39e84 d9b38000 c0116b5c d9bcb940 c010a006 0000000b c034e105 00000002
Call Trace:
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
 <6>note: bash[462] exited with preempt_count 4
bad: scheduling while atomic!
Call Trace:
 [schedule+1017/1022] schedule+0x3f9/0x3fe
 [generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
 [vgacon_cursor+236/478] vgacon_cursor+0xec/0x1de
 [set_cursor+117/142] set_cursor+0x75/0x8e
 [vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
 [generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
 [ext3_file_write+68/194] ext3_file_write+0x44/0xc2
 [do_sync_write+182/227] do_sync_write+0xb6/0xe3
 [vgacon_scroll+386/555] vgacon_scroll+0x182/0x22b
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [check_free_space+225/364] check_free_space+0xe1/0x16c
 [poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
 [vt_console_print+521/747] vt_console_print+0x209/0x2eb
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_acct_process+637/653] do_acct_process+0x27d/0x28d
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [acct_process+72/132] acct_process+0x48/0x84
 [do_exit+135/1102] do_exit+0x87/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [kill_fasync+48/82] kill_fasync+0x30/0x52
 [pipe_release+153/203] pipe_release+0x99/0xcb
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#3]
PREEMPT
CPU:    0
EIP:    0060:[schedule+143/1022]    Not tainted VLI
EFLAGS: 00010006
EIP is at schedule+0x8f/0x3fe
eax: 00000008   ebx: d9bcb940   ecx: d9bcb960   edx: ffffffff
esi: 00000000   edi: c04558a0   ebp: d9b39c30   esp: d9b39c08
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: 00000000 00000000 d9bcb990 0000000b d9bcb9e0 d9bcb940 c0132844 00000000
       00000004 00000000 d9bcb940 c011e785 d9bcb940 00000000 000001ce 00000004
       d9b39d2c d9b38000 c0116b5c d9bcb940 c010a006 0000000b c034e105 00000002
Call Trace:
 [acct_process+79/132] acct_process+0x4f/0x84
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [kill_fasync+48/82] kill_fasync+0x30/0x52
 [pipe_release+153/203] pipe_release+0x99/0xcb
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
 <6>note: bash[462] exited with preempt_count 6
bad: scheduling while atomic!
Call Trace:
 [schedule+1017/1022] schedule+0x3f9/0x3fe
 [generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [__down+268/290] __down+0x10c/0x122
 [default_wake_function+0/46] default_wake_function+0x0/0x2e
 [vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
 [generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
 [ext3_file_write+68/194] ext3_file_write+0x44/0xc2
 [do_sync_write+182/227] do_sync_write+0xb6/0xe3
 [mempool_free+81/177] mempool_free+0x51/0xb1
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [check_free_space+225/364] check_free_space+0xe1/0x16c
 [poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
 [vt_console_print+521/747] vt_console_print+0x209/0x2eb
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_acct_process+637/653] do_acct_process+0x27d/0x28d
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [acct_process+72/132] acct_process+0x48/0x84
 [do_exit+135/1102] do_exit+0x87/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [acct_process+79/132] acct_process+0x4f/0x84
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [kill_fasync+48/82] kill_fasync+0x30/0x52
 [pipe_release+153/203] pipe_release+0x99/0xcb
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

I pressed alt_ctl+del here:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c0118d2d
*pde = 00000000
Oops: 0002 [#4]
PREEMPT
CPU:    0
EIP:    0060:[schedule+143/1022]    Not tainted VLI
EFLAGS: 00010006
EIP is at schedule+0x8f/0x3fe
eax: 00000008   ebx: d9bcb940   ecx: d9bcb960   edx: ffffffff
esi: 00000000   edi: c04558a0   ebp: d9b39ad8   esp: d9b39ab0
ds: 007b   es: 007b   ss: 0068
Process bash (pid: 462, threadinfo=d9b38000 task=d9bcb940)
Stack: 00000000 00000000 d9bcb990 0000000b d9bcb9e0 d9bcb940 c0132844 00000000
       00000006 00000000 d9bcb940 c011e785 d9bcb940 00000000 000001ce 00000006
       d9b39bd4 d9b38000 c0116b5c d9bcb940 c010a006 0000000b c034e105 00000002
Call Trace:
 [acct_process+79/132] acct_process+0x4f/0x84
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [acct_process+79/132] acct_process+0x4f/0x84
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [kill_fasync+48/82] kill_fasync+0x30/0x52
 [pipe_release+153/203] pipe_release+0x99/0xcb
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

Code: 17 04 75 6d 8b 03 85 c0 74 67 83 f8 01 0f 84 3f 03 00 00 83 2d a0 58 45 c0 01 8b 03 83 f8 02 0f 84 1d 03 00 00 8b 73 28 8d 4b 20 <83> 2e 01 8b 51 04 39 0a 0f 85 fc 02 00 00 8b 43 20 39 48 04 0f
 <6>note: bash[462] exited with preempt_count 8
bad: scheduling while atomic!
Call Trace:
 [schedule+1017/1022] schedule+0x3f9/0x3fe
 [generic_file_aio_write_nolock+1574/2931] generic_file_aio_write_nolock+0x626/0xb73
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [__down+268/290] __down+0x10c/0x122
 [default_wake_function+0/46] default_wake_function+0x0/0x2e
 [vt_console_print+491/747] vt_console_print+0x1eb/0x2eb
 [generic_file_aio_write+137/253] generic_file_aio_write+0x89/0xfd
 [ext3_file_write+68/194] ext3_file_write+0x44/0xc2
 [do_sync_write+182/227] do_sync_write+0xb6/0xe3
 [vgacon_scroll+386/555] vgacon_scroll+0x182/0x22b
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [check_free_space+225/364] check_free_space+0xe1/0x16c
 [poke_blanked_console+92/111] poke_blanked_console+0x5c/0x6f
 [vt_console_print+521/747] vt_console_print+0x209/0x2eb
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_acct_process+637/653] do_acct_process+0x27d/0x28d
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [acct_process+72/132] acct_process+0x48/0x84
 [do_exit+135/1102] do_exit+0x87/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [acct_process+79/132] acct_process+0x4f/0x84
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [try_to_wake_up+160/410] try_to_wake_up+0xa0/0x19a
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [acct_process+79/132] acct_process+0x4f/0x84
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [do_notify_parent+329/1279] do_notify_parent+0x149/0x4ff
 [kill_fasync+48/82] kill_fasync+0x30/0x52
 [pipe_release+153/203] pipe_release+0x99/0xcb
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [schedule+143/1022] schedule+0x8f/0x3fe
 [do_exit+625/1102] do_exit+0x271/0x44e
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [do_divide_error+0/250] do_divide_error+0x0/0xfa
 [do_page_fault+300/1113] do_page_fault+0x12c/0x459
 [__rmqueue+204/305] __rmqueue+0xcc/0x131
 [buffered_rmqueue+229/434] buffered_rmqueue+0xe5/0x1b2
 [do_page_fault+0/1113] do_page_fault+0x0/0x459
 [error_code+45/56] error_code+0x2d/0x38
 [check_version+120/216] check_version+0x78/0xd8
 [schedule+143/1022] schedule+0x8f/0x3fe
 [pipe_wait+123/154] pipe_wait+0x7b/0x9a
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [autoremove_wake_function+0/79] autoremove_wake_function+0x0/0x4f
 [pipe_read+319/573] pipe_read+0x13f/0x23d
 [update_process_times+70/82] update_process_times+0x46/0x52
 [vfs_read+176/281] vfs_read+0xb0/0x119
 [sys_read+66/99] sys_read+0x42/0x63
 [syscall_call+7/11] syscall_call+0x7/0xb

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 13:09                     ` 2.5.74-mm1 Alex Riesen
@ 2003-07-07 14:33                       ` Daniel Phillips
  2003-07-07 14:34                         ` 2.5.74-mm1 Alex Riesen
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-07 14:33 UTC (permalink / raw)
  To: alexander.riesen; +Cc: Linux Kernel Mailing List

On Monday 07 July 2003 15:09, Alex Riesen wrote:
> Daniel Phillips, Mon, Jul 07, 2003 14:24:06 +0200:
> > In retrospect, the idea of renicing all the applications but the
> > realtime one  doesn't work, because it doesn't take care of
> > applications started afterwards.
>
> start login niced to -X ?

Actually, the opposite: start login niced to +X (x ~= 5).  This is a tidy way 
of providing the user with the needed manuevering room on the not-nice side, 
and is guaranteed not to interfere with root processes.  All logins on that 
machine would have to start with that same positive niceness, including for 
example, ssh logins.  The correct place to centralize this is the login 
program, I think, perhaps by making it aware of some environment variable or 
some setting in /etc.

To work well, this strategy has to be coupled with a scheduler guarantee that 
no priority level can completely starve any lower priority.  At this point, I 
don't know where we stand in that regard.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 14:33                       ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 14:34                         ` Alex Riesen
  0 siblings, 0 replies; 147+ messages in thread
From: Alex Riesen @ 2003-07-07 14:34 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

Daniel Phillips, Mon, Jul 07, 2003 16:33:15 +0200:
> On Monday 07 July 2003 15:09, Alex Riesen wrote:
> > Daniel Phillips, Mon, Jul 07, 2003 14:24:06 +0200:
> > > In retrospect, the idea of renicing all the applications but the
> > > realtime one  doesn't work, because it doesn't take care of
> > > applications started afterwards.
> >
> > start login niced to -X ?
> 
> Actually, the opposite: start login niced to +X (x ~= 5). ...

of course: "nice -5 /bin/login" is the login niced to +5.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 13:16                     ` 2.5.74-mm1 Mel Gorman
@ 2003-07-07 14:47                       ` Davide Libenzi
  2003-07-07 15:23                         ` 2.5.74-mm1 Jamie Lokier
  2003-07-07 15:28                         ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 2 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-07 14:47 UTC (permalink / raw)
  To: Mel Gorman
  Cc: Daniel Phillips, Jamie Lokier, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Mon, 7 Jul 2003, Mel Gorman wrote:

> On Mon, 7 Jul 2003, Daniel Phillips wrote:
>
> > And set up distros to grant it by default.  Yes.
> >
> > The problem I see is that it lets user space priorities invade the range of
> > priorities used by root processes.
>
> That is the main drawback all right but it could be addressed by having a
> CAP_SYS_USERNICE capability which allows a user to renice only their own
> processes to a highest priority of -5, or some other reasonable value
> that wouldn't interfere with root processes. This capability would only be
> for applications like music players which need to give hints to the
> scheduler.

The scheduler has to work w/out external input, period. If it doesn't we
have to fix it and not to force the user to submit external hints.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 14:47                       ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 15:23                         ` Jamie Lokier
  2003-07-07 17:25                           ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 15:28                         ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 1 reply; 147+ messages in thread
From: Jamie Lokier @ 2003-07-07 15:23 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Mel Gorman, Daniel Phillips, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

Davide Libenzi wrote:
> The scheduler has to work w/out external input, period.

Can you justify this?

It strikes me that a music player's thread which requests a special
music-playing scheduling hint is not unreasonable, if that actually
works and scheduler heuristics do not.

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 14:47                       ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 15:23                         ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-07 15:28                         ` Daniel Phillips
  2003-07-07 17:58                           ` 2.5.74-mm1 Davide Libenzi
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-07 15:28 UTC (permalink / raw)
  To: Davide Libenzi, Mel Gorman
  Cc: Jamie Lokier, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Monday 07 July 2003 16:47, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Mel Gorman wrote:
> > On Mon, 7 Jul 2003, Daniel Phillips wrote:
> > > And set up distros to grant it by default.  Yes.
> > >
> > > The problem I see is that it lets user space priorities invade the
> > > range of priorities used by root processes.
> >
> > That is the main drawback all right but it could be addressed by having a
> > CAP_SYS_USERNICE capability which allows a user to renice only their own
> > processes to a highest priority of -5, or some other reasonable value
> > that wouldn't interfere with root processes. This capability would only
> > be for applications like music players which need to give hints to the
> > scheduler.
>
> The scheduler has to work w/out external input, period. If it doesn't we
> have to fix it and not to force the user to submit external hints.

That's not correct in this case, because the sound servicing routine is 
realtime, which makes it special.  Furthermore, Zinf is already trying to 
provide the kernel with the hint it needs via PThreads SetPriority but 
because Linux has brain damage - both in the kernel and user space imho - the 
hint isn't accomplishing what it's supposed to.

As I said earlier: trying to detect automagically which threads are realtime 
and which aren't is stupid.  Such policy decisions don't belong in the 
kernel.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
       [not found]                     ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
@ 2003-07-07 17:15                       ` Mike Galbraith
  0 siblings, 0 replies; 147+ messages in thread
From: Mike Galbraith @ 2003-07-07 17:15 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Mel Gorman, Daniel Phillips, Jamie Lokier, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

At 07:47 AM 7/7/2003 -0700, Davide Libenzi wrote:
>On Mon, 7 Jul 2003, Mel Gorman wrote:
>
> > On Mon, 7 Jul 2003, Daniel Phillips wrote:
> >
> > > And set up distros to grant it by default.  Yes.
> > >
> > > The problem I see is that it lets user space priorities invade the 
> range of
> > > priorities used by root processes.
> >
> > That is the main drawback all right but it could be addressed by having a
> > CAP_SYS_USERNICE capability which allows a user to renice only their own
> > processes to a highest priority of -5, or some other reasonable value
> > that wouldn't interfere with root processes. This capability would only be
> > for applications like music players which need to give hints to the
> > scheduler.
>
>The scheduler has to work w/out external input, period. If it doesn't we
>have to fix it and not to force the user to submit external hints.

What about internal hints?

Fishing expedition:

I'm tinkering with Linus' backboost trick, and what I'd like to try is 
filtering out things which are doing I/O to graphics card, sound card, 
mouse, kdb... whatnot with an in_interactive_interrupt().  Before I go off 
tilting at that windmill, do you (or anyone) know of any reason why that 
would be either stupid or impossible?

Right now, I've got backboost max cpu consumption restricted, max priority 
restricted /proc enabled and /proc tweakable, but I need to further 
restrict/focus it somehow.  Any ideas wrt taming/focusing the little 
beastie would be appreciated.  I'd really like to get it tame enough to be 
reconsidered...

I like backboost for the desktop quite a bit. Take xmms for instance, fire 
it up and turn on it's cpu-hog-and-a-half gl visualization.  The sound 
thread runs at high priority due to low cpu usage.  The gl thread otoh is 
down in the mud, and is instantly disturbed by background tasks who 
unreasonably ;) want their fair share of cpu.  With backboost, the gl 
thread is boosted above background stuff where he belongs, the whole point 
of interactivity being that it's not only ok to be grossly unfair about 
things a human being is connecting to, it's a goodthing(tm)... worker can 
stare mindlessly at glitz and listen to skip free music while his 
employer's code gets moldy instead of being compiled. ;-)

Neat thing about backboost is that when you cover the gl thread, it 
automagically loses boost, so when unreasonable boss walks in and you cover 
it up, the compile speeds back up.  The glitz thread is only interactive if 
you can see it, and does in fact only receive boost when you can see 
it.  That's pretty cool.

         -Mike 


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 15:23                         ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-07 17:25                           ` Davide Libenzi
  2003-07-07 17:55                             ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 19:36                             ` 2.5.74-mm1 Jamie Lokier
  0 siblings, 2 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-07 17:25 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Mel Gorman, Daniel Phillips, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Mon, 7 Jul 2003, Jamie Lokier wrote:

> Davide Libenzi wrote:
> > The scheduler has to work w/out external input, period.
>
> Can you justify this?
>
> It strikes me that a music player's thread which requests a special
> music-playing scheduling hint is not unreasonable, if that actually
> works and scheduler heuristics do not.

Jamie, looking at those reports it seems it is not only a sound players
problem. It is fine that an application that has strict timing issues
hints the scheduler. The *application* has to hint the scheduler, not the
user. If reports about UI interactivity are true, this means that there's
something wrong in the current scheduler though. Besides the player issue.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 17:25                           ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 17:55                             ` Daniel Phillips
  2003-07-07 18:36                               ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 19:36                             ` 2.5.74-mm1 Jamie Lokier
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-07 17:55 UTC (permalink / raw)
  To: Davide Libenzi, Jamie Lokier
  Cc: Mel Gorman, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Jamie Lokier wrote:
> > Davide Libenzi wrote:
> > > The scheduler has to work w/out external input, period.
> >
> > Can you justify this?
> >
> > It strikes me that a music player's thread which requests a special
> > music-playing scheduling hint is not unreasonable, if that actually
> > works and scheduler heuristics do not.
>
> Jamie, looking at those reports it seems it is not only a sound players
> problem.

You still seem to be having trouble with the idea that the sound servicing 
thread is a realtime process, and thus fundamentally different from other 
kinds of processes.  Could you please explain why you disagree with this?

> The *application* has to hint the scheduler, not the user.

Partly true, in that users should be able to supply the hint in some way, they 
desire.  However in this case - Zinf - the point is moot, because Zinf is 
trying hard to give the hint, but it fails because of above-mentioned 
braindamage.

> If reports about UI interactivity are true, this means that there's
> something wrong in the current scheduler though. Besides the player issue.

The current scheduler, complete with Con's tweaks, is working very well for me 
in combination with "nice -something".  The remaining issue there is pure 
policy.  In that regard, I'm trying to find the most appropriate way of 
fixing up user space so that Zinf's SetPriority actually achieves its 
intended effect.  Running all logins at some setable non-negative default 
priority is the best idea I've seen so far in that regard, and soon my system 
will be doing just that.  I'll let you know if anything explodes ;-)

If there's a remaining fundamental flaw in the kernel scheduler, it would be 
the lower-priority process starvation question, which holds the promise of 
plenty of future lkml navel gaz^W^Wdiscussion indeed.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 15:28                         ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 17:58                           ` Davide Libenzi
  0 siblings, 0 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-07 17:58 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Mel Gorman, Jamie Lokier, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Mon, 7 Jul 2003, Daniel Phillips wrote:

> That's not correct in this case, because the sound servicing routine is
> realtime, which makes it special.  Furthermore, Zinf is already trying to
> provide the kernel with the hint it needs via PThreads SetPriority but
> because Linux has brain damage - both in the kernel and user space imho - the
> hint isn't accomplishing what it's supposed to.
>
> As I said earlier: trying to detect automagically which threads are realtime
> and which aren't is stupid.  Such policy decisions don't belong in the
> kernel.

Having hacked a little bit with vsound I can say that many sound players
do not use at 100% the buffering the sound card/kernel is able to provide
and they still use 4-8Kb feeding chunks. That require very short timings
to not lose the time.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 17:55                             ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 18:36                               ` Davide Libenzi
  2003-07-07 19:07                                 ` 2.5.74-mm1 Daniel Phillips
  2003-07-07 19:39                                 ` 2.5.74-mm1 Jamie Lokier
  0 siblings, 2 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-07 18:36 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Jamie Lokier, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Mon, 7 Jul 2003, Daniel Phillips wrote:

> On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> >
> > Jamie, looking at those reports it seems it is not only a sound players
> > problem.
>
> You still seem to be having trouble with the idea that the sound servicing
> thread is a realtime process, and thus fundamentally different from other
> kinds of processes.  Could you please explain why you disagree with this?

I'm just trying to figure out why :

1) RealPlayer does not skip on my 2.4.20
2) RealPlayer does not skip on my office XP
3) MediaPlayer does not skip on my office XP

Maybe it is more of an application problem.


> > The *application* has to hint the scheduler, not the user.
>
> Partly true, in that users should be able to supply the hint in some way, they
> desire.  However in this case - Zinf - the point is moot, because Zinf is
> trying hard to give the hint, but it fails because of above-mentioned
> braindamage.

Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
Feeding the sound card with 4Kb writes will make you skip after about 50ms
CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
makes it able to sustain up to 200ms of blackout.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 18:36                               ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-07 19:07                                 ` Daniel Phillips
  2003-07-07 22:03                                   ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 19:39                                 ` 2.5.74-mm1 Jamie Lokier
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-07 19:07 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Jamie Lokier, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Monday 07 July 2003 20:36, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Daniel Phillips wrote:
> > On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> > > Jamie, looking at those reports it seems it is not only a sound players
> > > problem.
> >
> > You still seem to be having trouble with the idea that the sound
> > servicing thread is a realtime process, and thus fundamentally different
> > from other kinds of processes.  Could you please explain why you disagree
> > with this?
>
> I'm just trying to figure out why :
>
> 1) RealPlayer does not skip on my 2.4.20
                                    ^^^^^^
We're talking about 2.5.

> 2) RealPlayer does not skip on my office XP
> 3) MediaPlayer does not skip on my office XP
>
> Maybe it is more of an application problem.

Partly.  We've been through that in pretty good detail.  There are 
combinations of hardware and kernel versions that happen to be pretty good at 
running sound, that doesn't mean the problem is dealt with so that corner 
cases don't come up.  A 99% solution is not good enough, that still will 
leave 10,000's of Linux users with poor sound performance.

Zinf does things correctly: it has a big buffer and it tries to set an 
elevated priority for its sound servicing thread.  With 2.5, that isn't 
enough, and Con's tweaking isn't enough.  And that's not wrong, because the 
kernel *should not* try to identify realtime threads automagically.

Zinf could go further and try to set a posix realtime scheduling mode, but 
that attempt would be blocked by the root requirement for realtime 
scheduling, which is ihmo due to braindamage in the definition of the posix 
realtime scheduling modes.  This last we *can* fix in the kernel, by creating 
a new realtime scheduling mode that is sane enough to be used by normal 
users.  Then sound applications would need to be changed to use it, which 
really is no big deal.

In the meantime, a combination of Con's priority tweaks and user-initiated 
nice works well.

> > > The *application* has to hint the scheduler, not the user.
> >
> > Partly true, in that users should be able to supply the hint in some way,
> > they desire.  However in this case - Zinf - the point is moot, because
> > Zinf is trying hard to give the hint, but it fails because of
> > above-mentioned braindamage.
>
> Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
> Feeding the sound card with 4Kb writes will make you skip after about 50ms
> CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
> makes it able to sustain up to 200ms of blackout.

That's just fiddling, it doesn't deal with the basic problem.  Anyway, big 
buffers have their own annoyances.  Have you tried the graphic equalizer in 
xmms lately?  A one second lag on slider adjustment is not nice.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 17:25                           ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 17:55                             ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 19:36                             ` Jamie Lokier
  2003-07-09 22:17                               ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 1 reply; 147+ messages in thread
From: Jamie Lokier @ 2003-07-07 19:36 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Mel Gorman, Daniel Phillips, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

Davide Libenzi wrote:

> The *application* has to hint the scheduler, not the user.

Agreed.

(I think the user/PAM idea came up for the same sort of reason that
only console users are able to open /dev/cdrom: asking for extra
resource (in this case low latency is a resource) might be something
you'd restrict to console users.  But that is a very separate question
from how do we get low latency to work at all!)

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 18:36                               ` 2.5.74-mm1 Davide Libenzi
  2003-07-07 19:07                                 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 19:39                                 ` Jamie Lokier
  1 sibling, 0 replies; 147+ messages in thread
From: Jamie Lokier @ 2003-07-07 19:39 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Daniel Phillips, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

Davide Libenzi wrote:
> Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
> Feeding the sound card with 4Kb writes will make you skip after about 50ms
> CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
> makes it able to sustain up to 200ms of blackout.

Large buffers are fine for streaming, provided you aren't sliding the
volume or graphic equaliser.  I find xmms annoying in this regard: I
adjust the eq and wait some absurd length of time (fully tenths of a
second :) to hear the feedback.

Large buffers are useless for games or telephony.

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 19:07                                 ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-07 22:03                                   ` Davide Libenzi
  2003-07-08  0:13                                     ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-07 22:03 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

[ trimmed cc ]

On Mon, 7 Jul 2003, Daniel Phillips wrote:

> > I'm just trying to figure out why :
> >
> > 1) RealPlayer does not skip on my 2.4.20
>                                     ^^^^^^
> We're talking about 2.5.

This is exactly my point. It seems that all I'm earing here is that the OS
cannot do the right thing alone. I'm asking you why other apps/OS/kernels
can make it work just fine ? And I am not running RealPlay as superuser.



> Partly.  We've been through that in pretty good detail.  There are
> combinations of hardware and kernel versions that happen to be pretty good at
> running sound, that doesn't mean the problem is dealt with so that corner
> cases don't come up.  A 99% solution is not good enough, that still will
> leave 10,000's of Linux users with poor sound performance.
>
> Zinf does things correctly: it has a big buffer and it tries to set an
> elevated priority for its sound servicing thread.  With 2.5, that isn't
> enough, and Con's tweaking isn't enough.  And that's not wrong, because the
> kernel *should not* try to identify realtime threads automagically.

If a big buffer is for example 32kb, this will give you about 350ms of
sustainable CPU blackout. That is pretty much difficult to hit. Having a
blackout of more than 300-400ms means that either the load is not
realistic or that the timeslice policy has to be tuned. Has anyone tried
to lower the maximum timeslice and to assign it in an exponential fashion ?
Example, maximum timeslice = 100-120ms with :

  ts
    ^
120 |                            .
    |                           .
    |                          .
    |                         .
    |                        .
    |                      .
    |                    .
    |                .
    |           .
 10 | .  .
    |
    ------------------------------------->
      |min                    max|        prio

In a scheduling model that is timeslice driven, two factors influence the
maximum CPU blackout time. One is the number of TASK_RUNNING tasks and the
other one is the timeslice avg length. Interactivity is ruled by the
ratio between the lo-priority timeslice and the hi-priority one. If we
lower the maximum timeslice and we assign it in an exponential way, we can
lower the avg timeslice by keeping "almost" intact the ratio (interactivity).
In this way you basically maintain timeslice ratios (interactivity) while
lowering the cycle time it takes to the scheduler to exhaust the active
array. And this time is basically our maximum blackout time.



> Zinf could go further and try to set a posix realtime scheduling mode, but
> that attempt would be blocked by the root requirement for realtime
> scheduling, which is ihmo due to braindamage in the definition of the posix
> realtime scheduling modes.  This last we *can* fix in the kernel, by creating
> a new realtime scheduling mode that is sane enough to be used by normal
> users.  Then sound applications would need to be changed to use it, which
> really is no big deal.

Again, while I see one application that survives skips, this makes me
think that other apps do not have the correct timing code.



> > Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> > let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
> > Feeding the sound card with 4Kb writes will make you skip after about 50ms
> > CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
> > makes it able to sustain up to 200ms of blackout.
>
> That's just fiddling, it doesn't deal with the basic problem.  Anyway, big
> buffers have their own annoyances.  Have you tried the graphic equalizer in
> xmms lately?  A one second lag on slider adjustment is not nice.

That's not fiddling. It is tuning your app so that it won't require
realtime when it is not needed. This is design in my books.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 22:03                                   ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-08  0:13                                     ` Daniel Phillips
  2003-07-08  0:29                                       ` 2.5.74-mm1 Davide Libenzi
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-08  0:13 UTC (permalink / raw)
  To: Davide Libenzi; +Cc: Linux Kernel Mailing List

On Tuesday 08 July 2003 00:03, Davide Libenzi wrote:
> > > Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> > > let you set a dma buf for 0.5 up to 1 sec of play (upper limited by
> > > 64Kb). Feeding the sound card with 4Kb writes will make you skip after
> > > about 50ms CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding
> > > chunks that makes it able to sustain up to 200ms of blackout.
> >
> > That's just fiddling, it doesn't deal with the basic problem.  Anyway,
> > big buffers have their own annoyances.  Have you tried the graphic
> > equalizer in xmms lately?  A one second lag on slider adjustment is not
> > nice.
>
> That's not fiddling. It is tuning your app so that it won't require
> realtime when it is not needed.

But realtime is needed, because there is a deadline for each buffer-fill.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08  0:13                                     ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-08  0:29                                       ` Davide Libenzi
  2003-07-08  1:07                                         ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-08  0:29 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

On Tue, 8 Jul 2003, Daniel Phillips wrote:

> On Tuesday 08 July 2003 00:03, Davide Libenzi wrote:
> > > > Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> > > > let you set a dma buf for 0.5 up to 1 sec of play (upper limited by
> > > > 64Kb). Feeding the sound card with 4Kb writes will make you skip after
> > > > about 50ms CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding
> > > > chunks that makes it able to sustain up to 200ms of blackout.
> > >
> > > That's just fiddling, it doesn't deal with the basic problem.  Anyway,
> > > big buffers have their own annoyances.  Have you tried the graphic
> > > equalizer in xmms lately?  A one second lag on slider adjustment is not
> > > nice.
> >
> > That's not fiddling. It is tuning your app so that it won't require
> > realtime when it is not needed.
>
> But realtime is needed, because there is a deadline for each buffer-fill.

Yes, in theory it is needed since you have to meet a deadline. But if
you program you timings such that your deadline is 400-500ms it is really
hard to lose it against one of 50-100ms.


- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08  0:29                                       ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-08  1:07                                         ` Daniel Phillips
  2003-07-08  7:48                                           ` 2.5.74-mm1 Davide Libenzi
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-08  1:07 UTC (permalink / raw)
  To: Davide Libenzi; +Cc: Linux Kernel Mailing List

On Tuesday 08 July 2003 02:29, Davide Libenzi wrote:
> On Tue, 8 Jul 2003, Daniel Phillips wrote:
> > On Tuesday 08 July 2003 00:03, Davide Libenzi wrote:
> > > > > Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the
> > > > > kernel let you set a dma buf for 0.5 up to 1 sec of play (upper
> > > > > limited by 64Kb). Feeding the sound card with 4Kb writes will make
> > > > > you skip after about 50ms CPU blackout at 44KHz 16 bit. RealPlayer
> > > > > uses 16Kb feeding chunks that makes it able to sustain up to 200ms
> > > > > of blackout.
> > > >
> > > > That's just fiddling, it doesn't deal with the basic problem. 
> > > > Anyway, big buffers have their own annoyances.  Have you tried the
> > > > graphic equalizer in xmms lately?  A one second lag on slider
> > > > adjustment is not nice.
> > >
> > > That's not fiddling. It is tuning your app so that it won't require
> > > realtime when it is not needed.
> >
> > But realtime is needed, because there is a deadline for each buffer-fill.
>
> Yes, in theory it is needed since you have to meet a deadline. But if
> you program you timings such that your deadline is 400-500ms it is really
> hard to lose it against one of 50-100ms.

1. 400ms buffers are hated by users, as was noted previously.  They are 
passable for some applications, but way too laggy for others.

2. Even if you are will to have a 400-500 ms buffer, if you can prove that you 
will always meet that deadline, then it's a realtime system.

3. If you can show logically that you will nearly always meet the deadline, 
it's a soft realtime system.  That's what we're after here.  From a design 
standpoint, there are elegant soft realtime systems, and there are sucky 
ones.

4. So how do you propose to "program timings" so that it's really hard to miss  
those deadlines?

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08  1:07                                         ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-08  7:48                                           ` Davide Libenzi
  2003-07-08  9:18                                             ` 2.5.74-mm1 Nick Piggin
  2003-07-08 11:09                                             ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 2 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-08  7:48 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

On Tue, 8 Jul 2003, Daniel Phillips wrote:

> 1. 400ms buffers are hated by users, as was noted previously.  They are
> passable for some applications, but way too laggy for others.
>
> 2. Even if you are will to have a 400-500 ms buffer, if you can prove that you
> will always meet that deadline, then it's a realtime system.
>
> 3. If you can show logically that you will nearly always meet the deadline,
> it's a soft realtime system.  That's what we're after here.  From a design
> standpoint, there are elegant soft realtime systems, and there are sucky
> ones.
>
> 4. So how do you propose to "program timings" so that it's really hard to miss
> those deadlines?

Having a backup of 400-500ms gives you an average hang-over of 200-250ms
that are hardly noticeable by a human in this topic. The issue is not if
you always meet the deadline, the issue is what amount of load will make
you miss it. If I have to hire five ppl clicking and dragging on my desktop
to make my player to skip, and it skips, I don't care if it missed the
deadline. This because my desktop will hardly see that load. But if you
have a 50-100ms backup, things turns out to be a little bit different.
If you pretend to run a `make -jUNREAL` and still have the audio not
skipping it is simply wrong. Running a `make -j20` in my machine shows an
average of 24 TASK_RUNNING tasks, that even if they're granted with a mere
40ms timeslice, it'll take a full second before an expired task will see
the light again. BTW, under such load RealPlayer skips badly, but I don't
really care since it never did while I was doing all the normal (and many
extra) stuff I'm doing on my desktop.




- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08  7:48                                           ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-08  9:18                                             ` Nick Piggin
  2003-07-08 15:24                                               ` 2.5.74-mm1 Davide Libenzi
  2003-07-08 11:09                                             ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 1 reply; 147+ messages in thread
From: Nick Piggin @ 2003-07-08  9:18 UTC (permalink / raw)
  To: Davide Libenzi; +Cc: Daniel Phillips, Linux Kernel Mailing List



Davide Libenzi wrote:

>On Tue, 8 Jul 2003, Daniel Phillips wrote:
>
>
>>1. 400ms buffers are hated by users, as was noted previously.  They are
>>passable for some applications, but way too laggy for others.
>>
>>2. Even if you are will to have a 400-500 ms buffer, if you can prove that you
>>will always meet that deadline, then it's a realtime system.
>>
>>3. If you can show logically that you will nearly always meet the deadline,
>>it's a soft realtime system.  That's what we're after here.  From a design
>>standpoint, there are elegant soft realtime systems, and there are sucky
>>ones.
>>
>>4. So how do you propose to "program timings" so that it's really hard to miss
>>those deadlines?
>>
>
>Having a backup of 400-500ms gives you an average hang-over of 200-250ms
>that are hardly noticeable by a human in this topic. The issue is not if
>you always meet the deadline, the issue is what amount of load will make
>you miss it. If I have to hire five ppl clicking and dragging on my desktop
>to make my player to skip, and it skips, I don't care if it missed the
>deadline. This because my desktop will hardly see that load. But if you
>have a 50-100ms backup, things turns out to be a little bit different.
>If you pretend to run a `make -jUNREAL` and still have the audio not
>skipping it is simply wrong. Running a `make -j20` in my machine shows an
>average of 24 TASK_RUNNING tasks, that even if they're granted with a mere
>40ms timeslice, it'll take a full second before an expired task will see
>the light again. BTW, under such load RealPlayer skips badly, but I don't
>really care since it never did while I was doing all the normal (and many
>extra) stuff I'm doing on my desktop.
>
>

I agree some people have some inflated ideas about a desktop workload,
but I'd just point out that if your mp3 player was using say 2% CPU,
it should be able to preempt the make soon after it becomes runnable,
and not have to wait at the end of the queue. It would become a CPU
hog itself if you had 48 other processes running though.



^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08  7:48                                           ` 2.5.74-mm1 Davide Libenzi
  2003-07-08  9:18                                             ` 2.5.74-mm1 Nick Piggin
@ 2003-07-08 11:09                                             ` Daniel Phillips
  2003-07-08 18:19                                               ` 2.5.74-mm1 Davide Libenzi
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-08 11:09 UTC (permalink / raw)
  To: Davide Libenzi; +Cc: Linux Kernel Mailing List

On Tuesday 08 July 2003 09:48, Davide Libenzi wrote:
> On Tue, 8 Jul 2003, Daniel Phillips wrote:
> > 4. So how do you propose to "program timings" so that it's really hard to
> > miss those deadlines?
>
> Having a backup of 400-500ms gives you an average hang-over of 200-250ms
> that are hardly noticeable by a human in this topic. The issue is not if
> you always meet the deadline, the issue is what amount of load will make
> you miss it.

With realtime scheduling, you will make the deadline regardless of load (and 
there is the normal fudge when you add the word "soft").  You're arguing that 
having your sound skip, so long as it only skips under load, is good enough.  
I'm arguing that, no, that sucks too much, it should never skip.  I'll also 
argue that even on 2.4, sound skips under normal loads if your machine isn't 
very fast.

So let's fix this properly, instead of wrapping on more duct tape.

Now, I will not argue that -nice+mingo+con is a proper realtime approach, but 
I will argue that it's considerably better than just fiddling with buffer 
size and hoping for the best.

> If I have to hire five ppl clicking and dragging on my desktop
> to make my player to skip, and it skips, I don't care if it missed the
> deadline. This because my desktop will hardly see that load. But if you
> have a 50-100ms backup, things turns out to be a little bit different.
> If you pretend to run a `make -jUNREAL` and still have the audio not
> skipping it is simply wrong. Running a `make -j20` in my machine shows an
> average of 24 TASK_RUNNING tasks, that even if they're granted with a mere
> 40ms timeslice, it'll take a full second before an expired task will see
> the light again. BTW, under such load RealPlayer skips badly, but I don't
> really care since it never did while I was doing all the normal (and many
> extra) stuff I'm doing on my desktop.

I'm running make -j30 now, with the arrangement I described and sound is not 
skipping.  Convinced?

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08  9:18                                             ` 2.5.74-mm1 Nick Piggin
@ 2003-07-08 15:24                                               ` Davide Libenzi
  2003-07-09  0:36                                                 ` 2.5.74-mm1 Nick Piggin
  0 siblings, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-08 15:24 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Daniel Phillips, Linux Kernel Mailing List

On Tue, 8 Jul 2003, Nick Piggin wrote:

> I agree some people have some inflated ideas about a desktop workload,
> but I'd just point out that if your mp3 player was using say 2% CPU,
> it should be able to preempt the make soon after it becomes runnable,
> and not have to wait at the end of the queue. It would become a CPU
> hog itself if you had 48 other processes running though.

This is clearly true, actually even more since player usually suck way
less than 2% of the CPU. If no video is involved, they simply do a write()
to /dev/dsp and then they sync by calling GETOSPACE and sleeping in the
"hope" to be wake up almost in time. I never said that the scheduler
should not be fixed. It definitely has to.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08 11:09                                             ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-08 18:19                                               ` Davide Libenzi
  2003-07-08 19:12                                                 ` 2.5.74-mm1 Davide Libenzi
  0 siblings, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-08 18:19 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

On Tue, 8 Jul 2003, Daniel Phillips wrote:

> On Tuesday 08 July 2003 09:48, Davide Libenzi wrote:
> > On Tue, 8 Jul 2003, Daniel Phillips wrote:
> > > 4. So how do you propose to "program timings" so that it's really hard to
> > > miss those deadlines?
> >
> > Having a backup of 400-500ms gives you an average hang-over of 200-250ms
> > that are hardly noticeable by a human in this topic. The issue is not if
> > you always meet the deadline, the issue is what amount of load will make
> > you miss it.
>
> With realtime scheduling, you will make the deadline regardless of load (and
> there is the normal fudge when you add the word "soft").  You're arguing that
> having your sound skip, so long as it only skips under load, is good enough.
> I'm arguing that, no, that sucks too much, it should never skip.  I'll also
> argue that even on 2.4, sound skips under normal loads if your machine isn't
> very fast.
>
> So let's fix this properly, instead of wrapping on more duct tape.
>
> Now, I will not argue that -nice+mingo+con is a proper realtime approach, but
> I will argue that it's considerably better than just fiddling with buffer
> size and hoping for the best.

If you seek to meet the dead under any load, there's no patch that uses
the timeslice driven scheduling that will work. You need a non-timeslice
driven scheduling like SCHED_RR (and talking about realtime, it is not
even sufficent with Linux). Since the POSIX SCHED_RR definition cannot be
allowed to be used w/out superuser rights for obvious starvation issues
that might cause of other tasks, we would really need either to push
a new POSIX defintion or to modify the SCHED_RR behaviour if called from a
non-superuser account. For example, a slot above all standard priorities
and below RT priorities should be reserved to host those pseudo-rt tasks,
whose dynamic priority will not decay but that they might expire if they
abuse of a predetermined CPU utilization policy. Basically their timeslice
will vary depending on the CPU utilization pattern and they might end up
in the expired array if they abuse it. For example, when one of those
internally mapped SCHED_SOFTRR tasks will expire we will recalc their
timelisce like we are doing now and we will also register for the
timestamp (jiffies) when the got recharged. If (jiffies - last_charge) is
lower then a pre-defined threshold we drop the task in expired array,
otherwise in the active one. This will make our SCHED_SOFTRR to be able to
always preempt SCHED_OTHER tasks and the above trick will also avoid
starvation.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08 18:19                                               ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-08 19:12                                                 ` Davide Libenzi
  0 siblings, 0 replies; 147+ messages in thread
From: Davide Libenzi @ 2003-07-08 19:12 UTC (permalink / raw)
  To: Daniel Phillips; +Cc: Linux Kernel Mailing List

On Tue, 8 Jul 2003, Davide Libenzi wrote:

> If you seek to meet the dead under any load, there's no patch that uses

Sorry, it is clearly 's/dead/deadline/'. There was no life threat here :)



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-08 15:24                                               ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-09  0:36                                                 ` Nick Piggin
  0 siblings, 0 replies; 147+ messages in thread
From: Nick Piggin @ 2003-07-09  0:36 UTC (permalink / raw)
  To: Davide Libenzi; +Cc: Daniel Phillips, Linux Kernel Mailing List



Davide Libenzi wrote:

>On Tue, 8 Jul 2003, Nick Piggin wrote:
>
>
>>I agree some people have some inflated ideas about a desktop workload,
>>but I'd just point out that if your mp3 player was using say 2% CPU,
>>it should be able to preempt the make soon after it becomes runnable,
>>and not have to wait at the end of the queue. It would become a CPU
>>hog itself if you had 48 other processes running though.
>>
>
>This is clearly true, actually even more since player usually suck way
>less than 2% of the CPU. If no video is involved, they simply do a write()
>to /dev/dsp and then they sync by calling GETOSPACE and sleeping in the
>"hope" to be wake up almost in time. I never said that the scheduler
>should not be fixed. It definitely has to.
>

Well, yeah, I can run xmms on my 2xCPU system with 32 processes in
an infinite loop, and 32 in an infinite loop of fork+wait. No skipping.
So maybe gcc gets its priority elevated too much due to the small
amount of waiting it does.



^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-07 19:36                             ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-09 22:17                               ` Daniel Phillips
  2003-07-09 22:24                                 ` 2.5.74-mm1 Jamie Lokier
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-09 22:17 UTC (permalink / raw)
  To: Jamie Lokier, Davide Libenzi
  Cc: Mel Gorman, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Monday 07 July 2003 21:36, Jamie Lokier wrote:
> Davide Libenzi wrote:
> > The *application* has to hint the scheduler, not the user.
>
> Agreed.
>
> (I think the user/PAM idea came up for the same sort of reason that
> only console users are able to open /dev/cdrom: asking for extra
> resource (in this case low latency is a resource) might be something
> you'd restrict to console users.

I frequently run Zinf over ssh, to a machine that's connected to speakers.

> But that is a very separate question from how do we get low latency to work
> at all!)

We've got something better than we've had before, even though it doesn't go as 
far as making true realtime processing available to normal users.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-09 22:17                               ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-09 22:24                                 ` Jamie Lokier
  2003-07-09 22:29                                   ` 2.5.74-mm1 Davide Libenzi
  2003-07-09 22:59                                   ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 2 replies; 147+ messages in thread
From: Jamie Lokier @ 2003-07-09 22:24 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Davide Libenzi, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

Daniel Phillips wrote:
> > (I think the user/PAM idea came up for the same sort of reason that
> > only console users are able to open /dev/cdrom: asking for extra
> > resource (in this case low latency is a resource) might be something
> > you'd restrict to console users.
> 
> I frequently run Zinf over ssh, to a machine that's connected to speakers.

I do similar things.  I also read /dev/cdrom over ssh, which is not
permitted by the default security policy.  I.e. it's a userspace
policy issue.

> We've got something better than we've had before, even though it doesn't go as 
> far as making true realtime processing available to normal users.

Indeed.  But maybe true (bounded CPU) realtime, reliable, would more
accurately reflect what the user actually wants for some apps?

Just a thought,
-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-09 22:24                                 ` 2.5.74-mm1 Jamie Lokier
@ 2003-07-09 22:29                                   ` Davide Libenzi
  2003-07-09 23:15                                     ` 2.5.74-mm1 Daniel Phillips
  2003-07-09 22:59                                   ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-09 22:29 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Daniel Phillips, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Wed, 9 Jul 2003, Jamie Lokier wrote:

> Indeed.  But maybe true (bounded CPU) realtime, reliable, would more
> accurately reflect what the user actually wants for some apps?

Hopefully I'll have a couple of hours free to code and test the
SCHED_SOFTRR idea ;) It's hard to push for a new POSIX definition though :)
Looking at recent posts it seems that this is not the only problem though.
It seems interactivity lowered in the latest versions of the scheduler.
The good news is that Ingo is back on Earth and he'll fix it :)



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-09 22:24                                 ` 2.5.74-mm1 Jamie Lokier
  2003-07-09 22:29                                   ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-09 22:59                                   ` Daniel Phillips
  2003-07-10  2:01                                     ` 2.5.74-mm1 Peter Chubb
  1 sibling, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-09 22:59 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: Davide Libenzi, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Thursday 10 July 2003 00:24, Jamie Lokier wrote:
> Daniel Phillips wrote:
> > We've got something better than we've had before, even though it doesn't
> > go as far as making true realtime processing available to normal users.
>
> Indeed.  But maybe true (bounded CPU) realtime, reliable, would more
> accurately reflect what the user actually wants for some apps?

No doubt about it.  Other OSes have it:

   http://www.chemie.fu-berlin.de/cgi-bin/man/sgi_irix?realtime+5

Hopefully in the next cycle, we will too.

I like your idea of allowing normal users to set SCHED_RR, but automatically 
placing some bound on cpu usage.  It's guaranteed not to break any existing 
programs.

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-09 22:29                                   ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-09 23:15                                     ` Daniel Phillips
  2003-07-09 23:19                                       ` 2.5.74-mm1 Jamie Lokier
  0 siblings, 1 reply; 147+ messages in thread
From: Daniel Phillips @ 2003-07-09 23:15 UTC (permalink / raw)
  To: Davide Libenzi, Jamie Lokier
  Cc: Mel Gorman, Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Thursday 10 July 2003 00:29, Davide Libenzi wrote:
> On Wed, 9 Jul 2003, Jamie Lokier wrote:
> > Indeed.  But maybe true (bounded CPU) realtime, reliable, would more
> > accurately reflect what the user actually wants for some apps?
>
> Hopefully I'll have a couple of hours free to code and test the
> SCHED_SOFTRR idea ;) It's hard to push for a new POSIX definition though :)

Oops, sorry for attributing that to Jamie instead of you :-/

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-09 23:15                                     ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-09 23:19                                       ` Jamie Lokier
  0 siblings, 0 replies; 147+ messages in thread
From: Jamie Lokier @ 2003-07-09 23:19 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Davide Libenzi, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

Daniel Phillips wrote:
> Oops, sorry for attributing that to Jamie instead of you :-/

They say great minds think alike ;)

-- Jamie

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-09 22:59                                   ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-10  2:01                                     ` Peter Chubb
  2003-07-11  1:04                                       ` 2.5.74-mm1 Daniel Phillips
  0 siblings, 1 reply; 147+ messages in thread
From: Peter Chubb @ 2003-07-10  2:01 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Jamie Lokier, Davide Libenzi, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

>>>>> "Daniel" == Daniel Phillips <phillips@arcor.de> writes:


Daniel> I like your idea of allowing normal users to set SCHED_RR, but
Daniel> automatically placing some bound on cpu usage.  It's
Daniel> guaranteed not to break any existing programs.

I suspect that what's really wanted here is not SCHED_RR but
guaranteed rate-of-forward progress.  A dynamic-window-constrained
scheduler (that guarantees not that you'll run until you sleep, but
that in any (settable) time period you'll get the opportunity to run
for at least (a smaller settable period)) is closer to what's wanted.

See http://www.cs.bu.edu/fac/richwest/dwcs.html

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories,   all slightly different.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-10  2:01                                     ` 2.5.74-mm1 Peter Chubb
@ 2003-07-11  1:04                                       ` Daniel Phillips
  2003-07-11  1:08                                         ` 2.5.74-mm1 William Lee Irwin III
  2003-07-11  5:44                                         ` 2.5.74-mm1 Davide Libenzi
  0 siblings, 2 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-11  1:04 UTC (permalink / raw)
  To: Peter Chubb
  Cc: Jamie Lokier, Davide Libenzi, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Thursday 10 July 2003 04:01, Peter Chubb wrote:
> I suspect that what's really wanted here is not SCHED_RR but
> guaranteed rate-of-forward progress.

I suspect you are right.  I'd also like to note that this is ground so 
thoroughly trodden that the grass is flat.  Realtime schedulers are a well 
researched topic, it's just too bad that committees don't design them as well 
as engineers would.

Thinking strictly about the needs of sound processing, what's needed is a 
guarantee of so much cpu time each time the timer fires, and a user limit to 
prevent cpu hogging.  It's worth pondering the difference between that and 
rate-of-forward-progress.  I suspect some simple improvements to the current 
scheduler can be made to do the job, and at the same time, avoid the 
priorty-based starvation issue that seems to have been practically mandated 
by POSIX.

> A dynamic-window-constrained
> scheduler (that guarantees not that you'll run until you sleep, but
> that in any (settable) time period you'll get the opportunity to run
> for at least (a smaller settable period)) is closer to what's wanted.

It's possible that may be equivalent to what I said :-)

> See http://www.cs.bu.edu/fac/richwest/dwcs.html

This is an interesting link.  One of the design rules has to be that O(1) 
performance is never degraded, at least when there are no realtime processes.  
Also, I want to be clear that I'm not suggesting this sort of thing has 
anything to do with the current cycle, unless tweaking of the incumbent 
sheduler fails for some reason, which it seems unlikely to do.

Regards,

Daniel
>
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> You are lost in a maze of BitKeeper repositories,   all slightly different.


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-11  1:04                                       ` 2.5.74-mm1 Daniel Phillips
@ 2003-07-11  1:08                                         ` William Lee Irwin III
  2003-07-11  5:44                                         ` 2.5.74-mm1 Davide Libenzi
  1 sibling, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-11  1:08 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Peter Chubb, Jamie Lokier, Davide Libenzi, Mel Gorman,
	Andrew Morton, Linux Kernel Mailing List,
	Linux Memory Management List

On Fri, Jul 11, 2003 at 03:04:11AM +0200, Daniel Phillips wrote:
> Thinking strictly about the needs of sound processing, what's needed is a 
> guarantee of so much cpu time each time the timer fires, and a user limit to 
> prevent cpu hogging.  It's worth pondering the difference between that and 
> rate-of-forward-progress.  I suspect some simple improvements to the current 
> scheduler can be made to do the job, and at the same time, avoid the 
> priorty-based starvation issue that seems to have been practically mandated 
> by POSIX.

Such scheduling policies are called "isochronous".


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-11  1:04                                       ` 2.5.74-mm1 Daniel Phillips
  2003-07-11  1:08                                         ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-11  5:44                                         ` Davide Libenzi
  2003-07-11  8:07                                           ` 2.5.74-mm1 Daniel Phillips
  1 sibling, 1 reply; 147+ messages in thread
From: Davide Libenzi @ 2003-07-11  5:44 UTC (permalink / raw)
  To: Daniel Phillips
  Cc: Peter Chubb, Jamie Lokier, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Fri, 11 Jul 2003, Daniel Phillips wrote:

> I suspect you are right.  I'd also like to note that this is ground so
> thoroughly trodden that the grass is flat.  Realtime schedulers are a well
> researched topic, it's just too bad that committees don't design them as well
> as engineers would.
>
> Thinking strictly about the needs of sound processing, what's needed is a
> guarantee of so much cpu time each time the timer fires, and a user limit to
> prevent cpu hogging.  It's worth pondering the difference between that and
> rate-of-forward-progress.  I suspect some simple improvements to the current
> scheduler can be made to do the job, and at the same time, avoid the
> priorty-based starvation issue that seems to have been practically mandated
> by POSIX.

I've been finally able to make my sound card to sing with 2.5 and I was
able to sh*t load my machine running RealPlay with the SOFTRR path :

http://www.xmailserver.org/linux-patches/softrr.html

I was not able to get a single skip. For many kind of applications it is
not strong real time that is needed. For example, in case on those
multimedia pps, I saw that they can live pretty happy with 10-20ms
latencies. The problem is that w/out living in the realtime priority even,
they can be sucked in by interactive tasks running they loong timeslice
multiple times. Plus-latencies of 100-150ms are very easy to get. Even if
the average latency, like graphs show, is very close to the expected one.



- Davide


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-11  5:44                                         ` 2.5.74-mm1 Davide Libenzi
@ 2003-07-11  8:07                                           ` Daniel Phillips
  0 siblings, 0 replies; 147+ messages in thread
From: Daniel Phillips @ 2003-07-11  8:07 UTC (permalink / raw)
  To: Davide Libenzi
  Cc: Peter Chubb, Jamie Lokier, Mel Gorman, Andrew Morton,
	Linux Kernel Mailing List, Linux Memory Management List

On Friday 11 July 2003 07:44, Davide Libenzi wrote:
> http://www.xmailserver.org/linux-patches/softrr.html

:-)

Regards,

Daniel


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04 20:00         ` 2.5.74-mm1 Helge Hafting
@ 2003-07-04 20:08           ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04 20:08 UTC (permalink / raw)
  To: Helge Hafting; +Cc: Andrew Morton, zboszor, linux-kernel

On Fri, Jul 04, 2003 at 10:00:46PM +0200, Helge Hafting wrote:
> I'm sorry, both cpu's are up.  I did a better test
> with busy loops.  One high-priority (nice --10)
> busy loop has no effect on performance, two such ones
> makes the mouse cursor very jumpy. 
> So both cpus are working, after all and not merely being
> detected.  I'm using gcc 3.3 from debian testing.

Same compiler I'm using, which has been seen to work.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 21:15       ` 2.5.74-mm1 Andrew Morton
  2003-07-04  5:53         ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-04 20:00         ` Helge Hafting
  2003-07-04 20:08           ` 2.5.74-mm1 William Lee Irwin III
  1 sibling, 1 reply; 147+ messages in thread
From: Helge Hafting @ 2003-07-04 20:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: zboszor, linux-kernel

On Thu, Jul 03, 2003 at 02:15:08PM -0700, Andrew Morton wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
[...]
> > I may have this problem on my dual celeron.  I noticed X got sluggish
> > while generating a key for mozilla - very strange on a dual
> > but I put it down to the scheduler changes.
> > 
> > Looking at dmesg I see that both is detected, and it claims
> > both are "activated", but I get this a little later:
[...] 
> ok.  If you're feeling keen could you please revert the cpumask_t patch.
> 
> And please send the .config, thanks.

I'm sorry, both cpu's are up.  I did a better test
with busy loops.  One high-priority (nice --10)
busy loop has no effect on performance, two such ones
makes the mouse cursor very jumpy. 

So both cpus are working, after all and not merely being
detected.  I'm using gcc 3.3 from debian testing.

Helge Hafting

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  8:56                 ` 2.5.74-mm1 Andrew Morton
@ 2003-07-04  8:57                   ` William Lee Irwin III
  0 siblings, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04  8:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Zwane Mwaikambo, helgehaf, zboszor, linux-kernel

On Fri, Jul 04, 2003 at 01:56:42AM -0700, Andrew Morton wrote:
> Like this.  I erased every `volatile' I could find.  No idea why they were
> in there.

Some were inherited from the preexisting code. The bitmap.h bits
were to prevent warnings when passed volatiles.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  8:37               ` 2.5.74-mm1 Zwane Mwaikambo
@ 2003-07-04  8:56                 ` Andrew Morton
  2003-07-04  8:57                   ` 2.5.74-mm1 William Lee Irwin III
  0 siblings, 1 reply; 147+ messages in thread
From: Andrew Morton @ 2003-07-04  8:56 UTC (permalink / raw)
  To: Zwane Mwaikambo; +Cc: wli, helgehaf, zboszor, linux-kernel

Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
>
> > I shall make that change.
> 
>  Very nice, thanks!

Like this.  I erased every `volatile' I could find.  No idea why they were
in there.


 arch/i386/kernel/smp.c     |    2 -
 arch/i386/kernel/smpboot.c |    6 ++---
 include/asm-i386/smp.h     |    2 -
 include/linux/bitmap.h     |   52 ++++++++++++++++++++++++++-------------------
 4 files changed, 36 insertions(+), 26 deletions(-)

diff -puN include/linux/bitmap.h~gcc-bug-workaround include/linux/bitmap.h
--- 25/include/linux/bitmap.h~gcc-bug-workaround	2003-07-04 01:52:11.000000000 -0700
+++ 25-akpm/include/linux/bitmap.h	2003-07-04 01:52:11.000000000 -0700
@@ -10,7 +10,7 @@
 #include <linux/bitops.h>
 #include <linux/string.h>
 
-static inline int bitmap_empty(const volatile unsigned long *bitmap, int bits)
+static inline int bitmap_empty(const unsigned long *bitmap, int bits)
 {
 	int k;
 	for (k = 0; k < bits/BITS_PER_LONG; ++k)
@@ -24,7 +24,7 @@ static inline int bitmap_empty(const vol
 	return 1;
 }
 
-static inline int bitmap_full(const volatile unsigned long *bitmap, int bits)
+static inline int bitmap_full(const unsigned long *bitmap, int bits)
 {
 	int k;
 	for (k = 0; k < bits/BITS_PER_LONG; ++k)
@@ -38,7 +38,8 @@ static inline int bitmap_full(const vola
 	return 1;
 }
 
-static inline int bitmap_equal(const volatile unsigned long *bitmap1, volatile unsigned long *bitmap2, int bits)
+static inline int bitmap_equal(const unsigned long *bitmap1,
+				unsigned long *bitmap2, int bits)
 {
 	int k;
 	for (k = 0; k < bits/BITS_PER_LONG; ++k)
@@ -46,13 +47,14 @@ static inline int bitmap_equal(const vol
 			return 0;
 
 	if (bits % BITS_PER_LONG)
-		if ((bitmap1[k] ^ bitmap2[k]) & ((1UL << (bits % BITS_PER_LONG)) - 1))
+		if ((bitmap1[k] ^ bitmap2[k]) &
+				((1UL << (bits % BITS_PER_LONG)) - 1))
 			return 0;
 
 	return 1;
 }
 
-static inline void bitmap_complement(volatile unsigned long *bitmap, int bits)
+static inline void bitmap_complement(unsigned long *bitmap, int bits)
 {
 	int k;
 
@@ -60,23 +62,24 @@ static inline void bitmap_complement(vol
 		bitmap[k] = ~bitmap[k];
 }
 
-static inline void bitmap_clear(volatile unsigned long *bitmap, int bits)
+static inline void bitmap_clear(unsigned long *bitmap, int bits)
 {
 	CLEAR_BITMAP((unsigned long *)bitmap, bits);
 }
 
-static inline void bitmap_fill(volatile unsigned long *bitmap, int bits)
+static inline void bitmap_fill(unsigned long *bitmap, int bits)
 {
-	memset((unsigned long *)bitmap, 0xff, BITS_TO_LONGS(bits)*sizeof(unsigned long));
+	memset(bitmap, 0xff, BITS_TO_LONGS(bits)*sizeof(unsigned long));
 }
 
-static inline void bitmap_copy(volatile unsigned long *dst, const volatile unsigned long *src, int bits)
+static inline void bitmap_copy(unsigned long *dst,
+			const unsigned long *src, int bits)
 {
-	memcpy((unsigned long *)dst, (unsigned long *)src, BITS_TO_LONGS(bits)*sizeof(unsigned long));
+	memcpy(dst, src, BITS_TO_LONGS(bits)*sizeof(unsigned long));
 }
 
-static inline void bitmap_shift_left(volatile unsigned long *,const volatile unsigned long *,int,int);
-static inline void bitmap_shift_right(volatile unsigned long *dst, const volatile unsigned long *src, int shift, int bits)
+static inline void bitmap_shift_right(unsigned long *dst,
+				const unsigned long *src, int shift, int bits)
 {
 	int k;
 	DECLARE_BITMAP(__shr_tmp, bits);
@@ -88,7 +91,8 @@ static inline void bitmap_shift_right(vo
 	bitmap_copy(dst, __shr_tmp, bits);
 }
 
-static inline void bitmap_shift_left(volatile unsigned long *dst, const volatile unsigned long *src, int shift, int bits)
+static inline void bitmap_shift_left(unsigned long *dst,
+				const unsigned long *src, int shift, int bits)
 {
 	int k;
 	DECLARE_BITMAP(__shl_tmp, bits);
@@ -100,24 +104,28 @@ static inline void bitmap_shift_left(vol
 	bitmap_copy(dst, __shl_tmp, bits);
 }
 
-static inline void bitmap_and(volatile unsigned long *dst, const volatile unsigned long *bitmap1, const volatile unsigned long *bitmap2, int bits)
+static inline void bitmap_and(unsigned long *dst, const unsigned long *bitmap1,
+				const unsigned long *bitmap2, int bits)
 {
 	int k;
+	int nr = BITS_TO_LONGS(bits);
 
-	for (k = 0; k < BITS_TO_LONGS(bits); ++k)
+	for (k = 0; k < nr; k++)
 		dst[k] = bitmap1[k] & bitmap2[k];
 }
 
-static inline void bitmap_or(volatile unsigned long *dst, const volatile unsigned long *bitmap1, const volatile unsigned long *bitmap2, int bits)
+static inline void bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
+				const unsigned long *bitmap2, int bits)
 {
 	int k;
+	int nr = BITS_TO_LONGS(bits);
 
-	for (k = 0; k < BITS_TO_LONGS(bits); ++k)
+	for (k = 0; k < nr; k++)
 		dst[k] = bitmap1[k] | bitmap2[k];
 }
 
 #if BITS_PER_LONG == 32
-static inline int bitmap_weight(const volatile unsigned long *bitmap, int bits)
+static inline int bitmap_weight(const unsigned long *bitmap, int bits)
 {
 	int k, w = 0;
 
@@ -125,12 +133,13 @@ static inline int bitmap_weight(const vo
 		w += hweight32(bitmap[k]);
 
 	if (bits % BITS_PER_LONG)
-		w+= hweight32(bitmap[k] & ((1UL << (bits % BITS_PER_LONG)) - 1));
+		w += hweight32(bitmap[k] &
+				((1UL << (bits % BITS_PER_LONG)) - 1));
 
 	return w;
 }
 #else
-static inline int bitmap_weight(const volatile unsigned long *bitmap, int bits)
+static inline int bitmap_weight(const unsigned long *bitmap, int bits)
 {
 	int k, w = 0;
 
@@ -138,7 +147,8 @@ static inline int bitmap_weight(const vo
 		w += hweight64(bitmap[k]);
 
 	if (bits % BITS_PER_LONG)
-		w += hweight64(bitmap[k] & ((1UL << (bits % BITS_PER_LONG)) - 1));
+		w += hweight64(bitmap[k] &
+				((1UL << (bits % BITS_PER_LONG)) - 1));
 
 	return w;
 }
diff -puN include/asm-i386/smp.h~gcc-bug-workaround include/asm-i386/smp.h
--- 25/include/asm-i386/smp.h~gcc-bug-workaround	2003-07-04 01:52:17.000000000 -0700
+++ 25-akpm/include/asm-i386/smp.h	2003-07-04 01:52:25.000000000 -0700
@@ -53,7 +53,7 @@ extern void zap_low_mappings (void);
  */
 #define smp_processor_id() (current_thread_info()->cpu)
 
-extern volatile cpumask_t cpu_callout_map;
+extern cpumask_t cpu_callout_map;
 
 #define cpu_possible(cpu) cpu_isset(cpu, cpu_callout_map)
 
diff -puN arch/i386/kernel/smpboot.c~gcc-bug-workaround arch/i386/kernel/smpboot.c
--- 25/arch/i386/kernel/smpboot.c~gcc-bug-workaround	2003-07-04 01:52:36.000000000 -0700
+++ 25-akpm/arch/i386/kernel/smpboot.c	2003-07-04 01:52:59.000000000 -0700
@@ -64,8 +64,8 @@ int phys_proc_id[NR_CPUS]; /* Package ID
 /* bitmap of online cpus */
 cpumask_t cpu_online_map;
 
-static volatile cpumask_t cpu_callin_map;
-volatile cpumask_t cpu_callout_map;
+static cpumask_t cpu_callin_map;
+cpumask_t cpu_callout_map;
 static cpumask_t smp_commenced_mask;
 
 /* Per CPU bogomips and other parameters */
@@ -529,7 +529,7 @@ static inline void unmap_cpu_to_node(int
 
 #endif /* CONFIG_NUMA */
 
-volatile u8 cpu_2_logical_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
+u8 cpu_2_logical_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
 
 void map_cpu_to_logical_apicid(void)
 {
diff -puN arch/i386/kernel/smp.c~gcc-bug-workaround arch/i386/kernel/smp.c
--- 25/arch/i386/kernel/smp.c~gcc-bug-workaround	2003-07-04 01:55:10.000000000 -0700
+++ 25-akpm/arch/i386/kernel/smp.c	2003-07-04 01:55:25.000000000 -0700
@@ -241,7 +241,7 @@ inline void send_IPI_mask_sequence(cpuma
  *	Optimizations Manfred Spraul <manfred@colorfullife.com>
  */
 
-static volatile cpumask_t flush_cpumask;
+static cpumask_t flush_cpumask;
 static struct mm_struct * flush_mm;
 static unsigned long flush_va;
 static spinlock_t tlbstate_lock = SPIN_LOCK_UNLOCKED;

_


^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  8:27             ` 2.5.74-mm1 Andrew Morton
  2003-07-04  8:37               ` 2.5.74-mm1 Zwane Mwaikambo
@ 2003-07-04  8:52               ` William Lee Irwin III
  1 sibling, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04  8:52 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Zwane Mwaikambo, helgehaf, zboszor, linux-kernel

On Fri, Jul 04, 2003 at 01:27:34AM -0700, Andrew Morton wrote:
> fixes it up, and looks nicer anyway.  Removing the volatiles (what were
> they doing there?) did not fix it.  The `nr' thing fixed it.  

Those were to prevent warnings in case someone passed in a volatile
bitmap. Which no one is doing at the moment that I know of offhand.


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  8:27             ` 2.5.74-mm1 Andrew Morton
@ 2003-07-04  8:37               ` Zwane Mwaikambo
  2003-07-04  8:56                 ` 2.5.74-mm1 Andrew Morton
  2003-07-04  8:52               ` 2.5.74-mm1 William Lee Irwin III
  1 sibling, 1 reply; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04  8:37 UTC (permalink / raw)
  To: Andrew Morton; +Cc: wli, helgehaf, zboszor, linux-kernel

On Fri, 4 Jul 2003, Andrew Morton wrote:

> static inline void bitmap_or(unsigned long *dst, unsigned long *bitmap1,
>                                 unsigned long *bitmap2, int bits)
> {
>         int k;
>         int nr = BITS_TO_LONGS(bits);
> 
>         for (k = 0; k < nr; k++)
>                 dst[k] = bitmap1[k] | bitmap2[k];
> }
> 
> fixes it up, and looks nicer anyway.  Removing the volatiles (what were
> they doing there?) did not fix it.  The `nr' thing fixed it.  
> 
> I shall make that change.

Very nice, thanks!

	Zwane
-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  7:15           ` 2.5.74-mm1 Zwane Mwaikambo
  2003-07-04  7:50             ` 2.5.74-mm1 Zwane Mwaikambo
@ 2003-07-04  8:27             ` Andrew Morton
  2003-07-04  8:37               ` 2.5.74-mm1 Zwane Mwaikambo
  2003-07-04  8:52               ` 2.5.74-mm1 William Lee Irwin III
  1 sibling, 2 replies; 147+ messages in thread
From: Andrew Morton @ 2003-07-04  8:27 UTC (permalink / raw)
  To: Zwane Mwaikambo; +Cc: wli, helgehaf, zboszor, linux-kernel

Zwane Mwaikambo <zwane@arm.linux.org.uk> wrote:
>

Changing this:

>  static inline void bitmap_or(volatile unsigned long *dst, const volatile unsigned long *bitmap1,
>  				const volatile unsigned long *bitmap2, int bits)
>  {
>  	int k;
> 
>  	for (k = 0; k < BITS_TO_LONGS(bits); ++k)
>  		dst[k] = bitmap1[k] | bitmap2[k];
>  }

to this:

static inline void bitmap_or(unsigned long *dst, unsigned long *bitmap1,
                                unsigned long *bitmap2, int bits)
{
        int k;
        int nr = BITS_TO_LONGS(bits);

        for (k = 0; k < nr; k++)
                dst[k] = bitmap1[k] | bitmap2[k];
}

fixes it up, and looks nicer anyway.  Removing the volatiles (what were
they doing there?) did not fix it.  The `nr' thing fixed it.  

I shall make that change.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  7:15           ` 2.5.74-mm1 Zwane Mwaikambo
@ 2003-07-04  7:50             ` Zwane Mwaikambo
  2003-07-04  8:27             ` 2.5.74-mm1 Andrew Morton
  1 sibling, 0 replies; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04  7:50 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Andrew Morton, Helge Hafting, zboszor, Linux Kernel

On Fri, 4 Jul 2003, Zwane Mwaikambo wrote:

> The second one is correct. So one definite failing piece of code was in 
> the cpus_or() path, i'm not so sure about the others. I have attached the 
> test case. Bill says his gcc 3.3 works...

Uninlining bitmap_or fixes the test case with -O2 Could you try the 
following patch with your kernels?

--- linux-2.5.74-cpumask/include/linux/bitmap.h.orig	2003-07-04 03:48:22.746229592 -0400
+++ linux-2.5.74-cpumask/include/linux/bitmap.h	2003-07-04 03:49:39.606545048 -0400
@@ -100,7 +100,7 @@
 	bitmap_copy(dst, __shl_tmp, bits);
 }
 
-static inline void bitmap_and(volatile unsigned long *dst, const volatile unsigned long *bitmap1, const volatile unsigned long *bitmap2, int bits)
+static void bitmap_and(volatile unsigned long *dst, const volatile unsigned long *bitmap1, const volatile unsigned long *bitmap2, int bits)
 {
 	int k;
 
@@ -108,7 +108,7 @@
 		dst[k] = bitmap1[k] & bitmap2[k];
 }
 
-static inline void bitmap_or(volatile unsigned long *dst, const volatile unsigned long *bitmap1, const volatile unsigned long *bitmap2, int bits)
+static void bitmap_or(volatile unsigned long *dst, const volatile unsigned long *bitmap1, const volatile unsigned long *bitmap2, int bits)
 {
 	int k;
 

-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  7:12           ` 2.5.74-mm1 Boszormenyi Zoltan
@ 2003-07-04  7:16             ` Zwane Mwaikambo
  0 siblings, 0 replies; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04  7:16 UTC (permalink / raw)
  To: Boszormenyi Zoltan
  Cc: William Lee Irwin III, Andrew Morton, Helge Hafting, linux-kernel

On Fri, 4 Jul 2003, Boszormenyi Zoltan wrote:

> [zozo@catv-50622120 zozo]$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
> --infodir=/usr/share/info --enable-shared --enable-threads=posix 
> --disable-checking --with-system-zlib --enable-__cxa_atexit 
> --host=i386-redhat-linux
> Thread model: posix
> gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

Yes looks like what ships with RH9 (my build box is also RH9)

-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  5:53         ` 2.5.74-mm1 William Lee Irwin III
  2003-07-04  7:12           ` 2.5.74-mm1 Boszormenyi Zoltan
@ 2003-07-04  7:15           ` Zwane Mwaikambo
  2003-07-04  7:50             ` 2.5.74-mm1 Zwane Mwaikambo
  2003-07-04  8:27             ` 2.5.74-mm1 Andrew Morton
  1 sibling, 2 replies; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-04  7:15 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Andrew Morton, Helge Hafting, zboszor, Linux Kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2233 bytes --]

On Thu, 3 Jul 2003, William Lee Irwin III wrote:

> On Thu, Jul 03, 2003 at 02:15:08PM -0700, Andrew Morton wrote:
> > ok.  If you're feeling keen could you please revert the cpumask_t patch.
> > And please send the .config, thanks.
> 
> Zwane reproduced this and when I compiled an identical kernel for him
> it went away; the only difference wsa the compiler version.

This is definitely a compiler issue, i rebuilt with;

zwane@montezuma linux-2.5.74-cpumask {0:0} gcc296 -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux7/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-118)

And that works with NR_CPUS = 3 (it also explains why my 8way test box 
with RH7.3 worked)

Also i ended up writing a userspace test case. I then narrowed it down to 
-O2 with gcc 3.2 (native RH9 compiler) which causes failure;

e.g.

zwane@montezuma linux-2.5.74-cpumask {0:0} gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

zwane@montezuma linux-2.5.74-cpumask {0:0} gcc -O2 test.c -o test-gcc3.2
zwane@montezuma linux-2.5.74-cpumask {0:0} ./test-gcc3.2
main: tmp 1
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 0
main: tmp 8
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 0
main: tmp 10
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 0

zwane@montezuma linux-2.5.74-cpumask {0:0} gcc -O1 test.c -o test-gcc3.2
zwane@montezuma linux-2.5.74-cpumask {0:0} ./test-gcc3.2
main: tmp 1
main: phys_cpu_present_map before 0
main: phys_cpu_present_map after 1
main: tmp 8
main: phys_cpu_present_map before 1
main: phys_cpu_present_map after 9
main: tmp 10
main: phys_cpu_present_map before 9
main: phys_cpu_present_map after 19

The second one is correct. So one definite failing piece of code was in 
the cpus_or() path, i'm not so sure about the others. I have attached the 
test case. Bill says his gcc 3.3 works...

Andrew?

-- 
function.linuxpower.ca

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1941 bytes --]

#include <stdio.h>
#include <linux/bitops.h>

#define BITS_PER_LONG	32
#define NR_CPUS 3
#define printk(x...)	printf(x)

#define BITS_TO_LONGS(bits) \
	(((bits)+BITS_PER_LONG-1)/BITS_PER_LONG)
#define DECLARE_BITMAP(name,bits) \
	unsigned long name[BITS_TO_LONGS(bits)]
#define CLEAR_BITMAP(name,bits) \
	memset(name, 0, BITS_TO_LONGS(bits)*sizeof(unsigned long))

static inline void bitmap_or(volatile unsigned long *dst, const volatile unsigned long *bitmap1,
				const volatile unsigned long *bitmap2, int bits)
{
	int k;

	for (k = 0; k < BITS_TO_LONGS(bits); ++k)
		dst[k] = bitmap1[k] | bitmap2[k];
}

#define cpu_set(cpu, map)	set_bit(cpu, (map).mask)
#define cpus_or(dst,src1,src2)	bitmap_or((dst).mask, (src1).mask, (src2).mask, NR_CPUS)
#define cpus_coerce(map)	((map).mask[0])

#define CPU_ARRAY_SIZE		BITS_TO_LONGS(NR_CPUS)

#define CPU_MASK_ALL	{ {[0 ... CPU_ARRAY_SIZE-1] = ~0UL} }
#define CPU_MASK_NONE	{ {[0 ... CPU_ARRAY_SIZE-1] =  0UL} }

#define cpumask_of_cpu(cpu)	({ cpumask_t __cpu_mask = CPU_MASK_NONE;\
					cpu_set(cpu, __cpu_mask);	\
					__cpu_mask;			\
				})

struct cpumask
{
	unsigned long mask[CPU_ARRAY_SIZE];
};

typedef struct cpumask cpumask_t;

static inline cpumask_t apicid_to_cpu_present(int phys_apicid)
{
	return cpumask_of_cpu(phys_apicid);
}

int main(int argc, char **argv)
{
	int bios_apicids[] = { 0, 3, 4, -1}, i, apicid;
	cpumask_t phys_cpu_present_map = CPU_MASK_NONE, tmp;

	for (i = 0; bios_apicids[i] != -1; i++) {
		apicid = bios_apicids[i];
		tmp = apicid_to_cpu_present(apicid);
		printk("%s: tmp %lx\n", __FUNCTION__, cpus_coerce(tmp));
		printk("%s: phys_cpu_present_map before %lx\n",
			__FUNCTION__, cpus_coerce(phys_cpu_present_map));
		cpus_or(phys_cpu_present_map, phys_cpu_present_map, tmp);
		printk("%s: phys_cpu_present_map after %lx\n",
			__FUNCTION__, cpus_coerce(phys_cpu_present_map));
	}
	return 0;
}

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-04  5:53         ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-04  7:12           ` Boszormenyi Zoltan
  2003-07-04  7:16             ` 2.5.74-mm1 Zwane Mwaikambo
  2003-07-04  7:15           ` 2.5.74-mm1 Zwane Mwaikambo
  1 sibling, 1 reply; 147+ messages in thread
From: Boszormenyi Zoltan @ 2003-07-04  7:12 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: Andrew Morton, Helge Hafting, linux-kernel

William Lee Irwin III wrote:

>On Thu, Jul 03, 2003 at 02:15:08PM -0700, Andrew Morton wrote:
>  
>
>>ok.  If you're feeling keen could you please revert the cpumask_t patch.
>>And please send the .config, thanks.
>>    
>>
>
>Zwane reproduced this and when I compiled an identical kernel for him
>it went away; the only difference wsa the compiler version.
>
>i.e. this looks like a compiler issue of some kind.
>
>Boszormenyi, Helge, could I get compiler versions? Zwane had
>
><zwane:#offtopic> gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
><zwane:#offtopic> Copyright (C) 2002 Free Software Foundation, Inc.
><zwane:#offtopic> This is free software; see the source for copying conditions
>+.  There is NO
><zwane:#offtopic> warranty; not even for MERCHANTABILITY or FITNESS FOR A
>+PARTICULAR PURPOSE.
>
>so this looks like one of the offending compilers; the one I used that worked
>was:
>
>$ gcc --version
>gcc (GCC) 3.3 (Debian)
>Copyright (C) 2003 Free Software Foundation, Inc.
>This is free software; see the source for copying conditions.  There is NO
>warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>Going over the disassemblies...
>
>
>-- wli
>
>
>
>
>  
>
Mine is:

[zozo@catv-50622120 zozo]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

-- 
Best regards,
Zoltán Böszörményi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.




^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 21:15       ` 2.5.74-mm1 Andrew Morton
@ 2003-07-04  5:53         ` William Lee Irwin III
  2003-07-04  7:12           ` 2.5.74-mm1 Boszormenyi Zoltan
  2003-07-04  7:15           ` 2.5.74-mm1 Zwane Mwaikambo
  2003-07-04 20:00         ` 2.5.74-mm1 Helge Hafting
  1 sibling, 2 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-04  5:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Helge Hafting, zboszor, linux-kernel

On Thu, Jul 03, 2003 at 02:15:08PM -0700, Andrew Morton wrote:
> ok.  If you're feeling keen could you please revert the cpumask_t patch.
> And please send the .config, thanks.

Zwane reproduced this and when I compiled an identical kernel for him
it went away; the only difference wsa the compiler version.

i.e. this looks like a compiler issue of some kind.

Boszormenyi, Helge, could I get compiler versions? Zwane had

<zwane:#offtopic> gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
<zwane:#offtopic> Copyright (C) 2002 Free Software Foundation, Inc.
<zwane:#offtopic> This is free software; see the source for copying conditions
+.  There is NO
<zwane:#offtopic> warranty; not even for MERCHANTABILITY or FITNESS FOR A
+PARTICULAR PURPOSE.

so this looks like one of the offending compilers; the one I used that worked
was:

$ gcc --version
gcc (GCC) 3.3 (Debian)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Going over the disassemblies...


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 19:22   ` 2.5.74-mm1 Andrew Morton
  2003-07-03 20:08     ` 2.5.74-mm1 Helge Hafting
@ 2003-07-03 23:16     ` William Lee Irwin III
  1 sibling, 0 replies; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-03 23:16 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Boszormenyi Zoltan, linux-kernel

Boszormenyi Zoltan <zboszor@freemail.hu> wrote:
>> I actually tried it. It seems that although I compiled an SMP kernel, it 
>> does not use both CPUs.

On Thu, Jul 03, 2003 at 12:22:43PM -0700, Andrew Morton wrote:
> You're right.  The kernel sort-of saw the second CPU but it appears to have
> not come up.
> Have you used any other 2.5 kernels?  Are you able to pinpoint and
> particular kernel version at which this started to happen?
> If not then I'd appreciate it if you could test stock 2.4.74.

Boszormenyi, can you try with APIC_DEBUG defined to 1 in
include/asm-i386/acpidef.h and reproduce with ACPI off in your .config?


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 22:26       ` 2.5.74-mm1 William Lee Irwin III
@ 2003-07-03 23:01         ` Zwane Mwaikambo
  0 siblings, 0 replies; 147+ messages in thread
From: Zwane Mwaikambo @ 2003-07-03 23:01 UTC (permalink / raw)
  To: William Lee Irwin III
  Cc: Helge Hafting, Andrew Morton, Boszormenyi Zoltan, linux-kernel

On Thu, 3 Jul 2003, William Lee Irwin III wrote:

> > Starting migration thread for cpu 0
> > Bringing up 1
> > CPU 1 IS NOW UP!
> > Starting migration thread for cpu 1
> > CPUS done 2
> > mtrr: v2.0 (20020519)
> > I never get a CPU 2 IS NOW UP (or CPU 0)

You never get "CPU 0 IS NOW UP", and you don't have 3 processors so you 
wouldn't see "CPU 2 IS NOW UP". Just cat /proc/cpuinfo or /proc/interrupts 
to verify processor count.

> Could you #define APIC_DEBUG to 1 in include/asm-i386/apicdef.h and
> send me a full bootlog?
> 
> 
> -- wli
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
function.linuxpower.ca

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 20:08     ` 2.5.74-mm1 Helge Hafting
  2003-07-03 21:15       ` 2.5.74-mm1 Andrew Morton
@ 2003-07-03 22:26       ` William Lee Irwin III
  2003-07-03 23:01         ` 2.5.74-mm1 Zwane Mwaikambo
  1 sibling, 1 reply; 147+ messages in thread
From: William Lee Irwin III @ 2003-07-03 22:26 UTC (permalink / raw)
  To: Helge Hafting; +Cc: Andrew Morton, Boszormenyi Zoltan, linux-kernel

On Thu, Jul 03, 2003 at 10:08:58PM +0200, Helge Hafting wrote:
> I may have this problem on my dual celeron.  I noticed X got sluggish
> while generating a key for mozilla - very strange on a dual
> but I put it down to the scheduler changes.
> Looking at dmesg I see that both is detected, and it claims
> both are "activated", but I get this a little later:
> Starting migration thread for cpu 0
> Bringing up 1
> CPU 1 IS NOW UP!
> Starting migration thread for cpu 1
> CPUS done 2
> mtrr: v2.0 (20020519)
> I never get a CPU 2 IS NOW UP (or CPU 0)

Could you #define APIC_DEBUG to 1 in include/asm-i386/apicdef.h and
send me a full bootlog?


-- wli

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 20:08     ` 2.5.74-mm1 Helge Hafting
@ 2003-07-03 21:15       ` Andrew Morton
  2003-07-04  5:53         ` 2.5.74-mm1 William Lee Irwin III
  2003-07-04 20:00         ` 2.5.74-mm1 Helge Hafting
  2003-07-03 22:26       ` 2.5.74-mm1 William Lee Irwin III
  1 sibling, 2 replies; 147+ messages in thread
From: Andrew Morton @ 2003-07-03 21:15 UTC (permalink / raw)
  To: Helge Hafting; +Cc: zboszor, linux-kernel

Helge Hafting <helgehaf@aitel.hist.no> wrote:
>
> On Thu, Jul 03, 2003 at 12:22:43PM -0700, Andrew Morton wrote:
> > Boszormenyi Zoltan <zboszor@freemail.hu> wrote:
> > >
> > > Hi,
> > > 
> > > I actually tried it. It seems that although I compiled an SMP kernel, it 
> > > does not use both CPUs.
> > 
> > You're right.  The kernel sort-of saw the second CPU but it appears to have
> > not come up.
> > 
> I may have this problem on my dual celeron.  I noticed X got sluggish
> while generating a key for mozilla - very strange on a dual
> but I put it down to the scheduler changes.
> 
> Looking at dmesg I see that both is detected, and it claims
> both are "activated", but I get this a little later:
> 
> Starting migration thread for cpu 0
> Bringing up 1
> CPU 1 IS NOW UP!
> Starting migration thread for cpu 1
> CPUS done 2
> mtrr: v2.0 (20020519)
> 
> I never get a CPU 2 IS NOW UP (or CPU 0)
> 

ok.  If you're feeling keen could you please revert the cpumask_t patch.

And please send the .config, thanks.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 19:22   ` 2.5.74-mm1 Andrew Morton
@ 2003-07-03 20:08     ` Helge Hafting
  2003-07-03 21:15       ` 2.5.74-mm1 Andrew Morton
  2003-07-03 22:26       ` 2.5.74-mm1 William Lee Irwin III
  2003-07-03 23:16     ` 2.5.74-mm1 William Lee Irwin III
  1 sibling, 2 replies; 147+ messages in thread
From: Helge Hafting @ 2003-07-03 20:08 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Boszormenyi Zoltan, linux-kernel

On Thu, Jul 03, 2003 at 12:22:43PM -0700, Andrew Morton wrote:
> Boszormenyi Zoltan <zboszor@freemail.hu> wrote:
> >
> > Hi,
> > 
> > I actually tried it. It seems that although I compiled an SMP kernel, it 
> > does not use both CPUs.
> 
> You're right.  The kernel sort-of saw the second CPU but it appears to have
> not come up.
> 
I may have this problem on my dual celeron.  I noticed X got sluggish
while generating a key for mozilla - very strange on a dual
but I put it down to the scheduler changes.

Looking at dmesg I see that both is detected, and it claims
both are "activated", but I get this a little later:

Starting migration thread for cpu 0
Bringing up 1
CPU 1 IS NOW UP!
Starting migration thread for cpu 1
CPUS done 2
mtrr: v2.0 (20020519)

I never get a CPU 2 IS NOW UP (or CPU 0)

Helge Hafting

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 13:09 ` 2.5.74-mm1 Boszormenyi Zoltan
@ 2003-07-03 19:22   ` Andrew Morton
  2003-07-03 20:08     ` 2.5.74-mm1 Helge Hafting
  2003-07-03 23:16     ` 2.5.74-mm1 William Lee Irwin III
  0 siblings, 2 replies; 147+ messages in thread
From: Andrew Morton @ 2003-07-03 19:22 UTC (permalink / raw)
  To: Boszormenyi Zoltan; +Cc: linux-kernel

Boszormenyi Zoltan <zboszor@freemail.hu> wrote:
>
> Hi,
> 
> I actually tried it. It seems that although I compiled an SMP kernel, it 
> does not use both CPUs.

You're right.  The kernel sort-of saw the second CPU but it appears to have
not come up.

Have you used any other 2.5 kernels?  Are you able to pinpoint and
particular kernel version at which this started to happen?

If not then I'd appreciate it if you could test stock 2.4.74.

> I got one oops on boot.

That's a warning, not an oops.  The ACPI IRQ handler claims that it's not
handling the IRQ all the time.  That's a fairly, err, mature problem
actually.


> I was doing two "find / | xargs cat >/dev/null" on two terminals and I 
> didn't notice them.

Well that's nice.  We have a fancy I/O scheduler in there.

> Tried recompiling the .74-mm1 tree with "make -j2" and my xmms does not 
> skip at all
> but my mozilla windows are slowly refreshing, even the compose window is 
> reacting
> slowly. Somehow it's understandable. :-) The machine is a dual P3/500
> with 512MB memory.

Thanks for the feedback.

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
  2003-07-03 10:39 2.5.74-mm1 Boszormenyi Zoltan
@ 2003-07-03 13:09 ` Boszormenyi Zoltan
  2003-07-03 19:22   ` 2.5.74-mm1 Andrew Morton
  0 siblings, 1 reply; 147+ messages in thread
From: Boszormenyi Zoltan @ 2003-07-03 13:09 UTC (permalink / raw)
  To: linux-kernel

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

Hi,

I actually tried it. It seems that although I compiled an SMP kernel, it 
does not
use both CPUs. I got one oops on boot. Attached is the dmesg, 
/proc/cpuinfo and
.config combined. Although everything seems very fast.
I was doing two "find / | xargs cat >/dev/null" on two terminals and I 
didn't notice them.
Tried recompiling the .74-mm1 tree with "make -j2" and my xmms does not 
skip at all
but my mozilla windows are slowly refreshing, even the compose window is 
reacting
slowly. Somehow it's understandable. :-) The machine is a dual P3/500
with 512MB memory.

Best regards,

Zoltán Böszörményi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.


[-- Attachment #2: dmesg --]
[-- Type: text/plain, Size: 48502 bytes --]

roadband.hu) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Thu Jul 3 13:27:04 CEST 2003
Video mode to be used for restore is f00
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fffd000 (usable)
 BIOS-e820: 000000001fffd000 - 000000001ffff000 (ACPI data)
 BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
found SMP MP-table at 000f6ec0
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f7000 reserved twice.
On node 0 totalpages: 131069
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 126973 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 ASUS                       ) @ 0x000f80f0
ACPI: RSDT (v001 ASUS   P2B-D    22616.11826) @ 0x1fffd000
ACPI: FADT (v001 ASUS   P2B-D    22616.11826) @ 0x1fffd100
ACPI: BOOT (v001 ASUS   P2B-D    22616.11826) @ 0x1fffd040
ACPI: MADT (v001 ASUS   P2B-D    00000.00000) @ 0x1fffd080
ACPI: DSDT (v001   ASUS P2B-D    00000.04096) @ 0x00000000
ACPI: BIOS passes blacklist
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x01] enabled)
Processor #1 6:7 APIC version 17
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:7 APIC version 17
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
IOAPIC[0]: Assigned apic_id 2
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, IRQ 0-23
ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x1])
ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x14] polarity[0x1] trigger[0x3])
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Building zonelist for node : 0
Kernel command line: ro root=/dev/hda3 hdd=ide-scsi apm=power-off
ide_setup: hdd=ide-scsi
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 501.344 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 989.18 BogoMIPS
Memory: 515168k/524276k available (1866k kernel code, 8312k reserved, 738k data, 164k init, 0k highmem)
Security Scaffold v1.0.0 initialized
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU:     After generic, caps: 0383fbff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel Pentium III (Katmai) stepping 03
per-CPU timeslice cutoff: 1462.08 usecs.
task migration cache decay timeout: 2 msecs.
weird, boot CPU (#1) not listed by the BIOS.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Error: only one processor found.
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-9, 2-16, 2-17, 2-18, 2-19, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=-1
number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 000 00  1    0    0   0   0    0    0    00
 0a 001 01  0    0    0   0   0    1    1    71
 0b 001 01  0    0    0   0   0    1    1    79
 0c 001 01  0    0    0   0   0    1    1    81
 0d 001 01  0    0    0   0   0    1    1    89
 0e 001 01  0    0    0   0   0    1    1    91
 0f 001 01  0    0    0   0   0    1    1    99
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 001 01  1    1    0   0   0    1    1    A1
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:20
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 501.0054 MHz.
..... host bus clock speed is 100.0210 MHz.
Starting migration thread for cpu 0
CPUS done 2
mtrr: v2.0 (20020519)
Initializing RT netlink socket
PCI: PCI BIOS revision 2.10 entry at 0xf0730, last bus=1
PCI: Using configuration type 1
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]:   1 bvecs: 256 entries (12 bytes)
biovec pool[1]:   4 bvecs: 256 entries (48 bytes)
biovec pool[2]:  16 bvecs: 256 entries (192 bytes)
biovec pool[3]:  64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20030619
IOAPIC[0]: Set PCI routing entry (2-20 -> 0xa9 -> IRQ 20)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Linux Plug and Play Support v0.96 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fd2c0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xd2f0, dseg 0xf0000
PnPBIOS: 15 nodes reported by PnP BIOS; 15 recorded by driver
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 9
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xb1 -> IRQ 16)
00:00:0c[A] -> 2-16 -> IRQ 16
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb9 -> IRQ 17)
00:00:0c[B] -> 2-17 -> IRQ 17
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xc1 -> IRQ 18)
00:00:0c[C] -> 2-18 -> IRQ 18
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xc9 -> IRQ 19)
00:00:0c[D] -> 2-19 -> IRQ 19
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
pty: 256 Unix98 ptys configured
SBF: Simple Boot Flag extension found and enabled.
SBF: Setting boot flags 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
Enabling SEP on CPU 0
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Journalled Block Device driver loaded
Initializing Cryptographic API
Limiting direct PCI/PCI transfers.
ACPI: Power Button (FF) [PWRF]
ACPI: Processor [CPU] (supports C1)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.11
Non-volatile memory driver v1.2
ipmi: message handler initialized
ipmi: device interface at char major 254
ipmi_kcs: SPMI table not found.
ipmi_kcs: No KCS @ port 0x0ca2
ipmi_kcs: Unable to find any KCS interfaces
IPMI watchdog by Corey Minyard (minyard@mvista.com)
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
anticipatory scheduling elevator
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller at PCI slot 0000:00:04.1
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD800BB-00CAA1, ATA DISK drive
irq 20: nobody cared!
Call Trace:
 [<c010bb4a>] __report_bad_irq+0x2a/0x90
 [<c010bc40>] note_interrupt+0x70/0xb0
 [<c010bf90>] do_IRQ+0x170/0x1b0
 [<c0109f88>] common_interrupt+0x18/0x20
 [<c01159e4>] delay_tsc+0x14/0x1c
 [<c01d9442>] __delay+0x12/0x20
 [<c02520cd>] ide_delay_50ms+0x1d/0x30
 [<c0249622>] actual_try_to_identify+0xd2/0x5b0
 [<c0249b56>] try_to_identify+0x56/0x130
 [<c0249d38>] do_probe+0x108/0x260
 [<c02308c2>] device_add+0xe2/0x100
 [<c024a465>] probe_hwif+0x435/0x480
 [<c0257cdf>] do_ide_setup_pci_device+0x9f/0x170
 [<c024a4cc>] probe_hwif_init+0x1c/0x70
 [<c0257e00>] ide_setup_pci_device+0x50/0x80
 [<c024764a>] piix_init_one+0x3a/0x40
 [<c03a7b2d>] ide_scan_pcidev+0x5d/0x70
 [<c03a7b86>] ide_scan_pcibus+0x46/0xe0
 [<c03a78e0>] probe_for_hwifs+0x10/0x20
 [<c03a78f5>] ide_init_builtin_drivers+0x5/0x10
 [<c03a7939>] ide_init+0x39/0x50
 [<c038e9eb>] do_initcalls+0x2b/0xa0
 [<c013588f>] init_workqueues+0xf/0x24
 [<c01050d7>] init+0x57/0x1d0
 [<c0105080>] init+0x0/0x1d0
 [<c0107279>] kernel_thread_helper+0x5/0xc

handlers:
[<c01e1246>] (acpi_irq+0x0/0x16)
Disabling IRQ #20
hda: TCQ not supported
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: QUANTUM FIREBALLlct15 07, ATA DISK drive
hdd: HL-DT-ST GCE-8520B, ATAPI CD/DVD-ROM drive
hdc: only one drive on a channel supported for tcq
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: host protected area => 1
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=155061/16/63, UDMA(33)
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 >
hdc: max request size: 128KiB
hdc: host protected area => 1
hdc: 14668290 sectors (7510 MB) w/418KiB Cache, CHS=15522/15/63, UDMA(33)
 hdc: hdc1
mice: PS/2 mouse device common for all mice
input: PC Speaker
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
BIOS EDD facility v0.09 2003-Jan-22, 2 devices found
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 164k freed
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
Please use the 'usbfs' filetype instead, the 'usbdevfs' name is deprecated.
drivers/usb/core/usb.c: registered new driver hiddev
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
EXT3 FS on hda3, internal journal
Adding 530136k swap on /dev/hda2.  Priority:-1 extents:1
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda12, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda10, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda11, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SCSI subsystem initialized
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: HL-DT-ST  Model: CD-RW GCE-8520B   Rev: 1.02
  Type:   CD-ROM                             ANSI SCSI revision: 02
microcode: CPU0 updated from revision 0 to 14, date=09101999
microcode: freed 4096 bytes
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
ip_tables: (C) 2000-2002 Netfilter core team
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 304 bytes per conntrack
8139too Fast Ethernet driver 0.9.26
eth0: SMC1211TX EZCard 10/100 (RealTek RTL8139) at 0xe08a7000, 00:04:e2:00:44:ab, IRQ 19
eth0:  Identified 8139 chip type 'RTL-8139C'
eth1: RealTek RTL8139 Fast Ethernet at 0xe0910000, 00:50:bf:7d:4e:f4, IRQ 16
eth1:  Identified 8139 chip type 'RTL-8139C'
eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
eth1: Setting half-duplex based on auto-negotiated partner ability 0000.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Module nfsd cannot be unloaded due to unsafe usage in include/linux/module.h:482
Module lockd cannot be unloaded due to unsafe usage in include/linux/module.h:482
lp0: using parport0 (polling).
Linux agpgart interface v0.100 (c) Dave Jones
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
es1371: version v0.32 time 12:56:04 Jul  3 2003
es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
es1371: found es1371 rev 8 at io 0xa800 irq 17 joystick 0x0
ac97_codec: AC97 Audio codec, id: CRY19 (Cirrus Logic CS4297A rev A)

************************************************************

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 7
model name	: Pentium III (Katmai)
stepping	: 3
cpu MHz		: 501.344
cache size	: 512 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips	: 989.18

************************************************************

#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_EMBEDDED is not set
CONFIG_FUTEX=y
CONFIG_EPOLL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_HUGETLB_PAGE=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_PREEMPT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_EDD=y
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_HAVE_DEC_LOCK=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_HT_ONLY is not set
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_TOSHIBA=m
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=m

#
# Generic Driver Options
#
CONFIG_FW_LOADER=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_NAMES=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
# CONFIG_PARIDE_PCD is not set
# CONFIG_PARIDE_PF is not set
# CONFIG_PARIDE_PT is not set
# CONFIG_PARIDE_PG is not set

#
# Parallel IDE protocol modules
#
# CONFIG_PARIDE_ATEN is not set
# CONFIG_PARIDE_BPCK is not set
# CONFIG_PARIDE_BPCK6 is not set
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
# CONFIG_PARIDE_FIT2 is not set
# CONFIG_PARIDE_FIT3 is not set
# CONFIG_PARIDE_EPAT is not set
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
CONFIG_PARIDE_KTTI=m
# CONFIG_PARIDE_ON20 is not set
# CONFIG_PARIDE_ON26 is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_IDE_TASK_IOCTL=y
# CONFIG_IDE_TASKFILE_IO is not set

#
# IDE chipset support/bugfixes
#
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_IDE_TCQ=y
CONFIG_BLK_DEV_IDE_TCQ_DEFAULT=y
CONFIG_BLK_DEV_IDE_TCQ_DEPTH=8
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_PCI_WIP=y
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI device support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_PPA=m
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C406A is not set
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_FERAL_ISP is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_DM=m

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_UNIX=y
CONFIG_NET_KEY=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_NAT_LOCAL=y
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_NAT_TFTP=m
CONFIG_IP_NF_NAT_AMANDA=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
# CONFIG_IP_NF_COMPAT_IPCHAINS is not set
# CONFIG_IP_NF_COMPAT_IPFWADM is not set
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_TUNNEL=m

#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AHESP=m
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_XFRM_USER=m

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=m
CONFIG_IP_SCTP=m
# CONFIG_SCTP_ADLER32 is not set
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
CONFIG_LLC=m
CONFIG_LLC_UI=y
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
# CONFIG_NET_SCH_INGRESS is not set
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices (depends on LLC=y)
#
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=y
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
CONFIG_GAMEPORT=m
CONFIG_SOUND_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_VORTEX is not set
# CONFIG_GAMEPORT_FM801 is not set
# CONFIG_GAMEPORT_CS461x is not set
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_CT82C710=y
# CONFIG_SERIO_PARKBD is not set
CONFIG_SERIO_PCIPS2=m

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDDLER is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
# CONFIG_INPUT_JOYDUMP is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_INPUT_UINPUT=y

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_ACPI=y
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_MULTIPORT is not set
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_PHILIPSPAR is not set
# CONFIG_I2C_ELV is not set
# CONFIG_I2C_VELLEMAN is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_CHARDEV=m

#
# I2C Hardware Sensors Mainboard support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
CONFIG_I2C_ISA=m
CONFIG_I2C_PIIX4=m
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIAPRO is not set

#
# I2C Hardware Sensors Chip support
#
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_IT87 is not set
CONFIG_SENSORS_LM75=m
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_VIA686A is not set
CONFIG_SENSORS_W83781D=m
CONFIG_I2C_SENSOR=m

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
CONFIG_IPMI_HANDLER=y
CONFIG_IPMI_PANIC_EVENT=y
CONFIG_IPMI_DEVICE_INTERFACE=y
CONFIG_IPMI_KCS=y
CONFIG_IPMI_WATCHDOG=y

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
CONFIG_AGP_ALI=m
CONFIG_AGP_AMD=m
CONFIG_AGP_AMD_8151=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_NVIDIA=m
CONFIG_AGP_SIS=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_VIA=m
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
# CONFIG_DRM_GAMMA is not set
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_MGA=m
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_HANGCHECK_TIMER=m

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_W9966 is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
# CONFIG_XFS_RT is not set
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_QUOTA=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=m
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp850"
CONFIG_CIFS=m
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=m
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Graphics support
#
# CONFIG_FB is not set
CONFIG_VIDEO_SELECT=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# ISA devices
#
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set

#
# PCI devices
#
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS4281 is not set
CONFIG_SND_EMU10K1=m
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=m
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VX222 is not set

#
# ALSA USB devices
#
CONFIG_SND_USB_AUDIO=m

#
# Open Sound System
#
CONFIG_SOUND_PRIME=m
CONFIG_SOUND_BT878=m
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
CONFIG_SOUND_ES1371=m
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
CONFIG_SOUND_TVMIXER=m

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m

#
# USB Bluetooth TTY can only be used with disabled Bluetooth subsystem
#
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
# CONFIG_THRUSTMASTER_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
CONFIG_USB_SCANNER=m
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_STV680 is not set

#
# USB Network adaptors
#
# CONFIG_USB_AX8817X is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
CONFIG_USB_TEST=m
# CONFIG_USB_GADGET is not set

#
# Bluetooth support
#
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_USB_SCO=y
CONFIG_BT_USB_ZERO_PACKET=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_BCSP_TXCRC=y
CONFIG_BT_HCIVHCI=m

#
# Profiling support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_SPINLINE is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_KALLSYMS=y
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_KGDB is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FRAME_POINTER is not set
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
# CONFIG_SLEEPOMETER is not set

#
# Security options
#
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_ROOTPLUG=m

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_TEST=m

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y

^ permalink raw reply	[flat|nested] 147+ messages in thread

* Re: 2.5.74-mm1
@ 2003-07-03 10:39 Boszormenyi Zoltan
  2003-07-03 13:09 ` 2.5.74-mm1 Boszormenyi Zoltan
  0 siblings, 1 reply; 147+ messages in thread
From: Boszormenyi Zoltan @ 2003-07-03 10:39 UTC (permalink / raw)
  To: linux-kernel

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

Hi,

fs/jfs/xattr.c does not compile after applying your .74-mm1
because of a simple typo. Fix is attached.

-- 
Best regards,
Zoltán Böszörményi

---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.


[-- Attachment #2: jfs-xattr-typo-fix.patch --]
[-- Type: text/plain, Size: 320 bytes --]

--- fs/jfs/xattr.c~	2003-07-03 12:35:32.000000000 +0200
+++ fs/jfs/xattr.c	2003-07-03 12:35:32.000000000 +0200
@@ -1028,7 +1028,7 @@
 	err = __jfs_listxattr(dentry->d_inode, data, buf_size);
 	up(&dentry->d_inode->i_sem);
 
-	rerturn err;
+	return err;
 }
 
 int jfs_removexattr(struct dentry *dentry, const char *name)

^ permalink raw reply	[flat|nested] 147+ messages in thread

end of thread, other threads:[~2003-07-11  7:52 UTC | newest]

Thread overview: 147+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-03  9:37 2.5.74-mm1 Andrew Morton
2003-07-03 10:37 ` 2.5.74-mm1 Wiktor Wodecki
2003-07-03 11:06   ` 2.5.74-mm1 Russell King
2003-07-03 14:15     ` 2.5.74-mm1 Russell King
2003-07-03 16:05       ` 2.5.74-mm1 Patrick Mochel
2003-07-03 16:19         ` 2.5.74-mm1 Russell King
2003-07-03 16:24           ` 2.5.74-mm1 Patrick Mochel
2003-07-03 16:47       ` 2.5.74-mm1 Wiktor Wodecki
2003-07-03 18:43       ` 2.5.74-mm1 Serge Eric Thiam
2003-07-03 21:49       ` 2.5.74-mm1 Wiktor Wodecki
2003-07-03 21:53         ` 2.5.74-mm1 Russell King
2003-07-03 22:12           ` 2.5.74-mm1 Patrick Mochel
2003-07-03 22:14         ` 2.5.74-mm1 Russell King
2003-07-04  8:00           ` 2.5.74-mm1 Wiktor Wodecki
2003-07-03 11:27   ` pcmcia problem [was: Re: 2.5.74-mm1] Wiktor Wodecki
2003-07-03 10:45 ` 2.5.74-mm1 (p4-clockmod does not compile) Dumitru Ciobarcianu
2003-07-03 11:07   ` William Lee Irwin III
2003-07-03 11:17     ` Dumitru Ciobarcianu
2003-07-03 11:20       ` William Lee Irwin III
2003-07-03 11:32         ` 2.5.74-mm1 (p4-clockmod does not compile) PATCH Dumitru Ciobarcianu
2003-07-07  5:24         ` 2.5.74-mm1 (p4-clockmod does not compile) Zwane Mwaikambo
2003-07-07  5:47           ` William Lee Irwin III
2003-07-03 13:15 ` o1-interactivity.patch (was Re: 2.5.74-mm1) Sean Neakums
2003-07-03 13:30   ` Con Kolivas
2003-07-03 16:02 ` 2.5.74-mm1 Felipe Alfaro Solana
2003-07-03 18:11 ` 2.5.74-mm1 Pasi Savolainen
2003-07-03 20:25 ` 2.5.74-mm1 William Lee Irwin III
2003-07-03 20:48   ` 2.5.74-mm1 William Lee Irwin III
2003-07-04  8:55 ` 2.5.74-mm1 fails to boot due to APIC trouble, 2.5.73mm3 works Helge Hafting
2003-07-04  8:53   ` William Lee Irwin III
2003-07-04  9:35   ` William Lee Irwin III
2003-07-04  9:50     ` William Lee Irwin III
2003-07-04 10:02       ` William Lee Irwin III
2003-07-04 10:07         ` William Lee Irwin III
2003-07-04 11:12           ` Helge Hafting
2003-07-04 11:10             ` William Lee Irwin III
2003-07-04 12:50             ` Vincent Hanquez
2003-07-04 15:41       ` Martin J. Bligh
2003-07-04 15:47         ` Zwane Mwaikambo
2003-07-04 16:18           ` Martin J. Bligh
2003-07-04 16:16             ` Zwane Mwaikambo
2003-07-04 18:31             ` William Lee Irwin III
2003-07-04 19:20               ` Martin J. Bligh
2003-07-04 19:31                 ` William Lee Irwin III
2003-07-04 19:53                   ` Martin J. Bligh
2003-07-04 20:17                     ` William Lee Irwin III
2003-07-04 18:32             ` William Lee Irwin III
2003-07-04 18:36             ` William Lee Irwin III
2003-07-04 18:29           ` William Lee Irwin III
2003-07-04 18:26         ` William Lee Irwin III
2003-07-04 19:38           ` Martin J. Bligh
2003-07-04 20:07             ` William Lee Irwin III
2003-07-04 20:37               ` Martin J. Bligh
2003-07-04 21:07 ` 2.5.74-mm1 William Lee Irwin III
2003-07-05  1:15   ` 2.5.74-mm1 Andrew Morton
2003-07-05  5:21     ` 2.5.74-mm1 Anton Blanchard
2003-07-05 11:18       ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 11:46         ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 10:44     ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 18:43       ` 2.5.74-mm1 Andrew Morton
2003-07-05 21:17         ` 2.5.74-mm1 William Lee Irwin III
2003-07-05 21:27           ` 2.5.74-mm1 Andrew Morton
2003-07-05 22:03             ` 2.5.74-mm1 William Lee Irwin III
2003-07-05  0:16 ` 2.5.74-mm1 Daniel Phillips
2003-07-05 15:28   ` 2.5.74-mm1 Daniel Phillips
2003-07-05 16:01     ` 2.5.74-mm1 Con Kolivas
2003-07-05 17:47       ` 2.5.74-mm1 Daniel Phillips
2003-07-06  3:41         ` 2.5.74-mm1 Con Kolivas
2003-07-06 18:50           ` 2.5.74-mm1 Daniel Phillips
2003-07-05 19:14     ` 2.5.74-mm1 Andrew Morton
2003-07-05 21:09       ` 2.5.74-mm1 Daniel Phillips
2003-07-05 21:44         ` 2.5.74-mm1 Jamie Lokier
2003-07-05 22:10           ` 2.5.74-mm1 Daniel Phillips
2003-07-06  1:28             ` 2.5.74-mm1 Jamie Lokier
2003-07-06  2:14               ` 2.5.74-mm1 Daniel Phillips
2003-07-06  2:21                 ` 2.5.74-mm1 Davide Libenzi
2003-07-06 13:54                   ` 2.5.74-mm1 Daniel Phillips
2003-07-07 10:00                 ` 2.5.74-mm1 Mel Gorman
2003-07-07 12:24                   ` 2.5.74-mm1 Daniel Phillips
2003-07-07 13:09                     ` 2.5.74-mm1 Alex Riesen
2003-07-07 14:33                       ` 2.5.74-mm1 Daniel Phillips
2003-07-07 14:34                         ` 2.5.74-mm1 Alex Riesen
2003-07-07 13:16                     ` 2.5.74-mm1 Mel Gorman
2003-07-07 14:47                       ` 2.5.74-mm1 Davide Libenzi
2003-07-07 15:23                         ` 2.5.74-mm1 Jamie Lokier
2003-07-07 17:25                           ` 2.5.74-mm1 Davide Libenzi
2003-07-07 17:55                             ` 2.5.74-mm1 Daniel Phillips
2003-07-07 18:36                               ` 2.5.74-mm1 Davide Libenzi
2003-07-07 19:07                                 ` 2.5.74-mm1 Daniel Phillips
2003-07-07 22:03                                   ` 2.5.74-mm1 Davide Libenzi
2003-07-08  0:13                                     ` 2.5.74-mm1 Daniel Phillips
2003-07-08  0:29                                       ` 2.5.74-mm1 Davide Libenzi
2003-07-08  1:07                                         ` 2.5.74-mm1 Daniel Phillips
2003-07-08  7:48                                           ` 2.5.74-mm1 Davide Libenzi
2003-07-08  9:18                                             ` 2.5.74-mm1 Nick Piggin
2003-07-08 15:24                                               ` 2.5.74-mm1 Davide Libenzi
2003-07-09  0:36                                                 ` 2.5.74-mm1 Nick Piggin
2003-07-08 11:09                                             ` 2.5.74-mm1 Daniel Phillips
2003-07-08 18:19                                               ` 2.5.74-mm1 Davide Libenzi
2003-07-08 19:12                                                 ` 2.5.74-mm1 Davide Libenzi
2003-07-07 19:39                                 ` 2.5.74-mm1 Jamie Lokier
2003-07-07 19:36                             ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:17                               ` 2.5.74-mm1 Daniel Phillips
2003-07-09 22:24                                 ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:29                                   ` 2.5.74-mm1 Davide Libenzi
2003-07-09 23:15                                     ` 2.5.74-mm1 Daniel Phillips
2003-07-09 23:19                                       ` 2.5.74-mm1 Jamie Lokier
2003-07-09 22:59                                   ` 2.5.74-mm1 Daniel Phillips
2003-07-10  2:01                                     ` 2.5.74-mm1 Peter Chubb
2003-07-11  1:04                                       ` 2.5.74-mm1 Daniel Phillips
2003-07-11  1:08                                         ` 2.5.74-mm1 William Lee Irwin III
2003-07-11  5:44                                         ` 2.5.74-mm1 Davide Libenzi
2003-07-11  8:07                                           ` 2.5.74-mm1 Daniel Phillips
2003-07-07 15:28                         ` 2.5.74-mm1 Daniel Phillips
2003-07-07 17:58                           ` 2.5.74-mm1 Davide Libenzi
     [not found]                     ` <Pine.LNX.4.55.0307070745250.4428@bigblue.dev.mcafeelabs.co m>
2003-07-07 17:15                       ` 2.5.74-mm1 Mike Galbraith
2003-07-05 22:11         ` 2.5.74-mm1 Diego Calleja García
2003-07-05 23:31           ` 2.5.74-mm1 Daniel Phillips
2003-07-06  0:23             ` 2.5.74-mm1 Diego Calleja García
2003-07-06 22:59               ` 2.5.74-mm1 Jamie Lokier
2003-07-06  2:29           ` 2.5.74-mm1 Davide Libenzi
2003-07-06  0:10       ` 2.5.74-mm1 Daniel Phillips
2003-07-06  0:10         ` 2.5.74-mm1 Davide Libenzi
2003-07-05 19:40     ` 2.5.74-mm1 Diego Calleja García
2003-07-05 19:48       ` 2.5.74-mm1 Davide Libenzi
2003-07-05 21:22       ` 2.5.74-mm1 Daniel Phillips
2003-07-07 13:38 ` OOPS: 2.5.74-mm2 Maciej Soltysiak
2003-07-03 10:39 2.5.74-mm1 Boszormenyi Zoltan
2003-07-03 13:09 ` 2.5.74-mm1 Boszormenyi Zoltan
2003-07-03 19:22   ` 2.5.74-mm1 Andrew Morton
2003-07-03 20:08     ` 2.5.74-mm1 Helge Hafting
2003-07-03 21:15       ` 2.5.74-mm1 Andrew Morton
2003-07-04  5:53         ` 2.5.74-mm1 William Lee Irwin III
2003-07-04  7:12           ` 2.5.74-mm1 Boszormenyi Zoltan
2003-07-04  7:16             ` 2.5.74-mm1 Zwane Mwaikambo
2003-07-04  7:15           ` 2.5.74-mm1 Zwane Mwaikambo
2003-07-04  7:50             ` 2.5.74-mm1 Zwane Mwaikambo
2003-07-04  8:27             ` 2.5.74-mm1 Andrew Morton
2003-07-04  8:37               ` 2.5.74-mm1 Zwane Mwaikambo
2003-07-04  8:56                 ` 2.5.74-mm1 Andrew Morton
2003-07-04  8:57                   ` 2.5.74-mm1 William Lee Irwin III
2003-07-04  8:52               ` 2.5.74-mm1 William Lee Irwin III
2003-07-04 20:00         ` 2.5.74-mm1 Helge Hafting
2003-07-04 20:08           ` 2.5.74-mm1 William Lee Irwin III
2003-07-03 22:26       ` 2.5.74-mm1 William Lee Irwin III
2003-07-03 23:01         ` 2.5.74-mm1 Zwane Mwaikambo
2003-07-03 23:16     ` 2.5.74-mm1 William Lee Irwin III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).