* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
@ 2004-02-26 8:22 ` Alexander Hoogerhuis
2004-02-26 8:48 ` 2.6.3-mm4 Marc-Christian Petersen
2004-02-26 8:51 ` 2.6.3-mm4 Nuno Silva
` (7 subsequent siblings)
8 siblings, 1 reply; 33+ messages in thread
From: Alexander Hoogerhuis @ 2004-02-26 8:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-mm4/
>
> - Big knfsd update. Mainly for nfsv4
>
> - DVB udpate
>
> - Various fixes
>
And a few symbols that are not exported?
WARNING: /lib/modules/2.6.3-mm4/kernel/fs/quota_v2.ko needs unknown symbol mark_info_dirty
WARNING: /lib/modules/2.6.3-mm4/kernel/fs/nfsd/nfsd.ko needs unknown symbol locks_remove_posix
WARNING: /lib/modules/2.6.3-mm4/kernel/net/ipv6/ipv6.ko needs unknown symbol sysctl_optmem_max
mvh,
A
--
Alexander Hoogerhuis | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE | +47 908 21 485
"You have zero privacy anyway. Get over it." --Scott McNealy
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4
2004-02-26 8:22 ` 2.6.3-mm4 Alexander Hoogerhuis
@ 2004-02-26 8:48 ` Marc-Christian Petersen
0 siblings, 0 replies; 33+ messages in thread
From: Marc-Christian Petersen @ 2004-02-26 8:48 UTC (permalink / raw)
To: linux-kernel; +Cc: Alexander Hoogerhuis, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Thursday 26 February 2004 09:22, Alexander Hoogerhuis wrote:
Hi Alex,
> And a few symbols that are not exported?
> WARNING: /lib/modules/2.6.3-mm4/kernel/fs/quota_v2.ko needs unknown symbol
> mark_info_dirty WARNING: /lib/modules/2.6.3-mm4/kernel/fs/nfsd/nfsd.ko
> needs unknown symbol locks_remove_posix WARNING:
> /lib/modules/2.6.3-mm4/kernel/net/ipv6/ipv6.ko needs unknown symbol
> sysctl_optmem_max
Apply attached patch.
ciao, Marc
[-- Attachment #2: 2.6.3-mm4-missing-exports.patch --]
[-- Type: text/x-diff, Size: 899 bytes --]
--- old/fs/locks.c 2004-02-26 01:29:14.000000000 +0100
+++ new/fs/locks.c 2004-02-26 08:27:02.000000000 +0100
@@ -1699,6 +1699,8 @@ void locks_remove_posix(struct file *fil
unlock_kernel();
}
+EXPORT_SYMBOL(locks_remove_posix);
+
/*
* This function is called on the last close of an open file.
*/
--- old/fs/dquot.c 2004-02-26 05:12:21.000000000 +0100
+++ new/fs/dquot.c 2004-02-26 08:28:26.000000000 +0100
@@ -1672,3 +1672,4 @@ EXPORT_SYMBOL(unregister_quota_format);
EXPORT_SYMBOL(dqstats);
EXPORT_SYMBOL(dq_list_lock);
EXPORT_SYMBOL(dq_data_lock);
+EXPORT_SYMBOL(mark_info_dirty);
--- old/net/core/sock.c 2004-02-26 05:12:22.000000000 +0100
+++ new/net/core/sock.c 2004-02-26 08:30:01.000000000 +0100
@@ -1198,4 +1198,5 @@ EXPORT_SYMBOL(sock_wmalloc);
#ifdef CONFIG_SYSCTL
EXPORT_SYMBOL(sysctl_rmem_max);
EXPORT_SYMBOL(sysctl_wmem_max);
+EXPORT_SYMBOL(sysctl_optmem_max);
#endif
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
2004-02-26 8:22 ` 2.6.3-mm4 Alexander Hoogerhuis
@ 2004-02-26 8:51 ` Nuno Silva
2004-02-27 0:48 ` 2.6.3-mm4 Greg KH
2004-02-26 15:50 ` 2.6.3-mm4 David Martínez Moreno
` (6 subsequent siblings)
8 siblings, 1 reply; 33+ messages in thread
From: Nuno Silva @ 2004-02-26 8:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi!
After make modules_install, I got these:
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.6.3-mm4; fi
WARNING: /lib/modules/2.6.3-mm4/kernel/net/ipv6/ipv6.ko needs unknown
symbol sysctl_optmem_max
WARNING: /lib/modules/2.6.3-mm4/kernel/drivers/i2c/busses/i2c-elektor.ko
needs unknown symbol cli
WARNING: /lib/modules/2.6.3-mm4/kernel/drivers/i2c/busses/i2c-elektor.ko
needs unknown symbol sti
WARNING: /lib/modules/2.6.3-mm4/kernel/drivers/net/typhoon.ko needs
unknown symbol direct_csum_partial_copy_generic
Thanks,
Nuno Silva
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4
2004-02-26 8:51 ` 2.6.3-mm4 Nuno Silva
@ 2004-02-27 0:48 ` Greg KH
0 siblings, 0 replies; 33+ messages in thread
From: Greg KH @ 2004-02-27 0:48 UTC (permalink / raw)
To: Nuno Silva; +Cc: Andrew Morton, linux-kernel
On Thu, Feb 26, 2004 at 08:51:13AM +0000, Nuno Silva wrote:
> WARNING: /lib/modules/2.6.3-mm4/kernel/drivers/i2c/busses/i2c-elektor.ko needs unknown symbol cli
> WARNING: /lib/modules/2.6.3-mm4/kernel/drivers/i2c/busses/i2c-elektor.ko needs unknown symbol sti
Known issue. If you enable CONFIG_BROKEN_ON_SMP then you will not see
this problem (as you will not be able to build the driver...)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
2004-02-26 8:22 ` 2.6.3-mm4 Alexander Hoogerhuis
2004-02-26 8:51 ` 2.6.3-mm4 Nuno Silva
@ 2004-02-26 15:50 ` David Martínez Moreno
2004-02-26 15:59 ` 2.6.3-mm4 Christoph Hellwig
2004-02-26 16:30 ` 2.6.3-mm4 (compile stats) John Cherry
` (5 subsequent siblings)
8 siblings, 1 reply; 33+ messages in thread
From: David Martínez Moreno @ 2004-02-26 15:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ender
[-- Attachment #1: clearsigned data --]
[-- Type: Text/Plain, Size: 1363 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Jueves, 26 de Febrero de 2004 03:55, Andrew Morton escribió:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-m
>m4/
>
> - Big knfsd update. Mainly for nfsv4
>
> - DVB udpate
>
> - Various fixes
Hello, Andrew, I jumped from rc1-mm1 to this and found that somebody finally
touched ini9100 driver, but it needs further cleaning. It doesn't compile
properly, and give warnings.
Attached patch fixes compilation of ini9100u driver and cleans several
unneeded definitions. It applies cleanly to 2.6.3-mm4 (I think).
Could you please review, because although simple, I'm scared, I don't really
know if my patch is doing the Right Thing (tm)? Thanks. :-)
Regards,
Ender.
- --
What was that, honey? It was bad. It had no fire, no energy, no nothing.
So tomorrow from 5 to 7 will you PLEASE act like you have more than a
two word vocabulary. It must be green.
-- DJ Ruby Rhod (The Fifth Element).
- --
Servicios de red - Network services
RedIRIS - Spanish Academic Network for Research and Development
Madrid (Spain)
Tlf (+34) 91.585.51.50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAPhW3Ws/EhA1iABsRAoqPAJ4m9/jMcJ9/W54qLwEhKn9uC9AKOACeOJ2u
wy7M+GgPS8dWP2nR0IoeBnw=
=p/NV
-----END PGP SIGNATURE-----
[-- Attachment #2: ini9100u-broken-patch --]
[-- Type: text/x-diff, Size: 1058 bytes --]
--- drivers/scsi/ini9100u.c.orig 2004-02-26 14:12:32.000000000 +0100
+++ drivers/scsi/ini9100u.c 2004-02-26 14:13:27.000000000 +0100
@@ -180,14 +180,7 @@
static char *setup_str = (char *) NULL;
-static irqreturn_t i91u_intr0(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr1(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr2(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr3(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr4(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr5(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr6(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr7(int irq, void *dev_id, struct pt_regs *);
+static struct Scsi_Host *hreg;
static void i91u_panic(char *msg);
@@ -340,7 +333,6 @@
int i91u_detect(Scsi_Host_Template * tpnt)
{
HCS *pHCB;
- struct Scsi_Host *hreg;
unsigned long i; /* 01/14/98 */
int ok = 0, iAdapters;
ULONG dBiosAdr;
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4
2004-02-26 15:50 ` 2.6.3-mm4 David Martínez Moreno
@ 2004-02-26 15:59 ` Christoph Hellwig
0 siblings, 0 replies; 33+ messages in thread
From: Christoph Hellwig @ 2004-02-26 15:59 UTC (permalink / raw)
To: David Martínez Moreno; +Cc: Andrew Morton, linux-kernel
On Thu, Feb 26, 2004 at 04:50:14PM +0100, David Martínez Moreno wrote:
Content-Description: clearsigned data
> Attached patch fixes compilation of ini9100u driver and cleans several
> unneeded definitions. It applies cleanly to 2.6.3-mm4 (I think).
>
> Could you please review, because although simple, I'm scared, I don't really
> know if my patch is doing the Right Thing (tm)? Thanks. :-)
it's not 100% correct as the driver should support multiple HBAs.
Here's a better one:
--- 1.21/drivers/scsi/ini9100u.c Wed Feb 4 06:38:11 2004
+++ edited/drivers/scsi/ini9100u.c Thu Feb 26 17:58:20 2004
@@ -180,15 +180,6 @@
static char *setup_str = (char *) NULL;
-static irqreturn_t i91u_intr0(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr1(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr2(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr3(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr4(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr5(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr6(int irq, void *dev_id, struct pt_regs *);
-static irqreturn_t i91u_intr7(int irq, void *dev_id, struct pt_regs *);
-
static void i91u_panic(char *msg);
static void i91uSCBPost(BYTE * pHcb, BYTE * pScb);
@@ -278,7 +269,7 @@
unsigned long flags;
spin_lock_irqsave(dev->host_lock, flags);
- tul_isr((HCS *)hreg->base);
+ tul_isr((HCS *)dev->base);
spin_unlock_irqrestore(dev->host_lock, flags);
return IRQ_HANDLED;
}
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4 (compile stats)
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (2 preceding siblings ...)
2004-02-26 15:50 ` 2.6.3-mm4 David Martínez Moreno
@ 2004-02-26 16:30 ` John Cherry
2004-02-26 18:59 ` Mike Fedyk
2004-02-26 18:50 ` 2.6.3-mm4 Matthias Hentges
` (4 subsequent siblings)
8 siblings, 1 reply; 33+ messages in thread
From: John Cherry @ 2004-02-26 16:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel@vger.kernel.org
Much better...
Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2)
Warnings/Errors Summary
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
--------------- ---------- -------- -------- -------- -------- --------
2.6.3-mm3 1w/0e 5w/0e 146w/ 0e 7w/0e 3w/0e 142w/0e
2.6.3-mm3 1w/2e 5w/2e 146w/15e 7w/0e 3w/2e 144w/5e
2.6.3-mm2 1w/8e 5w/0e 140w/ 0e 7w/0e 3w/0e 138w/0e
2.6.3-mm1 1w/0e 5w/0e 143w/ 5e 7w/0e 3w/0e 141w/0e
2.6.3-rc3-mm1 1w/0e 0w/0e 144w/13e 7w/0e 3w/0e 142w/3e
2.6.3-rc2-mm1 1w/0e 0w/265e 144w/ 5e 7w/0e 3w/0e 145w/0e
2.6.3-rc1-mm1 1w/0e 0w/265e 141w/ 5e 7w/0e 3w/0e 143w/0e
2.6.2-mm1 2w/0e 0w/264e 147w/ 5e 7w/0e 3w/0e 173w/0e
2.6.2-rc3-mm1 2w/0e 0w/265e 146w/ 5e 7w/0e 3w/0e 172w/0e
2.6.2-rc2-mm2 0w/0e 0w/264e 145w/ 5e 7w/0e 3w/0e 171w/0e
2.6.2-rc2-mm1 0w/0e 0w/264e 146w/ 5e 7w/0e 3w/0e 172w/0e
2.6.2-rc1-mm3 0w/0e 0w/265e 144w/ 8e 7w/0e 3w/0e 169w/0e
2.6.2-rc1-mm2 0w/0e 0w/264e 144w/ 5e 10w/0e 3w/0e 171w/0e
2.6.2-rc1-mm1 0w/0e 0w/264e 144w/ 5e 10w/0e 3w/0e 171w/0e
2.6.1-mm5 2w/5e 0w/264e 153w/11e 10w/0e 3w/0e 180w/0e
2.6.1-mm4 0w/821e 0w/264e 154w/ 5e 8w/1e 5w/0e 179w/0e
2.6.1-mm3 0w/0e 0w/0e 151w/ 5e 10w/0e 3w/0e 177w/0e
2.6.1-mm2 0w/0e 0w/0e 143w/ 5e 12w/0e 3w/0e 171w/0e
2.6.1-mm1 0w/0e 0w/0e 146w/ 9e 12w/0e 6w/0e 171w/0e
2.6.1-rc2-mm1 0w/0e 0w/0e 149w/ 0e 12w/0e 6w/0e 171w/4e
2.6.1-rc1-mm2 0w/0e 0w/0e 157w/15e 12w/0e 3w/0e 185w/4e
2.6.1-rc1-mm1 0w/0e 0w/0e 156w/10e 12w/0e 3w/0e 184w/2e
2.6.0-mm2 0w/0e 0w/0e 161w/ 0e 12w/0e 3w/0e 189w/0e
2.6.0-mm1 0w/0e 0w/0e 173w/ 0e 12w/0e 3w/0e 212w/0e
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
John
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4 (compile stats)
2004-02-26 16:30 ` 2.6.3-mm4 (compile stats) John Cherry
@ 2004-02-26 18:59 ` Mike Fedyk
2004-02-26 19:26 ` John Cherry
0 siblings, 1 reply; 33+ messages in thread
From: Mike Fedyk @ 2004-02-26 18:59 UTC (permalink / raw)
To: John Cherry; +Cc: Andrew Morton, linux-kernel@vger.kernel.org
John Cherry wrote:
> Much better...
>
> Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2)
> Warnings/Errors Summary
>
> Kernel bzImage bzImage bzImage modules bzImage modules
> (defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
> --------------- ---------- -------- -------- -------- -------- --------
> 2.6.3-mm3 1w/0e 5w/0e 146w/ 0e 7w/0e 3w/0e 142w/0e
> 2.6.3-mm3 1w/2e 5w/2e 146w/15e 7w/0e 3w/2e 144w/5e
Yes, much better, especially since it's the same version? ;)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4 (compile stats)
2004-02-26 18:59 ` Mike Fedyk
@ 2004-02-26 19:26 ` John Cherry
0 siblings, 0 replies; 33+ messages in thread
From: John Cherry @ 2004-02-26 19:26 UTC (permalink / raw)
To: Mike Fedyk; +Cc: Andrew Morton, linux-kernel@vger.kernel.org
Sorry about the typo. At least you noticed it! :)
On Thu, 2004-02-26 at 10:59, Mike Fedyk wrote:
> John Cherry wrote:
> > Much better...
> >
> > Linux 2.6 (mm tree) Compile Statistics (gcc 3.2.2)
> > Warnings/Errors Summary
> >
> > Kernel bzImage bzImage bzImage modules bzImage modules
> > (defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
> > --------------- ---------- -------- -------- -------- -------- --------
> > 2.6.3-mm3 1w/0e 5w/0e 146w/ 0e 7w/0e 3w/0e 142w/0e
> > 2.6.3-mm3 1w/2e 5w/2e 146w/15e 7w/0e 3w/2e 144w/5e
>
> Yes, much better, especially since it's the same version? ;)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (3 preceding siblings ...)
2004-02-26 16:30 ` 2.6.3-mm4 (compile stats) John Cherry
@ 2004-02-26 18:50 ` Matthias Hentges
2004-02-26 23:35 ` 2.6.3-mm4, sensors broken Prakash K. Cheemplavam
` (3 subsequent siblings)
8 siblings, 0 replies; 33+ messages in thread
From: Matthias Hentges @ 2004-02-26 18:50 UTC (permalink / raw)
To: LKML
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
Hello!
In -mm4 ACPI suspend to ram (echo -n mem >/sys/power/state) no longer
suspends my centrino laptop. This used to work in -mm3.
It fails to suspend "radeonfb" (which isn't active BTW, fbcon is not
loaded but radeonfb is compiled in).
I have attached a photo of the suspend message.
Please note that on this laptop ACPI always used to suspend the machine.
It just never wakes up :)
And that's the reason i follow the latest -mm patches. I still hope
*some* day suspend/resume will work ;)
Thought i'd share this.
Dateils of the laptop (dmesg, lspci) can be found here:
http://www.hentges.net/howtos/samsung_p30_hwspecs.html
HTH & HAND
--
Matthias Hentges
Cologne / Germany
[www.hentges.net] -> PGP welcome, HTML tolerated
ICQ: 97 26 97 4 -> No files, no URL's
My OS: Debian SID. Geek by Nature, Linux by Choice
[-- Attachment #2: ACPI_small.jpg --]
[-- Type: image/jpeg, Size: 59986 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4, sensors broken
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (4 preceding siblings ...)
2004-02-26 18:50 ` 2.6.3-mm4 Matthias Hentges
@ 2004-02-26 23:35 ` Prakash K. Cheemplavam
2004-02-27 0:03 ` Andrew Morton
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
` (2 subsequent siblings)
8 siblings, 1 reply; 33+ messages in thread
From: Prakash K. Cheemplavam @ 2004-02-26 23:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hi,
this release made my sensors broken. With mm3 it worked nicely.
This is what sensors-detect gives me:
Driver `adm1021' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 5100' (Algorithm unavailable)
Busdriver `i2c-nforce2', I2C address 0x4e
Chip `National Semiconductor LM84' (confidence: 5)
Driver `eeprom' (should be inserted):
Detects correctly:
* Bus `SMBus nForce2 adapter at 5100' (Algorithm unavailable)
Busdriver `i2c-nforce2', I2C address 0x50
Chip `SPD EEPROM' (confidence: 8)
* Bus `SMBus nForce2 adapter at 5100' (Algorithm unavailable)
Busdriver `i2c-nforce2', I2C address 0x52
Chip `SPD EEPROM' (confidence: 8)
Driver `w83781d' (may not be inserted):
Misdetects:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `Winbond W83627HF' (confidence: 8)
Driver `w83627hf' (should be inserted):
Detects correctly:
* ISA bus address 0x0290 (Busdriver `i2c-isa')
Chip `Winbond W83627HF Super IO Sensors' (confidence: 9)
Of course most of the drivers are not in the kernel, but w83781d worked
for me with mm3 and now it does not. gkrellm2 still is able to read out
voltages and fan speeds but no temperatures anymore.
Typing "sensors" just gives me:
w83627hf-isa-0290
Adapter: ISA adapter
ERROR: Can't get IN0 data!
ERROR: Can't get IN1 data!
ERROR: Can't get IN2 data!
ERROR: Can't get IN3 data!
ERROR: Can't get IN4 data!
ERROR: Can't get IN5 data!
ERROR: Can't get IN6 data!
ERROR: Can't get IN7 data!
ERROR: Can't get IN8 data!
ERROR: Can't get FAN1 data!
ERROR: Can't get FAN2 data!
ERROR: Can't get FAN3 data!
ERROR: Can't get TEMP1 data!
ERROR: Can't get TEMP2 data!
ERROR: Can't get TEMP3 data!
ERROR: Can't get VID data!
alarms:
beep_enable:
Sound alarm disabled
:-(
Prakash
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (5 preceding siblings ...)
2004-02-26 23:35 ` 2.6.3-mm4, sensors broken Prakash K. Cheemplavam
@ 2004-02-27 0:11 ` J.A. Magallon
2004-02-27 0:46 ` 2.6.3-mm4 Greg KH
2004-02-27 9:00 ` 2.6.3-mm4 Prakash K. Cheemplavam
2004-02-27 23:51 ` 2.6.3-mm4 Adrian Bunk
2004-03-01 8:25 ` MM VM patches was: 2.6.3-mm4 Mike Fedyk
8 siblings, 2 replies; 33+ messages in thread
From: J.A. Magallon @ 2004-02-27 0:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Andrew Morton
On 02.26, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-mm4/
>
> - Big knfsd update. Mainly for nfsv4
>
> - DVB udpate
>
> - Various fixes
>
As somebody also stated, there are problems with sensors:
werewolf:~# service lm_sensors start
Loading sensors modules:
w83781d-isa-0290: Can't access procfs/sysfs file for writing;
Run as root?
Starting sensord: [ OK ]
I _was_ root. And initscripts are run as root ?
Perhaps this is a more generic problem with sysfs :(.
TIA
--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrake Linux release 10.0 (RC1) for i586
Linux 2.6.3-jam4 (gcc 3.4.0 (Mandrake Linux 10.0 3.4.0-0.2mdk))
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: 2.6.3-mm4
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
@ 2004-02-27 0:46 ` Greg KH
2004-02-27 8:35 ` 2.6.3-mm4 Jean Delvare
2004-02-27 16:48 ` 2.6.3-mm4 Prakash K. Cheemplavam
2004-02-27 9:00 ` 2.6.3-mm4 Prakash K. Cheemplavam
1 sibling, 2 replies; 33+ messages in thread
From: Greg KH @ 2004-02-27 0:46 UTC (permalink / raw)
To: J.A. Magallon, Prakash K. Cheemplavam
Cc: linux-kernel, Andrew Morton, sensors
On Fri, Feb 27, 2004 at 01:11:15AM +0100, J.A. Magallon wrote:
>
> As somebody also stated, there are problems with sensors:
>
On Fri, Feb 27, 2004 at 12:35:52AM +0100, Prakash K. Cheemplavam wrote:
> Hi,
>
> this release made my sensors broken. With mm3 it worked nicely.
Yup, we changed all of the sensors sysfs names :)
Hey, we did warn everyone here on lkml we were going to do this, and no
one complained...
Anyway, I think all you need to do is get the cvs tree of the lmsensors
package. Sensors people, the needed changes are commited into the tree,
right?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 0:46 ` 2.6.3-mm4 Greg KH
@ 2004-02-27 8:35 ` Jean Delvare
2004-02-27 18:16 ` 2.6.3-mm4 Mike Fedyk
2004-02-27 16:48 ` 2.6.3-mm4 Prakash K. Cheemplavam
1 sibling, 1 reply; 33+ messages in thread
From: Jean Delvare @ 2004-02-27 8:35 UTC (permalink / raw)
To: Greg KH
Cc: J.A. Magallon, Prakash K. Cheemplavam, linux-kernel,
Andrew Morton, sensors
Quoting Greg KH <greg@kroah.com>:
> Anyway, I think all you need to do is get the cvs tree of the
> lmsensors package. Sensors people, the needed changes are commited
> into the tree, right?
No. The changes are waiting in my local repository, ready to be applied.
I didn't want to apply them because we were supposed to release
lm_sensors 2.8.5 (for Linux 2.6.3 users) and the sysfs names change
wouldn't belong there.
The libsensors patches are available on my personal server here:
http://jdelvare.net1.nerim.net/sensors/
Apply both patches in order and you'll get a 2.6.3-mm4-compliant
library.
I will apply the libsensors changes to the CVS repository as soon as the
kernel modules changes are accepted into Linus' tree. If we did not
release a new version since there, I'll take a CVS snapshot right
before so that Linux 2.6.3 users have a usable version available (but
my preference strongly goes to releasing 2.8.5 instead).
Thanks for testing.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 8:35 ` 2.6.3-mm4 Jean Delvare
@ 2004-02-27 18:16 ` Mike Fedyk
2004-02-27 19:59 ` 2.6.3-mm4 Jean Delvare
0 siblings, 1 reply; 33+ messages in thread
From: Mike Fedyk @ 2004-02-27 18:16 UTC (permalink / raw)
To: Jean Delvare
Cc: Greg KH, J.A. Magallon, Prakash K. Cheemplavam, linux-kernel,
Andrew Morton, sensors
Jean Delvare wrote:
> Quoting Greg KH <greg@kroah.com>:
>
>
>>Anyway, I think all you need to do is get the cvs tree of the
>>lmsensors package. Sensors people, the needed changes are commited
>>into the tree, right?
>
>
> No. The changes are waiting in my local repository, ready to be applied.
> I didn't want to apply them because we were supposed to release
> lm_sensors 2.8.5 (for Linux 2.6.3 users) and the sysfs names change
> wouldn't belong there.
>
> The libsensors patches are available on my personal server here:
> http://jdelvare.net1.nerim.net/sensors/
> Apply both patches in order and you'll get a 2.6.3-mm4-compliant
> library.
>
> I will apply the libsensors changes to the CVS repository as soon as the
> kernel modules changes are accepted into Linus' tree. If we did not
> release a new version since there, I'll take a CVS snapshot right
> before so that Linux 2.6.3 users have a usable version available (but
> my preference strongly goes to releasing 2.8.5 instead).
You have to be kidding me. Are you saying that with your patches to
libsensors it won't support 2.6.3 style sensor sysfs names?
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 18:16 ` 2.6.3-mm4 Mike Fedyk
@ 2004-02-27 19:59 ` Jean Delvare
2004-02-29 7:51 ` 2.6.3-mm4 Mike Fedyk
0 siblings, 1 reply; 33+ messages in thread
From: Jean Delvare @ 2004-02-27 19:59 UTC (permalink / raw)
To: Mike Fedyk; +Cc: greg, jamagallon, PrakashKC, linux-kernel, akpm, sensors
> You have to be kidding me. Are you saying that with your patches to
> libsensors it won't support 2.6.3 style sensor sysfs names?
Yes I am. This isn't a fundamentally new problem. Each Linux 2.6 has
had its matching libsensors version that was not backward compatible
(with earlier 2.6 kernels; it's still fully compatible with 2.4).
Keeping newer versions of libsensors compatible with all early 2.6
kernel versions would make it incredibly more complex, with no
significant benefit IMHO.
The facts are that the sysfs interface to i2c chips is just stabilizing.
Greg's original naming scheme had many drawbacks (also we can't blame
him for that, since nobody objected before me), as I have been
explaining in a previous post on LKML. Also, many chip drivers did not
comply with it in early 2.6 kernels, and new chip drivers wouldn't fit
in it anyway.
The new interface is required if we want to write a chip-independant
libsensors someday. I estimate that this is worth breaking the
compatibility. The impacted kernels (later 2.5 and earlier 2.6) will
obviously not be used anymore within a short time anyway.
I invite you to read my original post here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107715308608606
I explain the problems of the current interface and my goals with the
new one. If you can think of a better solution to the problem, please
speak up.
Thanks.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 19:59 ` 2.6.3-mm4 Jean Delvare
@ 2004-02-29 7:51 ` Mike Fedyk
2004-02-29 10:11 ` 2.6.3-mm4 Jean Delvare
0 siblings, 1 reply; 33+ messages in thread
From: Mike Fedyk @ 2004-02-29 7:51 UTC (permalink / raw)
To: sensors, linux-kernel; +Cc: greg, jamagallon, PrakashKC, akpm
Jean Delvare wrote:
>>You have to be kidding me. Are you saying that with your patches to
>>libsensors it won't support 2.6.3 style sensor sysfs names?
>
>
> Yes I am. This isn't a fundamentally new problem. Each Linux 2.6 has
> had its matching libsensors version that was not backward compatible
> (with earlier 2.6 kernels; it's still fully compatible with 2.4).
>
> Keeping newer versions of libsensors compatible with all early 2.6
> kernel versions would make it incredibly more complex, with no
> significant benefit IMHO.
>
> The facts are that the sysfs interface to i2c chips is just stabilizing.
> Greg's original naming scheme had many drawbacks (also we can't blame
> him for that, since nobody objected before me), as I have been
> explaining in a previous post on LKML. Also, many chip drivers did not
> comply with it in early 2.6 kernels, and new chip drivers wouldn't fit
> in it anyway.
>
> The new interface is required if we want to write a chip-independant
> libsensors someday. I estimate that this is worth breaking the
> compatibility. The impacted kernels (later 2.5 and earlier 2.6) will
> obviously not be used anymore within a short time anyway.
>
> I invite you to read my original post here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107715308608606
>
> I explain the problems of the current interface and my goals with the
> new one. If you can think of a better solution to the problem, please
> speak up.
Working from the premise that there is a current (old-style with mostly
chip dependent code), libsensors has 2.4 /proc support, and each
specific release supports one of 2.6.[0123]...
I'm glad I'm not the maintainer of libsensors for a distribution. Since
you have effectively pushed the compatibility work to them. Just think
of angry customer complaints about this. :(
Since there is going to be an effective libsensors-new library with chip
independent code, I suggest you put the compat code into the old library.
Mike
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-29 7:51 ` 2.6.3-mm4 Mike Fedyk
@ 2004-02-29 10:11 ` Jean Delvare
0 siblings, 0 replies; 33+ messages in thread
From: Jean Delvare @ 2004-02-29 10:11 UTC (permalink / raw)
To: Mike Fedyk; +Cc: sensors, linux-kernel, greg, jamagallon, PrakashKC, akpm
> Working from the premise that there is a current (old-style with
> mostly chip dependent code), libsensors has 2.4 /proc support, and
> each specific release supports one of 2.6.[0123]...
Correct, that's mostly that.
> I'm glad I'm not the maintainer of libsensors for a distribution.
> Since you have effectively pushed the compatibility work to them.
> Just think of angry customer complaints about this. :(
Again, this is a temporary situation. I'm struggling for a better
future, at the cost of a slightly chaotic present, admittedly.
That said, I think that most packaging systems support that kind of
dependency. Since we clearly advertise the correct combinations of
lm_sensors and Linux kernel, they should be able to handle it quite
nicely (although I admit it has to represent some work for them).
The compatibility problems brought by libsensors are not new. From the
very beginning, each new version of lm_sensors had kernel modules,
libsensors and sensors program that mostly only worked well together. It
wasn't to the point of what we are experiencing today, of course,
because things were mostly (but not always) backward compatible. Still,
supporting each and every new driver or "kind" of chip would require
upgrading to new libsensors and sensors program. This is precisely what
I want to avoid with my proposal.
> Since there is going to be an effective libsensors-new library with
> chip independent code, I suggest you put the compat code into the old
> library.
Note that there is no effective plan for such a library as of today. I
am "simply" defining an interface such that writing such a library will
be possible. I don't think I have the skills to write it at the moment,
but I have no doubt that people will do (I'm in particular thinking to
the gkrellm folks who neved liked the old library and wouldn't use it at
all, at the cost of frequent compatibility issues). That said, if nobody
seems to go on working on it within a reasonable amount of time, it's
likely that I will learn what I need to know to do it myself, since I'm
so interested in seeing it exist.
I do not plan to spend time to provide compatibility with early 2.6
kernels. First, because it would bloat the current libsensors even more.
Second, because I believe that these kernels will stop being used within
a few months or even weeks.
Distributions or individuals running 2.6 kernels these days know pretty
well that things are not fully stabilized yet. Granted, the sensors area
seems to be the more unstable realm of them all at the moment. But I
just don't think that people need to have, say, a 2.6.1 and a 2.6.3
kernel running perfectly on their system. We never had any request in
that direction so far. What they most likely want is to have a 2.4 and a
2.6 kernel working, and we do provide this compatibility.
If you really believe that we have to support all early 2.6 kernel
releases and are able to write a not-too-bloated patch for libsensors
that does this, we'll consider applying it. But it's unlikely that any
of us will want to spend time on such a patch.
Thanks.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 0:46 ` 2.6.3-mm4 Greg KH
2004-02-27 8:35 ` 2.6.3-mm4 Jean Delvare
@ 2004-02-27 16:48 ` Prakash K. Cheemplavam
1 sibling, 0 replies; 33+ messages in thread
From: Prakash K. Cheemplavam @ 2004-02-27 16:48 UTC (permalink / raw)
To: Greg KH; +Cc: J.A. Magallon, linux-kernel, Andrew Morton, sensors
> Yup, we changed all of the sensors sysfs names :)
>
> Hey, we did warn everyone here on lkml we were going to do this, and no
> one complained...
Ok, that explains it. Seems like I have not seen it. :-) (Well, I
started using sensors only since a few days, btw...)
Prakash
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
2004-02-27 0:46 ` 2.6.3-mm4 Greg KH
@ 2004-02-27 9:00 ` Prakash K. Cheemplavam
1 sibling, 0 replies; 33+ messages in thread
From: Prakash K. Cheemplavam @ 2004-02-27 9:00 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel, Andrew Morton
J.A. Magallon wrote:
> On 02.26, Andrew Morton wrote:
>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-mm4/
>>
>>- Big knfsd update. Mainly for nfsv4
>>
>>- DVB udpate
>>
>>- Various fixes
>>
>
>
> As somebody also stated, there are problems with sensors:
>
> werewolf:~# service lm_sensors start
> Loading sensors modules:
> w83781d-isa-0290: Can't access procfs/sysfs file for writing;
> Run as root?
> Starting sensord: [ OK ]
>
> I _was_ root. And initscripts are run as root ?
>
> Perhaps this is a more generic problem with sysfs :(.
Oh, yes I have noticed the same: "sensors -s" complained about some
writeing issue. As I son't know what it is good for, I didn't care.
Backing out bk-i2c.patch, above command works again, and even before
doing that comand my sensors all worked as they should.
Prakash
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (6 preceding siblings ...)
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
@ 2004-02-27 23:51 ` Adrian Bunk
2004-03-01 8:25 ` MM VM patches was: 2.6.3-mm4 Mike Fedyk
8 siblings, 0 replies; 33+ messages in thread
From: Adrian Bunk @ 2004-02-27 23:51 UTC (permalink / raw)
To: Andrew Morton, David Woodhouse; +Cc: linux-kernel
On Wed, Feb 25, 2004 at 06:55:36PM -0800, Andrew Morton wrote:
>...
> All 267 patches:
>...
> sleep_on-needs_lock_kernel.patch
> sleep_on(): check for lock_kernel
>...
FYI:
This gives the following on my computer:
<-- snip -->
Feb 27 22:47:37 r063144 kernel: lp0 off-line
Feb 27 22:47:37 r063144 kernel: Badness in interruptible_sleep_on_timeout at kernel/sched.c:2271
Feb 27 22:47:37 r063144 kernel: Call Trace:
Feb 27 22:47:37 r063144 kernel: [interruptible_sleep_on_timeout+271/288] interruptible_sleep_on_timeout+0x10f/0x120
Feb 27 22:47:37 r063144 kernel: [default_wake_function+0/16] default_wake_function+0x0/0x10
Feb 27 22:47:37 r063144 kernel: [parport_release+160/341] parport_release+0xa0/0x155
Feb 27 22:47:37 r063144 kernel: [printk+285/368] printk+0x11d/0x170
Feb 27 22:47:37 r063144 kernel: [lp_error+61/176] lp_error+0x3d/0xb0
Feb 27 22:47:37 r063144 kernel: [lp_check_status+134/208] lp_check_status+0x86/0xd0
Feb 27 22:47:37 r063144 kernel: [lp_wait_ready+71/128] lp_wait_ready+0x47/0x80
Feb 27 22:47:37 r063144 kernel: [lp_write+292/912] lp_write+0x124/0x390
Feb 27 22:47:37 r063144 kernel: [vfs_write+176/256] vfs_write+0xb0/0x100
Feb 27 22:47:37 r063144 kernel: [sys_write+56/96] sys_write+0x38/0x60
Feb 27 22:47:37 r063144 kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Feb 27 22:47:37 r063144 kernel:
Feb 27 22:47:47 r063144 kernel: Badness in interruptible_sleep_on_timeout at kernel/sched.c:2271
<-- snip -->
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 33+ messages in thread* MM VM patches was: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (7 preceding siblings ...)
2004-02-27 23:51 ` 2.6.3-mm4 Adrian Bunk
@ 2004-03-01 8:25 ` Mike Fedyk
2004-03-01 8:44 ` Nick Piggin
8 siblings, 1 reply; 33+ messages in thread
From: Mike Fedyk @ 2004-03-01 8:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Nick Piggin
Andrew Morton wrote:
> shrink_slab-for-all-zones.patch
> vm: scan slab in response to highmem scanning
>
> zone-balancing-fix.patch
> vmscan: zone balancing fix
On 2.6.3 + [1] + nfsd-lofft.patch running on a 1GB ram file server. I
have noticed two related issues.
First, under 2.6.3 it averages about 90MB[2] anon memory, and 30MB with
the -mm4 vm (the rest is in swap cache). This could balance out on the
normal non-idle week-day load though...
Second the -mm4 vm, there is a lot more swapping[3] going on during the
daily updatedb, and backup runs that are performed on this machine.
I'd have to call this second issue a regression, but I want to run it a
couple more days to see if it gets any better (unless you agree of course).
Mike
[1]
instrument-highmem-page-reclaim.patch
blk_congestion_wait-return-remaining.patch
vmscan-remove-priority.patch
kswapd-throttling-fixes.patch
vm-dont-rotate-active-list.patch
vm-lru-info.patch
vm-shrink-zone.patch
vm-tune-throttle.patch
shrink_slab-for-all-zones.patch
zone-balancing-fix.patch
zone-balancing-batching.patch
[2]
http://www.matchmail.com/stats/lrrd/matchmail.com/fileserver.matchmail.com-memory.html
[3]
http://www.matchmail.com/stats/lrrd/matchmail.com/fileserver.matchmail.com-swap.html
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: MM VM patches was: 2.6.3-mm4
2004-03-01 8:25 ` MM VM patches was: 2.6.3-mm4 Mike Fedyk
@ 2004-03-01 8:44 ` Nick Piggin
2004-03-01 9:05 ` Mike Fedyk
2004-03-01 9:10 ` Nick Piggin
0 siblings, 2 replies; 33+ messages in thread
From: Nick Piggin @ 2004-03-01 8:44 UTC (permalink / raw)
To: Mike Fedyk; +Cc: Andrew Morton, linux-kernel
Mike Fedyk wrote:
> Andrew Morton wrote:
>
>> shrink_slab-for-all-zones.patch
>> vm: scan slab in response to highmem scanning
>>
>> zone-balancing-fix.patch
>> vmscan: zone balancing fix
>
>
> On 2.6.3 + [1] + nfsd-lofft.patch running on a 1GB ram file server.
> I have noticed two related issues.
>
> First, under 2.6.3 it averages about 90MB[2] anon memory, and 30MB
> with the -mm4 vm (the rest is in swap cache). This could balance out
> on the normal non-idle week-day load though...
>
> Second the -mm4 vm, there is a lot more swapping[3] going on during
> the daily updatedb, and backup runs that are performed on this machine.
> I'd have to call this second issue a regression, but I want to run it
> a couple more days to see if it gets any better (unless you agree of
> course).
>
There are a few things backed out now in 2.6.4-rc1-mm1, and quite a
few other changes. I hope we can trouble you to test 2.6.4-rc1-mm1?
Tell me, do you have highmem enabled on this system? If so, swapping
might be explained by the batching patch. With it, a small highmem
zone could possibly place quite a lot more pressure on a large
ZONE_NORMAL.
2.6.4-rc1-mm1 sould do much better here.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: MM VM patches was: 2.6.3-mm4
2004-03-01 8:44 ` Nick Piggin
@ 2004-03-01 9:05 ` Mike Fedyk
2004-03-01 9:27 ` Nick Piggin
2004-03-01 9:10 ` Nick Piggin
1 sibling, 1 reply; 33+ messages in thread
From: Mike Fedyk @ 2004-03-01 9:05 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, linux-kernel
Nick Piggin wrote:
>
>
> Mike Fedyk wrote:
>
>> Andrew Morton wrote:
>>
>>> shrink_slab-for-all-zones.patch
>>> vm: scan slab in response to highmem scanning
>>>
>>> zone-balancing-fix.patch
>>> vmscan: zone balancing fix
>>
>>
>>
>> On 2.6.3 + [1] + nfsd-lofft.patch running on a 1GB ram file server.
>> I have noticed two related issues.
>>
>> First, under 2.6.3 it averages about 90MB[2] anon memory, and 30MB
>> with the -mm4 vm (the rest is in swap cache). This could balance out
>> on the normal non-idle week-day load though...
>>
>> Second the -mm4 vm, there is a lot more swapping[3] going on during
>> the daily updatedb, and backup runs that are performed on this machine.
>> I'd have to call this second issue a regression, but I want to run it
>> a couple more days to see if it gets any better (unless you agree of
>> course).
>>
>
> There are a few things backed out now in 2.6.4-rc1-mm1, and quite a
> few other changes. I hope we can trouble you to test 2.6.4-rc1-mm1?
Yes, I saw that, but since I wasn't using the new code, I chose to keep
it in the "-mm4" thread. :-D
I'll backport it to 2.6.3 if it doesn't patch with "-F3"...
> Tell me, do you have highmem enabled on this system? If so, swapping
Yes, to get that extra 128MB ram. :)
> might be explained by the batching patch. With it, a small highmem
> zone could possibly place quite a lot more pressure on a large
> ZONE_NORMAL.
>
> 2.6.4-rc1-mm1 sould do much better here.
OK, I'll give that one a shot Monday or Tuesday night.
So, I'll merge up 2.6.3 + "vm of rc1-mm1" and tell you guys what I see.
Are the graphs helpful at all?
Mike
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: MM VM patches was: 2.6.3-mm4
2004-03-01 9:05 ` Mike Fedyk
@ 2004-03-01 9:27 ` Nick Piggin
2004-03-01 9:47 ` Mike Fedyk
0 siblings, 1 reply; 33+ messages in thread
From: Nick Piggin @ 2004-03-01 9:27 UTC (permalink / raw)
To: Mike Fedyk; +Cc: Andrew Morton, linux-kernel
Mike Fedyk wrote:
> Nick Piggin wrote:
>
>>
>>
>> There are a few things backed out now in 2.6.4-rc1-mm1, and quite a
>> few other changes. I hope we can trouble you to test 2.6.4-rc1-mm1?
>
>
> Yes, I saw that, but since I wasn't using the new code, I chose to
> keep it in the "-mm4" thread. :-D
>
> I'll backport it to 2.6.3 if it doesn't patch with "-F3"...
>
Actually, see my other post. It is possible you'll have the same
problem.
>> Tell me, do you have highmem enabled on this system? If so, swapping
>
>
> Yes, to get that extra 128MB ram. :)
>
Yeah thats fine. I think this would be the right thing to do,
especially for a file server. It is something that should work.
>> might be explained by the batching patch. With it, a small highmem
>> zone could possibly place quite a lot more pressure on a large
>> ZONE_NORMAL.
>>
>> 2.6.4-rc1-mm1 sould do much better here.
>
>
> OK, I'll give that one a shot Monday or Tuesday night.
>
> So, I'll merge up 2.6.3 + "vm of rc1-mm1" and tell you guys what I see.
>
I'm not so hopeful for you anymore :P
> Are the graphs helpful at all?
>
My eyes! The goggles, they do nothing!
They have a lot of good info but I'm a bit hard pressed working
out what kernel is running where, and it's a bit hard working out
all the shades of blue on my crappy little monitor.
But if they were easier to read I reckon they'd be useful ;)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: MM VM patches was: 2.6.3-mm4
2004-03-01 9:27 ` Nick Piggin
@ 2004-03-01 9:47 ` Mike Fedyk
0 siblings, 0 replies; 33+ messages in thread
From: Mike Fedyk @ 2004-03-01 9:47 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, linux-kernel
Nick Piggin wrote:
>
>
> Mike Fedyk wrote:
>> So, I'll merge up 2.6.3 + "vm of rc1-mm1" and tell you guys what I see.
>>
>
> I'm not so hopeful for you anymore :P
These patches apply with only a few offsets if you apply them like in
the series file, so there's not much work for either of us in applying
these patches (unless I need to test without a dependent patch or
something obvious like that...)
>
>> Are the graphs helpful at all?
>>
>
>
> My eyes! The goggles, they do nothing!
>
Heh.
> They have a lot of good info but I'm a bit hard pressed working
> out what kernel is running where
Suffice it to say, 2.6.3 is the begining of week9, and 2.6.3-lofft-mm4vm
is the end of week9. The graphs weren't meant to keep secondary
information like kernel version...
> and it's a bit hard working out
> all the shades of blue on my crappy little monitor.
Yeah, I see what you mean. The code in the lrrd/munin project controls
what colors come in what order, but I can control what order the info is
output in...
> But if they were easier to read I reckon they'd be useful ;)
I'd like for that to be true especially since I rewrote the memory
plugin for munin to graph as much as was exported to userspace from the
Linux kernel...
Did I miss anything? ;)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: MM VM patches was: 2.6.3-mm4
2004-03-01 8:44 ` Nick Piggin
2004-03-01 9:05 ` Mike Fedyk
@ 2004-03-01 9:10 ` Nick Piggin
2004-03-01 9:52 ` [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4) Nick Piggin
1 sibling, 1 reply; 33+ messages in thread
From: Nick Piggin @ 2004-03-01 9:10 UTC (permalink / raw)
To: Nick Piggin; +Cc: Mike Fedyk, Andrew Morton, linux-kernel
Nick Piggin wrote:
>
> There are a few things backed out now in 2.6.4-rc1-mm1, and quite a
> few other changes. I hope we can trouble you to test 2.6.4-rc1-mm1?
>
> Tell me, do you have highmem enabled on this system? If so, swapping
> might be explained by the batching patch. With it, a small highmem
> zone could possibly place quite a lot more pressure on a large
> ZONE_NORMAL.
>
> 2.6.4-rc1-mm1 sould do much better here.
Gah no. It would have the same problem actually, if that is indeed
what is happening.
It will take a bit more work to solve this in rc1-mm1. You would
probably want to explicitly use incremental min limits for kswapd.
(background info in kswapd-avoid-higher-zones.patch)
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4)
2004-03-01 9:10 ` Nick Piggin
@ 2004-03-01 9:52 ` Nick Piggin
2004-03-01 10:18 ` Andrew Morton
0 siblings, 1 reply; 33+ messages in thread
From: Nick Piggin @ 2004-03-01 9:52 UTC (permalink / raw)
To: Mike Fedyk, Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
Nick Piggin wrote:
>
>
> Nick Piggin wrote:
>
>>
>> There are a few things backed out now in 2.6.4-rc1-mm1, and quite a
>> few other changes. I hope we can trouble you to test 2.6.4-rc1-mm1?
>>
>> Tell me, do you have highmem enabled on this system? If so, swapping
>> might be explained by the batching patch. With it, a small highmem
>> zone could possibly place quite a lot more pressure on a large
>> ZONE_NORMAL.
>>
>> 2.6.4-rc1-mm1 sould do much better here.
>
>
>
> Gah no. It would have the same problem actually, if that is indeed
> what is happening.
>
> It will take a bit more work to solve this in rc1-mm1. You would
> probably want to explicitly use incremental min limits for kswapd.
>
> (background info in kswapd-avoid-higher-zones.patch)
>
>
Mike, it would be interesting if you could try out the 2.6.4-rc1-mm1
VM patches before and after this little beauty.
Andrew, I think you had kswapd scanning in the direction opposite the
one indicated by your comments. Or maybe I've just confused myself?
[-- Attachment #2: vm-kswapd-incremental-min.patch --]
[-- Type: text/plain, Size: 2585 bytes --]
linux-2.6-npiggin/mm/vmscan.c | 36 ++++++++++++++++++++++++------------
1 files changed, 24 insertions(+), 12 deletions(-)
diff -puN mm/vmscan.c~vm-kswapd-incremental-min mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-kswapd-incremental-min 2004-03-01 20:29:18.000000000 +1100
+++ linux-2.6-npiggin/mm/vmscan.c 2004-03-01 20:44:26.000000000 +1100
@@ -889,6 +889,8 @@ out:
return ret;
}
+extern int sysctl_lower_zone_protection;
+
/*
* For kswapd, balance_pgdat() will work across all this node's zones until
* they are all at pages_high.
@@ -907,12 +909,9 @@ out:
* dead and from now on, only perform a short scan. Basically we're polling
* the zone for when the problem goes away.
*
- * kswapd scans the zones in the highmem->normal->dma direction. It skips
- * zones which have free_pages > pages_high, but once a zone is found to have
- * free_pages <= pages_high, we scan that zone and the lower zones regardless
- * of the number of free pages in the lower zones. This interoperates with
- * the page allocator fallback scheme to ensure that aging of pages is balanced
- * across the zones.
+ * balance_pgdat tries to coexist with the INFAMOUS "incremental min" by
+ * trying to free lower zones a bit harder if higher zones are low too.
+ * See mm/page_alloc.c
*/
static int balance_pgdat(pg_data_t *pgdat, int nr_pages, struct page_state *ps)
{
@@ -930,24 +929,37 @@ static int balance_pgdat(pg_data_t *pgda
}
for (priority = DEF_PRIORITY; priority; priority--) {
+ unsigned long min;
int all_zones_ok = 1;
int pages_scanned = 0;
+ min = 0; /* Shut up gcc */
- for (i = pgdat->nr_zones - 1; i >= 0; i--) {
+ for (i = 0; i < pgdat->nr_zones; i++) {
struct zone *zone = pgdat->node_zones + i;
int total_scanned = 0;
int max_scan;
int reclaimed;
- if (zone->all_unreclaimable && priority != DEF_PRIORITY)
- continue;
-
if (nr_pages == 0) { /* Not software suspend */
- if (zone->free_pages <= zone->pages_high)
- all_zones_ok = 0;
+ /* "incremental min" right here */
if (all_zones_ok)
+ min = zone->pages_high;
+ else
+ min += zone->pages_high;
+
+ if (zone->free_pages <= min)
+ all_zones_ok = 0;
+ else
continue;
+
+ min += zone->pages_high *
+ sysctl_lower_zone_protection;
}
+
+ /* Note: this is checked *after* min is incremented */
+ if (zone->all_unreclaimable && priority != DEF_PRIORITY)
+ continue;
+
zone->temp_priority = priority;
max_scan = zone->nr_inactive >> priority;
reclaimed = shrink_zone(zone, max_scan, GFP_KERNEL,
_
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4)
2004-03-01 9:52 ` [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4) Nick Piggin
@ 2004-03-01 10:18 ` Andrew Morton
2004-03-01 10:29 ` Nick Piggin
0 siblings, 1 reply; 33+ messages in thread
From: Andrew Morton @ 2004-03-01 10:18 UTC (permalink / raw)
To: Nick Piggin; +Cc: mfedyk, linux-kernel
Nick Piggin <piggin@cyberone.com.au> wrote:
>
> Andrew, I think you had kswapd scanning in the direction opposite the
> one indicated by your comments. Or maybe I've just confused myself?
>
Nope, the node_zones[] array is indexed by
#define ZONE_DMA 0
#define ZONE_NORMAL 1
#define ZONE_HIGHMEM 2
Whereas the zonelist.zones[] array goes the other way:
[[[highmem,]normal,]dma,]NULL.
It's a complete dog's breakfast that stuff. Hard to understand, not very
logical and insufficiently commented.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [PATCH] 2.6.4-rc1-mm1: vm-kswapd-incremental-min (was Re: MM VM patches was: 2.6.3-mm4)
2004-03-01 10:18 ` Andrew Morton
@ 2004-03-01 10:29 ` Nick Piggin
0 siblings, 0 replies; 33+ messages in thread
From: Nick Piggin @ 2004-03-01 10:29 UTC (permalink / raw)
To: mfedyk; +Cc: Andrew Morton, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
Andrew Morton wrote:
>Nick Piggin <piggin@cyberone.com.au> wrote:
>
>>Andrew, I think you had kswapd scanning in the direction opposite the
>> one indicated by your comments. Or maybe I've just confused myself?
>>
>>
>
>Nope, the node_zones[] array is indexed by
>
>
OK. Mike, could you try this patch instead after testing rc1-mm1.
Thanks.
[-- Attachment #2: vm-kswapd-incremental-min.patch --]
[-- Type: text/plain, Size: 2575 bytes --]
linux-2.6-npiggin/mm/vmscan.c | 34 +++++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 11 deletions(-)
diff -puN mm/vmscan.c~vm-kswapd-incremental-min mm/vmscan.c
--- linux-2.6/mm/vmscan.c~vm-kswapd-incremental-min 2004-03-01 20:29:18.000000000 +1100
+++ linux-2.6-npiggin/mm/vmscan.c 2004-03-01 21:27:24.000000000 +1100
@@ -889,6 +889,8 @@ out:
return ret;
}
+extern int sysctl_lower_zone_protection;
+
/*
* For kswapd, balance_pgdat() will work across all this node's zones until
* they are all at pages_high.
@@ -907,12 +909,9 @@ out:
* dead and from now on, only perform a short scan. Basically we're polling
* the zone for when the problem goes away.
*
- * kswapd scans the zones in the highmem->normal->dma direction. It skips
- * zones which have free_pages > pages_high, but once a zone is found to have
- * free_pages <= pages_high, we scan that zone and the lower zones regardless
- * of the number of free pages in the lower zones. This interoperates with
- * the page allocator fallback scheme to ensure that aging of pages is balanced
- * across the zones.
+ * balance_pgdat tries to coexist with the INFAMOUS "incremental min" by
+ * trying to free lower zones a bit harder if higher zones are low too.
+ * See mm/page_alloc.c
*/
static int balance_pgdat(pg_data_t *pgdat, int nr_pages, struct page_state *ps)
{
@@ -930,8 +929,10 @@ static int balance_pgdat(pg_data_t *pgda
}
for (priority = DEF_PRIORITY; priority; priority--) {
+ unsigned long min;
int all_zones_ok = 1;
int pages_scanned = 0;
+ min = 0; /* Shut up gcc */
for (i = pgdat->nr_zones - 1; i >= 0; i--) {
struct zone *zone = pgdat->node_zones + i;
@@ -939,15 +940,26 @@ static int balance_pgdat(pg_data_t *pgda
int max_scan;
int reclaimed;
- if (zone->all_unreclaimable && priority != DEF_PRIORITY)
- continue;
-
if (nr_pages == 0) { /* Not software suspend */
- if (zone->free_pages <= zone->pages_high)
- all_zones_ok = 0;
+ /* "incremental min" right here */
if (all_zones_ok)
+ min = zone->pages_high;
+ else
+ min += zone->pages_high;
+
+ if (zone->free_pages <= min)
+ all_zones_ok = 0;
+ else
continue;
+
+ min += zone->pages_high *
+ sysctl_lower_zone_protection;
}
+
+ /* Note: this is checked *after* min is incremented */
+ if (zone->all_unreclaimable && priority != DEF_PRIORITY)
+ continue;
+
zone->temp_priority = priority;
max_scan = zone->nr_inactive >> priority;
reclaimed = shrink_zone(zone, max_scan, GFP_KERNEL,
_
^ permalink raw reply [flat|nested] 33+ messages in thread
![[-- Attachment #2: ACPI_small.jpg --] [-- Type: image/jpeg, Size: 59986 bytes --]](../../1077821445.976.7.camel@mhcln03/2-ACPI_small.jpg){kind=link}