* 2.5.65-mm1 @ 2003-03-18 11:11 ` Andrew Morton 0 siblings, 0 replies; 27+ messages in thread From: Andrew Morton @ 2003-03-18 11:11 UTC (permalink / raw) To: linux-kernel, linux-mm http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm1/ kernel.org is being slow. Should later appear at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.65/2.5.65-mm1/ . An updated version of Russell's PCMCIA patches . Lots more anticipatory scheduler work. . It turns out that calling disk request_fns from timer/tasklet context is not permitted because a few old drivers like to sleep in that function. keventd cannot be used for this because it can deadlock. So another kernel thread per CPU has been reluctantly added. Changes since 2.5.64-mm8: -fix-mem-equals.patch -hugetlb-unmap_vmas-fix.patch -early-writeback-init.patch -e100-memleak-fix.patch -ext2-ext3-noatime-fix.patch -ext2-balloc-fix.patch -pci-6.patch -pci-7.patch -pci-8.patch -pci-9.patch -pci-10.patch -pci-11.patch -pci-12.patch -pci-13.patch -pci-14.patch -pci-15.patch -pci-update-1.patch -aio-bits-fix.patch -clean-inode-fix.patch -affs-lock_kernel-fix.patch -raid0-oops-fix.patch Merged +kgdb-cleanup.patch Tidy up the kgdb stub a little +kblockd.patch Kernel threads for running disk request functions. +as-np-1.patch +as-use-kblockd.patch +as-cleanup-2.patch +as-as_remove_request-simplification.patch +as-dont-go-BUG-again.patch +as-handle-non-block-requests.patch +as-np-reads-1.patch +as-np-reads-2.patch Anticipatory scheduler work -unplug-from-timer.patch request_fns cannot be called from timer context +unplug-use-kblockd.patch Call request_fns from kblockd, not keventd. +sched-2.5.64-D3.patch Interactivity work -scheduler-starvation-fixes.patch Obsoleted by 2.5.65 fixes -pcmcia-1-kill-get_foo_map.patch -pcmcia-2-remove-bus_foo-abstractions.patch -pcmcia-3-add-SOCKET_CARDBUS_CONFIG.patch -pcmcia-4-add-locking.patch -pcmcia-5-add-CONFIG_PCMCIA_PROBE.patch -pcmcia-6-remove-old-cardbus-clients.patch +pcmcia-2.patch +pcmcia-3b.patch +pcmcia-3.patch +pcmcia-4.patch +pcmcia-5.patch +pcmcia-6.patch +pcmcia-7b.patch +pcmcia-7.patch +pcmcia-8.patch +pcmcia-9.patch +pcmcia-10.patch Updated pcmcia patch series -ext2-no-lock-super-whitespace-fixes.patch -ext2-no-lock_super-fix-1.patch -ext2-no-lock_super-fix-2.patch -ext2-no-lock_super-fix-3.patch -ext2-no-lock_super-fix-4.patch -ext2-no-lock_super-fix-5.patch -ext2-no-lock_super-fix-6.patch -ext2-no-lock_super-fix-7.patch -ext2-no-lock_super-set-s_dirt.patch Folded into ext2-no-lock_super.patch -ext2-ialloc-no-lock_super-fixes.patch Folded into ext2-ialloc-no-lock_super.patch +CONFIG_NUMA-fixes.patch Make CONFIG_NUMA harder to enable +nfsd-symlink-failpath.patch knfsd error handling fix +ide_probe-init_irq-fix.patch Fix the sleep-in-spinlock problem in IDE. +get_disk-error-checking.patch sysfs/kobject fix +raid1-fix.patch Fix broken RAID1 resync +nmi-watchdog-fix.patch Fix i386 NMI watchdog +vm_enough_memory-speedup.patch Make vm_enough_memory() more SMP-friendly +nanosleep-accuracy-fix.patch Fix sys_nanosleep() inaccuracy problem All 115 patches mm.patch add -mmN to EXTRAVERSION kgdb.patch kgdb-cleanup.patch make kgdb less invasive (when disabled) proc-sys-debug.patch create /proc/sys/debug/0 ... 7 noirqbalance-fix.patch Fix noirqbalance config_spinline.patch uninline spinlocks for profiling accuracy. ppc64-reloc_hide.patch ppc64-pci-patch.patch Subject: pci patch ppc64-aio-32bit-emulation.patch 32/64bit emulation for aio ppc64-64-bit-exec-fix.patch Pass the load address into ELF_PLAT_INIT() ppc64-scruffiness.patch Fix some PPC64 compile warnings sym-do-160.patch make the SYM driver do 160 MB/sec config-PAGE_OFFSET.patch Configurable kenrel/user memory split ptrace-flush.patch cache flushing in the ptrace code buffer-debug.patch buffer.c debugging warn-null-wakeup.patch ext3-truncate-ordered-pages.patch ext3: explicitly free truncated pages reiserfs_file_write-5.patch tcp-wakeups.patch Use fast wakeups in TCP/IPV4 rcu-stats.patch RCU statistics reporting ext3-journalled-data-assertion-fix.patch Remove incorrect assertion from ext3 nfs-speedup.patch nfs-oom-fix.patch nfs oom fix sk-allocation.patch Subject: Re: nfs oom nfs-more-oom-fix.patch rpciod-atomic-allocations.patch Make rcpiod use atomic allocations linux-isp.patch isp-update-1.patch remove-unused-congestion-stuff.patch Subject: [PATCH] remove unused congestion stuff kblockd.patch Create `kblockd' workqueue as-iosched.patch anticipatory I/O scheduler as-debug-BUG-fix.patch as-eject-BUG-fix.patch AS: don't go BUG during cdrom eject as-jumbo-fix.patch AS: OSDL fixes as-request_fn-in-timer.patch Remove the scheduled_work thing as-remove-request-fix.patch as-np-1.patch as: cleanups & comments as-use-kblockd.patch as-cleanup-2.patch AS: cleanup + comments as-as_remove_request-simplification.patch as: as_remove_request simplification as-dont-go-BUG-again.patch as-handle-non-block-requests.patch AS: handle non-block requests as-np-reads-1.patch AS: read-vs-read fixes as-np-reads-2.patch AS: more read-vs-read fixes cfq-2.patch CFQ scheduler, #2 unplug-use-kblockd.patch Use kblockd for running request queues smalldevfs.patch smalldevfs remap-file-pages-2.5.63-a1.patch Subject: [patch] remap-file-pages-2.5.63-A1 hugh-remap-fix.patch hugh's file-offset-in-pte fix fremap-limit-offsets.patch fremap: limit remap_file_pages() file offsets fremap-all-mappings.patch Make all executable mappings be nonlinear filemap_populate-speedup.patch filemap_populate speedup file-offset-in-pte-x86_64.patch x86_64: support for file offsets in pte's file-offset-in-pte-ppc64.patch objrmap-2.5.62-5.patch object-based rmap objrmap-nonlinear-fixes.patch objrmap fix for nonlinear sched-2.5.64-D3.patch sched-2.5.64-D3, more interactivity changes scheduler-tunables.patch scheduler tunables timer-cleanup.patch timer code cleanup timer-readdition-fix.patch timer re-addition lockup fix show_task-free-stack-fix.patch show_task() fix and cleanup yellowfin-set_bit-fix.patch yellowfin driver set_bit fix htree-nfs-fix.patch Fix ext3 htree / NFS compatibility problems update_atime-ng.patch inode a/c/mtime modification speedup one-sec-times.patch Implement a/c/time speedup in ext2 & ext3 task_prio-fix.patch simple task_prio() fix set_current_state-fs.patch use set_current_state in fs set_current_state-mm.patch use set_current_state in mm copy_thread-leak-fix.patch Fix memory leak in copy_thread slab_store_user-large-objects.patch slab debug: perform redzoning against larger objects file_list_lock-contention-fix.patch file_list_lock contention fixes tty_files-fixes.patch file->f_list locking in tty_io.c file_list_cleanup.patch file_list cleanup file_list-remove-free_list.patch file_table: remove the private freelist file-list-less-locking.patch file_list: less locking vt_ioctl-stack-use.patch stack reduction in drivers/char/vt_ioctl.c no-mmu-stubs.patch a few missing stubs for !CONFIG_MMU nommu-slab.patch slab changes for !CONFIG_MMU nfs-memleak-fix.patch memleak in fs/nfs/inode.c::nfs_get_sb() ufs-memleak-fix.patch Memleak in fs/ufs/util.c posix-timers-update.patch posix timers update pcmcia-2.patch pcmcia-3b.patch pcmcia-3.patch pcmcia-4.patch pcmcia-5.patch pcmcia-6.patch pcmcia-7b.patch pcmcia-7.patch pcmcia-8.patch pcmcia-9.patch pcmcia-10.patch oops-counters.patch OOPS instance counters io_apic-DO_ACTION-cleanup.patch io-apic.c: DO_ACTION cleanup oprofile-timer-fix.patch fix oprofile timer race htree-nfs-fix-2.patch htree nfs fix ext2-no-lock_super.patch concurrent block allocation for ext2 ext2-ialloc-no-lock_super.patch concurrent inode allocation for ext2 brlock-removal-1.patch Brlock removal 1/5 - core brlock-removal-2.patch brlock removal 2/5: remove brlock from snap and vlan brlock-removal-3.patch brlock removal 3/5: remove brlock from bridge brlock-removal-4.patch brlock removal 4/5: removal from ipv4/ipv6 brlock-removal-5.patch brlock removal 5/5: remove brlock code pgd_index-comments.patch pgd_index/pmd_index/pte_index commentary proc-sysrq-trigger.patch /proc/sysrq-trigger: trigger sysrq functions via /proc lseek-ext2_readdir.patch remove lock_kernel() from readdir implementations. inode_setattr-lock_kernel-removal.patch remove lock_kernel() from inode_setattr's vmtruncate() call CONFIG_NUMA-fixes.patch Tighten CONFIG_NUMA preconditions nfsd-symlink-failpath.patch Fix nfsd_symlink() failure path ide_probe-init_irq-fix.patch ide-probe init_irq cleanup get_disk-error-checking.patch Add error checking get_disk(). raid1-fix.patch MD RAID1 fix nmi-watchdog-fix.patch NMI watchdog fix vm_enough_memory-speedup.patch speed up vm_enough_memory() nanosleep-accuracy-fix.patch fix nanosleep() granularity bumps ^ permalink raw reply [flat|nested] 27+ messages in thread
* 2.5.65-mm1 @ 2003-03-18 11:11 ` Andrew Morton 0 siblings, 0 replies; 27+ messages in thread From: Andrew Morton @ 2003-03-18 11:11 UTC (permalink / raw) To: linux-kernel, linux-mm http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm1/ kernel.org is being slow. Should later appear at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.65/2.5.65-mm1/ . An updated version of Russell's PCMCIA patches . Lots more anticipatory scheduler work. . It turns out that calling disk request_fns from timer/tasklet context is not permitted because a few old drivers like to sleep in that function. keventd cannot be used for this because it can deadlock. So another kernel thread per CPU has been reluctantly added. Changes since 2.5.64-mm8: -fix-mem-equals.patch -hugetlb-unmap_vmas-fix.patch -early-writeback-init.patch -e100-memleak-fix.patch -ext2-ext3-noatime-fix.patch -ext2-balloc-fix.patch -pci-6.patch -pci-7.patch -pci-8.patch -pci-9.patch -pci-10.patch -pci-11.patch -pci-12.patch -pci-13.patch -pci-14.patch -pci-15.patch -pci-update-1.patch -aio-bits-fix.patch -clean-inode-fix.patch -affs-lock_kernel-fix.patch -raid0-oops-fix.patch Merged +kgdb-cleanup.patch Tidy up the kgdb stub a little +kblockd.patch Kernel threads for running disk request functions. +as-np-1.patch +as-use-kblockd.patch +as-cleanup-2.patch +as-as_remove_request-simplification.patch +as-dont-go-BUG-again.patch +as-handle-non-block-requests.patch +as-np-reads-1.patch +as-np-reads-2.patch Anticipatory scheduler work -unplug-from-timer.patch request_fns cannot be called from timer context +unplug-use-kblockd.patch Call request_fns from kblockd, not keventd. +sched-2.5.64-D3.patch Interactivity work -scheduler-starvation-fixes.patch Obsoleted by 2.5.65 fixes -pcmcia-1-kill-get_foo_map.patch -pcmcia-2-remove-bus_foo-abstractions.patch -pcmcia-3-add-SOCKET_CARDBUS_CONFIG.patch -pcmcia-4-add-locking.patch -pcmcia-5-add-CONFIG_PCMCIA_PROBE.patch -pcmcia-6-remove-old-cardbus-clients.patch +pcmcia-2.patch +pcmcia-3b.patch +pcmcia-3.patch +pcmcia-4.patch +pcmcia-5.patch +pcmcia-6.patch +pcmcia-7b.patch +pcmcia-7.patch +pcmcia-8.patch +pcmcia-9.patch +pcmcia-10.patch Updated pcmcia patch series -ext2-no-lock-super-whitespace-fixes.patch -ext2-no-lock_super-fix-1.patch -ext2-no-lock_super-fix-2.patch -ext2-no-lock_super-fix-3.patch -ext2-no-lock_super-fix-4.patch -ext2-no-lock_super-fix-5.patch -ext2-no-lock_super-fix-6.patch -ext2-no-lock_super-fix-7.patch -ext2-no-lock_super-set-s_dirt.patch Folded into ext2-no-lock_super.patch -ext2-ialloc-no-lock_super-fixes.patch Folded into ext2-ialloc-no-lock_super.patch +CONFIG_NUMA-fixes.patch Make CONFIG_NUMA harder to enable +nfsd-symlink-failpath.patch knfsd error handling fix +ide_probe-init_irq-fix.patch Fix the sleep-in-spinlock problem in IDE. +get_disk-error-checking.patch sysfs/kobject fix +raid1-fix.patch Fix broken RAID1 resync +nmi-watchdog-fix.patch Fix i386 NMI watchdog +vm_enough_memory-speedup.patch Make vm_enough_memory() more SMP-friendly +nanosleep-accuracy-fix.patch Fix sys_nanosleep() inaccuracy problem All 115 patches mm.patch add -mmN to EXTRAVERSION kgdb.patch kgdb-cleanup.patch make kgdb less invasive (when disabled) proc-sys-debug.patch create /proc/sys/debug/0 ... 7 noirqbalance-fix.patch Fix noirqbalance config_spinline.patch uninline spinlocks for profiling accuracy. ppc64-reloc_hide.patch ppc64-pci-patch.patch Subject: pci patch ppc64-aio-32bit-emulation.patch 32/64bit emulation for aio ppc64-64-bit-exec-fix.patch Pass the load address into ELF_PLAT_INIT() ppc64-scruffiness.patch Fix some PPC64 compile warnings sym-do-160.patch make the SYM driver do 160 MB/sec config-PAGE_OFFSET.patch Configurable kenrel/user memory split ptrace-flush.patch cache flushing in the ptrace code buffer-debug.patch buffer.c debugging warn-null-wakeup.patch ext3-truncate-ordered-pages.patch ext3: explicitly free truncated pages reiserfs_file_write-5.patch tcp-wakeups.patch Use fast wakeups in TCP/IPV4 rcu-stats.patch RCU statistics reporting ext3-journalled-data-assertion-fix.patch Remove incorrect assertion from ext3 nfs-speedup.patch nfs-oom-fix.patch nfs oom fix sk-allocation.patch Subject: Re: nfs oom nfs-more-oom-fix.patch rpciod-atomic-allocations.patch Make rcpiod use atomic allocations linux-isp.patch isp-update-1.patch remove-unused-congestion-stuff.patch Subject: [PATCH] remove unused congestion stuff kblockd.patch Create `kblockd' workqueue as-iosched.patch anticipatory I/O scheduler as-debug-BUG-fix.patch as-eject-BUG-fix.patch AS: don't go BUG during cdrom eject as-jumbo-fix.patch AS: OSDL fixes as-request_fn-in-timer.patch Remove the scheduled_work thing as-remove-request-fix.patch as-np-1.patch as: cleanups & comments as-use-kblockd.patch as-cleanup-2.patch AS: cleanup + comments as-as_remove_request-simplification.patch as: as_remove_request simplification as-dont-go-BUG-again.patch as-handle-non-block-requests.patch AS: handle non-block requests as-np-reads-1.patch AS: read-vs-read fixes as-np-reads-2.patch AS: more read-vs-read fixes cfq-2.patch CFQ scheduler, #2 unplug-use-kblockd.patch Use kblockd for running request queues smalldevfs.patch smalldevfs remap-file-pages-2.5.63-a1.patch Subject: [patch] remap-file-pages-2.5.63-A1 hugh-remap-fix.patch hugh's file-offset-in-pte fix fremap-limit-offsets.patch fremap: limit remap_file_pages() file offsets fremap-all-mappings.patch Make all executable mappings be nonlinear filemap_populate-speedup.patch filemap_populate speedup file-offset-in-pte-x86_64.patch x86_64: support for file offsets in pte's file-offset-in-pte-ppc64.patch objrmap-2.5.62-5.patch object-based rmap objrmap-nonlinear-fixes.patch objrmap fix for nonlinear sched-2.5.64-D3.patch sched-2.5.64-D3, more interactivity changes scheduler-tunables.patch scheduler tunables timer-cleanup.patch timer code cleanup timer-readdition-fix.patch timer re-addition lockup fix show_task-free-stack-fix.patch show_task() fix and cleanup yellowfin-set_bit-fix.patch yellowfin driver set_bit fix htree-nfs-fix.patch Fix ext3 htree / NFS compatibility problems update_atime-ng.patch inode a/c/mtime modification speedup one-sec-times.patch Implement a/c/time speedup in ext2 & ext3 task_prio-fix.patch simple task_prio() fix set_current_state-fs.patch use set_current_state in fs set_current_state-mm.patch use set_current_state in mm copy_thread-leak-fix.patch Fix memory leak in copy_thread slab_store_user-large-objects.patch slab debug: perform redzoning against larger objects file_list_lock-contention-fix.patch file_list_lock contention fixes tty_files-fixes.patch file->f_list locking in tty_io.c file_list_cleanup.patch file_list cleanup file_list-remove-free_list.patch file_table: remove the private freelist file-list-less-locking.patch file_list: less locking vt_ioctl-stack-use.patch stack reduction in drivers/char/vt_ioctl.c no-mmu-stubs.patch a few missing stubs for !CONFIG_MMU nommu-slab.patch slab changes for !CONFIG_MMU nfs-memleak-fix.patch memleak in fs/nfs/inode.c::nfs_get_sb() ufs-memleak-fix.patch Memleak in fs/ufs/util.c posix-timers-update.patch posix timers update pcmcia-2.patch pcmcia-3b.patch pcmcia-3.patch pcmcia-4.patch pcmcia-5.patch pcmcia-6.patch pcmcia-7b.patch pcmcia-7.patch pcmcia-8.patch pcmcia-9.patch pcmcia-10.patch oops-counters.patch OOPS instance counters io_apic-DO_ACTION-cleanup.patch io-apic.c: DO_ACTION cleanup oprofile-timer-fix.patch fix oprofile timer race htree-nfs-fix-2.patch htree nfs fix ext2-no-lock_super.patch concurrent block allocation for ext2 ext2-ialloc-no-lock_super.patch concurrent inode allocation for ext2 brlock-removal-1.patch Brlock removal 1/5 - core brlock-removal-2.patch brlock removal 2/5: remove brlock from snap and vlan brlock-removal-3.patch brlock removal 3/5: remove brlock from bridge brlock-removal-4.patch brlock removal 4/5: removal from ipv4/ipv6 brlock-removal-5.patch brlock removal 5/5: remove brlock code pgd_index-comments.patch pgd_index/pmd_index/pte_index commentary proc-sysrq-trigger.patch /proc/sysrq-trigger: trigger sysrq functions via /proc lseek-ext2_readdir.patch remove lock_kernel() from readdir implementations. inode_setattr-lock_kernel-removal.patch remove lock_kernel() from inode_setattr's vmtruncate() call CONFIG_NUMA-fixes.patch Tighten CONFIG_NUMA preconditions nfsd-symlink-failpath.patch Fix nfsd_symlink() failure path ide_probe-init_irq-fix.patch ide-probe init_irq cleanup get_disk-error-checking.patch Add error checking get_disk(). raid1-fix.patch MD RAID1 fix nmi-watchdog-fix.patch NMI watchdog fix vm_enough_memory-speedup.patch speed up vm_enough_memory() nanosleep-accuracy-fix.patch fix nanosleep() granularity bumps -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 11:11 ` 2.5.65-mm1 Andrew Morton @ 2003-03-18 13:15 ` Helge Hafting -1 siblings, 0 replies; 27+ messages in thread From: Helge Hafting @ 2003-03-18 13:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm 2.5.65-mm1 seems to work fine on my up office machine. Using devfs is no problem with debian unstable/testing. No config files needed to be changed compared to "normal" devfs. Three files needed changing compared to plain old non-devfs: /etc/fstab: use /dev/discs/disc0/partX instead /dev/hdaX /etc/gpm: use mouse device /dev/input/mouse0 instead of /dev/psaux /etc/inittab: Specify vc/X instead of ttyX for getty. X came up even without this. Helge Hafting ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-18 13:15 ` Helge Hafting 0 siblings, 0 replies; 27+ messages in thread From: Helge Hafting @ 2003-03-18 13:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm 2.5.65-mm1 seems to work fine on my up office machine. Using devfs is no problem with debian unstable/testing. No config files needed to be changed compared to "normal" devfs. Three files needed changing compared to plain old non-devfs: /etc/fstab: use /dev/discs/disc0/partX instead /dev/hdaX /etc/gpm: use mouse device /dev/input/mouse0 instead of /dev/psaux /etc/inittab: Specify vc/X instead of ttyX for getty. X came up even without this. Helge Hafting -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 small nfs umount problem, also in 64-mm8 2003-03-18 11:11 ` 2.5.65-mm1 Andrew Morton (?) (?) @ 2003-03-18 13:29 ` Helge Hafting 2003-03-18 13:56 ` Andreas Haumer -1 siblings, 1 reply; 27+ messages in thread From: Helge Hafting @ 2003-03-18 13:29 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel I have some nfs mounts that users are allowed to mount. That works, but the user can't umount. "Only root can umount..." I believe the user doing the mount were allowed to umount before. Helge Hafting ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 small nfs umount problem, also in 64-mm8 2003-03-18 13:29 ` 2.5.65-mm1 small nfs umount problem, also in 64-mm8 Helge Hafting @ 2003-03-18 13:56 ` Andreas Haumer 0 siblings, 0 replies; 27+ messages in thread From: Andreas Haumer @ 2003-03-18 13:56 UTC (permalink / raw) To: Helge Hafting; +Cc: Andrew Morton, linux-kernel Hi! Helge Hafting wrote: > > I have some nfs mounts that users are allowed to mount. > That works, but the user can't umount. "Only root can umount..." > I believe the user doing the mount were allowed to umount before. > Did you upgrade your util-linux package recently and do you have /etc/mtab symlinked to /proc/mounts? I noticed a similar problem (with user-mountable CD-ROM devices and linux-kernel v2.2) and found a change in util-linux/mount/umount.c which might be responsible for it. If so, it is IMHO not a kernel issue, anyway I didn't have the time to further examine the problem yet, though... HTH - andreas -- Andreas Haumer | mailto:andreas@xss.co.at *x Software + Systeme | http://www.xss.co.at/ Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0 A-1100 Vienna, Austria | Fax: +43-1-6060114-71 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 11:11 ` 2.5.65-mm1 Andrew Morton @ 2003-03-18 15:08 ` Alexander Hoogerhuis -1 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-18 15:08 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > > [SNIP] > I tried to get find what made 2.5.64-mm1 special that made my Radeon card work, and had no luck in boiling down the differences more than generally waving in the general direction "seems to be the PCI updates". Nothing, up to and including 2.5.64-mm8, worked, but now 2.5.65-mm1 works like a charm and I'm on it now. I'll let you know if it breaks again (or other breakage I find) :) mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-18 15:08 ` Alexander Hoogerhuis 0 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-18 15:08 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > > [SNIP] > I tried to get find what made 2.5.64-mm1 special that made my Radeon card work, and had no luck in boiling down the differences more than generally waving in the general direction "seems to be the PCI updates". Nothing, up to and including 2.5.64-mm8, worked, but now 2.5.65-mm1 works like a charm and I'm on it now. I'll let you know if it breaks again (or other breakage I find) :) mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 15:08 ` 2.5.65-mm1 Alexander Hoogerhuis @ 2003-03-18 15:51 ` Alexander Hoogerhuis -1 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-18 15:51 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm Alexander Hoogerhuis <alexh@ihatent.com> writes: > Andrew Morton <akpm@digeo.com> writes: > > > > [SNIP] > > > > [SNIP MYSELF] > Oh well, I've had one hang within 10 minutes of booting, came back and the machine was unresponsive (mouse and keyboard under X, unable to switch to console). Apart from that I've got two funnies in my boot messages: PCI: Cannot allocate resource region 0 of device 02:0e.2 THe device is my USB hub in the laptop: lapper root # lspci -vv -s 02:0e.2 02:0e.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (4000ns min, 8500ns max), cache line size 20 Interrupt: pin C routed to IRQ 10 Region 0: Memory at 30000000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- And this one when probing for my PCIC: Intel PCIC probe: PNP <6>pnp: res: The PnP device '00:0f' is already active. And related to the video trouble, I fond this in the bootlog: agpgart: Putting AGP V2 device at 00:00.0 into 1x mode agpgart: Putting AGP V2 device at 01:00.0 into 1x mode lapper root # lspci 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) With 2.4 I used 4x AGP with X with no hassle. mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-18 15:51 ` Alexander Hoogerhuis 0 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-18 15:51 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm Alexander Hoogerhuis <alexh@ihatent.com> writes: > Andrew Morton <akpm@digeo.com> writes: > > > > [SNIP] > > > > [SNIP MYSELF] > Oh well, I've had one hang within 10 minutes of booting, came back and the machine was unresponsive (mouse and keyboard under X, unable to switch to console). Apart from that I've got two funnies in my boot messages: PCI: Cannot allocate resource region 0 of device 02:0e.2 THe device is my USB hub in the laptop: lapper root # lspci -vv -s 02:0e.2 02:0e.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (4000ns min, 8500ns max), cache line size 20 Interrupt: pin C routed to IRQ 10 Region 0: Memory at 30000000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- And this one when probing for my PCIC: Intel PCIC probe: PNP <6>pnp: res: The PnP device '00:0f' is already active. And related to the video trouble, I fond this in the bootlog: agpgart: Putting AGP V2 device at 00:00.0 into 1x mode agpgart: Putting AGP V2 device at 01:00.0 into 1x mode lapper root # lspci 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) With 2.4 I used 4x AGP with X with no hassle. mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 15:51 ` 2.5.65-mm1 Alexander Hoogerhuis @ 2003-03-18 16:09 ` Russell King -1 siblings, 0 replies; 27+ messages in thread From: Russell King @ 2003-03-18 16:09 UTC (permalink / raw) To: Alexander Hoogerhuis; +Cc: Andrew Morton, linux-kernel, linux-mm On Tue, Mar 18, 2003 at 04:51:11PM +0100, Alexander Hoogerhuis wrote: > Oh well, I've had one hang within 10 minutes of booting, came back and > the machine was unresponsive (mouse and keyboard under X, unable to > switch to console). Apart from that I've got two funnies in my boot > messages: Could you send the full bus information for all devices (lspci -vv), and the contents of /proc/iomem and /proc/ioports ? I don't believe there's anything in my PCI updates which should have changed the behaviour - they were touching mainly the scanning for devices, and the way we write resources back into the hardware. The latter rarely happens on x86, except for cardbus devices. -- 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] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-18 16:09 ` Russell King 0 siblings, 0 replies; 27+ messages in thread From: Russell King @ 2003-03-18 16:09 UTC (permalink / raw) To: Alexander Hoogerhuis; +Cc: Andrew Morton, linux-kernel, linux-mm On Tue, Mar 18, 2003 at 04:51:11PM +0100, Alexander Hoogerhuis wrote: > Oh well, I've had one hang within 10 minutes of booting, came back and > the machine was unresponsive (mouse and keyboard under X, unable to > switch to console). Apart from that I've got two funnies in my boot > messages: Could you send the full bus information for all devices (lspci -vv), and the contents of /proc/iomem and /proc/ioports ? I don't believe there's anything in my PCI updates which should have changed the behaviour - they were touching mainly the scanning for devices, and the way we write resources back into the hardware. The latter rarely happens on x86, except for cardbus devices. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 16:09 ` 2.5.65-mm1 Russell King @ 2003-03-19 0:14 ` Alexander Hoogerhuis -1 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 0:14 UTC (permalink / raw) To: Russell King; +Cc: Andrew Morton, linux-kernel, linux-mm Russell King <rmk@arm.linux.org.uk> writes: > On Tue, Mar 18, 2003 at 04:51:11PM +0100, Alexander Hoogerhuis wrote: > > Oh well, I've had one hang within 10 minutes of booting, came back and > > the machine was unresponsive (mouse and keyboard under X, unable to > > switch to console). Apart from that I've got two funnies in my boot > > messages: > > Could you send the full bus information for all devices (lspci -vv), > and the contents of /proc/iomem and /proc/ioports ? > > I don't believe there's anything in my PCI updates which should have > changed the behaviour - they were touching mainly the scanning for > devices, and the way we write resources back into the hardware. The > latter rarely happens on x86, except for cardbus devices. > I'm not suspecting the PCI in particular for the PCIC-bits, only making X and the Radeon work again. But here you are: lapper root # lspci -vv 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Region 0: Memory at a0000000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] #09 [d104] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4 Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=x4 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00003000-00003fff Memory behind bridge: 80300000-803fffff Prefetchable memory behind bridge: 88000000-900fffff BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B- 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=02, subordinate=03, sec-latency=32 I/O behind bridge: 00002000-00002fff Memory behind bridge: 80000000-803fffff BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at <unassigned> Region 1: I/O ports at <unassigned> Region 2: I/O ports at <unassigned> Region 3: I/O ports at <unassigned> Region 4: I/O ports at 4440 [size=16] Region 5: Memory at 30000400 (32-bit, non-prefetchable) [size=1K] 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 5 Region 0: I/O ports at 4000 [size=256] Region 1: I/O ports at 4400 [size=64] 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at 80380000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:04.0 Communication controller: Lucent Microelectronics LT WinModem (rev 02) Subsystem: AMBIT Microsystem Corp.: Unknown device 0450 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (63000ns min, 3500ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at 80280000 (32-bit, non-prefetchable) [size=256] Region 1: I/O ports at 2440 [size=8] Region 2: I/O ports at 2000 [size=256] Capabilities: [f8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=160mA PME(D0-,D1-,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 168, cache line size 20 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 80080000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: 30400000-307ff000 (prefetchable) Memory window 1: 30800000-30bff000 I/O window 0: 00001400-000014ff I/O window 1: 00001800-000018ff BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) Subsystem: Compaq Computer Corporation: Unknown device 0093 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (2000ns min, 14000ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at 2400 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 02:0e.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (250ns min, 10500ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at 80180000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:0e.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (250ns min, 10500ns max), cache line size 08 Interrupt: pin B routed to IRQ 10 Region 0: Memory at 80200000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:0e.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (4000ns min, 8500ns max), cache line size 20 Interrupt: pin C routed to IRQ 10 Region 0: Memory at 30000000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- lapper root # cat /proc/iomem /proc/ioports 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-2ffcffff : System RAM 00100000-002af453 : Kernel code 002af454-00364003 : Kernel data 2ffd0000-2fff0bff : reserved 2fff0c00-2fffbfff : ACPI Non-volatile Storage 2fffc000-2fffffff : reserved 30000000-300000ff : NEC Corporation USB 2.0 30000000-300000ff : ehci-hcd 30000400-300007ff : Intel Corp. 82801CAM IDE U100 30400000-307fffff : PCI CardBus #03 30800000-30bfffff : PCI CardBus #03 80080000-80080fff : Texas Instruments PCI1410 PC card Card 80100000-80100fff : Intel Corp. 82801CAM (ICH3) PRO/ 80100000-80100fff : eepro100 80180000-80180fff : NEC Corporation USB 80180000-80180fff : ohci-hcd 80200000-80200fff : NEC Corporation USB (#2) 80200000-80200fff : ohci-hcd 80280000-802800ff : Lucent Microelectron LT WinModem 80300000-803fffff : PCI Bus #01 80380000-8038ffff : ATI Technologies Inc Radeon Mobility M7 L 88000000-900fffff : PCI Bus #01 88000000-8fffffff : ATI Technologies Inc Radeon Mobility M7 L a0000000-afffffff : Intel Corp. 82845 845 (Brookdale 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 1060-106f : i810 TCO 1400-14ff : PCI CardBus #03 1800-18ff : PCI CardBus #03 2000-20ff : Lucent Microelectron LT WinModem 2400-243f : Intel Corp. 82801CAM (ICH3) PRO/ 2400-243f : eepro100 2440-2447 : Lucent Microelectron LT WinModem 3000-3fff : PCI Bus #01 3000-30ff : ATI Technologies Inc Radeon Mobility M7 L 4000-40ff : Intel Corp. 82801CA/CAM AC'97 Au 4000-40ff : Intel ICH3 4400-443f : Intel Corp. 82801CA/CAM AC'97 Au 4400-443f : Intel ICH3 4440-444f : Intel Corp. 82801CAM IDE U100 4440-4447 : ide0 4448-444f : ide1 lapper root # mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-19 0:14 ` Alexander Hoogerhuis 0 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 0:14 UTC (permalink / raw) To: Russell King; +Cc: Andrew Morton, linux-kernel, linux-mm Russell King <rmk@arm.linux.org.uk> writes: > On Tue, Mar 18, 2003 at 04:51:11PM +0100, Alexander Hoogerhuis wrote: > > Oh well, I've had one hang within 10 minutes of booting, came back and > > the machine was unresponsive (mouse and keyboard under X, unable to > > switch to console). Apart from that I've got two funnies in my boot > > messages: > > Could you send the full bus information for all devices (lspci -vv), > and the contents of /proc/iomem and /proc/ioports ? > > I don't believe there's anything in my PCI updates which should have > changed the behaviour - they were touching mainly the scanning for > devices, and the way we write resources back into the hardware. The > latter rarely happens on x86, except for cardbus devices. > I'm not suspecting the PCI in particular for the PCIC-bits, only making X and the Radeon work again. But here you are: lapper root # lspci -vv 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Region 0: Memory at a0000000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] #09 [d104] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW+ Rate=x1,x2,x4 Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=x4 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00003000-00003fff Memory behind bridge: 80300000-803fffff Prefetchable memory behind bridge: 88000000-900fffff BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B- 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=02, subordinate=03, sec-latency=32 I/O behind bridge: 00002000-00002fff Memory behind bridge: 80000000-803fffff BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if 8a [Master SecP PriP]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 5 Region 0: I/O ports at <unassigned> Region 1: I/O ports at <unassigned> Region 2: I/O ports at <unassigned> Region 3: I/O ports at <unassigned> Region 4: I/O ports at 4440 [size=16] Region 5: Memory at 30000400 (32-bit, non-prefetchable) [size=1K] 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 5 Region 0: I/O ports at 4000 [size=256] Region 1: I/O ports at 4400 [size=64] 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at 80380000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:04.0 Communication controller: Lucent Microelectronics LT WinModem (rev 02) Subsystem: AMBIT Microsystem Corp.: Unknown device 0450 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (63000ns min, 3500ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at 80280000 (32-bit, non-prefetchable) [size=256] Region 1: I/O ports at 2440 [size=8] Region 2: I/O ports at 2000 [size=256] Capabilities: [f8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=160mA PME(D0-,D1-,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 168, cache line size 20 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 80080000 (32-bit, non-prefetchable) [size=4K] Bus: primary=02, secondary=03, subordinate=06, sec-latency=176 Memory window 0: 30400000-307ff000 (prefetchable) Memory window 1: 30800000-30bff000 I/O window 0: 00001400-000014ff I/O window 1: 00001800-000018ff BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) Subsystem: Compaq Computer Corporation: Unknown device 0093 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (2000ns min, 14000ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at 80100000 (32-bit, non-prefetchable) [size=4K] Region 1: I/O ports at 2400 [size=64] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 02:0e.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (250ns min, 10500ns max), cache line size 08 Interrupt: pin A routed to IRQ 10 Region 0: Memory at 80180000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:0e.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (250ns min, 10500ns max), cache line size 08 Interrupt: pin B routed to IRQ 10 Region 0: Memory at 80200000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:0e.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Compaq Computer Corporation: Unknown device 004a Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64 (4000ns min, 8500ns max), cache line size 20 Interrupt: pin C routed to IRQ 10 Region 0: Memory at 30000000 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- lapper root # cat /proc/iomem /proc/ioports 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000f0000-000fffff : System ROM 00100000-2ffcffff : System RAM 00100000-002af453 : Kernel code 002af454-00364003 : Kernel data 2ffd0000-2fff0bff : reserved 2fff0c00-2fffbfff : ACPI Non-volatile Storage 2fffc000-2fffffff : reserved 30000000-300000ff : NEC Corporation USB 2.0 30000000-300000ff : ehci-hcd 30000400-300007ff : Intel Corp. 82801CAM IDE U100 30400000-307fffff : PCI CardBus #03 30800000-30bfffff : PCI CardBus #03 80080000-80080fff : Texas Instruments PCI1410 PC card Card 80100000-80100fff : Intel Corp. 82801CAM (ICH3) PRO/ 80100000-80100fff : eepro100 80180000-80180fff : NEC Corporation USB 80180000-80180fff : ohci-hcd 80200000-80200fff : NEC Corporation USB (#2) 80200000-80200fff : ohci-hcd 80280000-802800ff : Lucent Microelectron LT WinModem 80300000-803fffff : PCI Bus #01 80380000-8038ffff : ATI Technologies Inc Radeon Mobility M7 L 88000000-900fffff : PCI Bus #01 88000000-8fffffff : ATI Technologies Inc Radeon Mobility M7 L a0000000-afffffff : Intel Corp. 82845 845 (Brookdale 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 1060-106f : i810 TCO 1400-14ff : PCI CardBus #03 1800-18ff : PCI CardBus #03 2000-20ff : Lucent Microelectron LT WinModem 2400-243f : Intel Corp. 82801CAM (ICH3) PRO/ 2400-243f : eepro100 2440-2447 : Lucent Microelectron LT WinModem 3000-3fff : PCI Bus #01 3000-30ff : ATI Technologies Inc Radeon Mobility M7 L 4000-40ff : Intel Corp. 82801CA/CAM AC'97 Au 4000-40ff : Intel ICH3 4400-443f : Intel Corp. 82801CA/CAM AC'97 Au 4400-443f : Intel ICH3 4440-444f : Intel Corp. 82801CAM IDE U100 4440-4447 : ide0 4448-444f : ide1 lapper root # mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-19 0:14 ` 2.5.65-mm1 Alexander Hoogerhuis @ 2003-03-19 0:26 ` Andrew Morton -1 siblings, 0 replies; 27+ messages in thread From: Andrew Morton @ 2003-03-19 0:26 UTC (permalink / raw) To: Alexander Hoogerhuis; +Cc: rmk, linux-kernel, linux-mm Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > I'm not suspecting the PCI in particular for the PCIC-bits, only > making X and the Radeon work again. But here you are: Something bad has happened to the Radeon driver in recent kernels. I've seen various reports with various syptoms and some suspicion has been directed at the AGP changes. But as far as I know nobody has actually got down and done the binary search to find out exactly when it started happening. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-19 0:26 ` Andrew Morton 0 siblings, 0 replies; 27+ messages in thread From: Andrew Morton @ 2003-03-19 0:26 UTC (permalink / raw) To: Alexander Hoogerhuis; +Cc: rmk, linux-kernel, linux-mm Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > I'm not suspecting the PCI in particular for the PCIC-bits, only > making X and the Radeon work again. But here you are: Something bad has happened to the Radeon driver in recent kernels. I've seen various reports with various syptoms and some suspicion has been directed at the AGP changes. But as far as I know nobody has actually got down and done the binary search to find out exactly when it started happening. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-19 0:26 ` 2.5.65-mm1 Andrew Morton @ 2003-03-19 6:16 ` Alexander Hoogerhuis -1 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 6:16 UTC (permalink / raw) To: Andrew Morton; +Cc: rmk, linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > I'm not suspecting the PCI in particular for the PCIC-bits, only > > making X and the Radeon work again. But here you are: > > Something bad has happened to the Radeon driver in recent kernels. I've seen > various reports with various syptoms and some suspicion has been directed at > the AGP changes. > > But as far as I know nobody has actually got down and done the binary search > to find out exactly when it started happening. The AGP code enables my machine with 1xAGP, but under 2.4 with same X version it will support 4x. I had a poke around in the Intel AGP code and there doesn't seem to be a way to manually convinve the driver of the truth :) mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-19 6:16 ` Alexander Hoogerhuis 0 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 6:16 UTC (permalink / raw) To: Andrew Morton; +Cc: rmk, linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > I'm not suspecting the PCI in particular for the PCIC-bits, only > > making X and the Radeon work again. But here you are: > > Something bad has happened to the Radeon driver in recent kernels. I've seen > various reports with various syptoms and some suspicion has been directed at > the AGP changes. > > But as far as I know nobody has actually got down and done the binary search > to find out exactly when it started happening. The AGP code enables my machine with 1xAGP, but under 2.4 with same X version it will support 4x. I had a poke around in the Intel AGP code and there doesn't seem to be a way to manually convinve the driver of the truth :) mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-19 0:26 ` 2.5.65-mm1 Andrew Morton @ 2003-03-19 8:12 ` Alexander Hoogerhuis -1 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 8:12 UTC (permalink / raw) To: Andrew Morton; +Cc: rmk, linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > I'm not suspecting the PCI in particular for the PCIC-bits, only > > making X and the Radeon work again. But here you are: > > Something bad has happened to the Radeon driver in recent kernels. I've seen > various reports with various syptoms and some suspicion has been directed at > the AGP changes. > > But as far as I know nobody has actually got down and done the binary search > to find out exactly when it started happening. Just got my machine out and booted up, this time I did enable my chipset into 4x AGP, instead of 1x as last night: alexh@lapper ~ $ dmesg | grep -i agp Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected Intel i845 chipset agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 256M @ 0xa0000000 agpgart: Putting AGP V2 device at 00:00.0 into 4x mode agpgart: Putting AGP V2 device at 01:00.0 into 4x mode alexh@lapper ~ $ mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-19 8:12 ` Alexander Hoogerhuis 0 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 8:12 UTC (permalink / raw) To: Andrew Morton; +Cc: rmk, linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > I'm not suspecting the PCI in particular for the PCIC-bits, only > > making X and the Radeon work again. But here you are: > > Something bad has happened to the Radeon driver in recent kernels. I've seen > various reports with various syptoms and some suspicion has been directed at > the AGP changes. > > But as far as I know nobody has actually got down and done the binary search > to find out exactly when it started happening. Just got my machine out and booted up, this time I did enable my chipset into 4x AGP, instead of 1x as last night: alexh@lapper ~ $ dmesg | grep -i agp Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected Intel i845 chipset agpgart: Maximum main memory to use for agp memory: 690M agpgart: AGP aperture is 256M @ 0xa0000000 agpgart: Putting AGP V2 device at 00:00.0 into 4x mode agpgart: Putting AGP V2 device at 01:00.0 into 4x mode alexh@lapper ~ $ mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-19 0:26 ` 2.5.65-mm1 Andrew Morton @ 2003-03-19 8:20 ` Alexander Hoogerhuis -1 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 8:20 UTC (permalink / raw) To: Andrew Morton; +Cc: rmk, linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > I'm not suspecting the PCI in particular for the PCIC-bits, only > > making X and the Radeon work again. But here you are: > > Something bad has happened to the Radeon driver in recent kernels. I've seen > various reports with various syptoms and some suspicion has been directed at > the AGP changes. > > But as far as I know nobody has actually got down and done the binary search > to find out exactly when it started happening. The best I've narrowed it down to is whatever makes 2.5.64-mm1 be different from plain 2.5.64 and 2.5.64-mm2. In addition, I have one more gripe, and this one is present in 2.4 too, but seems kernel related: When closing Gnome (Gnome 2.x, Gentoo), after the screen has been "faded" by the logout applet, on the first keystroke or movement of the mouse the machine will instantly cold start the machine. mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-19 8:20 ` Alexander Hoogerhuis 0 siblings, 0 replies; 27+ messages in thread From: Alexander Hoogerhuis @ 2003-03-19 8:20 UTC (permalink / raw) To: Andrew Morton; +Cc: rmk, linux-kernel, linux-mm Andrew Morton <akpm@digeo.com> writes: > Alexander Hoogerhuis <alexh@ihatent.com> wrote: > > > > I'm not suspecting the PCI in particular for the PCIC-bits, only > > making X and the Radeon work again. But here you are: > > Something bad has happened to the Radeon driver in recent kernels. I've seen > various reports with various syptoms and some suspicion has been directed at > the AGP changes. > > But as far as I know nobody has actually got down and done the binary search > to find out exactly when it started happening. The best I've narrowed it down to is whatever makes 2.5.64-mm1 be different from plain 2.5.64 and 2.5.64-mm2. In addition, I have one more gripe, and this one is present in 2.4 too, but seems kernel related: When closing Gnome (Gnome 2.x, Gentoo), after the screen has been "faded" by the logout applet, on the first keystroke or movement of the mouse the machine will instantly cold start the machine. mvh, A -- Alexander Hoogerhuis | alexh@ihatent.com CCNP - CCDP - MCNE - CCSE | +47 908 21 485 "You have zero privacy anyway. Get over it." --Scott McNealy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re[2]: 2.5.65-mm1 2003-03-18 15:51 ` 2.5.65-mm1 Alexander Hoogerhuis (?) (?) @ 2003-03-18 19:49 ` Ruslan U. Zakirov 2003-03-18 21:33 ` 2.5.65-mm1 Adam Belay -1 siblings, 1 reply; 27+ messages in thread From: Ruslan U. Zakirov @ 2003-03-18 19:49 UTC (permalink / raw) To: linux-kernel-owner, Alexander Hoogerhuis Cc: Andrew Morton, linux-mm, Adam Belay AH> Alexander Hoogerhuis <alexh@ihatent.com> writes: >> Andrew Morton <akpm@digeo.com> writes: >> > >> > [SNIP] >> > >> >> [SNIP MYSELF] >> AH> And this one when probing for my PCIC: AH> Intel PCIC probe: PNP <6>pnp: res: The PnP device '00:0f' is already AH> active. Hello, Alexandre and other. This error is not mm specific. This was brought with latest PnP changes. As I've understood that latest PnP Layer activates all devices during layer initialisation, but I don't know how it could be if we don't register pnp_driver. With first look I didn't find this runpaths. I'll try to review all changes. Adam know absolutly right solution in this case, I think :) Best regards, Ruslan. mailto:cubic@wr.miee.ru -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 19:49 ` Re[2]: 2.5.65-mm1 Ruslan U. Zakirov @ 2003-03-18 21:33 ` Adam Belay 0 siblings, 0 replies; 27+ messages in thread From: Adam Belay @ 2003-03-18 21:33 UTC (permalink / raw) To: Ruslan U. Zakirov Cc: Andrew Morton, linux-mm, Alexander Hoogerhuis, linux-kernel On Tue, Mar 18, 2003 at 10:49:25PM +0300, Ruslan U. Zakirov wrote: > AH> Alexander Hoogerhuis <alexh@ihatent.com> writes: > >> Andrew Morton <akpm@digeo.com> writes: > >> > > >> > [SNIP] > >> > > >> > >> [SNIP MYSELF] > >> > AH> And this one when probing for my PCIC: > > AH> Intel PCIC probe: PNP <6>pnp: res: The PnP device '00:0f' is already > AH> active. > Hello, Alexandre and other. > This error is not mm specific. > This was brought with latest PnP changes. > As I've understood that latest PnP Layer activates all devices during layer > initialisation, but I don't know how it could be if we don't register PnP code currently assigns resources at init and then activates during driver matching. > pnp_driver. With first look I didn't find this runpaths. I'll try to > review all changes. > Adam know absolutly right solution in this case, I think :) > Best regards, Ruslan. > > mailto:cubic@wr.miee.ru Hi Ruslan and others, Yes, this is actually a glitch in the driver. The bios has activated this device at boot time and the driver tries to activate it again without checking if it was active in the first place. I'm going to do the following to correct this: 1.) Update this driver to use the new pnp code, the new code automatically manages this. 2.) Change pnp_activate_dev so that it doesn't return an error if the device is already active, instead have it silently stop. This is a more logical behavior because the device will function properly even if it was already active. I should probably do the same with pnp_disable_dev. Regards, Adam ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-18 21:33 ` Adam Belay 0 siblings, 0 replies; 27+ messages in thread From: Adam Belay @ 2003-03-18 21:33 UTC (permalink / raw) To: Ruslan U. Zakirov Cc: Andrew Morton, linux-mm, Alexander Hoogerhuis, linux-kernel On Tue, Mar 18, 2003 at 10:49:25PM +0300, Ruslan U. Zakirov wrote: > AH> Alexander Hoogerhuis <alexh@ihatent.com> writes: > >> Andrew Morton <akpm@digeo.com> writes: > >> > > >> > [SNIP] > >> > > >> > >> [SNIP MYSELF] > >> > AH> And this one when probing for my PCIC: > > AH> Intel PCIC probe: PNP <6>pnp: res: The PnP device '00:0f' is already > AH> active. > Hello, Alexandre and other. > This error is not mm specific. > This was brought with latest PnP changes. > As I've understood that latest PnP Layer activates all devices during layer > initialisation, but I don't know how it could be if we don't register PnP code currently assigns resources at init and then activates during driver matching. > pnp_driver. With first look I didn't find this runpaths. I'll try to > review all changes. > Adam know absolutly right solution in this case, I think :) > Best regards, Ruslan. > > mailto:cubic@wr.miee.ru Hi Ruslan and others, Yes, this is actually a glitch in the driver. The bios has activated this device at boot time and the driver tries to activate it again without checking if it was active in the first place. I'm going to do the following to correct this: 1.) Update this driver to use the new pnp code, the new code automatically manages this. 2.) Change pnp_activate_dev so that it doesn't return an error if the device is already active, instead have it silently stop. This is a more logical behavior because the device will function properly even if it was already active. I should probably do the same with pnp_disable_dev. Regards, Adam -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 2003-03-18 11:11 ` 2.5.65-mm1 Andrew Morton @ 2003-03-18 21:40 ` William Lee Irwin III -1 siblings, 0 replies; 27+ messages in thread From: William Lee Irwin III @ 2003-03-18 21:40 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm On Tue, Mar 18, 2003 at 03:11:04AM -0800, Andrew Morton wrote: > . An updated version of Russell's PCMCIA patches > . Lots more anticipatory scheduler work. > . It turns out that calling disk request_fns from timer/tasklet context is > not permitted because a few old drivers like to sleep in that function. > keventd cannot be used for this because it can deadlock. So another > kernel thread per CPU has been reluctantly added. So far so good. There are couple of non-critical things I noticed. On my home machine, 600MHz Athlon w/768MB RAM, Adaptec 39160 + U160 disk pte_chain: 4644KB 4661KB 99.64 dentry_cache: 987KB 1275KB 77.47 radix_tree_node: 988KB 1233KB 80.14 reiser_inode_cache: 755KB 1181KB 63.93 biovec-BIO_MAX_PAGES: 768KB 780KB 98.46 size-4096: 624KB 624KB 100.0 inode_cache: 457KB 457KB 100.0 pgd: 432KB 432KB 100.0 shpte really blew the doors off of pte_chains for my home box and slightly more than halved pagetable space. It really helps keep things from swapping, a good 4-6 MB of pte_chain + pagetable space. I wish for it back relatively often. OTOH objrmap appears to have blown page_*_rmap() functions off the profiles on the execution time front. Window wiggle test times (ms): inter-arrival service response ------------- ------- -------- 113.828 0.093 4.702 113.828 0.093 4.702 113.828 0.093 4.702 113.828 0.093 4.702 113.828 0.093 4.702 56.762 0.090 4.593 56.762 0.090 4.593 56.762 0.090 4.593 56.762 0.090 4.593 56.762 0.090 4.593 106.250 0.088 4.545 51.944 0.135 6.133 34.006 0.172 7.345 27.087 0.194 7.276 26.807 0.120 6.549 27.975 0.128 6.721 31.292 0.161 7.278 32.952 0.147 6.692 32.952 0.147 6.692 32.952 0.147 6.692 32.952 0.147 6.692 32.952 0.147 6.692 This is really the only visible task scheduling pathology. The user observable effect is that now transparent xterms "flash" when being wiggled, where before they merely showed some refresh jitter. But it's a vast net improvement; good work on mingo's part. I've not been noticing the more refined aspects of io scheduling. Basically once deadline-iosched hit, my home machine was very happy, and the gains after mostly slight. There's some of app startup time that appears to have been trimmed down that may have come from this. I noticed it while booting but by and large I don't spawn new large tasks regularly, so it sort of doesn't do as much for me as others. It could also be due to the prefaulting or a combined effect. -- wli ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: 2.5.65-mm1 @ 2003-03-18 21:40 ` William Lee Irwin III 0 siblings, 0 replies; 27+ messages in thread From: William Lee Irwin III @ 2003-03-18 21:40 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, linux-mm On Tue, Mar 18, 2003 at 03:11:04AM -0800, Andrew Morton wrote: > . An updated version of Russell's PCMCIA patches > . Lots more anticipatory scheduler work. > . It turns out that calling disk request_fns from timer/tasklet context is > not permitted because a few old drivers like to sleep in that function. > keventd cannot be used for this because it can deadlock. So another > kernel thread per CPU has been reluctantly added. So far so good. There are couple of non-critical things I noticed. On my home machine, 600MHz Athlon w/768MB RAM, Adaptec 39160 + U160 disk pte_chain: 4644KB 4661KB 99.64 dentry_cache: 987KB 1275KB 77.47 radix_tree_node: 988KB 1233KB 80.14 reiser_inode_cache: 755KB 1181KB 63.93 biovec-BIO_MAX_PAGES: 768KB 780KB 98.46 size-4096: 624KB 624KB 100.0 inode_cache: 457KB 457KB 100.0 pgd: 432KB 432KB 100.0 shpte really blew the doors off of pte_chains for my home box and slightly more than halved pagetable space. It really helps keep things from swapping, a good 4-6 MB of pte_chain + pagetable space. I wish for it back relatively often. OTOH objrmap appears to have blown page_*_rmap() functions off the profiles on the execution time front. Window wiggle test times (ms): inter-arrival service response ------------- ------- -------- 113.828 0.093 4.702 113.828 0.093 4.702 113.828 0.093 4.702 113.828 0.093 4.702 113.828 0.093 4.702 56.762 0.090 4.593 56.762 0.090 4.593 56.762 0.090 4.593 56.762 0.090 4.593 56.762 0.090 4.593 106.250 0.088 4.545 51.944 0.135 6.133 34.006 0.172 7.345 27.087 0.194 7.276 26.807 0.120 6.549 27.975 0.128 6.721 31.292 0.161 7.278 32.952 0.147 6.692 32.952 0.147 6.692 32.952 0.147 6.692 32.952 0.147 6.692 32.952 0.147 6.692 This is really the only visible task scheduling pathology. The user observable effect is that now transparent xterms "flash" when being wiggled, where before they merely showed some refresh jitter. But it's a vast net improvement; good work on mingo's part. I've not been noticing the more refined aspects of io scheduling. Basically once deadline-iosched hit, my home machine was very happy, and the gains after mostly slight. There's some of app startup time that appears to have been trimmed down that may have come from this. I noticed it while booting but by and large I don't spawn new large tasks regularly, so it sort of doesn't do as much for me as others. It could also be due to the prefaulting or a combined effect. -- wli -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a> ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2003-03-19 8:20 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-03-18 11:11 2.5.65-mm1 Andrew Morton 2003-03-18 11:11 ` 2.5.65-mm1 Andrew Morton 2003-03-18 13:15 ` 2.5.65-mm1 Helge Hafting 2003-03-18 13:15 ` 2.5.65-mm1 Helge Hafting 2003-03-18 13:29 ` 2.5.65-mm1 small nfs umount problem, also in 64-mm8 Helge Hafting 2003-03-18 13:56 ` Andreas Haumer 2003-03-18 15:08 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-18 15:08 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-18 15:51 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-18 15:51 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-18 16:09 ` 2.5.65-mm1 Russell King 2003-03-18 16:09 ` 2.5.65-mm1 Russell King 2003-03-19 0:14 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 0:14 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 0:26 ` 2.5.65-mm1 Andrew Morton 2003-03-19 0:26 ` 2.5.65-mm1 Andrew Morton 2003-03-19 6:16 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 6:16 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 8:12 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 8:12 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 8:20 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-19 8:20 ` 2.5.65-mm1 Alexander Hoogerhuis 2003-03-18 19:49 ` Re[2]: 2.5.65-mm1 Ruslan U. Zakirov 2003-03-18 21:33 ` 2.5.65-mm1 Adam Belay 2003-03-18 21:33 ` 2.5.65-mm1 Adam Belay 2003-03-18 21:40 ` 2.5.65-mm1 William Lee Irwin III 2003-03-18 21:40 ` 2.5.65-mm1 William Lee Irwin III
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.