Happy new year^H^H^H^Hkernel..

Happy new year^H^H^H^Hkernel..

[Linus Torvalds]

Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
last-minute stuff that needed fixing (ie the dirty page lists etc), and
the best I can do is make a prerelease.

There's a 2.4.0-prerelease out there, and this is basically it. I want
people to test it for a while, and I want to give other architectures the
chance to catch up with some of the changes, but read my lips: no more
recounts. There is no "prerelease1", to become "prerelease2" and so on.

One thing other architectures will want to catch up with is the changes to
handle 2GHz+ machines, which due to overflow issues caused "loops_per_sec"
to become "loops_per_jiffy". And some architectures have not had much
chance to synchronize with me due to other fires to put out.

Give it your worst. After you recover from being hung-over, of course.

			Linus

-----
prerelease:
   - Alan Cox: more synchronizations
   - Manfred Spraul: ptrace/suid-exec race fix

 - pre7:
   - x86 LDT handling fixes: revert some cleanups (the LDT really
     doesn't act like a TLB context)
   - Richard Henderson: alpha update (working memmove() from Ivan
     Kokshaysky etc)
   - Manfred: winbond-840.c net driver update (fix oops on module unload etc)
   - Alan Cox: more synchronizations (with some fixes from Andrew Morton)

 - pre6:
   - Marc Joosen: BIOS int15/e820 memory query: don't assume %edx
     unchanged by the BIOS. Fixes at least some IBM ThinkPads.
   - Alan Cox: synchronize
   - Marcelo Tosatti & me: properly sync dirty pages
   - Andreas Dilger: proper ext2 compat flag checking

 - pre5:
   - NIIBE Yutaka: SuperH update
   - Geert Uytterhoeven: m68k update
   - David Miller: TCP RTO calc fix, UDP multicast fix etc
   - Duncan Laurie: ServerWorks PIRQ routing definition.
   - mm PageDirty cleanups, added sanity checks, and don't lose the bit. 

 - pre4:
   - Christoph Rohland: shmfs cleanup
   - Nicolas Pitre: don't forget loop.c flags
   - Geert Uytterhoeven: new-style m68k Makefiles
   - Neil Brown: knfsd cleanups, raid5 re-org
   - Andrea Arkangeli: update to LVM-0.9
   - LC Chang: sis900 driver doc update
   - David Miller: netfilter oops fix
   - Andrew Grover: acpi update

 - pre3:
   - Christian Jullien: smc9194: proper dev_kfree_skb_irq
   - Cort Dougan: new-style PowerPC Makefiles
   - Andrew Morton, Petr Vandrovec: fix run_task_queue
   - Christoph Rohland: shmfs for shared memory handling

 - pre2:
   - Kai Germaschewski: ISDN update (including Makefiles)
   - Jens Axboe: cdrom updates
   - Petr Vandrovec; Matrox G450 support
   - Bill Nottingham: fix FAT32 filesystems on 64-bit platforms
   - David Miller: sparc (and other) Makefile fixup
   - Andrea Arkangeli: alpha SMP TLB context fix (and cleanups)
   - Niels Kristian Bech Jensen: checkconfig, USB warnings
   - Andrew Grover: large ACPI update

 - pre1:
   - me: drop support for old-style Makefiles entirely. Big.
   - me: check b_end_io at the IO submission path
   - me: fix "ptep_mkdirty()" (so that swapoff() works correctly)
   - fix fault case in copy_from_user() with a constant size, where
     ((size & 3) == 3)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Adam Sampson]

Linus Torvalds <torvalds@transmeta.com> writes:

> Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> last-minute stuff that needed fixing (ie the dirty page lists etc), and
> the best I can do is make a prerelease.

It appears to work (even with the reiserfs patch with the obvious
Makefile tweak), but the drm modules have unresolved symbols:

root# modprobe mga
/lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o:
unresolved symbol remap_page_range
/lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o:
unresolved symbol __wake_up
/lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o:
unresolved symbol mtrr_add
/lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o:
unresolved symbol __generic_copy_from_user
/lib/modules/2.4.0-prerelease/kernel/drivers/char/drm/mga.o:
unresolved symbol schedule
[...]

-- 

Adam Sampson
azz@gnu.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Linus Torvalds]

On 1 Jan 2001, Adam Sampson wrote:
> 
> It appears to work (even with the reiserfs patch with the obvious
> Makefile tweak), but the drm modules have unresolved symbols:

Does this fix it for you (do a "make clean" before re-building your tree)?

		Linus

