public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* test13-pre3
@ 2000-12-17 21:55 Linus Torvalds
  2000-12-17 23:43 ` test13-pre3 Albert Cranford
                   ` (2 more replies)
  0 siblings, 3 replies; 16+ messages in thread
From: Linus Torvalds @ 2000-12-17 21:55 UTC (permalink / raw)
  To: Kernel Mailing List


The most noticeable part of this is that the run_task_queue fix should
cure the lockup that some people have seen.

The shmfs cleanup should be unnoticeable except to users who use SAP with
huge shared memory segments, where Christoph Rohlands work not only
makes the code much more readable, it should also make it dependable..

		Linus

----

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: test13-pre3
@ 2000-12-18 17:35 Petr Vandrovec
  2000-12-18 17:18 ` test13-pre3 Maciej W. Rozycki
  0 siblings, 1 reply; 16+ messages in thread
From: Petr Vandrovec @ 2000-12-18 17:35 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Kernel Mailing List, mingo, torvalds

On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:

>  What is this change about?
> 
> diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
> --- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c      Mon Dec 11 17:59:43 2000
> +++ linux/arch/i386/kernel/smpboot.c    Thu Dec 14 14:54:40 2000
> @@ -694,6 +694,11 @@
>         apic_write_around(APIC_ICR, APIC_DM_STARTUP
>                     | (start_eip >> 12));
>  
> +       /*
> +        * Give the other CPU some time to accept the IPI.
> +        */
> +       udelay(300);
> +
>         Dprintk("Startup point 1.\n");
>  
>         Dprintk("Waiting for send to finish...\n");
> 
> There is the following code is just after it, making the above change
> just useless garbage:

No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x), where x >= 200,
before first printk. I sent patch twice to linux-kernel, and to 
mingo@redhat.com, and nobody said anything against it.
 
>         timeout = 0;
>         do {
>             Dprintk("+");
>             udelay(100);
>             send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>         } while (send_status && (timeout++ < 1000));
> 
>         /*
>          * Give the other CPU some time to accept the IPI.
>          */
>         udelay(200);
> 
> If we need 600usecs of delay for certain systems, then why not just make
> it like below?

No. If there is no udelay() before first printk(), on my GA-6VXD7 board
(SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting
for send to finish...'. So maybe we do not need udelay(200) below loop,
but for sure we need udelay() before first printk(). (my board works
without ANY udelay() in smpboot.c, except one I added... This one is 
required.) If somebody lives in Prague, and wants to come with logical
analyzer (or if I should come with motherboard), I'm willing to continue
testing. But current idea is that inb/outb done by cursor positioning
code is incompatible with something else done in secondary CPU startup.
(it boots also without any kernel change with 'console=ttyS0,9600', but 
it may be caused by slow serial line)

Without delay() both CPU die, and board does not react to anything except
hard reset anymore (and sometime it does not react even to hard reset; lookup
for my messages during last week).
                                    Best regards,
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
                                            
-
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/

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: test13-pre3
@ 2000-12-19  0:58 Dieter Nützel
  0 siblings, 0 replies; 16+ messages in thread
From: Dieter Nützel @ 2000-12-19  0:58 UTC (permalink / raw)
  To: Linux Kernel List; +Cc: Rik Faith, Dri-devel, Alan Cox

> List:     linux-kernel
> Subject:  Re: test13-pre3 woes
> From:     Peter Samuelson <peter@cadcamlab.org>
> Date:     2000-12-18 9:19:13
> [Download message RAW]
>
>
> [J Sloan]
> > The module now compiles and gets installed -
> > Unfortunately, attempting to load it does not go well:
> >
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc
> > kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo
>
> Those symbols are rather generic and rather important.  Sounds like a
> generic module problem.  Do other modules load?  Does your kernel use
> MODVERSIONS?  (This module apparently doesn't.)  Are you using a recent
> version of modutils?
>
> Puzzled.  Maybe Keith Owens knows something.
>
> Peter

I got this, too. The one liner send here on lkm seems to be not enough. Even 
Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake 
this stuff. It works before these changes.
So Rik any comments?

Thanks,
	Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: nuetzel@kogs.informatik.uni-hamburg.de
@home: Dieter.Nuetzel@hamburg.de
-
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/

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2000-12-20  6:32 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-12-17 21:55 test13-pre3 Linus Torvalds
2000-12-17 23:43 ` test13-pre3 Albert Cranford
2000-12-18  5:50   ` test13-pre3 woes J Sloan
2000-12-18  6:03     ` Niels Kristian Bech Jensen
2000-12-18  8:51       ` J Sloan
2000-12-18  9:19         ` Peter Samuelson
2000-12-18 14:27           ` Olaf Titz
2000-12-19  0:01             ` J Sloan
2000-12-20  6:02         ` J Sloan
2000-12-18  6:00   ` test13-pre3 Peter Samuelson
2000-12-18 12:58 ` test13-pre3 Maciej W. Rozycki
2000-12-18 14:34 ` test13-pre3 Christoph Rohland
2000-12-18 19:24   ` test13-pre3 Christoph Rohland
  -- strict thread matches above, loose matches on Subject: below --
2000-12-18 17:35 test13-pre3 Petr Vandrovec
2000-12-18 17:18 ` test13-pre3 Maciej W. Rozycki
2000-12-19  0:58 test13-pre3 Dieter Nützel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox