2.5.65-mm1

2.5.65-mm1

[Andrew Morton]

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>

Re: 2.5.65-mm1

[Helge Hafting]

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>

Re: 2.5.65-mm1

[Alexander Hoogerhuis]

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>

Re: 2.5.65-mm1

[Alexander Hoogerhuis]

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>

Re: 2.5.65-mm1

[Russell King]

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>

Re[2]: 2.5.65-mm1

[Ruslan U. Zakirov]

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>

Re: 2.5.65-mm1

[Adam Belay]

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>

Re: 2.5.65-mm1

[William Lee Irwin III]

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>

Re: 2.5.65-mm1

[Alexander Hoogerhuis]

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>

Re: 2.5.65-mm1

[Andrew Morton]

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>

Re: 2.5.65-mm1

[Alexander Hoogerhuis]

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>

Re: 2.5.65-mm1

[Alexander Hoogerhuis]

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>

Re: 2.5.65-mm1

[Alexander Hoogerhuis]

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>