----
--- v2.4.0-prerelease/linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:35 2001
+++ linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:04 2001
@@ -44,22 +44,22 @@
 mga-objs   := mga_drv.o   mga_dma.o     mga_context.o  mga_bufs.o  mga_state.o
 i810-objs  := i810_drv.o  i810_dma.o    i810_context.o i810_bufs.o
 
-obj-$(CONFIG_DRM_GAMMA) += gamma.o
-obj-$(CONFIG_DRM_TDFX)  += tdfx.o
-obj-$(CONFIG_DRM_R128)  += r128.o
-obj-$(CONFIG_DRM_FFB)   += ffb.o
-obj-$(CONFIG_DRM_MGA)   += mga.o
-obj-$(CONFIG_DRM_I810)  += i810.o
-
-
 # When linking into the kernel, link the library just once. 
 # If making modules, we include the library into each module
 
 ifdef MAKING_MODULES
   lib = drmlib.a
 else
-  obj-y += drmlib.a
+  extra-obj = drmlib.a  
 endif
+
+obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj)
+obj-$(CONFIG_DRM_TDFX)  += tdfx.o $(extra-obj)
+obj-$(CONFIG_DRM_R128)  += r128.o $(extra-obj)
+obj-$(CONFIG_DRM_FFB)   += ffb.o $(extra-obj)
+obj-$(CONFIG_DRM_MGA)   += mga.o $(extra-obj)
+obj-$(CONFIG_DRM_I810)  += i810.o $(extra-obj)
+
 
 include $(TOPDIR)/Rules.make
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Frank Jacobberger]

Linus Torvalds wrote:

> On 1 Jan 2001, Adam Sampson wrote:
> >
> > It appears to work (even with the reiserfs patch with the obvious
> > Makefile tweak), but the drm modules have unresolved symbols:
>
> Does this fix it for you (do a "make clean" before re-building your tree)?
>
>                 Linus
>
> ----
> --- v2.4.0-prerelease/linux/drivers/char/drm/Makefile   Mon Jan  1 09:38:35 2001
> +++ linux/drivers/char/drm/Makefile     Mon Jan  1 09:38:04 2001
> @@ -44,22 +44,22 @@
>  mga-objs   := mga_drv.o   mga_dma.o     mga_context.o  mga_bufs.o  mga_state.o
>  i810-objs  := i810_drv.o  i810_dma.o    i810_context.o i810_bufs.o
>
> -obj-$(CONFIG_DRM_GAMMA) += gamma.o
> -obj-$(CONFIG_DRM_TDFX)  += tdfx.o
> -obj-$(CONFIG_DRM_R128)  += r128.o
> -obj-$(CONFIG_DRM_FFB)   += ffb.o
> -obj-$(CONFIG_DRM_MGA)   += mga.o
> -obj-$(CONFIG_DRM_I810)  += i810.o
> -
> -
>  # When linking into the kernel, link the library just once.
>  # If making modules, we include the library into each module
>
>  ifdef MAKING_MODULES
>    lib = drmlib.a
>  else
> -  obj-y += drmlib.a
> +  extra-obj = drmlib.a
>  endif
> +
> +obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj)
> +obj-$(CONFIG_DRM_TDFX)  += tdfx.o $(extra-obj)
> +obj-$(CONFIG_DRM_R128)  += r128.o $(extra-obj)
> +obj-$(CONFIG_DRM_FFB)   += ffb.o $(extra-obj)
> +obj-$(CONFIG_DRM_MGA)   += mga.o $(extra-obj)
> +obj-$(CONFIG_DRM_I810)  += i810.o $(extra-obj)
> +
>
>  include $(TOPDIR)/Rules.make

Works like a charm here.... fix added drmlib.a with tdfx.o to
/lib/modules/2.4.0-prerelease/kernel/drivers/char/drm


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Keith Owens]

