Hi,
Here goes -pre6.
This release came out so quickly because -pre5 contains a deadly mistake
in one of the fs patches.
It contains SPARC/x86-64 updates, networking and crypto updates, amongst
others.
Summary of changes from v2.4.25-pre5 to v2.4.25-pre6
============================================
<jmorris:redhat.com>:
o [CRYPTO]: Clean up tcrypt module and allow it to be unloaded
<kartik_me:hotmail.com>:
o [CRYPTO]: Add CAST6 (CAST-256) algorithm
<marcelo:logos.cnet>:
o Changed EXTRAVERSION to -pre6
<my:utfors.se>:
o [CRYPTO]: Move ivsize from algorithm to tfm
Andi Kleen:
o x86-64 update
Chas Williams:
o [ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt <[email protected]>)
o [ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" <[email protected]>)
o [ATM]: better behavior for sendmsg/recvmsg during async closes
o [ATM]: refcount atm sockets
David S. Miller:
o [SPARC64]: In early bootup, BUG() if cannot find TLB entry for remapping
o [SPARC64]: Disable PCI ROM address OBP sanity check for now
o [IPV4]: Print correct source addr in invalid ICMP msgs, from Dennis Jorgensen
David Stevens:
o [IPV4/IPV6]: In MLD, add new filter first, then delete old one
David Woodhouse:
o Do not leave inodes with stale waitqueue on slab cache
Harald Welte:
o [NETFILTER]: Add config help texts for IP_NF_ARP{TABLES,FILTER}
Jean Tourrilhes:
o NSC '39x support
o VIA IrDA driver
Kurt Garloff:
o [NETFILTER]: Align nulldevname properly in ip_tables
Marcel Holtmann:
o [Bluetooth] Use R2 for default value of pscan_rep_mode
o [Bluetooth] Set disconnect timer for incoming ACL links
o [Bluetooth] Start inquiry if cache is empty
o [Bluetooth] Change maintainer role of the Bluetooth subsystem
> o [IPV4]: Print correct source addr in invalid ICMP msgs, from Dennis
Jorgensen
:-( That was my bad doing, when I was extending the information included in
that
message. Sorry.
The even worse thing is that I actually knew about the problem with it,
reported
by someone a few months ago, but never got around checking it.
Regards,
Maciej
In article <[email protected]> you wrote:
>
> Hi,
>
> Here goes -pre6.
>
> This release came out so quickly because -pre5 contains a deadly mistake
> in one of the fs patches.
SMP (2x2.66GHz Intel), with scsi aic79xx with kernel -pre6 crashed after
3 days.
No ooops in logs files or console.
Output from console SysRq showTasks, showMem and showTasks you can see
here:
http://lukasz.eu.org/minicom.txt
or here, if first will not work:
http://www.pm.waw.pl/~lukasz/minicom.txt
--
*[ ?T ]*
Lukasz Trabinski wrote:
> SMP (2x2.66GHz Intel), with scsi aic79xx with kernel -pre6 crashed after
> 3 days.
as usual:
- run memtest86+ [1] and cpuburn [2] to check the HW.
- update the firmware(MOBO BIOS and BackPlane/ESM, SCSI, hard disks, ...)
to latest levels.
[1] http://www.memtest.org
[2] http://users.ev1.net/~redelm
--
Software is like sex, it's better when it's bug free.
On Tue, 20 Jan 2004, Lukasz Trabinski wrote:
> In article <[email protected]> you wrote:
> >
> > Hi,
> >
> > Here goes -pre6.
> >
> > This release came out so quickly because -pre5 contains a deadly mistake
> > in one of the fs patches.
>
> SMP (2x2.66GHz Intel), with scsi aic79xx with kernel -pre6 crashed after
> 3 days.
>
> No ooops in logs files or console.
> Output from console SysRq showTasks, showMem and showTasks you can see
> here:
>
> http://lukasz.eu.org/minicom.txt
> or here, if first will not work:
> http://www.pm.waw.pl/~lukasz/minicom.txt
Hi Lukasz,
Can you please run the output through ksymoops?
On Tue, 20 Jan 2004, Marcelo Tosatti wrote:
> > Output from console SysRq showTasks, showMem and showTasks you can see
> > here:
> >
> > http://lukasz.eu.org/minicom.txt
> Hi Lukasz,
>
> Can you please run the output through ksymoops?
Here is:
http://lukasz.eu.org/ksymoops.txt
--
*[ ?ukasz Tr?bi?ski ]*
On Tue, 20 Jan 2004, Xose Vazquez Perez wrote:
> as usual:
>
> - run memtest86+ [1] and cpuburn [2] to check the HW.
> - update the firmware(MOBO BIOS and BackPlane/ESM, SCSI, hard disks, ...)
> to latest levels.
Hardware is OK, with older kernel (2.4.22?) works fine.
--
*[ ?ukasz Tr?bi?ski ]*
On Wed, 2004-01-21 at 07:47 +0100, Lukasz Trabinski wrote:
> Here is:
> http://lukasz.eu.org/ksymoops.txt
Some weirdness in there. This is init, for example. Apparently in R
state (as are 260-odd other processes), and:
>>EIP; c02d5d38 <contig_page_data+298/3b8> <=====
Trace; c0106cfc <setup_frame+11c/210>
Trace; c0115ba8 <schedule_timeout+58/b0>
Trace; c013849c <__get_free_pages+1c/20>
Trace; c0115b30 <process_timeout+0/20>
Trace; c014be47 <pipe_poll+37/80>
Trace; c015315d <do_select+12d/250>
>From what I can tell, there are many people waiting on the inode_lock,
because kswapd has taken it and then taken a page fault....
Trace; c0130018 <filemap_nopage+f8/220>
Trace; c01148f0 <do_page_fault+0/5e4>
Trace; c01077f0 <error_code+34/3c>
Trace; c0158fb7 <refile_inode+47/a0>
Trace; c012d7a2 <__remove_inode_page+82/90>
I wonder if one of the lists is corrupt. I'd like to know _precisely_
what's at refile_inode+47 in your build. Please could you run 'gdb
vmlinux' and tell it 'disass refile_inode'. Then save the original
vmlinux somewhere, run 'make CFLAGS_inode.o=-g SUBDIRS=fs vmlinux', load
it in GDB again and repeat the disassembly, followed by 'list
*0xc0158fb7'?
I assume this is a clean 2.4.25-pre6 build with no other patches or
modules?
--
dwmw2
On Wed, 21 Jan 2004, Lukasz Trabinski wrote:
> On Tue, 20 Jan 2004, Marcelo Tosatti wrote:
> > > Output from console SysRq showTasks, showMem and showTasks you can see
> > > here:
> > >
> > > http://lukasz.eu.org/minicom.txt
> > Hi Lukasz,
> >
> > Can you please run the output through ksymoops?
>
> Here is:
> http://lukasz.eu.org/ksymoops.txt
Hi again Lukasz,
I forgot to ask you: What compiler are you using?
On Wed, 21 Jan 2004, Lukasz Trabinski wrote:
> On Tue, 20 Jan 2004, Marcelo Tosatti wrote:
> > > Output from console SysRq showTasks, showMem and showTasks you can see
> > > here:
> > >
> > > http://lukasz.eu.org/minicom.txt
> > Hi Lukasz,
> >
> > Can you please run the output through ksymoops?
>
> Here is:
> http://lukasz.eu.org/ksymoops.txt
Thanks Lukasz,
Great, Sir Woodhouse is investingating this. The traces look pretty odd.
Can you put the vmlinux file for that kernel up on the net, too?
On Wed, 21 Jan 2004, Marcelo Tosatti wrote:
> Thanks Lukasz,
>
> Great, Sir Woodhouse is investingating this. The traces look pretty odd.
>
> Can you put the vmlinux file for that kernel up on the net, too?
http://lukasz.eu.org/vmlinux
oceanic:~$ gcc --version
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
System is RedHat 9 + updates
--
*[ ?ukasz Tr?bi?ski ]*
On Wed, 2004-01-21 at 12:28 +0100, Lukasz Trabinski wrote:
> On Wed, 21 Jan 2004, Marcelo Tosatti wrote:
> > Thanks Lukasz,
> >
> > Great, Sir Woodhouse is investingating this. The traces look pretty odd.
> >
> > Can you put the vmlinux file for that kernel up on the net, too?
>
> http://lukasz.eu.org/vmlinux
Thanks. The fault is happening in the list_del() at line 301 of
fs/inode.c; the penultimate line of __refile_inode(). It seems
that inode->i_list.prev is an invalid pointer, which caused it to oops
while holding the inode_lock.
At least, it _should_ have oopsed -- the call trace shows it's gone
through die() and do_exit(). I don't understand why you didn't get
anything on the console.
Neither do I understand why i_list.prev is corrupt. Not seeing the oops
and knowing what it actually was doesn't help. Rik?
--
dwmw2
On Wed, 21 Jan 2004, David Woodhouse wrote:
> Neither do I understand why i_list.prev is corrupt. Not seeing the oops
> and knowing what it actually was doesn't help. Rik?
I have logs from this host on different machine - no ooops.
Emergency Sync and Emergency Remount R/O didn't work.
SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem showPc unRaw Sync
showTa
sks Unmount
SysRq : Emergency Sync
SysRq : Emergency Remount R/O
--
*[ ?ukasz Tr?bi?ski ]*
On Wed, 21 Jan 2004, Lukasz Trabinski wrote:
> On Wed, 21 Jan 2004, David Woodhouse wrote:
>
> > Neither do I understand why i_list.prev is corrupt. Not seeing the oops
> > and knowing what it actually was doesn't help. Rik?
>
> I have logs from this host on different machine - no ooops.
>
> Emergency Sync and Emergency Remount R/O didn't work.
>
> SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem showPc unRaw Sync
> showTa
> sks Unmount
> SysRq : Emergency Sync
> SysRq : Emergency Remount R/O
Lukasz,
Lets try the clueless approach and remove the inode reclaim highmem fixes
from Rik.
Please revert the attached patch (againts -pre6).
Thank you for yours efforts helping track the problem down :)
On Fri, Jan 16, 2004 at 12:11:58PM -0200, Marcelo Tosatti wrote:
>...
> Summary of changes from v2.4.25-pre5 to v2.4.25-pre6
> ============================================
>...
> Jean Tourrilhes:
>...
> o VIA IrDA driver
>...
I got the following link error in 2.4.25-pre7 when trying to compile
drivers/net/irda/via-ircc.c statically into the kernel:
<-- snip -->
...
-o vmlinux
local symbol 0: discarded in section `.text.exit' from drivers/net/irda/irda.o
make: *** [vmlinux] Error 1
<-- snip -->
The patch below fixes this issue. It does:
- remove __init/__exit from function prototypes (not needed)
- __init -> __devinit
- __exit -> __devexit
- __devexit_p for via_remove_one
cu
Adrian
--- linux-2.4.25-pre7-full/drivers/net/irda/via-ircc.c.old 2004-01-24 20:19:32.000000000 +0100
+++ linux-2.4.25-pre7-full/drivers/net/irda/via-ircc.c 2004-01-24 20:23:16.000000000 +0100
@@ -79,7 +79,7 @@
/* Some prototypes */
static int via_ircc_open(int i, chipio_t * info, unsigned int id);
-static int __exit via_ircc_close(struct via_ircc_cb *self);
+static int via_ircc_close(struct via_ircc_cb *self);
static int via_ircc_setup(chipio_t * info, unsigned int id);
static int via_ircc_dma_receive(struct via_ircc_cb *self);
static int via_ircc_dma_receive_complete(struct via_ircc_cb *self,
@@ -107,8 +107,8 @@
void hwreset(struct via_ircc_cb *self);
static int via_ircc_dma_xmit(struct via_ircc_cb *self, u16 iobase);
static int upload_rxdata(struct via_ircc_cb *self, int iobase);
-static int __init via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id);
-static void __exit via_remove_one (struct pci_dev *pdev);
+static int via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id);
+static void via_remove_one (struct pci_dev *pdev);
/* Should use udelay() instead, even if we are x86 only - Jean II */
void iodelay(int udelay)
@@ -137,7 +137,7 @@
.name = VIA_MODULE_NAME,
.id_table = via_pci_tbl,
.probe = via_init_one,
- .remove = via_remove_one,
+ .remove = __devexit_p(via_remove_one),
};
@@ -146,7 +146,7 @@
*
* Initialize chip. Just find out chip type and resource.
*/
-int __init via_ircc_init(void)
+int __devinit via_ircc_init(void)
{
int rc;
@@ -168,7 +168,7 @@
}
-static int __init via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id)
+static int __devinit via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id)
{
int rc;
u8 temp,oldPCI_40,oldPCI_44,bTmp,bTmp1;
@@ -288,7 +288,7 @@
* Close all configured chips
*
*/
-static void __exit via_ircc_clean(void)
+static void __devexit via_ircc_clean(void)
{
int i;
@@ -301,7 +301,7 @@
}
}
-static void __exit via_remove_one (struct pci_dev *pdev)
+static void __devexit via_remove_one (struct pci_dev *pdev)
{
#ifdef HEADMSG
DBG(printk(KERN_INFO "via_remove_one : ......\n"));
@@ -310,7 +310,7 @@
}
-static void __exit via_ircc_cleanup(void)
+static void __devexit via_ircc_cleanup(void)
{
#ifdef HEADMSG
@@ -326,7 +326,7 @@
* Open driver instance
*
*/
-static __init int via_ircc_open(int i, chipio_t * info, unsigned int id)
+static __devinit int via_ircc_open(int i, chipio_t * info, unsigned int id)
{
struct net_device *dev;
struct via_ircc_cb *self;
@@ -460,7 +460,7 @@
* Close driver instance
*
*/
-static int __exit via_ircc_close(struct via_ircc_cb *self)
+static int __devexit via_ircc_close(struct via_ircc_cb *self)
{
int iobase;
On Sun, Jan 25, 2004 at 01:40:30AM +0100, Adrian Bunk wrote:
> On Fri, Jan 16, 2004 at 12:11:58PM -0200, Marcelo Tosatti wrote:
> >...
> > Summary of changes from v2.4.25-pre5 to v2.4.25-pre6
> > ============================================
> >...
> > Jean Tourrilhes:
> >...
> > o VIA IrDA driver
> >...
>
> I got the following link error in 2.4.25-pre7 when trying to compile
> drivers/net/irda/via-ircc.c statically into the kernel:
>
> <-- snip -->
>
> ...
> -o vmlinux
> local symbol 0: discarded in section `.text.exit' from drivers/net/irda/irda.o
> make: *** [vmlinux] Error 1
>
> <-- snip -->
>
>
> The patch below fixes this issue. It does:
> - remove __init/__exit from function prototypes (not needed)
> - __init -> __devinit
> - __exit -> __devexit
> - __devexit_p for via_remove_one
>
>
> cu
> Adrian
Thanks you Adrian. Yes, I must confess that I never test
non-modular build (because it doesn't work).
Marcelo, would you mind including Adrian's patch in your next
kernel (added again below). I tested his patch successfully with
modular and static compile. Sorry for it...
Jean
----------------------------------------------------------------
--- linux-2.4.25-pre7-full/drivers/net/irda/via-ircc.c.old 2004-01-24 20:19:32.000000000 +0100
+++ linux-2.4.25-pre7-full/drivers/net/irda/via-ircc.c 2004-01-24 20:23:16.000000000 +0100
@@ -79,7 +79,7 @@
/* Some prototypes */
static int via_ircc_open(int i, chipio_t * info, unsigned int id);
-static int __exit via_ircc_close(struct via_ircc_cb *self);
+static int via_ircc_close(struct via_ircc_cb *self);
static int via_ircc_setup(chipio_t * info, unsigned int id);
static int via_ircc_dma_receive(struct via_ircc_cb *self);
static int via_ircc_dma_receive_complete(struct via_ircc_cb *self,
@@ -107,8 +107,8 @@
void hwreset(struct via_ircc_cb *self);
static int via_ircc_dma_xmit(struct via_ircc_cb *self, u16 iobase);
static int upload_rxdata(struct via_ircc_cb *self, int iobase);
-static int __init via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id);
-static void __exit via_remove_one (struct pci_dev *pdev);
+static int via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id);
+static void via_remove_one (struct pci_dev *pdev);
/* Should use udelay() instead, even if we are x86 only - Jean II */
void iodelay(int udelay)
@@ -137,7 +137,7 @@
.name = VIA_MODULE_NAME,
.id_table = via_pci_tbl,
.probe = via_init_one,
- .remove = via_remove_one,
+ .remove = __devexit_p(via_remove_one),
};
@@ -146,7 +146,7 @@
*
* Initialize chip. Just find out chip type and resource.
*/
-int __init via_ircc_init(void)
+int __devinit via_ircc_init(void)
{
int rc;
@@ -168,7 +168,7 @@
}
-static int __init via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id)
+static int __devinit via_init_one (struct pci_dev *pcidev, const struct pci_device_id *id)
{
int rc;
u8 temp,oldPCI_40,oldPCI_44,bTmp,bTmp1;
@@ -288,7 +288,7 @@
* Close all configured chips
*
*/
-static void __exit via_ircc_clean(void)
+static void __devexit via_ircc_clean(void)
{
int i;
@@ -301,7 +301,7 @@
}
}
-static void __exit via_remove_one (struct pci_dev *pdev)
+static void __devexit via_remove_one (struct pci_dev *pdev)
{
#ifdef HEADMSG
DBG(printk(KERN_INFO "via_remove_one : ......\n"));
@@ -310,7 +310,7 @@
}
-static void __exit via_ircc_cleanup(void)
+static void __devexit via_ircc_cleanup(void)
{
#ifdef HEADMSG
@@ -326,7 +326,7 @@
* Open driver instance
*
*/
-static __init int via_ircc_open(int i, chipio_t * info, unsigned int id)
+static __devinit int via_ircc_open(int i, chipio_t * info, unsigned int id)
{
struct net_device *dev;
struct via_ircc_cb *self;
@@ -460,7 +460,7 @@
* Close driver instance
*
*/
-static int __exit via_ircc_close(struct via_ircc_cb *self)
+static int __devexit via_ircc_close(struct via_ircc_cb *self)
{
int iobase;
On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
>
> Thanks you Adrian. Yes, I must confess that I never test
> non-modular build (because it doesn't work).
>...
Are you saying it might compile statically, but it won't work?
In this case, what about disallowing building it statically in the
Config.in?
> Jean
>...
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
From: Adrian Bunk <[email protected]>
Date: Mon, 26 Jan 2004 22:01:26 +0100
On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
> Thanks you Adrian. Yes, I must confess that I never test
> non-modular build (because it doesn't work).
Are you saying it might compile statically, but it won't work?
It won't link because many IRDA drivers erroneously don't
mark their module_{init,exit}() routines static, thus
symbols conflict.
I'm fixing that now.
On Mon, Jan 26, 2004 at 01:02:42PM -0800, David S. Miller wrote:
> From: Adrian Bunk <[email protected]>
> Date: Mon, 26 Jan 2004 22:01:26 +0100
>
> On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
> > Thanks you Adrian. Yes, I must confess that I never test
> > non-modular build (because it doesn't work).
>
> Are you saying it might compile statically, but it won't work?
>
> It won't link because many IRDA drivers erroneously don't
> mark their module_{init,exit}() routines static, thus
> symbols conflict.
>
> I'm fixing that now.
I was talking with Adrian about 2.4.X where things are quite
different with respect to driver initialisation.
Jean
On Mon, Jan 26, 2004 at 10:01:26PM +0100, Adrian Bunk wrote:
> On Mon, Jan 26, 2004 at 11:28:36AM -0800, Jean Tourrilhes wrote:
> >
> > Thanks you Adrian. Yes, I must confess that I never test
> > non-modular build (because it doesn't work).
> >...
>
> Are you saying it might compile statically, but it won't work?
>
> In this case, what about disallowing building it statically in the
> Config.in?
I never looked in details at those issues. Some people claim
it works, but personally I always had touble with driver init (double
initialisation). I don't want to disable it if some embedded people
depend on it (stable kernel => stable feature list).
My "solution" was to totally rework the driver init (and stack
init) in 2.5.X and put ample warning on my web page "use static at
your own risk".
Jean
On Wed, 2004-01-21 at 18:12 -0200, Marcelo Tosatti wrote:
> Lets try the clueless approach and remove the inode reclaim highmem fixes
> from Rik.
>
> Please revert the attached patch (againts -pre6).
Did this make a difference?
--
dwmw2
On Wed, 28 Jan 2004, David Woodhouse wrote:
Hello.
> On Wed, 2004-01-21 at 18:12 -0200, Marcelo Tosatti wrote:
> > Lets try the clueless approach and remove the inode reclaim highmem fixes
> > from Rik.
> >
> > Please revert the attached patch (againts -pre6).
>
> Did this make a difference?
Machine works for 5 days without any crash or any oops.
oceanic:~# uptime
17:58:56 up 5 days, 22:08, 28 users, load average: 0.41, 0.53, 0.60
2.4.25-pre6 + nohighmem.patch
--
*[ ?ukasz Tr?bi?ski ]*
SysAdmin @wsisiz.edu.pl
Lukasz Trabinski wrote:
> On Tue, 20 Jan 2004, Xose Vazquez Perez wrote:
> > as usual:
> >
> > - run memtest86+ [1] and cpuburn [2] to check the HW.
> > - update the firmware(MOBO BIOS and BackPlane/ESM, SCSI, hard disks, ...)
> > to latest levels.
>
> Hardware is OK, with older kernel (2.4.22?) works fine.
This could be misleading, still.
I`ve had a situation in the past when a n+1`th 2.4 kernel had sound crashes
where none of the ...n`th didn`t have any.
I`ve narrowed it down to cpu overclocking... ;-)
It was a very intricate situation for the kernel crashed more or less
after a certain fixed amount of time of sound playing, no matter how
long ago the bootup happened...
regards, Samium Gromoff