2.5.69-mm1

2.5.69-mm1

[Andrew Morton]

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

Re: 2.5.69-mm1

[Andrei Ivanov]

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 ?

Re: 2.5.69-mm1

[Greg KH]

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

Re: 2.5.69-mm1

[Andrei Ivanov]

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
> 

Re: 2.5.69-mm1

[Andrew Morton]

Andrei Ivanov <andrei.ivanov@ines.ro> 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.

Re: 2.5.69-mm1

[William Lee Irwin III]

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;
 }

Re: 2.5.69-mm1

[Dipankar Sarma]

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

Re: 2.5.69-mm1

[David S. Miller]

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 <davem@redhat.com>

Re: 2.5.69-mm1

[Dipankar Sarma]

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

Re: 2.5.69-mm1

[David S. Miller]

   From: Dipankar Sarma <dipankar@in.ibm.com>
   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.

Re: 2.5.69-mm1

[Dipankar Sarma]

On Tue, May 06, 2003 at 07:20:51AM -0700, David S. Miller wrote:
>    From: Dipankar Sarma <dipankar@in.ibm.com>
>    
>    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

Re: 2.5.69-mm1

[William Lee Irwin III]

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;
 
 	/*

Re: 2.5.69-mm1

[Steven Cole]

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

Re: 2.5.69-mm1

[Andrew Morton]

Steven Cole <elenstev@mesatop.com> 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 ;)

Re: 2.5.69-mm1

[Eric W. Biederman]

Andrew Morton <akpm@digeo.com> writes:

> Steven Cole <elenstev@mesatop.com> 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

Re: 2.5.69-mm1

[Steven Cole]

On Tue, 2003-05-06 at 09:36, Eric W. Biederman wrote:
> Andrew Morton <akpm@digeo.com> writes:
> 
> > Steven Cole <elenstev@mesatop.com> 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