On Mon, 1 Jan 2001 09:39:38 -0800 (PST), 
Linus Torvalds <torvalds@transmeta.com> wrote:
>On 1 Jan 2001, Adam Sampson wrote:
>> 
>> It appears to work (even with the reiserfs patch with the obvious
>> Makefile tweak), but the drm modules have unresolved symbols:
>
>Does this fix it for you (do a "make clean" before re-building your tree)?
>
>		Linus
>
>----
>--- v2.4.0-prerelease/linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:35 2001
>+++ linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:04 2001
>@@ -44,22 +44,22 @@
> mga-objs   := mga_drv.o   mga_dma.o     mga_context.o  mga_bufs.o  mga_state.o
> i810-objs  := i810_drv.o  i810_dma.o    i810_context.o i810_bufs.o
> 
>-obj-$(CONFIG_DRM_GAMMA) += gamma.o
>-obj-$(CONFIG_DRM_TDFX)  += tdfx.o
>-obj-$(CONFIG_DRM_R128)  += r128.o
>-obj-$(CONFIG_DRM_FFB)   += ffb.o
>-obj-$(CONFIG_DRM_MGA)   += mga.o
>-obj-$(CONFIG_DRM_I810)  += i810.o
>-
>-
> # When linking into the kernel, link the library just once. 
> # If making modules, we include the library into each module
> 
> ifdef MAKING_MODULES
>   lib = drmlib.a
> else
>-  obj-y += drmlib.a
>+  extra-obj = drmlib.a  
> endif
>+
>+obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj)
>+obj-$(CONFIG_DRM_TDFX)  += tdfx.o $(extra-obj)
>+obj-$(CONFIG_DRM_R128)  += r128.o $(extra-obj)
>+obj-$(CONFIG_DRM_FFB)   += ffb.o $(extra-obj)
>+obj-$(CONFIG_DRM_MGA)   += mga.o $(extra-obj)
>+obj-$(CONFIG_DRM_I810)  += i810.o $(extra-obj)
>+
> 
> include $(TOPDIR)/Rules.make

That will break for anybody compiling a DRM card into the kernel and
compiling a second DRM card as a module.  drmlib.a will get a split
personality, it will be compiled twice, once for kernel and once for
module, which version actually gets linked will depend on the phase of
the moon.  Either that or it only gets compiled for kernel, which is
where we came in.

DRM maintainers: can we remove this restriction on needing multiple
copies of the library?  It makes no sense anyway.  If you build a new
library with the same function names then you cannot have two DRM cards
built into the kernel, the function names will collide within vmlinux.
So you have to use different function names for a new library, but then the
old cards can share the old library and the new cards can share the new
library, i.e. there is no need for each driver to have its own copy of
the library.

I strongly recommend that you remove the restriction on having multiple
copies of the library.  Then Adam J. Richter's patch does the job
nicely, making drmlib.a a helper module.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Rik Faith]

On Tue  2 Jan 2001 08:32:45 +1100,
   Keith Owens <kaos@ocs.com.au> wrote:
> On Mon, 1 Jan 2001 09:39:38 -0800 (PST), 
> Linus Torvalds <torvalds@transmeta.com> wrote:
> >On 1 Jan 2001, Adam Sampson wrote:
> >> 
> >> It appears to work (even with the reiserfs patch with the obvious
> >> Makefile tweak), but the drm modules have unresolved symbols:
> >
> >Does this fix it for you (do a "make clean" before re-building your tree)?
> >
> >		Linus
> >
> >----
> >--- v2.4.0-prerelease/linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:35 2001
> >+++ linux/drivers/char/drm/Makefile	Mon Jan  1 09:38:04 2001
> >@@ -44,22 +44,22 @@
> > mga-objs   := mga_drv.o   mga_dma.o     mga_context.o  mga_bufs.o  mga_state.o
> > i810-objs  := i810_drv.o  i810_dma.o    i810_context.o i810_bufs.o
> > 
> >-obj-$(CONFIG_DRM_GAMMA) += gamma.o
> >-obj-$(CONFIG_DRM_TDFX)  += tdfx.o
> >-obj-$(CONFIG_DRM_R128)  += r128.o
> >-obj-$(CONFIG_DRM_FFB)   += ffb.o
> >-obj-$(CONFIG_DRM_MGA)   += mga.o
> >-obj-$(CONFIG_DRM_I810)  += i810.o
> >-
> >-
> > # When linking into the kernel, link the library just once. 
> > # If making modules, we include the library into each module
> > 
> > ifdef MAKING_MODULES
> >   lib = drmlib.a
> > else
> >-  obj-y += drmlib.a
> >+  extra-obj = drmlib.a  
> > endif
> >+
> >+obj-$(CONFIG_DRM_GAMMA) += gamma.o $(extra-obj)
> >+obj-$(CONFIG_DRM_TDFX)  += tdfx.o $(extra-obj)
> >+obj-$(CONFIG_DRM_R128)  += r128.o $(extra-obj)
> >+obj-$(CONFIG_DRM_FFB)   += ffb.o $(extra-obj)
> >+obj-$(CONFIG_DRM_MGA)   += mga.o $(extra-obj)
> >+obj-$(CONFIG_DRM_I810)  += i810.o $(extra-obj)
> >+
> > 
> > include $(TOPDIR)/Rules.make
> 
> That will break for anybody compiling a DRM card into the kernel and
> compiling a second DRM card as a module.  drmlib.a will get a split
> personality, it will be compiled twice, once for kernel and once for
> module, which version actually gets linked will depend on the phase of
> the moon.  Either that or it only gets compiled for kernel, which is
> where we came in.
> 
> DRM maintainers: can we remove this restriction on needing multiple
> copies of the library?  It makes no sense anyway.  If you build a new
> library with the same function names then you cannot have two DRM cards
> built into the kernel, the function names will collide within vmlinux.
> So you have to use different function names for a new library, but then the
> old cards can share the old library and the new cards can share the new
> library, i.e. there is no need for each driver to have its own copy of
> the library.
> 
> I strongly recommend that you remove the restriction on having multiple
> copies of the library.  Then Adam J. Richter's patch does the job
> nicely, making drmlib.a a helper module.

