ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
. Added all of Russell King's PCMCIA changes. If anyone tests this on
cardbus/PCMCIA machines please let us know.
. Starting to concentrate a bit more on the nonlinear mapping and objrmap
patches. These conflict to various degrees, but we seem to be getting that
sorted now.
To test the nonlinear mapping code more thoroughly I have arranged for all
executable file-backed mmaps to be treated as nonlinear.
This means that when an executable is first mapped in, the kernel will
slurp the whole thing off disk in one hit. Some IO changes were made to
speed this up.
This means that large cache-cold executables start significantly faster.
Launching X11+KDE+mozilla goes from 23 seconds to 16. Starting OpenOffice
seems to be 2x to 3x faster, and starting Konqueror maybe 3x faster too.
Interesting.
This might cause weird thing to happen, especially on small-memory machines.
Changes since 2.5.64-mm5:
+ppc64-compat-flock.patch
+ppc64-eeh-fix.patch
+ppc64-socketcall-fix.patch
Various ppc64 build fixes
+remap-file-pages-2.5.63-a1.patch
Reworked to apply before objrmap,
+hugh-remap-fix.patch
The remap_file_pages part of hugh-nonlinear-fixes.patch
+fremap-limit-offsets.patch
Constrain remap_file_pages() input to fit inside the file-offset-in-pte
representation. 29 bits on ia32.
+fremap-all-mappings.patch
Make all PROT_EXEC file-backed mmappings use MAP_POPULATE treatment.
+filemap_populate-speedup.patch
Use large IOs for prefaulting.
+file-offset-in-pte-x86_64.patch
Reworked for remap_file_pages offset limiting.
+file-offset-in-pte-ppc64.patch
PPC64 support. Untested...
+objrmap-nonlinear-fixes.patch
The other part of hugh-nonlinear-fixes.patch
-hugh-nonlinear-fixes.patch
Split up.
-brlock-1.patch
-brlock-2.patch
-brlock-3.patch
-brlock-4.patch
-brlock-5.patch
-brlock-6.patch
-brlock-7.patch
-brlock-8.patch
Dropped. Stephen has a new patch, but it doesn't compile.
+early-writeback-init.patch
Intialsie writeback early for rootfs population.
+posix-timers-update.patch
Permit long sleeps.
+e100-memleak-fix.patch
Plug another leak.
+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
rmk's pcmcia rework
+oops-counters.patch
Display the oops instance in the oops record
+io_apic-DO_ACTION-cleanup.patch
Clean up the IO APIC code.
+ext2-ext3-noatime-fix.patch
Ext2 and ext3 inode flags initialisation fixes.
All 86 patches:
linus.patch
Latest from Linus
mm.patch
add -mmN to EXTRAVERSION
kgdb.patch
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
ppc64-compat-flock.patch
compat_sys_fcntl{,64} 2/9 ppc64 part
ppc64-eeh-fix.patch
ppc64 build fix
ppc64-socketcall-fix.patch
sym-do-160.patch
make the SYM driver do 160 MB/sec
nfsd-disable-softirq.patch
Fix race in svcsock.c in 2.5.61
report-lost-ticks.patch
make lost-tick detection more informative
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
lockd-lockup-fix-2.patch
Subject: Re: Fw: Re: 2.4.20 NFS server lock-up (SMP)
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
as-iosched.patch
anticipatory I/O scheduler
as-debug-BUG-fix.patch
cfq-2.patch
CFQ scheduler, #2
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
scheduler-tunables.patch
scheduler tunables
show_task-free-stack-fix.patch
show_task() fix and cleanup
reiserfs-fix-memleaks.patch
ReiserFS: fix memleaks on journal opening failures
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
register-tty_devclass.patch
Register tty_devclass before use
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
fix-mem-equals.patch
Fix mem= options
no-mmu-stubs.patch
a few missing stubs for !CONFIG_MMU
nommu-slab.patch
slab changes for !CONFIG_MMU
nfsd-memleak-fix.patch
nfsd/export.c memleak.
nfs-memleak-fix.patch
memleak in fs/nfs/inode.c::nfs_get_sb()
ufs-memleak-fix.patch
Memleak in fs/ufs/util.c
hugetlb-unmap_vmas-fix.patch
fix the fix for unmap_vmas & hugepages
early-writeback-init.patch
Early writeback initialisation
posix-timers-update.patch
posix timers update
e100-memleak-fix.patch
Memleak in e100 driver
bsd-printk-limit.patch
pcmcia-1-kill-get_foo_map.patch
pcmcia: 1/6 kill get_*_map
pcmcia-2-remove-bus_foo-abstractions.patch
pcmcia: 2/6: Remove bus_* abstractions
pcmcia-3-add-SOCKET_CARDBUS_CONFIG.patch
pcmcia: 3/6: add SOCKET_CARDBUS_CONFIG flag
pcmcia-4-add-locking.patch
pcmcia: 4/6: Add some locking to rsrc_mgr.c
pcmcia-5-add-CONFIG_PCMCIA_PROBE.patch
pcmcia 5/6: Introduce CONFIG_PCMCIA_PROBE
pcmcia-6-remove-old-cardbus-clients.patch
pcmcia: 6/6: Remove support for old cardbus clients
oops-counters.patch
OOPS instance counters
io_apic-DO_ACTION-cleanup.patch
io-apic.c: DO_ACTION cleanup
ext2-ext3-noatime-fix.patch
Ext2/3 noatime and dirsync sometimes ignored
Andrew Morton <[email protected]> writes:
> This means that large cache-cold executables start significantly faster.
> Launching X11+KDE+mozilla goes from 23 seconds to 16. Starting OpenOffice
> seems to be 2x to 3x faster, and starting Konqueror maybe 3x faster too.
> Interesting.
>
> This might cause weird thing to happen, especially on small-memory machines.
That's great. It would be nice to have this as a sysctl or perhaps
some heuristic based on file size and available memory for 2.6.
-Andi
----- Original Message -----
From: Andrew Morton <[email protected]>
Date: Thu, 13 Mar 2003 03:26:15 -0800
To: [email protected], [email protected]
Subject: 2.5.64-mm6
> . Added all of Russell King's PCMCIA changes. If anyone tests this on
> cardbus/PCMCIA machines please let us know.
Testing 2.5.64-mm6 on my NEC laptop, TI CardBus Bridge,
3Com 3c575. No problems yet ;-)
> This means that large cache-cold executables start significantly faster.
> Launching X11+KDE+mozilla goes from 23 seconds to 16. Starting OpenOffice
> seems to be 2x to 3x faster, and starting Konqueror maybe 3x faster too.
> Interesting.
I feel the system a little bit faster and more responsive. I've also set
max_timeslice to 50 to experiment a little more with interactive loads.
Thanks!
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> This means that when an executable is first mapped in, the kernel will
> slurp the whole thing off disk in one hit. Some IO changes were made to
> speed this up.
Does this just pull in text and data, or will it pull any debug sections
too? That could fill memory with a lot of useless junk.
J
Jeremy Fitzhardinge <[email protected]> wrote:
>
> On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > This means that when an executable is first mapped in, the kernel will
> > slurp the whole thing off disk in one hit. Some IO changes were made to
> > speed this up.
>
> Does this just pull in text and data, or will it pull any debug sections
> too? That could fill memory with a lot of useless junk.
>
Just text, I expect. Unless glibc is mapping debug info with PROT_EXEC ;)
It's just a fun hack. Should be done in glibc.
Andi Kleen <[email protected]> wrote:
>
> Andrew Morton <[email protected]> writes:
>
>
> > This means that large cache-cold executables start significantly faster.
> > Launching X11+KDE+mozilla goes from 23 seconds to 16. Starting OpenOffice
> > seems to be 2x to 3x faster, and starting Konqueror maybe 3x faster too.
> > Interesting.
> >
> > This might cause weird thing to happen, especially on small-memory machines.
>
> That's great. It would be nice to have this as a sysctl or perhaps
> some heuristic based on file size and available memory for 2.6.
>
We shouldn't be putting this in-kernel, really. Userspace can obtain
the same results by running madvise(MADV_WILLNEED) against the mapping
immediately after setting it up. So a simple
map = mmap(...);
+ if (getenv("MAP_PREFAULT"))
+ madvise(map, len, MADV_WILLNEED);
in glibc is enough.
That will work on 2.4, too. I haven't tested that though.
On Thu, 13 Mar 2003, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
>
> . Added all of Russell King's PCMCIA changes. If anyone tests this on
> cardbus/PCMCIA machines please let us know.
I decided to try it because of this. My test machine was a Compaq
Presario 12XL325, PIII-650, RedHat 8.0 with updates. The cardbus bridge
is listed as a TI PCI1410 controller. I've been doing daily bk pulls and
compiles on this machine for some time with no problems noted on the
resulting kernel. On the cardbus interface I have an SMC wireless NIC as
modules.
I downloaded the mm-6 patch and a pristine 2.5.64 tarball. After applying
the patch I compiled with the standard configuration I've been using all
along. No problems were noted during the compile cycle. During bootup
the system locked up at the point where it did a modprobe uhci-hcd for the
USB controller. Nothing of interest was noted in the log. I rebooted
with nousb in the command line and got a good boot. After working with
this kernel for awhile I don't see anything out of the ordainary except
that on a 2.5.64-bk kernel I get 330 Kbytes per second download speed
whereas with mm6 I get 280 Kbytes per second. Several runs show this is
fairly consistent, with results within one or two percent.
----- Original Message -----
From: Thomas Molina <[email protected]>
Date: Thu, 13 Mar 2003 14:35:18 -0600 (CST)
To: Andrew Morton <[email protected]>
Subject: Re: 2.5.64-mm6
> I downloaded the mm-6 patch and a pristine 2.5.64 tarball. After applying
> the patch I compiled with the standard configuration I've been using all
> along. No problems were noted during the compile cycle. During bootup
> the system locked up at the point where it did a modprobe uhci-hcd for the
> USB controller. Nothing of interest was noted in the log. I rebooted
> with nousb in the command line and got a good boot. After working with
> this kernel for awhile I don't see anything out of the ordainary except
> that on a 2.5.64-bk kernel I get 330 Kbytes per second download speed
> whereas with mm6 I get 280 Kbytes per second. Several runs show this is
> fairly consistent, with results within one or two percent.
Hmmm... I have experienced some hard locks similar to what
you describe: if I compile usb-uhci as a module, Phoebe3
(8.0.94) locks hard at the time of doing a "modprobe
usb-controller" (being usb-controller an alias for uhci-hcd)
during boot (rc.sysinit script). To fix this, I have had to compile
usb-uhci in to the kernel and then fix rc.sysinit. I haven't tried
using usb-uhci as a module since then.
What's curious is that doing a "modprobe usb-controller" by
hand doesn't cause hard locks. So, there must be some kind
of timing or interaction that's causing rc.sysinit to invoke
"modprobe uchi-hcd" and freeze the machine. Any ideas?
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
> Hmmm... I have experienced some hard locks similar to what
> you describe: if I compile usb-uhci as a module, Phoebe3
> (8.0.94) locks hard at the time of doing a "modprobe
> usb-controller" (being usb-controller an alias for uhci-hcd)
> during boot (rc.sysinit script). To fix this, I have had to compile
> usb-uhci in to the kernel and then fix rc.sysinit. I haven't tried
> using usb-uhci as a module since then.
>
> What's curious is that doing a "modprobe usb-controller" by
> hand doesn't cause hard locks. So, there must be some kind
> of timing or interaction that's causing rc.sysinit to invoke
> "modprobe uchi-hcd" and freeze the machine. Any ideas?
Not sure. The configuration I used to build 2.5.64-mm6 was the same as
every other 2.5 build I've used recently. All of those included modular
usb, so I don't believe it is that. In my case 2.5.64-mm6 is the only
version on which I see this. My initial SWAG was some interaction between
the new pcmcia core and usb, possibly at the pci layer. I only ever try
very few mm kernel versions, so I don't have a whole lot of data at the
moment.
On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> Jeremy Fitzhardinge <[email protected]> wrote:
> >
> > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > > This means that when an executable is first mapped in, the kernel will
> > > slurp the whole thing off disk in one hit. Some IO changes were made to
> > > speed this up.
> >
> > Does this just pull in text and data, or will it pull any debug sections
> > too? That could fill memory with a lot of useless junk.
> >
>
> Just text, I expect. Unless glibc is mapping debug info with PROT_EXEC ;)
>
> It's just a fun hack. Should be done in glibc.
Well, fun hack or glibc to-do list candidate, I hope it doesn't get
forgotten. I am happy to confirm that it did speed up the initial
launch time of Open Office from 20 seconds (2.5-bk) to 11 seconds (-mm6)
and Mozilla from 10 seconds (2.5-bk) to 6 seconds (-mm6).
I did run 2.5.64-mm6 with mem=64M under stress for several hours and it
took a beating and kept on ticking, although quite slowly.
Steven
Steven Cole <[email protected]> wrote:
>
> On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> > Jeremy Fitzhardinge <[email protected]> wrote:
> > >
> > > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > > > This means that when an executable is first mapped in, the kernel will
> > > > slurp the whole thing off disk in one hit. Some IO changes were made to
> > > > speed this up.
> > >
> > > Does this just pull in text and data, or will it pull any debug sections
> > > too? That could fill memory with a lot of useless junk.
> > >
> >
> > Just text, I expect. Unless glibc is mapping debug info with PROT_EXEC ;)
> >
> > It's just a fun hack. Should be done in glibc.
>
> Well, fun hack or glibc to-do list candidate, I hope it doesn't get
> forgotten.
I have to pull the odd party trick to get people to test -mm kernels.
> I am happy to confirm that it did speed up the initial
> launch time of Open Office from 20 seconds (2.5-bk) to 11 seconds (-mm6)
> and Mozilla from 10 seconds (2.5-bk) to 6 seconds (-mm6).
OK, thanks for confirming that. Both these apps are *very* compute-intensive
at startup. Try starting them when everything is in cache... The
proportional benefits for saner apps wil be larger.
As for glibc, yup, the two-liner which I mentioned is a good start. Finer
tuning would involve looking at the data segments, dlopen(), etc. A fun
project.
One subtlety: the linker (ld) lays files out very poorly. So the prefaulting
trick will not help much when run against an executable which was written by
ld. But if you've copied it into /bin (make install) then it will work well.
That's something to watch out for.
Doing it in madvise may work better actually. madvise will pull the pages
into pagecache and leave them on the inactive list. A subsequent minor fault
will activate the pages. So the unneeded pages get thrown away quickly.
Which is exactly what we want.
However -mm6 actually maps all the pages into the process's pagetables at
mmap() time. That saves the cost of thousands of minor pagefaults, but it
means that the pages which we didn't really want will take longer to be
reclaimed.
On Thu, 2003-03-13 at 21:28, Andrew Morton wrote:
> Steven Cole <[email protected]> wrote:
> >
> > On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> > > Jeremy Fitzhardinge <[email protected]> wrote:
> > > >
> > > > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > > > > This means that when an executable is first mapped in, the kernel will
> > > > > slurp the whole thing off disk in one hit. Some IO changes were made to
> > > > > speed this up.
> > > >
> > > > Does this just pull in text and data, or will it pull any debug sections
> > > > too? That could fill memory with a lot of useless junk.
> > > >
> > >
> > > Just text, I expect. Unless glibc is mapping debug info with PROT_EXEC ;)
> > >
> > > It's just a fun hack. Should be done in glibc.
> >
> > Well, fun hack or glibc to-do list candidate, I hope it doesn't get
> > forgotten.
>
> I have to pull the odd party trick to get people to test -mm kernels.
This reminds me of something I've not looked into for some time.
Being an active user of the 2.5 series including -mm, should I have
updated glibc, or is there nothing new enough yet to warrant that?
Maybe I should just ask the glibc people. Wasn't sure what the proper
forum was.
Shawn <[email protected]> wrote:
>
> Being an active user of the 2.5 series including -mm, should I have
> updated glibc, or is there nothing new enough yet to warrant that?
I think so, yes. There is the threading support and also the new
sysenter system-call entry code.
On Thu, 2003-03-13 at 22:46, Shawn wrote:
> This reminds me of something I've not looked into for some time.
>
> Being an active user of the 2.5 series including -mm, should I have
> updated glibc, or is there nothing new enough yet to warrant that?
In 2.3 and beyond (current is 2.3.2 I think), there are a few 2.5
changes. Nothing required, though.
The biggest is NPTL, which takes advantage of all the threading stuff.
There is also sysenter support.
And support for new 2.5 system calls - most, but not all, of them are
there. I know the affinity calls are. And the new posix_fadvise().
> Maybe I should just ask the glibc people. Wasn't sure what the proper
> forum was.
libc-alpha is the public glibc list. It is hosted at
sources.redhat.com.
Robert Love
I've used tried the -mm-kernels since they've actually made
2.5-kernels usable on my laptop lately (Compaq Evo800c), but
2.5.64-mm2 and onwards doesnt work with X anymore. I run 4.3.0-r1 from
the Gentoo unstable "branch".
with -mm1 I X coming up just nicely, and now the screen just goes
black after trying to start X, and it seems related to DRM. With
-mm[56] the last bit I see in my X startup is this:
(==) RADEON(0): Write-combining range (0x88000000,0x4000000)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
[HANG]
With -mm1 and 2.4.21preX it shows this:
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xf098d000
(II) RADEON(0): [drm] mapped SAREA 0xf098d000 to 0x40013000
.
.
.
Although it hangs under -mm[56] the machine will still respond to
CRTL-ALT-DEL and reboot nicely. The only modification to the kernel
I've done it backing out smalldevfs (Gentoo likes to have the full
thing). I've also tried having the DRM-stuff as modules and as
compiled in, no difference
The graphics adapter is a Radeon with 64Mb RAM:
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=x1
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-
Other than that 2.5.64-mm6 is very usable, but only in text mode.
mvh,
A
Andrew Morton <[email protected]> writes:
> [SNIP]
--
Alexander Hoogerhuis | [email protected]
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
Alexander Hoogerhuis <[email protected]> wrote:
>
> I've used tried the -mm-kernels since they've actually made
> 2.5-kernels usable on my laptop lately (Compaq Evo800c), but
> 2.5.64-mm2 and onwards doesnt work with X anymore. I run 4.3.0-r1 from
> the Gentoo unstable "branch".
>
> with -mm1 I X coming up just nicely, and now the screen just goes
> black after trying to start X, and it seems related to DRM.
I have a radeon card here. Just tried it. The X server starts up OK but as
soon as I run tuxracer, some ioctl down in the radeon driver keeps on timing
out waiting for the FIFO, spins for ten milliseconds in-kernel and the X
server immediately calls the ioctl again. The whole thing is bust. I went
all the way back to 2.5.39, where it is still bust. 2.4.21-pre5 is OK
though.
So it looks like my breakage is different from yours.
Could you please try just 2.5.64 plus
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/broken-out/linus.patch
That will tell us if it is a -mm bug or a -linus bug.
It it is the latter, and if you're feeling really keen then could you search through the patches at
http://www.zip.com.au/~akpm/linux/patches/2.5/badari/
and work out exactly which one introduced the problem?
Each of those patches is against 2.5.64. The chronological order is:
cset-1.1085-to-1.1085.txt.gz
cset-1.1085-to-1.1086.txt.gz
cset-1.1085-to-1.1089.txt.gz
cset-1.1085-to-1.1090.txt.gz
cset-1.1085-to-1.1091.txt.gz
cset-1.1085-to-1.1094.txt.gz
cset-1.1068.1.17-to-1.1075.txt.gz
cset-1.1068.1.17-to-1.1077.txt.gz
cset-1.1068.1.17-to-1.1106.txt.gz
cset-1.1068.1.17-to-1.1107.txt.gz
cset-1.1068.1.17-to-1.1110.txt.gz
cset-1.1068.1.17-to-1.1122.txt.gz
cset-1.1068.1.17-to-1.1123.txt.gz
cset-1.1068.1.17-to-1.1124.txt.gz
cset-1.1068.1.17-to-1.1125.txt.gz
cset-1.1068.1.17-to-1.1127.txt.gz
cset-1.1068.1.17-to-1.1131.txt.gz
cset-1.1068.1.17-to-1.1137.txt.gz
cset-1.1068.1.17-to-1.1160.txt.gz
cset-1.1068.1.17-to-1.1166.txt.gz
cset-1.1068.1.17-to-1.1168.txt.gz
cset-1.1068.1.17-to-1.1171.txt.gz
cset-1.1068.1.17-to-1.1173.txt.gz
cset-1.1068.1.17-to-1.1174.txt.gz
cset-1.1068.1.17-to-1.1175.txt.gz
cset-1.1068.1.17-to-1.1177.txt.gz
cset-1.1068.1.17-to-1.1101.txt.gz
cset-1.1068.1.17-to-1.1113.txt.gz
cset-1.1068.1.17-to-1.1119.txt.gz
cset-1.1068.1.17-to-1.1147.txt.gz
cset-1.1068.1.17-to-1.1154.txt.gz
cset-1.1068.1.17-to-1.1157.txt.gz
Thanks.
Andrew Morton wrote:
> This might cause weird thing to happen, especially on small-memory machines.
Weird things happened.
mm1 (and mm2 on smp) have been running very fine for me. So I decided to
try mm6 on UP. The machine have 512M, and uses soft raid-1 on / The
rest is plain ide disk partitions, all using ext2.
It booted fine.
I fired up openoffice, a 2x-3x speedup ought to be noticeable.
It didn't start, but got stuck with the annoying on-top-of-everything
splash screen showing. ps aux showed lpd in D state - perhaps
oo queries lpd. I also tried mozilla, and it got stuck in D state too.
Openoffice was only in sleep so I killed it. Mozilla was unkillable
as expected from the D state.
I've heard that this is supposed to be an anticipatory scheduler bug,
and started looking for information on how to use deadline. But
everything suddenly came loose and things works normally now.
Openoffice and mozilla starts just fine now. I guess AS have some
boot trouble, or could it be a jiffy wraparound issue? (Assuming
2.5.64-mm6 starts the counter near a wrap)
Please tell if there's anything I can do to test further.
Helge Hafting
Helge Hafting <[email protected]> wrote:
>
> Andrew Morton wrote:
> > This might cause weird thing to happen, especially on small-memory machines.
>
> Weird things happened.
> mm1 (and mm2 on smp) have been running very fine for me. So I decided to
> try mm6 on UP. The machine have 512M, and uses soft raid-1 on / The
> rest is plain ide disk partitions, all using ext2.
>
> It booted fine.
> I fired up openoffice, a 2x-3x speedup ought to be noticeable.
> It didn't start, but got stuck with the annoying on-top-of-everything
> splash screen showing. ps aux showed lpd in D state - perhaps
> oo queries lpd. I also tried mozilla, and it got stuck in D state too.
> Openoffice was only in sleep so I killed it. Mozilla was unkillable
> as expected from the D state.
The elevator bug. I'll make deadline the deefault until we get this sorted.
Booting with "elevator=deadline" should be OK.
On Thu, Mar 13, 2003 at 07:28:09PM -0800, Andrew Morton wrote:
> One subtlety: the linker (ld) lays files out very poorly. So the prefaulting
> trick will not help much when run against an executable which was written by
> ld. But if you've copied it into /bin (make install) then it will work well.
> That's something to watch out for.
Andrew,
I am not sure what you mean by this. Are you saying that the way ld
accesses files causes the blocks on the disk to be layed out poorly?
That is the only thing I can think of that would get fixed by copying.
Thanks,
Jim
[email protected] wrote:
>
> On Thu, Mar 13, 2003 at 07:28:09PM -0800, Andrew Morton wrote:
>
> > One subtlety: the linker (ld) lays files out very poorly. So the prefaulting
> > trick will not help much when run against an executable which was written by
> > ld. But if you've copied it into /bin (make install) then it will work well.
> > That's something to watch out for.
>
> Andrew,
> I am not sure what you mean by this. Are you saying that the way ld
> accesses files causes the blocks on the disk to be layed out poorly?
> That is the only thing I can think of that would get fixed by copying.
>
Exactly that. ld seeks all over the file when adding new blocks to it, so
with ext2 and ext3 (at least) there is poor correspondence between file
offset and block indices.
I recently compiled distccd:
mnm:/usr/src/distcc-1.1> 0 bmap distccd
0-0: 4544516-4544516 (1)
1-1: 4544519-4544519 (1)
2-2: 4544525-4544525 (1)
3-3: 4544531-4544531 (1)
4-4: 4544536-4544536 (1)
5-5: 4544540-4544540 (1)
6-6: 4544520-4544520 (1)
7-7: 4544528-4544528 (1)
8-8: 4544539-4544539 (1)
9-9: 4544521-4544521 (1)
10-10: 4544524-4544524 (1)
11-12: 4544526-4544527 (2)
13-14: 4544529-4544530 (2)
15-18: 4544532-4544535 (4)
19-20: 4544537-4544538 (2)
21-26: 4544541-4544546 (6)
27-40: 4544549-4544562 (14)
41-42: 4544522-4544523 (2)
43-43: 4544518-4544518 (1)
44-45: 4544547-4544548 (2)
And then I copied it:
mnm:/usr/src/distcc-1.1> 0 bmap /usr/local/bin/distccd
0-11: 3913857-3913868 (12)
12-45: 3913870-3913903 (34)
>>>>> Andrew Morton (AM) writes:
AM> [email protected] wrote:
>>
>> Andrew, I am not sure what you mean by this. Are you saying that
>> the way ld accesses files causes the blocks on the disk to be
>> layed out poorly? That is the only thing I can think of that
>> would get fixed by copying.
>>
AM> Exactly that. ld seeks all over the file when adding new blocks
AM> to it, so with ext2 and ext3 (at least) there is poor
AM> correspondence between file offset and block indices.
hmm. I thought delayed allocation should solve this problem. Isn't it?
Alex Tomas <[email protected]> wrote:
>
> >>>>> Andrew Morton (AM) writes:
>
> AM> [email protected] wrote:
> >>
> >> Andrew, I am not sure what you mean by this. Are you saying that
> >> the way ld accesses files causes the blocks on the disk to be
> >> layed out poorly? That is the only thing I can think of that
> >> would get fixed by copying.
> >>
>
> AM> Exactly that. ld seeks all over the file when adding new blocks
> AM> to it, so with ext2 and ext3 (at least) there is poor
> AM> correspondence between file offset and block indices.
>
>
> hmm. I thought delayed allocation should solve this problem. Isn't it?
Absolutely. XFS shouldn't have this problem.
I have patches (against 2.5.7!) which get it all working for ext2
as well.
>>>>> Andrew Morton (AM) writes:
AM> Absolutely. XFS shouldn't have this problem.
AM> I have patches (against 2.5.7!) which get it all working for ext2
AM> as well.
it's really strange that these patches aren't in 2.5 yet
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
[snip]
> kgdb.patch
I'm interested in this patch in your tree. (Just to warn you of my
biases, I'm currently working with the XScale/ARM arch.) I've noticed
some things about it in an initial look, namely:
There appears to be some code duplication between hex() and stubhex() in
arch/i386/kernel/gdbstub.c.
Also, the bulk of gdbstub.c appears to be generic code. There are a
number of functions that have x86 asm in them, but it looks to me on
initial viewing, that most of the logic is applicable to other arches.
Am I understanding that correctly?
Right now it looks like an arch would need to provide a way to:
- reboot the processor
- implement 'continue at address' and 'step one instruction from address'
- handle_exeption()
- printexception()
- correct_hw_break()
- regs_to_gdb_regs() and gdb_regs_to_regs()
Hmm, there's probably some more to that part...
The above is just for the gdbstub.c. I'm still reading the patch. :)
Would breaking the arch-independent parts out to linux/kernel/gdbstub.c
be a reasonable change or is that a dumb question? ;)
Thanks,
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Eli Carter <[email protected]> wrote:
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
> [snip]
> > kgdb.patch
>
> I'm interested in this patch in your tree.
You're brave.
The kgdb patch is pretty nasty-looking code. I've managed to keep it working
for every kernel since 2.4.0-test10 while avoiding actually looking at it.
(I turn the monitor off when the patch needs fixing). Fed it through Lindent
once.
George Anzinger is maintaining another strain of the stub, and that mostly
works OK and has improved features. But the diff is larger and I once had a
couple of problems with it and need to spend more time testing it. It's up
to date though.
> (Just to warn you of my
> biases, I'm currently working with the XScale/ARM arch.) I've noticed
> some things about it in an initial look, namely:
>
> There appears to be some code duplication between hex() and stubhex() in
> arch/i386/kernel/gdbstub.c.
No surprise there.
> Also, the bulk of gdbstub.c appears to be generic code. There are a
> number of functions that have x86 asm in them, but it looks to me on
> initial viewing, that most of the logic is applicable to other arches.
> Am I understanding that correctly?
> Right now it looks like an arch would need to provide a way to:
> - reboot the processor
> - implement 'continue at address' and 'step one instruction from address'
> - handle_exeption()
> - printexception()
> - correct_hw_break()
> - regs_to_gdb_regs() and gdb_regs_to_regs()
> Hmm, there's probably some more to that part...
> The above is just for the gdbstub.c. I'm still reading the patch. :)
>
> Would breaking the arch-independent parts out to linux/kernel/gdbstub.c
> be a reasonable change or is that a dumb question? ;)
That would be a fantastic thing to do. Note that there are already about ten
kgdb stubs in the shipped kernel at present. If you can identify exactly
which functions need to be provided by the architecture, pull that out into
struct kgdb_operations, etc then it would make maintenance and addition of
new support much easier.
We might even end up with something we could submit for inclusion without
first having to set up an [email protected] account.
Andrew Morton wrote:
> Eli Carter <[email protected]> wrote:
>
>>Andrew Morton wrote:
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
>>
>>[snip]
>>
>>>kgdb.patch
>>
>>I'm interested in this patch in your tree.
>
>
> You're brave.
Heh. Insane might be more like it. ;)
> The kgdb patch is pretty nasty-looking code. I've managed to keep it working
> for every kernel since 2.4.0-test10 while avoiding actually looking at it.
> (I turn the monitor off when the patch needs fixing). Fed it through Lindent
> once.
>
> George Anzinger is maintaining another strain of the stub, and that mostly
> works OK and has improved features. But the diff is larger and I once had a
> couple of problems with it and need to spend more time testing it. It's up
> to date though.
If I can feed you changes to kgdb, would you be interested in taking
them? What was the last patch you shipped with George's version? Which
do you think would be the right place to start?
>>Would breaking the arch-independent parts out to linux/kernel/gdbstub.c
>>be a reasonable change or is that a dumb question? ;)
>
>
> That would be a fantastic thing to do. Note that there are already about ten
> kgdb stubs in the shipped kernel at present. If you can identify exactly
> which functions need to be provided by the architecture, pull that out into
> struct kgdb_operations, etc then it would make maintenance and addition of
> new support much easier.
I guess I'll go hunting. :)
> We might even end up with something we could submit for inclusion without
> first having to set up an [email protected] account.
"We"... I like that word. ;) If you can act as 'upstream' for my
changes and answer quick questions, I'll feed you patches. Some testing
of x86 would be wonderful too. (And while I'm at it, can I send you my
Christmas wishlist? ;) ) I have to warn you, I don't know how far I'll
get. But I'll give it a shot. My current concern is getting it working
under ARM, and there is a kgdb patch for 2.4 ARM I can draw from.
I'm thinking I'll try to wind up with 2 or 3 patches, kgdb.patch,
kgdb-arm.patch, and kgdb-ia32.patch. Maybe.
Are you feeling "brave"? 8)
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
Eli Carter <[email protected]> wrote:
>
> If I can feed you changes to kgdb, would you be interested in taking
> them?
Sure.
> What was the last patch you shipped with George's version?
Long time ago. I'll send you the latest.
> Which do you think would be the right place to start?
George's. It enters the debugger way earlier in boot and appears to have
stronger SMP support. Has more features, etc.
> "We"... I like that word. ;) If you can act as 'upstream' for my
> changes and answer quick questions, I'll feed you patches.
Sure. The patches are against base 2.5.x, so your work will be separated
from -mm goings-on.
> I'm thinking I'll try to wind up with 2 or 3 patches, kgdb.patch,
> kgdb-arm.patch, and kgdb-ia32.patch. Maybe.
That sounds appropriate.
Andrew Morton <[email protected]> writes:
> Alexander Hoogerhuis <[email protected]> wrote:
> >
> > I've used tried the -mm-kernels since they've actually made
> > 2.5-kernels usable on my laptop lately (Compaq Evo800c), but
> > 2.5.64-mm2 and onwards doesnt work with X anymore. I run 4.3.0-r1 from
> > the Gentoo unstable "branch".
> >
> > with -mm1 I X coming up just nicely, and now the screen just goes
> > black after trying to start X, and it seems related to DRM.
>
> I have a radeon card here. Just tried it. The X server starts up OK but as
> soon as I run tuxracer, some ioctl down in the radeon driver keeps on timing
> out waiting for the FIFO, spins for ten milliseconds in-kernel and the X
> server immediately calls the ioctl again. The whole thing is bust. I went
> all the way back to 2.5.39, where it is still bust. 2.4.21-pre5 is OK
> though.
>
> So it looks like my breakage is different from yours.
>
> Could you please try just 2.5.64 plus
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/broken-out/linus.patch
>
> That will tell us if it is a -mm bug or a -linus bug.
>
Vanilla 2.5.64 is b0rken, too. Tried it, and went back and tries -mm6
with and without ACPI as well, no difference. So instead of trudging
through that liste of change sets, I'll back out one and one patch
from -mm1 back to plain .64 to see where the thing goes belly
up. Seems reasonable?
mvh,
A
--
Alexander Hoogerhuis | [email protected]
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy