ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm1/
Various random fixups, cleanps and speedups. Mainly a resync to 2.5.69.
Changes since 2.5.68-mm4:
-compat-ioctl-fix.patch
Merged
+generic-subarch-numaq-fix.patch
Compile fix for the generic subarch patch
+3c59x-irq-fix.patch
Fix IRQ strangeness with old-style 3com cards
-semop-race-fix.patch
+semop-race-fix-2.patch
Updated patch from Mingming
+nfs-writeback-tweak.patch
NFS writeout stability
+sysrq-fs-cleanups.patch
+sysrq-fs-cleanups-fixes.patch
Clean up crufty sysrq handling code
+UPDATE_ATIME-update_atime.patch
Remove UPDATE_ATIME()
+irqreturn-pcmcia_cs.patch
Teach pcmcia_cs about new IRQ API
+printscreen-fix.patch
Fix up ALT-sysrq keystroke decoding
+disk_name-no-devfs.patch
Don't use devfs-style names in disk_name() if devfs is enabled.
+nobody-listens-to-wli.patch
set_pgd() fixups
-slab_store_user-large-objects.patch
+slab-debugging-improvement.patch
Enhancements to slab debugging infrastructure
+fget-speedup.patch
+fget-speedup-inline-fput_light.patch
Speed up fastpaths in filesystem syscalls
+devfs-01-api-change.patch
Internal devfs API rationalisation
All 110 patches
mm.patch
add -mmN to EXTRAVERSION
generic-subarch.patch
generic subarchitecture for ia32
generic-subarch-fix.patch
generic subarch: SMP only
generic-subarch-missing-bit.patch
generic subarch: missing chunk
generic-subarch-numaq-fix.patch
generic subarch: NUMAQ fix
ipmi-warning-fixes.patch
irqreturn-uml.patch
UML updates for the new IRQ API
irqreturn-aic79xx.patch
Fix aic79xx for new IRQ API
kgdb-ga.patch
kgdb stub for ia32 (George Anzinger's one)
kgdb-ga-ppc64-fix.patch
irqreturn-kgdb-ga.patch
irqreturn-drivers-net.patch
kgdb-ga-smp_num_cpus.patch
kgdb-ga-discontigmem-fixup.patch
kgdb: discontigmem fixup
slab-magazine-layer.patch
magazine layer for slab
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-scruffiness.patch
Fix some PPC64 compile warnings
ppc64-update.patch
ppc64 update
ppc64-update-fixes.patch
ppc64-irqfixes.patch
ppc64-pci-bogons.patch
sym-do-160.patch
make the SYM driver do 160 MB/sec
misc.patch
misc fixes
config-PAGE_OFFSET.patch
Configurable kenrel/user memory split
config-PAGE_OFFSET-025G.patch
3.75G config option
fat-speedup.patch
fat cluster search speedup
buffer-debug.patch
buffer.c debugging
ext3-truncate-ordered-pages.patch
ext3: explicitly free truncated pages
3c59x-irq-fix.patch
VM_RESERVED-check.patch
VM_RESERVED check
semop-race-fix-2.patch
semop race fix #2
nfs-writeback-tweak.patch
Tweak to NFS memory management for writes...
sysrq-fs-cleanups.patch
sysrq-S, sysrq-U cleanups
sysrq-fs-cleanups-fixes.patch
UPDATE_ATIME-update_atime.patch
s/UPDATE_ATIME/update_atime/ cleanup
irqreturn-pcmcia_cs.patch
irqreturn_t for drivers/net/pcmcia
printscreen-fix.patch
keyboard.c Fix CONFIG_MAGIC_SYSRQ+PrintScreen
reiserfs_file_write-5.patch
disk_name-no-devfs.patch
Don't use devfs names in disk_name()
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
dcache_lock-vs-tasklist_lock-take-2.patch
Fix dcache_lock/tasklist_lock ranking bug
clone-retval-fix.patch
copy_process return value fix
de_thread-fix.patch
de_thread memory corruption fix
list_del-debug.patch
list_del debug check
airo-schedule-fix.patch
airo.c: don't sleep in atomic regions
386-access_ok-race-fix.patch
access_ok() race fix for 80386.
synaptics-mouse-support.patch
Add Synaptics touchpad tweaking to psmouse driver
swapfile-hold-i_sem.patch
hold i_sem on swapfiles
dont-set-kernel-pgd-on-PAE.patch
remove unnecessary PAE pgd set
nobody-listens-to-wli.patch
set_pgd() update
shrink_slab-accounting.patch
account for slab reclaim in try_to_free_pages()
slab-debugging-improvement.patch
slab: additional debug checks
rq-dyn-works.patch
rq-dyn, dynamic request allocation
kblockd.patch
Create `kblockd' workqueue
cfq-infrastructure.patch
elevator-completion-api.patch
elevator completion API
as-iosched.patch
anticipatory I/O scheduler
as-use-completion.patch
AS use completion notifier
as-remove-debug-checks.patch
AS: remove debug checks
as-iosched-dyn.patch
AS: update to dynamic request allocation API
unplug-use-kblockd.patch
Use kblockd for running request queues
cfq-2.patch
CFQ scheduler, #2
cfq-iosched-dyn.patch
CFQ: update to rq-dyn API
unmap-page-debugging.patch
unmap unused pages for debugging
fremap-all-mappings.patch
Make all executable mappings be nonlinear
fget-speedup.patch
reduced overheads in fget/fput
fget-speedup-inline-fput_light.patch
inline fput_light()
devfs-01-api-change.patch
devfs: API changes
sched-2.5.68-B2.patch
HT scheduler, sched-2.5.68-B2
sched_idle-typo-fix.patch
fix sched_idle typo
kgdb-ga-idle-fix.patch
sched-2.5.64-D3.patch
sched-2.5.64-D3, more interactivity changes
show_task-free-stack-fix.patch
show_task() fix and cleanup
htree-nfs-fix.patch
Fix ext3 htree / NFS compatibility problems
i8042-share-irqs.patch
allow i8042 interrupt sharing
select-speedup.patch
Subject: Re: IA64 changes to fs/select.c
select-speedup-fix.patch
select() sleedup fix
htree-nfs-fix-2.patch
htree nfs fix
htree-leak-fix.patch
ext3: htree memory leak fix
put_task_struct-debug.patch
ia32-mknod64.patch
mknod64 for ia32
ext2-64-bit-special-inodes.patch
ext2: support for 64-bit device nodes
ext3-64-bit-special-inodes.patch
ext3: support for 64-bit device nodes
64-bit-dev_t-kdev_t.patch
64-bit dev_t and kdev_t
oops-dump-preceding-code.patch
i386 oops output: dump preceding code
lockmeter.patch
security_d_instantiate-movement.patch
Move security_d_instantiate hook calls
ext3-security-xattr.patch
ext3 xattr handler for security modules
ext2-security-xattr.patch
ext2 xattr handler for security modules
ext3-no-bkl.patch
journal_dirty_metadata-speedup.patch
journal_get_write_access-speedup.patch
ext3-concurrent-block-inode-allocation.patch
Subject: [PATCH] concurrent block/inode allocation for EXT3
ext3-orlov-approx-counter-fix.patch
Fix orlov allocator boundary case
ext3-concurrent-block-allocation-fix-1.patch
ext3-concurrent-block-allocation-hashed.patch
Subject: Re: [PATCH] concurrent block/inode allocation for EXT3
pcmcia-deadlock-fix-2.patch
Fix PCMCIA deadlock (rev. 2)
pcmcia-fix.patch
kexec.patch
kexec
The usb mouse still doesn't work... :(
Is there anything else I should try ?
And... about the "Trying to free free IRQ12" messages and
12: 1 XT-PIC acpi, i8042, i8042, i8042, i8042
should I worry ?
On Mon, May 05, 2003 at 06:32:36PM +0300, Andrei Ivanov wrote:
>
> The usb mouse still doesn't work... :(
> Is there anything else I should try ?
Yes, does 2.5.69 (no -mm) work ok?
And what are the usb messages from the kernel log when you plug your USB
mouse in?
thanks,
greg k-h
Andrei Ivanov <[email protected]> wrote:
>
> And... about the "Trying to free free IRQ12" messages and
>
> 12: 1 XT-PIC acpi, i8042, i8042, i8042, i8042
>
> should I worry ?
That's probably due to the "let i8042 share IRQs" patch. It seems to be
harmless, but I need to look into it.
On Sun, May 04, 2003 at 11:16:50PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm1/
> Various random fixups, cleanps and speedups. Mainly a resync to 2.5.69.
kernel/sched.c: In function `rebalance_tick':
kernel/sched.c:1352: warning: declaration of `this_cpu' shadows a parameter
diff -urpN mm1-2.5.69-1/kernel/sched.c mm1-2.5.69-2/kernel/sched.c
--- mm1-2.5.69-1/kernel/sched.c 2003-05-05 13:32:44.000000000 -0700
+++ mm1-2.5.69-2/kernel/sched.c 2003-05-05 13:37:28.000000000 -0700
@@ -1348,9 +1348,6 @@ static void balance_node(runqueue_t *thi
static void rebalance_tick(runqueue_t *this_rq, int this_cpu, int idle)
{
-#ifdef CONFIG_NUMA
- int this_cpu = smp_processor_id();
-#endif
unsigned long j = jiffies;
/*
On Sun, May 04, 2003 at 11:16:50PM -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm1/
> Various random fixups, cleanps and speedups. Mainly a resync to 2.5.69.
fs/file_table.c: In function `fget_light':
fs/file_table.c:209: warning: passing arg 1 of `_raw_read_lock' from incompatible pointer type
diff -urpN mm1-2.5.69-1/fs/file_table.c mm1-2.5.69-2/fs/file_table.c
--- mm1-2.5.69-1/fs/file_table.c 2003-05-05 13:32:43.000000000 -0700
+++ mm1-2.5.69-2/fs/file_table.c 2003-05-05 13:38:39.000000000 -0700
@@ -206,13 +206,13 @@ struct file *fget_light(unsigned int fd,
if (likely((atomic_read(&files->count) == 1))) {
file = fcheck(fd);
} else {
- read_lock(&files->file_lock);
+ spin_lock(&files->file_lock);
file = fcheck(fd);
if (file) {
get_file(file);
*fput_needed = 1;
}
- read_unlock(&files->file_lock);
+ spin_unlock(&files->file_lock);
}
return file;
}
I've tried plain 2.5.69 and -mm1, with all the combinations of acpi
and local apic (enabled and disabled), and it still doesn't work. The only
thing that works is to unplug and to plug in the mouse after start-up.
relevant boot messages:
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface
driver v2.0uhci-hcd 00:07.2: VIA Technologies, In USB
uhci-hcd 00:07.2: irq 11, io base 0000d400
uhci-hcd 00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:0: USB hub found
hub 1-0:0: 2 ports detected
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x301
hub 1-0:0: new USB device on port 2, assigned address 2
usb 1-2: USB device not accepting new address=2 (error=-110)
hub 1-0:0: new USB device on port 2, assigned address 3
usb 1-2: USB device not accepting new address=3 (error=-110)
after re-pluging the mouse:
hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x301
hub 1-0:0: new USB device on port 2, assigned address 4
input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with
IntelliEye(TM)] on usb-00:07.2-2
On Mon, 5 May 2003, Greg KH wrote:
> On Mon, May 05, 2003 at 06:32:36PM +0300, Andrei Ivanov wrote:
> >
> > The usb mouse still doesn't work... :(
> > Is there anything else I should try ?
>
> Yes, does 2.5.69 (no -mm) work ok?
> And what are the usb messages from the kernel log when you plug your USB
> mouse in?
>
> thanks,
>
> greg k-h
>
On Mon, May 05, 2003 at 09:09:34PM +0000, William Lee Irwin III wrote:
> On Sun, May 04, 2003 at 11:16:50PM -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm1/
> > Various random fixups, cleanps and speedups. Mainly a resync to 2.5.69.
>
> fs/file_table.c: In function `fget_light':
> fs/file_table.c:209: warning: passing arg 1 of `_raw_read_lock' from incompatible pointer type
I should have merged with 2.5.69 before mailing my fget-speedup patch out.
->file_lock has been changed to a spin_lock somewhere after 2.5.66.
That brings me to the point - with the fget-speedup patch, we should
probably change ->file_lock back to an rwlock again. We now take this
lock only when fd table is shared and under such situation the rwlock
should help. Andrew, it that ok ?
Thanks
Dipankar
On Tue, 2003-05-06 at 04:09, Dipankar Sarma wrote:
> That brings me to the point - with the fget-speedup patch, we should
> probably change ->file_lock back to an rwlock again. We now take this
> lock only when fd table is shared and under such situation the rwlock
> should help. Andrew, it that ok ?
rwlocks believe it or not tend not to be superior over spinlocks,
they actually promote cache line thrashing in the case they
are actually being effective (>1 parallel reader)
--
David S. Miller <[email protected]>
On Mon, 2003-05-05 at 00:16, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm1/
>
> Various random fixups, cleanps and speedups. Mainly a resync to 2.5.69.
>
I have one machine for testing which is running X, and a kexec reboot
glitches the video system when initiated from runlevel 5. Kexec works fine
from runlevel 3.
I was not able to test this until now, due to the "crash on leaving X"
bug which has been fixed in 2.5.69.
The symptoms are a blank screen for the 35 seconds that it takes this
box to do a kexec boot following do-kexec.sh /boot/vmlinuz-2.5.69-mm1
Then, if I had "id:3:initdefault:" in /etc/inittab, I just get a blank screen
at the console, but I can ssh into the box since it does come up fine otherwise.
If I had runlevel 5 instead in the above, then X starts OK (after a blank screen
startup) and all is well.
[steven@spc1 steven]$ /sbin/lspci
00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory Controller Hub] (rev 03)
00:01.0 VGA compatible controller: Intel Corp. 82810E DC-133 CGC [Chipset Graphics Controller] (rev 03)
00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02)
00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02)
00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02)
01:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
snippet from dmesg:
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel i810 E Chipset.
agpgart: Maximum main memory to use for agp memory: 202M
agpgart: detected 4MB dedicated video ram.
agpgart: AGP aperture is 64M @ 0xf8000000
[drm] Initialized i810 1.2.1 20020211 on minor 0
Steven
From: Dipankar Sarma <[email protected]>
Date: Tue, 6 May 2003 20:55:55 +0530
On Tue, May 06, 2003 at 05:02:22AM -0700, David S. Miller wrote:
> rwlocks believe it or not tend not to be superior over spinlocks,
> they actually promote cache line thrashing in the case they
> are actually being effective (>1 parallel reader)
Provided there isn't a very heavy contention among readers for the
spin_lock.
Even if there are thousands of readers trying to get the lock
at the same time, unless your hold time is significant these
readers will merely thrash the cache getting the rwlock_t.
And then thrash it again to release the rwlock_t.
This is especially true if the spinlock lives in the same cache
lines as the data it protects.
All of this is magnified on NUMA.
On Tue, May 06, 2003 at 05:02:22AM -0700, David S. Miller wrote:
> On Tue, 2003-05-06 at 04:09, Dipankar Sarma wrote:
> > That brings me to the point - with the fget-speedup patch, we should
> > probably change ->file_lock back to an rwlock again. We now take this
> > lock only when fd table is shared and under such situation the rwlock
> > should help. Andrew, it that ok ?
>
> rwlocks believe it or not tend not to be superior over spinlocks,
> they actually promote cache line thrashing in the case they
> are actually being effective (>1 parallel reader)
Provided there isn't a very heavy contention among readers for the spin_lock.
There is no evidence that this happens with ->file_lock as
spin_lock, so I guess we are ok for now. We should probably watch out
for some multi-threaded programs (Java->posix-threads ?) on
large smp boxes though.
Thanks
Dipankar
Steven Cole <[email protected]> wrote:
>
> I have one machine for testing which is running X, and a kexec reboot
> glitches the video system when initiated from runlevel 5. Kexec works fine
> from runlevel 3.
Yes, there are a lot of driver issues with kexec. Device drivers will assume
that the hardware is in the state which the BIOS left behind.
In this case, the Linus device driver's shutdown functions are obviously not
leaving the card in a pristine state. A lot of drivers _do_ do this
correctly. But some don't.
It seems that kexec is really supposed to be invoked from run level 1. ie:
you run all your system's shutdown scripts before switching. If you'd done
that then you wouldn't have been running X and all would be well.
do-kexec.sh is for the very impatient ;)
Andrew Morton <[email protected]> writes:
> Steven Cole <[email protected]> wrote:
> >
> > I have one machine for testing which is running X, and a kexec reboot
> > glitches the video system when initiated from runlevel 5. Kexec works fine
> > from runlevel 3.
>
> Yes, there are a lot of driver issues with kexec. Device drivers will assume
> that the hardware is in the state which the BIOS left behind.
>
> In this case, the Linus device driver's shutdown functions are obviously not
> leaving the card in a pristine state. A lot of drivers _do_ do this
> correctly. But some don't.
>
> It seems that kexec is really supposed to be invoked from run level 1. ie:
> you run all your system's shutdown scripts before switching. If you'd done
> that then you wouldn't have been running X and all would be well.
>
> do-kexec.sh is for the very impatient ;)
The biggest issue with kexec when you are in X is that nothing
tells X to shutdown. So you have to at least shutdown X manually.
Eric
On Tue, May 06, 2003 at 07:20:51AM -0700, David S. Miller wrote:
> From: Dipankar Sarma <[email protected]>
>
> Provided there isn't a very heavy contention among readers for the
> spin_lock.
>
> Even if there are thousands of readers trying to get the lock
> at the same time, unless your hold time is significant these
> readers will merely thrash the cache getting the rwlock_t.
> And then thrash it again to release the rwlock_t.
And now ISTR that this is indeed the case, atleast going by
what we saw with "chat" microbenchmarks (fwiw :)).
Hold times weren't very high and most of the performance penalty
came from bouncing of the rwlock cacheline, which prompted us to
write a RCU-based patch for lockfree lookup from fd table.
Thanks
Dipankar
On Tue, 2003-05-06 at 09:36, Eric W. Biederman wrote:
> Andrew Morton <[email protected]> writes:
>
> > Steven Cole <[email protected]> wrote:
> > >
> > > I have one machine for testing which is running X, and a kexec reboot
> > > glitches the video system when initiated from runlevel 5. Kexec works fine
> > > from runlevel 3.
> >
> > Yes, there are a lot of driver issues with kexec. Device drivers will assume
> > that the hardware is in the state which the BIOS left behind.
> >
> > In this case, the Linus device driver's shutdown functions are obviously not
> > leaving the card in a pristine state. A lot of drivers _do_ do this
> > correctly. But some don't.
> >
> > It seems that kexec is really supposed to be invoked from run level 1. ie:
> > you run all your system's shutdown scripts before switching. If you'd done
> > that then you wouldn't have been running X and all would be well.
> >
> > do-kexec.sh is for the very impatient ;)
>
> The biggest issue with kexec when you are in X is that nothing
> tells X to shutdown. So you have to at least shutdown X manually.
>
> Eric
Thanks for the answers. Kexec is pretty cool as it stands. I hope
Linus merges it soon.
Steven "very impatient" Cole