* 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
` (5 subsequent siblings)
6 siblings, 1 reply; 26+ 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] 26+ 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; 26+ 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] 26+ 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
` (4 subsequent siblings)
6 siblings, 1 reply; 26+ 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] 26+ 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; 26+ 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] 26+ 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 18:50 ` 2.6.3-mm4 Matthias Hentges
` (3 subsequent siblings)
6 siblings, 1 reply; 26+ 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] 26+ 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; 26+ 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] 26+ messages in thread
* Re: 2.6.3-mm4
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 18:50 ` Matthias Hentges
2004-02-26 23:35 ` 2.6.3-mm4, sensors broken Prakash K. Cheemplavam
` (2 subsequent siblings)
6 siblings, 0 replies; 26+ 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] 26+ messages in thread* Re: 2.6.3-mm4, sensors broken
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (3 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:11 ` 2.6.3-mm4 J.A. Magallon
2004-02-27 23:51 ` 2.6.3-mm4 Adrian Bunk
6 siblings, 0 replies; 26+ 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] 26+ messages in thread* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (4 preceding siblings ...)
2004-02-26 23:35 ` 2.6.3-mm4, sensors broken Prakash K. Cheemplavam
@ 2004-02-27 0:11 ` J.A. Magallon
2005-05-19 6:24 ` 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
6 siblings, 2 replies; 26+ 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] 26+ messages in thread* Re: 2.6.3-mm4
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
@ 2005-05-19 6:24 ` Greg KH
2004-02-27 9:00 ` 2.6.3-mm4 Prakash K. Cheemplavam
1 sibling, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Greg KH
0 siblings, 0 replies; 26+ messages in thread
From: Greg KH @ 2005-05-19 6:24 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] 26+ messages in thread
* Re: 2.6.3-mm4
2005-05-19 6:24 ` 2.6.3-mm4 Greg KH
@ 2005-05-19 6:24 ` Jean Delvare
-1 siblings, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Jean Delvare
0 siblings, 0 replies; 26+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 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] 26+ messages in thread
* Re: 2.6.3-mm4
2005-05-19 6:24 ` 2.6.3-mm4 Jean Delvare
@ 2005-05-19 6:24 ` Mike Fedyk
-1 siblings, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Mike Fedyk
0 siblings, 0 replies; 26+ messages in thread
From: Mike Fedyk @ 2005-05-19 6:24 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] 26+ messages in thread
* Re: 2.6.3-mm4
2005-05-19 6:24 ` 2.6.3-mm4 Mike Fedyk
@ 2005-05-19 6:24 ` Jean Delvare
-1 siblings, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Jean Delvare
0 siblings, 0 replies; 26+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 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\x107715308608606
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] 26+ messages in thread
* Re: 2.6.3-mm4
2005-05-19 6:24 ` 2.6.3-mm4 Jean Delvare
@ 2005-05-19 6:24 ` Mike Fedyk
-1 siblings, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Mike Fedyk
0 siblings, 0 replies; 26+ messages in thread
From: Mike Fedyk @ 2005-05-19 6:24 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\x107715308608606
>
> 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] 26+ messages in thread
* Re: 2.6.3-mm4
2005-05-19 6:24 ` 2.6.3-mm4 Mike Fedyk
@ 2005-05-19 6:24 ` Jean Delvare
-1 siblings, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Jean Delvare
0 siblings, 0 replies; 26+ messages in thread
From: Jean Delvare @ 2005-05-19 6:24 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] 26+ messages in thread
* Re: 2.6.3-mm4
2005-05-19 6:24 ` 2.6.3-mm4 Greg KH
@ 2005-05-19 6:24 ` Prakash K. Cheemplavam
-1 siblings, 0 replies; 26+ 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] 26+ messages in thread
* 2.6.3-mm4
@ 2005-05-19 6:24 ` Prakash K. Cheemplavam
0 siblings, 0 replies; 26+ messages in thread
From: Prakash K. Cheemplavam @ 2005-05-19 6:24 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] 26+ messages in thread
* Re: 2.6.3-mm4
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
2005-05-19 6:24 ` 2.6.3-mm4 Greg KH
@ 2004-02-27 9:00 ` Prakash K. Cheemplavam
1 sibling, 0 replies; 26+ 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] 26+ messages in thread
* Re: 2.6.3-mm4
2004-02-26 2:55 2.6.3-mm4 Andrew Morton
` (5 preceding siblings ...)
2004-02-27 0:11 ` 2.6.3-mm4 J.A. Magallon
@ 2004-02-27 23:51 ` Adrian Bunk
6 siblings, 0 replies; 26+ 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] 26+ 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}