We plan to remove the need to have multiple copies of drmlib.a and make
the kernel Makefile fully compatible with the 2.4 make system -- but we
haven't finished this work yet.  With this new work, however, the
end-user will still load a single module (e.g., tdfx.o), just like now.
(Loading a single kernel module is a significant win when dealing with
end users: there is no possibility of version skew or of having two
modules that were compiled with different options.)

Linus -- Please use your patch or Keith Owens' patch as a bandaid to
solve this problem until we can do it the right way.  Whatever patch you
select, please do *NOT* make drmlib into a separate helper module --
this will only lead to user confusion (especially since we'll move back
to a single-module solution soon).  From the user's standpoint, I'm not
concerned that you can't mix modules with in-kernel versions, since most
users don't do that [and we could fix the configuration file to prevent
this -- that's another way to bandage this problem that I'll send you a
patch for tomorrow].  I am very concerned that users will see us move
from 1 DRM module to 2 and then back to 1 -- that would be very
confusing for them.

--Rik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Alan Cox]

> haven't finished this work yet.  With this new work, however, the
> end-user will still load a single module (e.g., tdfx.o), just like now.
> (Loading a single kernel module is a significant win when dealing with
> end users: there is no possibility of version skew or of having two
> modules that were compiled with different options.)

So with 3 video cards I have 3 wasted chunks of ram just because of a tiny
tiny possibility that someone would manage to build two copies of the library
with matching ksyms. That doesnt strike me as a good tade off
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Adam Sampson]

Linus Torvalds <torvalds@transmeta.com> writes:

> > [...] the drm modules have unresolved symbols:
> 
> Does this fix it for you (do a "make clean" before re-building your tree)?

Yep, that works for a modular mga.o (although it also results in
drmlib.a being installed into /lib/modules, which makes depmod
whinge). Thanks!

Are there any plans to include Ian Hastie's ALi M1541 agpgart patches
in 2.4.0? They appear to do the job here...

-- 

Adam Sampson
azz@gnu.org



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Daniel Phillips]

Linus Torvalds wrote: 
> Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> last-minute stuff that needed fixing (ie the dirty page lists etc), and
> the best I can do is make a prerelease.

It's even better this way.  Now we kick off the new millenium with a new
kernel. :-)

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Gerold Jury]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

The ISDN changes for the HISAX drivers
that came in since test12 have introduced a bug that causes a 
AIEE-something and a complete kernel hang when i hangup the isdn line.
I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
isdn patch part and it works for me now.

The relevant part is attached. Please back it out for 2.4.0.

Happy new year

Gerold Jury

[-- Attachment #2: patch-2.4.0-prerelease.isdnrev --]
[-- Type: text/plain, Size: 4570 bytes --]

diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/config.c linux/drivers/isdn/hisax/config.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/config.c	Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/config.c	Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: config.c,v 2.57.6.3 2000/11/29 17:48:59 kai Exp $
+/* $Id: config.c,v 2.57.6.6 2000/12/10 23:39:19 kai Exp $
  *
  * Author       Karsten Keil (keil@isdn4linux.de)
  *              based on the teles driver from Jan den Ouden
@@ -1180,7 +1180,6 @@
 	cs->tx_skb = NULL;
 	cs->tx_cnt = 0;
 	cs->event = 0;
-	INIT_LIST_HEAD(&cs->tqueue.list);
 	cs->tqueue.sync = 0;
 	cs->tqueue.data = cs;
 
@@ -1756,6 +1755,7 @@
 	{PCI_VENDOR_ID_CCD,      PCI_DEVICE_ID_CCD_B00B,         PCI_ANY_ID, PCI_ANY_ID},
 	{PCI_VENDOR_ID_CCD,      PCI_DEVICE_ID_CCD_B00C,         PCI_ANY_ID, PCI_ANY_ID},
 	{PCI_VENDOR_ID_CCD,      PCI_DEVICE_ID_CCD_B100,         PCI_ANY_ID, PCI_ANY_ID},
+	{PCI_VENDOR_ID_ABOCOM,   PCI_DEVICE_ID_ABOCOM_2BD1,      PCI_ANY_ID, PCI_ANY_ID},
 	{PCI_VENDOR_ID_ASUSTEK,  PCI_DEVICE_ID_ASUSTEK_0675,     PCI_ANY_ID, PCI_ANY_ID},
 	{PCI_VENDOR_ID_BERKOM,   PCI_DEVICE_ID_BERKOM_T_CONCEPT, PCI_ANY_ID, PCI_ANY_ID},
 	{PCI_VENDOR_ID_BERKOM,   PCI_DEVICE_ID_BERKOM_A1T,       PCI_ANY_ID, PCI_ANY_ID},
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c linux/drivers/isdn/hisax/isdnl1.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c	Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/isdnl1.c	Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdnl1.c,v 2.41 2000/11/24 17:05:37 kai Exp $
+/* $Id: isdnl1.c,v 2.41.6.1 2000/12/10 22:01:04 kai Exp $
  *
  * isdnl1.c     common low level stuff for Siemens Chipsetbased isdn cards
  *              based on the teles driver from Jan den Ouden
@@ -15,7 +15,7 @@
  *
  */
 
-const char *l1_revision = "$Revision: 2.41 $";
+const char *l1_revision = "$Revision: 2.41.6.1 $";
 
 #define __NO_VERSION__
 #include <linux/init.h>
@@ -343,7 +343,6 @@
 
 	bcs->cs = cs;
 	bcs->channel = bc;
-	INIT_LIST_HEAD(&bcs->tqueue.list);
 	bcs->tqueue.sync = 0;
 	bcs->tqueue.routine = (void *) (void *) BChannel_bh;
 	bcs->tqueue.data = bcs;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c linux/drivers/isdn/hysdn/boardergo.c
--- v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c	Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hysdn/boardergo.c	Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: boardergo.c,v 1.5 2000/11/22 17:13:13 kai Exp $
+/* $Id: boardergo.c,v 1.5.6.1 2000/12/10 22:01:04 kai Exp $
 
  * Linux driver for HYSDN cards, specific routines for ergo type boards.
  *
@@ -458,7 +458,6 @@
 	card->writebootseq = ergo_writebootseq;
 	card->waitpofready = ergo_waitpofready;
 	card->set_errlog_state = ergo_set_errlog_state;
-	INIT_LIST_HEAD(&card->irq_queue.list);
 	card->irq_queue.sync = 0;
 	card->irq_queue.data = card;	/* init task queue for interrupt */
 	card->irq_queue.routine = (void *) (void *) ergo_irq_bh;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/isdn_net.c linux/drivers/isdn/isdn_net.c
--- v2.4.0-test12/linux/drivers/isdn/isdn_net.c	Sun Nov 19 18:44:08 2000
+++ linux/drivers/isdn/isdn_net.c	Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdn_net.c,v 1.140 2000/11/01 17:54:01 detabc Exp $
+/* $Id: isdn_net.c,v 1.140.6.1 2000/12/10 22:01:04 kai Exp $
 
  * Linux ISDN subsystem, network interfaces and related functions (linklevel).
  *
@@ -181,7 +181,7 @@
 int isdn_net_force_dial_lp(isdn_net_local *);
 static int isdn_net_start_xmit(struct sk_buff *, struct net_device *);
 
-char *isdn_net_revision = "$Revision: 1.140 $";
+char *isdn_net_revision = "$Revision: 1.140.6.1 $";
 
  /*
   * Code for raw-networking over ISDN
@@ -2371,7 +2371,7 @@
 	netdev->local->netdev = netdev;
 	netdev->local->next = netdev->local;
 
-	memset(&netdev->local->tqueue, 0, sizeof(struct tq_struct));
+	netdev->local->tqueue.sync = 0;
 	netdev->local->tqueue.routine = isdn_net_softint;
 	netdev->local->tqueue.data = netdev->local;
 	spin_lock_init(&netdev->local->xmit_lock);
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/pcbit/drv.c linux/drivers/isdn/pcbit/drv.c
--- v2.4.0-test12/linux/drivers/isdn/pcbit/drv.c	Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/pcbit/drv.c	Fri Dec 29 14:07:22 2000
@@ -134,8 +134,6 @@
 	memset(dev->b2, 0, sizeof(struct pcbit_chan));
 	dev->b2->id = 1;
 
-
-	INIT_LIST_HEAD(&dev->qdelivery.list);
 	dev->qdelivery.sync = 0;
 	dev->qdelivery.routine = pcbit_deliver;
 	dev->qdelivery.data = dev;

Re: Happy new year^H^H^H^Hkernel..

[Kurt Roeckx]

On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
> The ISDN changes for the HISAX drivers
> that came in since test12 have introduced a bug that causes a 
> AIEE-something and a complete kernel hang when i hangup the isdn line.
> I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
> isdn patch part and it works for me now.
> 
> The relevant part is attached. Please back it out for 2.4.0.

I'm using the hisax driver too (build in), and it works perfectly
for me.


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[David Woodhouse]

Q@ping.be said:
>  I'm using the hisax driver too (build in), and it works perfectly for
> me. 

I've also seen my machine die on taking down the ippp0 interface
("service isdn stop") - not on hanging up ("isdnctrl hangup ippp0").

I keep forgetting to investigate, because it's extremely rare that I 
actually disconnect or reboot, rather than just hitting the reset button 
when X has segfaulted again.

Is your machine SMP?

--
dwmw2


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Gerold Jury]

Sorry for that stupid mistake.
The patches to the isdn part do not make a difference to the kernel hang
that i experienced lately.
When i reversed the patch for the mentioned files i checked the kernel 
configuration and noticed that the "diversion services for isdn" where 
on, a feature that i cannot use at the moment with my carrier.
I switched them off before i compiled the new kernel.
This is what makes the difference.
Kernel 2.4.0-test13-pre4 was the previous one that I used (with 
diversion services on, i am a fan of make oldconfig) and that did not 
show the problem (as all of the previous kernels, test9, test10, test12).

I have reversed the patches part by part, the only thing that makes a 
difference is the diversion services.
The reason for this remains unknown for me.

I use a fritz pnp/isa card, driver compiled as a module.
No SMP, isdn in kernel.
Close to nothing running during the hangup.

The problem is reproducable and i would be glad to help testing any 
suggestions.

Gerold


Gerold Jury wrote:

> The ISDN changes for the HISAX drivers
> that came in since test12 have introduced a bug that causes a 
> AIEE-something and a complete kernel hang when i hangup the isdn line.
> I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
> isdn patch part and it works for me now.
> 
> The relevant part is attached. Please back it out for 2.4.0.
> 
> Happy new year
> 
> Gerold Jury
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Kai Germaschewski]

On Tue, 2 Jan 2001, Gerold Jury wrote:

> I have reversed the patches part by part, the only thing that makes a
> difference is the diversion services.
> The reason for this remains unknown for me.

I think I found it. Could everybody who was getting the crash on ISDN line
hangup try if the following patch fixes the problem?

I think the problem was that we relied on divert_if being initialized to
zero automatically, which didn't happen because it was not declared static
and therefore not in .bss (*is this true?*).

diff -ur linux-2.4.0-prerelease-diff/drivers/isdn/isdn_common.c linux-2.4.0-prerelease-diff.fix/drivers/isdn/isdn_common.c
--- linux-2.4.0-prerelease-diff/drivers/isdn/isdn_common.c	Tue Jan  2 12:26:45 2001
+++ linux-2.4.0-prerelease-diff.fix/drivers/isdn/isdn_common.c	Tue Jan  2 23:47:48 2001
@@ -68,7 +68,7 @@
 extern char *isdn_v110_revision;

 #ifdef CONFIG_ISDN_DIVERSION
-isdn_divert_if *divert_if; /* interface to diversion module */
+static isdn_divert_if *divert_if; /* = NULL */
 #endif CONFIG_ISDN_DIVERSION


@@ -2118,7 +2118,6 @@
 }

 #ifdef CONFIG_ISDN_DIVERSION
-extern isdn_divert_if *divert_if;

 static char *map_drvname(int di)
 {


I also attached a patch which disables diversion service being selected as
built-in during kernel config, because this doesn't work yet.

--Kai


diff -ur linux-2.4.0-prerelease-diff/drivers/isdn/Config.in linux-2.4.0-prerelease-diff.fix/drivers/isdn/Config.in
--- linux-2.4.0-prerelease-diff/drivers/isdn/Config.in	Tue Jan  2 12:26:45 2001
+++ linux-2.4.0-prerelease-diff.fix/drivers/isdn/Config.in	Tue Jan  2 23:46:00 2001
@@ -23,7 +23,7 @@
 mainmenu_option next_comment
 comment 'ISDN feature submodules'
    dep_tristate 'isdnloop support' CONFIG_ISDN_DRV_LOOP $CONFIG_ISDN
-   dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN
+   dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN m
 endmenu

 comment 'low-level hardware drivers'


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Gerold Jury]

It works for me.
With and without the divert module loaded.

Thanks a lot

Gerold

Kai Germaschewski wrote:

> I think I found it. Could everybody who was getting the crash on ISDN line
> hangup try if the following patch fixes the problem?
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Hugh Dickins]

On Tue, 2 Jan 2001, Kai Germaschewski wrote:

> I think the problem was that we relied on divert_if being initialized to
> zero automatically, which didn't happen because it was not declared static
> and therefore not in .bss (*is this true?*).

This is true in this particular case, and your added "static" is good.
But you seem to miss the root of the problem, that isdn_common.c declares
an "isdn_divert_if *divert_if", and divert/divert_init.c declares
an "isdn_divert_if divert_if" (initialized non-zero).  When the two .os
were linked, you got a single "divert_if" (initialized non-zero in .data).
Wouldn't it be best to (keep the "static" but also) change the name of the
pointer in isdn_common.c?

Hugh

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Eric W. Biederman]

Kai Germaschewski <kai@thphy.uni-duesseldorf.de> writes:

> On Tue, 2 Jan 2001, Gerold Jury wrote:
> 
> > I have reversed the patches part by part, the only thing that makes a
> > difference is the diversion services.
> > The reason for this remains unknown for me.
> 
> I think I found it. Could everybody who was getting the crash on ISDN line
> hangup try if the following patch fixes the problem?
> 
> I think the problem was that we relied on divert_if being initialized to
> zero automatically, which didn't happen because it was not declared static
> and therefore not in .bss (*is this true?*).

All variables with static storage (not with static scope) if not explicitly
initialized are placed in the bss segment.  In particular this
means that adding/removing a static changes nothing.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Kai Germaschewski]

On 3 Jan 2001, Eric W. Biederman wrote:

> Kai Germaschewski <kai@thphy.uni-duesseldorf.de> writes:
>
> > I think the problem was that we relied on divert_if being initialized to
> > zero automatically, which didn't happen because it was not declared static
> > and therefore not in .bss (*is this true?*).
>
> All variables with static storage (not with static scope) if not explicitly
> initialized are placed in the bss segment.  In particular this
> means that adding/removing a static changes nothing.

The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when
I found what was really going on. Other source files used a global
initialized variable "divert_if" as well, so this became the same one as
the one referenced in isdn_common.c.  That's why it wasn't zero, it was
explicitly initialized elsewhere. However, making divert_if static in
isdn_common.c fixes the problem, because now it's really local to this
file and therefore initialized to NULL.

--Kai



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Russell King]

Kai Germaschewski writes:
> The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when
> I found what was really going on. Other source files used a global
> initialized variable "divert_if" as well, so this became the same one as
> the one referenced in isdn_common.c.  That's why it wasn't zero, it was
> explicitly initialized elsewhere. However, making divert_if static in
> isdn_common.c fixes the problem, because now it's really local to this
> file and therefore initialized to NULL.

Maybe someone should compile the kernel with everything built in and
-fno-common to catch stuff like this?  Maybe we should always compile
the kernel with -fno-common?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Eric W. Biederman]

Russell King <rmk@arm.linux.org.uk> writes:

> Kai Germaschewski writes:
> > The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when
> > I found what was really going on. Other source files used a global
> > initialized variable "divert_if" as well, so this became the same one as
> > the one referenced in isdn_common.c.  That's why it wasn't zero, it was
> > explicitly initialized elsewhere. However, making divert_if static in
> > isdn_common.c fixes the problem, because now it's really local to this
> > file and therefore initialized to NULL.
> 
> Maybe someone should compile the kernel with everything built in and
> -fno-common to catch stuff like this?  Maybe we should always compile
> the kernel with -fno-common?

Sounds good.

We probably need to wait until after 2.4.0 is released to make the 
change though.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Matthias Andree]

On Sun, 31 Dec 2000, Linus Torvalds wrote:

> Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> last-minute stuff that needed fixing (ie the dirty page lists etc), and
> the best I can do is make a prerelease.

I just compiled that one into a 1032 kB kernel, and it failed to be
booted from GRUB 0.5.95 (some CVS version). I then made USB into
modules, the kernel was 887 kB and booted. Is Linux 2.4 supposed to
suffer from the 1 M limit still?

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Richard B. Johnson]

On Tue, 2 Jan 2001, Matthias Andree wrote:

> On Sun, 31 Dec 2000, Linus Torvalds wrote:
> 
> > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> > last-minute stuff that needed fixing (ie the dirty page lists etc), and
> > the best I can do is make a prerelease.
> 
> I just compiled that one into a 1032 kB kernel, and it failed to be
> booted from GRUB 0.5.95 (some CVS version). I then made USB into
> modules, the kernel was 887 kB and booted. Is Linux 2.4 supposed to
> suffer from the 1 M limit still?
> 

`make bzImage` gives you an image that can be (practically) any size.
I don't know anything about GRUB. However, LILO handles it fine.

When LILO boots, it reads up to 64k at a time, relocates this above
1 megabyte by using INT 0x15, then reuses the same buffer over and
over again. Therefore, it doesn't have a "size" problem since it only
uses 64k + some code-space, in an area that has at least 512 kbytes.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Andrzej Krzysztofowicz]

> 
> On Sun, 31 Dec 2000, Linus Torvalds wrote:
> 
> > Ok. I didn't make 2.4.0 in 2000. Tough. I tried, but we had some
> > last-minute stuff that needed fixing (ie the dirty page lists etc), and
> > the best I can do is make a prerelease.
> 
> I just compiled that one into a 1032 kB kernel, and it failed to be
> booted from GRUB 0.5.95 (some CVS version). I then made USB into
> modules, the kernel was 887 kB and booted. Is Linux 2.4 supposed to
> suffer from the 1 M limit still?

No.
$ ls -l /boot/bzImage
-rw-r--r--   1 root     root      1060541 Jan  2 22:18 /boot/bzImage
$ lilo -v
LILO version 20, Copyright 1992-1997 Werner Almesberger

$ uname -a
Linux kufel 2.4.0-prerelease #3 wto sty 2 21:33:36 CET 2001 i586 unknown

Maybe GRUB relies on the data (image size) in a build-in simple bootloader ?

Current i386 image size limit is about 2.5 MB

Andrzej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Dominik Kubla]

On Sun, Dec 31, 2000 at 12:24:44PM -0800, Linus Torvalds wrote:
...
> Give it your worst. After you recover from being hung-over, of course.
> 
> 			Linus

Dell Inspiron 7500VT (Pentium-II 400, 128 MB RAM, BIOS A14): no go when
ACPI is enabled. System hangs after the

  ACPI: System description tables loaded

message.  System boots fine with APM, but the Xircom Combi-Card (not
using the kernel drivers!) does not work. Will try with kernel drivers
ASAP.

Yours,
  Dominik Kubla
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Happy new year^H^H^H^Hkernel..

[Ray Strode]

>I want people to test it for a while, and I want to give other
architectures >the chance to catch up with some of the changes
Does that mean that other architectures have separate mailing lists and
kernel source trees?  Is that why i've been getting ignored =)?
If so, what are they? I'd really like to get the bugs I've been experiencing
on alpha figured out.

--Ray

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Ray Strode]

Eric W. Biederman writes,
>Some arches have separate maintenance but I don't believe alpha is.
>Though I do believe it has a separate mailing list for alpha specific
things,
>to get better signal to noise ratio.
Great! Do you know where I can find more info about it?

--Ray

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[Kai Germaschewski]

On Tue, 2 Jan 2001, Thorsten Kranzkowski wrote:

> On Tue, Jan 02, 2001 at 03:51:34AM +0100, Gerold Jury wrote:
> > The ISDN changes for the HISAX drivers
> > that came in since test12 have introduced a bug that causes a
> > AIEE-something and a complete kernel hang when i hangup the isdn line.
>
> I also saw this on my Alpha. Plus it hung one while the machine was idle
> and an analog phone call came in.
>
> For me disabling 'diversion services' solved the problem. Whether this fixed
> the problem or only hides it I don't know :)

I'm looking into this, but I'm not quite there yet. I don't believe it
really is connected to the INIT_LIST_HEAD changes, diversion services and
the Makefile changes are a more likely suspect. It'ld be nice if I could
reproduce it but I can't as of yet.

If somebody could catch a call trace, that would help a lot, too.

--Kai


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Happy new year^H^H^H^Hkernel..

[David Woodhouse]

On Tue, 2 Jan 2001, Gerold Jury wrote (in a private message, sorry):

> The machine is single CPU no SMP.
> It hangs with or without X when i hangup the ippp0 interface.
> One of the scripts that run when the line is hung up may do a ifconfig
> ippp0 down afterwards which could be the actual reason.

Turn off CONFIG_ISDN_DIVERSION. S'broken. I think Alan has fixes if you
really need it.

-- 
dwmw2



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/