Decstation broken Was: CVS Update@oss.sgi.com: linux

Decstation broken Was: CVS Update@oss.sgi.com: linux

[Florian Lohoff]

On Fri, Aug 25, 2000 at 02:31:06PM -0700, Ralf Baechle wrote:
> CVSROOT:	/home/pub/cvs
> Module name:	linux
> Changes by:	ralf@oss.sgi.com	00/08/25 14:30:56
> 
> Modified files:
> 	arch/mips      : Makefile 
> 	arch/mips/dec  : Makefile int-handler.S irq.c setup.c time.c 
> 	include/asm-mips: addrspace.h div64.h 
> 	include/asm-mips/dec: interrupts.h ioasic_addrs.h kn02xa.h 
> 	                      kn03.h 
> Added files:
> 	include/asm-mips/dec: ioasic.h 
> 
> Log message:
> 	NTP fixes from Maciej.

Hi,
since this commit my machines are all broken (5000/260, 5000/150 
and 5000/125) - They all hang in the "Calibrating delay loop ...".

Reverting it let me boot the current kernels ...

Maciej ?

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Klaus Naumann]

On Thu, 28 Sep 2000 21:40:02 Florian Lohoff wrote:
> Hi,
> since this commit my machines are all broken (5000/260, 5000/150 
> and 5000/125) - They all hang in the "Calibrating delay loop ...".
> 
> Reverting it let me boot the current kernels ...
> 
> Maciej ?

BTW: What did you actually fix ? ntpdate still doesn't work
while ntpd seems to work ok.
But ntpdate would be a very good idea because ntpd doesn't handle
large offsets ...
And obviously the realtime clock of the Indigo2 doesn't work 
correctly. So I was calling ntpdate at every bootup to get my 
system in a usable state. Maciej, can you take a look at ntpdate 
please ?

	TIA, Klaus

-- 
Full Name   : Klaus Naumann     | (http://www.mgnet.de/) (Germany)
Nickname    : Spock             | Org.: Mad Guys Network
Phone / FAX : ++49/177/7862964  | E-Mail: (spock@mgnet.de)
PGP Key     : www.mgnet.de/keys/key_spock.txt

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Thu, Sep 28, 2000 at 10:00:46PM +0200, Klaus Naumann wrote:

> BTW: What did you actually fix ? ntpdate still doesn't work
> while ntpd seems to work ok.

The NTP API was outdated.

What is the sympthom you observe with ntpdate?

> But ntpdate would be a very good idea because ntpd doesn't handle
> large offsets ...
> And obviously the realtime clock of the Indigo2 doesn't work 
> correctly. So I was calling ntpdate at every bootup to get my 
> system in a usable state. Maciej, can you take a look at ntpdate 
> please ?

I recently found that the Indigo2 apparently has a different realtime
clock from the Indy.  If that's true it explains your observation and
is unrelated the other problems.

  Ralf

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Klaus Naumann]

On Fri, 29 Sep 2000 01:39:54 Ralf Baechle wrote:
> On Thu, Sep 28, 2000 at 10:00:46PM +0200, Klaus Naumann wrote:
> 
> > BTW: What did you actually fix ? ntpdate still doesn't work
> > while ntpd seems to work ok.
> 
> The NTP API was outdated.
> 
> What is the sympthom you observe with ntpdate?

When I call it it's sleeping for several seconds.
And after that I get

29 Sep 07:49:37 ntpdate[10880]: poll(): nfound = 0, error: Operation not
permitted

which seems to loop then.
If I would have a working strace on my box I could tell you more :/

 
> > But ntpdate would be a very good idea because ntpd doesn't handle
> > large offsets ...
> > And obviously the realtime clock of the Indigo2 doesn't work 
> > correctly. So I was calling ntpdate at every bootup to get my 
> > system in a usable state. Maciej, can you take a look at ntpdate 
> > please ?
> 
> I recently found that the Indigo2 apparently has a different realtime
> clock from the Indy.  If that's true it explains your observation and
> is unrelated the other problems.

Yes, it's of course unrelated to the other problem - it's just
an explanation why ntpdate is of real use.

		CU, Klaus

-- 
Full Name   : Klaus Naumann     | (http://www.mgnet.de/) (Germany)
Nickname    : Spock             | Org.: Mad Guys Network
Phone / FAX : ++49/177/7862964  | E-Mail: (spock@mgnet.de)
PGP Key     : www.mgnet.de/keys/key_spock.txt

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Thu, 28 Sep 2000, Florian Lohoff wrote:

> since this commit my machines are all broken (5000/260, 5000/150 
> and 5000/125) - They all hang in the "Calibrating delay loop ...".

 Well, I asked for testing before the commit, but nobody bothered to write
anything, so I assumed everything is correct, sigh...

 OK, the /240 is definitely tested (the uptime of my -test7 was three
weeks before I rebooted to test NFS problems) so /260 should work for you. 
But the latter is R4K.  As Ralf already remarked me in a separate mail,
64-bit registers can get corrupted for the 32-bit kernel (but 64-bit code
is used throughout the kernel, strange), so please change the "#if
_MIPS_ISA" at the beginning of include/asm-mips/div64.h into "#if 1" and
tell me if it works for the /260. 

 As for the rest -- /125 is R3K, right?  Chances are I made a stupid
mistake and defined an address macro wrong.  I'll dig through the changes
and see (/150 should be no problem once /125 works, as it's the same issue
as /240 vs /260).  If I can't find anything relevant, please expect
certain debugging patches from me for the /125 path.

 Note that these are hi-res timer changes rather than NTP fixes, BTW -- my
communication channel with Ralf got corrupted somehow at one time. 
Although the code affects the performance of NTP handling, there were
separate NTP changes, as well. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Fri, 29 Sep 2000, Klaus Naumann wrote:

> When I call it it's sleeping for several seconds.
> And after that I get
> 
> 29 Sep 07:49:37 ntpdate[10880]: poll(): nfound = 0, error: Operation not
> permitted
> 
> which seems to loop then.
> If I would have a working strace on my box I could tell you more :/

 But gdb works -- try this one instead.

> > I recently found that the Indigo2 apparently has a different realtime
> > clock from the Indy.  If that's true it explains your observation and
> > is unrelated the other problems.
> 
> Yes, it's of course unrelated to the other problem - it's just
> an explanation why ntpdate is of real use.

 Well, all programs from the xntp3 distribution do work for me.  This may
also be a glibc issue -- I'm using glibc 2.2 only and this provides a
better API for NTP (clock_settime() and friends).  I'll double-check that
settimeofday() works right, too.

 But note that my patches do really affect only the DEC tree.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Florian Lohoff]

On Fri, Sep 29, 2000 at 11:36:07AM +0200, Maciej W. Rozycki wrote:
>  OK, the /240 is definitely tested (the uptime of my -test7 was three
> weeks before I rebooted to test NFS problems) so /260 should work for you. 
> But the latter is R4K.  As Ralf already remarked me in a separate mail,
> 64-bit registers can get corrupted for the 32-bit kernel (but 64-bit code
> is used throughout the kernel, strange), so please change the "#if
> _MIPS_ISA" at the beginning of include/asm-mips/div64.h into "#if 1" and
> tell me if it works for the /260. 

Sorry for the confusion - It seems i was inaccurate - I tried on
the /260 and it works ... See attached - Ill retry the /125 in a minute.

Loading R4000 MMU routines.
CPU revision is: 00000440
Primary instruction cache 16kb, linesize 16 bytes.
Primary data cache 16kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 32 bytes.
Linux version 2.4.0-test8-pre1 (flo@slimer.rfc822.org) (gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)) #1 Fri Sep 29 19:45:47 GMT 2000
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS2 root=/dev/sda5
Calibrating delay loop... 59.90 BogoMIPS
Memory: 62736k/65536k available (1204k kernel code, 2800k reserved, 76k data, 56k init)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
TURBOchannel rev. 1 at 25.0 MHz (no parity)
    slot 0: DEC      PMAF-AA  T5.2P-  
    slot 1: DEC      PMAZ-AA  V5.3d   
    slot 2: DEC      PMAZ-AA  V5.3d   
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
Starting kswapd v1.7
pty: 256 Unix98 ptys configured
SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236)
SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236)
SCSI ID 7 Clk 25MHz CCF=5 TOut 167 NCR53C9x(esp236)
ESP: Total of 3 ESP hosts found, 3 actually in use.
scsi0 : ESP236 (NCR53C9x)
scsi1 : ESP236 (NCR53C9x)
scsi2 : ESP236 (NCR53C9x)
scsi : 3 hosts.
esp0: hoping for msgout
  Vendor: IBM       Model: DGHS18Z           Rev: 03B0
  Type:   Direct-Access                      ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
  Vendor: DEC       Model: RZ23L    (C) DEC  Rev: 2528
  Type:   Direct-Access                      ANSI SCSI revision: 01 CCS
Detected scsi disk sdb at scsi0, channel 0, id 3, lun 0
scsi : detected 2 SCSI disks total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 35843670 [17501 MB] [17.5 GB]
Partition check:
 sda: sda1 < sda5 sda6 sda7 sda8 sda9 >
esp0: target 3 [period 252ns offset 8 3.96MHz synchronous SCSI]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 237588 [116 MB] [0.1 GB]
 sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8
DECstation Z8530 serial driver version 0.03
tty00 at 0xbf900001 (irq = 4) is a Z85C30 SCC
tty01 at 0xbf900009 (irq = 4) is a Z85C30 SCC
tty02 at 0xbf980001 (irq = 4) is a Z85C30 SCC
tty03 at 0xbf980009 (irq = 4) is a Z85C30 SCC
rtc: Digital DECstation epoch (2000) detected
Real Time Clock Driver v1.10d
declance.c: v0.008 by Linux Mips DECstation task force
eth0: IOASIC onboard LANCE, addr = 08:00:2b:2b:be:bc, irq = 3


-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Florian Lohoff]

On Fri, Sep 29, 2000 at 11:36:07AM +0200, Maciej W. Rozycki wrote:
>  As for the rest -- /125 is R3K, right?  Chances are I made a stupid

Yep

> mistake and defined an address macro wrong.  I'll dig through the changes
> and see (/150 should be no problem once /125 works, as it's the same issue
> as /240 vs /260).  If I can't find anything relevant, please expect
> certain debugging patches from me for the /125 path.

/125 dies 

>>boot
1532656+0+141200
This DECstation is a DS5000/1xx
Loading R[23]00 MMU routines.
CPU revision is: 00000230
Primary instruction cache 64kb, linesize 4 bytes
Primary data cache 64kb, linesize 4 bytes
Linux version 2.4.0-test8-pre1 (flo@slimer.rfc822.org) (gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)) #1 Fri Sep 29 20:09:51 GMT 2000
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS2 root=/dev/sda1
Calibrating delay loop... 

Hang ...

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Fri, Sep 29, 2000 at 11:36:07AM +0200, Maciej W. Rozycki wrote:

>  Well, I asked for testing before the commit, but nobody bothered to write
> anything, so I assumed everything is correct, sigh...

Not sigh ...  The lesson that not speaking up is a also wrong!

>  OK, the /240 is definitely tested (the uptime of my -test7 was three
> weeks before I rebooted to test NFS problems) so /260 should work for you. 
> But the latter is R4K.  As Ralf already remarked me in a separate mail,
> 64-bit registers can get corrupted for the 32-bit kernel (but 64-bit code
> is used throughout the kernel, strange), so please change the "#if
> _MIPS_ISA" at the beginning of include/asm-mips/div64.h into "#if 1" and
> tell me if it works for the /260. 

The ddiv usage outside of do_div / do_div64_32 is actually ok because
interrupts are always disabled.  We don't have the same guarantee for
do_div / do_div64_32 calls.

Hmm...  We got two error scenarios left - bus errors and cache errors.  If
we get one of those doomsday is near anyway ...  Anyway, these are rare,
so we rather make these exception handlers pay the price.

  Ralf

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Geert Uytterhoeven]

On Fri, 29 Sep 2000, Florian Lohoff wrote:
> tty00 at 0xbf900001 (irq = 4) is a Z85C30 SCC
> tty01 at 0xbf900009 (irq = 4) is a Z85C30 SCC
> tty02 at 0xbf980001 (irq = 4) is a Z85C30 SCC
> tty03 at 0xbf980009 (irq = 4) is a Z85C30 SCC

Shouldn't these be reported as ttyS0[0-3]?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Sun, Oct 01, 2000 at 11:40:41AM +0200, Geert Uytterhoeven wrote:

> On Fri, 29 Sep 2000, Florian Lohoff wrote:
> > tty00 at 0xbf900001 (irq = 4) is a Z85C30 SCC
> > tty01 at 0xbf900009 (irq = 4) is a Z85C30 SCC
> > tty02 at 0xbf980001 (irq = 4) is a Z85C30 SCC
> > tty03 at 0xbf980009 (irq = 4) is a Z85C30 SCC
> 
> Shouldn't these be reported as ttyS0[0-3]?

Search for tty% in the serial drivers - it's actually a widespread mistake ...

  Ralf

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Florian Lohoff]

On Sat, Sep 30, 2000 at 12:18:23PM +0200, Ralf Baechle wrote:
> On Fri, Sep 29, 2000 at 11:36:07AM +0200, Maciej W. Rozycki wrote:
> 
> >  Well, I asked for testing before the commit, but nobody bothered to write
> > anything, so I assumed everything is correct, sigh...
> 
> Not sigh ...  The lesson that not speaking up is a also wrong!
> 

I talked to a couple of people and everybody thought they made something
wrong and waited ...

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Fri, 29 Sep 2000, Florian Lohoff wrote:

> Sorry for the confusion - It seems i was inaccurate - I tried on
> the /260 and it works ... See attached - Ill retry the /125 in a minute.

 Good -- I was really wondering what would be wrong here -- the only
difference between the /260 and the (well-tested) /240 path is the use of
cycle counter routines and they weren't changed seriously.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Fri, 29 Sep 2000, Florian Lohoff wrote:

> >>boot
> 1532656+0+141200
> This DECstation is a DS5000/1xx
> Loading R[23]00 MMU routines.
> CPU revision is: 00000230
> Primary instruction cache 64kb, linesize 4 bytes
> Primary data cache 64kb, linesize 4 bytes
> Linux version 2.4.0-test8-pre1 (flo@slimer.rfc822.org) (gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)) #1 Fri Sep 29 20:09:51 GMT 2000
> On node 0 totalpages: 4096
> zone(0): 4096 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: console=ttyS2 root=/dev/sda1
> Calibrating delay loop... 

 I've looked through the code thoroughly and I cannot find the point of
failure.  Please try the following patch and report the addresses that get
printed after "dec_irq_setup".

 What versions of tools do you use?  Could you please provide me a
preprocessed copy of int-handler.S and a copy of int-handler.o?

 Thanks,

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

diff -u --recursive --new-file linux-mips-2.4.0-test8-20000829.macro/arch/mips/dec/setup.c linux-mips-2.4.0-test8-20000829/arch/mips/dec/setup.c
--- linux-mips-2.4.0-test8-20000829.macro/arch/mips/dec/setup.c	Sat Sep 30 16:33:17 2000
+++ linux-mips-2.4.0-test8-20000829/arch/mips/dec/setup.c	Sat Sep 30 17:32:26 2000
@@ -27,6 +27,8 @@
 #include <asm/dec/ioasic_addrs.h>
 #include <asm/dec/ioasic_ints.h>
 
+#define IOASIC_DEBUG
+
 extern asmlinkage void decstation_handle_int(void);
 
 void dec_init_kn01(void);
@@ -98,6 +100,13 @@
 	break;
     }
     set_except_vector(0, decstation_handle_int);
+#ifdef IOASIC_DEBUG
+    printk("dec_irq_setup: MMIO addresses:\n");
+    printk("I/O ASIC base: %p\n", ioasic_base);
+    printk("I/O ASIC SIR : %p\n", isr);
+    printk("I/O ASIC SIMR: %p\n", imr);
+    printk("RTC base     : %p\n", dec_rtc_base);
+#endif
 }
 
 /*
diff -u --recursive --new-file linux-mips-2.4.0-test8-20000829.macro/arch/mips/dec/time.c linux-mips-2.4.0-test8-20000829/arch/mips/dec/time.c
--- linux-mips-2.4.0-test8-20000829.macro/arch/mips/dec/time.c	Sat Sep 30 16:34:12 2000
+++ linux-mips-2.4.0-test8-20000829/arch/mips/dec/time.c	Sat Sep 30 17:52:30 2000
@@ -31,6 +31,8 @@
 
 #include <asm/div64.h>
 
+#define R4K_DEBUG
+
 extern volatile unsigned long wall_jiffies;
 extern rwlock_t xtime_lock;
 
@@ -548,11 +550,16 @@
 
 	init_cycle_counter();
 
+#ifndef R4K_DEBUG
 	if (cyclecounter_available) {
+		printk("time_init: using CP0.COUNT for do_gettimeoffset()...\n");
 		write_32bit_cp0_register(CP0_COUNT, 0);
 		do_gettimeoffset = do_fast_gettimeoffset;
 		irq0.handler = r4k_timer_interrupt;
-	} else if (IOASIC) {
+	} else
+#endif
+	if (IOASIC) {
+		printk("time_init: using IOASIC.FCTR for do_gettimeoffset()...\n");
 		ioasic_write(FCTR, 0);
 		do_gettimeoffset = do_ioasic_gettimeoffset;
 		irq0.handler = ioasic_timer_interrupt;
diff -u --recursive --new-file linux-mips-2.4.0-test8-20000829.macro/include/asm-mips/div64.h linux-mips-2.4.0-test8-20000829/include/asm-mips/div64.h
--- linux-mips-2.4.0-test8-20000829.macro/include/asm-mips/div64.h	Sat Aug 26 04:26:45 2000
+++ linux-mips-2.4.0-test8-20000829/include/asm-mips/div64.h	Sat Sep 30 17:47:57 2000
@@ -12,11 +12,14 @@
 
 #include <asm/sgidefs.h>
 
+#define DIV64_DEBUG
+
 /*
  * No traps on overflows for any of these...
  */
 
-#if (_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2)
+#if defined(DIV64_DEBUG) || \
+	(_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2)
 
 #define do_div64_32(res, high, low, base) ({ \
 	unsigned long __quot, __mod; \

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Sat, 30 Sep 2000, Ralf Baechle wrote:

> >  Well, I asked for testing before the commit, but nobody bothered to write
> > anything, so I assumed everything is correct, sigh...
> 
> Not sigh ...  The lesson that not speaking up is a also wrong!

 Well, if nobody reports a problem with a patch, it means it's either fine
or nobody bothered to test it.  For me both cases mean it's OK to apply
it. 

> The ddiv usage outside of do_div / do_div64_32 is actually ok because

 But can't we receive an exception for some reason???

> interrupts are always disabled.  We don't have the same guarantee for
> do_div / do_div64_32 calls.

 Yep -- it's used for printk.

> Hmm...  We got two error scenarios left - bus errors and cache errors.  If
> we get one of those doomsday is near anyway ...  Anyway, these are rare,
> so we rather make these exception handlers pay the price.

 I'd see two approaches: either wipe 64-bit code out completely (clean and
elegant -- I'd vote for it, even though there is performance penalty) or
disable interrupts around the 64-bit division (the window would be small
and it would still be a performance win, but it's ugly as hell).  What do
you think? 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Ralf Baechle]

On Mon, Oct 02, 2000 at 01:59:03PM +0200, Maciej W. Rozycki wrote:

> > >  Well, I asked for testing before the commit, but nobody bothered to write
> > > anything, so I assumed everything is correct, sigh...
> > 
> > Not sigh ...  The lesson that not speaking up is a also wrong!
> 
>  Well, if nobody reports a problem with a patch, it means it's either fine
> or nobody bothered to test it.  For me both cases mean it's OK to apply
> it. 

Sure.

> > The ddiv usage outside of do_div / do_div64_32 is actually ok because
> 
>  But can't we receive an exception for some reason???

No, the only exceptions we still may have to deal with are asynchronous
ones, that is cache error and bus error.  Oh yes, trace exception on
certain special CPUs that have support for tracing in hw.

> > interrupts are always disabled.  We don't have the same guarantee for
> > do_div / do_div64_32 calls.
> 
>  Yep -- it's used for printk.

>  I'd see two approaches: either wipe 64-bit code out completely (clean and
> elegant -- I'd vote for it, even though there is performance penalty) or
> disable interrupts around the 64-bit division (the window would be small
> and it would still be a performance win, but it's ugly as hell).  What do
> you think? 

I have a nice little solution, we can wrap the divide with ll / sc.  If
the sc ever fails we took an exception and retry ...

(I think I just felt like comming up with a coding stunt ;-)

  Ralf

RE: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Harald Koerfgen]

Hi,

On 28-Sep-00 Florian Lohoff wrote:
[...]

> since this commit my machines are all broken (5000/260, 5000/150 
> and 5000/125) - They all hang in the "Calibrating delay loop ...".

Fixed.

-- 
Regards,
Harald

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Tue, 3 Oct 2000, Ralf Baechle wrote:

> I have a nice little solution, we can wrap the divide with ll / sc.  If
> the sc ever fails we took an exception and retry ...

 Could be, but I'm still uncertain whether we want to keep 64-bit code at
all. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

RE: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Tue, 3 Oct 2000, Harald Koerfgen wrote:

> > since this commit my machines are all broken (5000/260, 5000/150 
> > and 5000/125) - They all hang in the "Calibrating delay loop ...".
> 
> Fixed.

 Thanks -- I've found the typo yesterday evening, too.  I knew it must
have been a stupid error.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Maciej W. Rozycki]

On Sun, 1 Oct 2000, Geert Uytterhoeven wrote:

> > tty00 at 0xbf900001 (irq = 4) is a Z85C30 SCC
> > tty01 at 0xbf900009 (irq = 4) is a Z85C30 SCC
> > tty02 at 0xbf980001 (irq = 4) is a Z85C30 SCC
> > tty03 at 0xbf980009 (irq = 4) is a Z85C30 SCC
> 
> Shouldn't these be reported as ttyS0[0-3]?

 Ralf, could you please apply?  Thanks.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

diff -u --recursive --new-file linux-mips-2.4.0-test7-20000829.macro/drivers/char/dz.c linux-mips-2.4.0-test7-20000829/drivers/char/dz.c
--- linux-mips-2.4.0-test7-20000829.macro/drivers/char/dz.c	Fri Jun 30 04:26:16 2000
+++ linux-mips-2.4.0-test7-20000829/drivers/char/dz.c	Mon Oct  2 22:27:38 2000
@@ -1047,7 +1047,7 @@
   }
 
   if (--info->count < 0) {
-    printk("ds_close: bad serial port count for ttys%d: %d\n",
+    printk("ds_close: bad serial port count for ttyS%02d: %d\n",
 	   info->line, info->count);
     info->count = 0;
   }
@@ -1379,7 +1379,7 @@
     if (! info->port)
       return 0;
 
-    printk("ttyS%02d at 0x%04x (irq = %d)\n", info->line, info->port, SERIAL);
+    printk("ttyS%02d at 0x%08x (irq = %d)\n", info->line, info->port, SERIAL);
   }
 
   /* reset the chip */
diff -u --recursive --new-file linux-mips-2.4.0-test7-20000829.macro/drivers/tc/zs.c linux-mips-2.4.0-test7-20000829/drivers/tc/zs.c
--- linux-mips-2.4.0-test7-20000829.macro/drivers/tc/zs.c	Fri Aug 11 04:26:34 2000
+++ linux-mips-2.4.0-test7-20000829/drivers/tc/zs.c	Mon Oct  2 22:25:15 2000
@@ -623,7 +623,7 @@
 	save_flags(flags); cli();
 
 #ifdef SERIAL_DEBUG_OPEN
-	printk("starting up ttyS%d (irq %d)...", info->line, info->irq);
+	printk("starting up ttyS%02d (irq %d)...", info->line, info->irq);
 #endif
 
 	/*
@@ -1258,7 +1258,7 @@
 	}
 	
 #ifdef SERIAL_DEBUG_OPEN
-	printk("rs_close ttys%d, count = %d\n", info->line, info->count);
+	printk("rs_close ttyS%02d, count = %d\n", info->line, info->count);
 #endif
 	if ((tty->count == 1) && (info->count != 1)) {
 		/*
@@ -1273,7 +1273,7 @@
 		info->count = 1;
 	}
 	if (--info->count < 0) {
-		printk("rs_close: bad serial port count for ttys%d: %d\n",
+		printk("rs_close: bad serial port count for ttyS%02d: %d\n",
 		       info->line, info->count);
 		info->count = 0;
 	}
@@ -1463,7 +1463,7 @@
 	retval = 0;
 	add_wait_queue(&info->open_wait, &wait);
 #ifdef SERIAL_DEBUG_OPEN
-	printk("block_til_ready before block: ttys%d, count = %d\n",
+	printk("block_til_ready before block: ttyS%02d, count = %d\n",
 	       info->line, info->count);
 #endif
 	cli();
@@ -1499,7 +1499,7 @@
 			break;
 		}
 #ifdef SERIAL_DEBUG_OPEN
-		printk("block_til_ready blocking: ttys%d, count = %d\n",
+		printk("block_til_ready blocking: ttyS%02d, count = %d\n",
 		       info->line, info->count);
 #endif
 		schedule();
@@ -1510,7 +1510,7 @@
 		info->count++;
 	info->blocked_open--;
 #ifdef SERIAL_DEBUG_OPEN
-	printk("block_til_ready after blocking: ttys%d, count = %d\n",
+	printk("block_til_ready after blocking: ttyS%02d, count = %d\n",
 	       info->line, info->count);
 #endif
 	if (retval)
@@ -1600,7 +1600,7 @@
 	info->pgrp = current->pgrp;
 
 #ifdef SERIAL_DEBUG_OPEN
-	printk("rs_open ttys%d successful...", info->line);
+	printk("rs_open ttyS%02d successful...", info->line);
 #endif
 /* tty->low_latency = 1; */
 	return 0;
@@ -1817,7 +1817,7 @@
 		info->normal_termios = serial_driver.init_termios;
 		init_waitqueue_head(&info->open_wait);
 		init_waitqueue_head(&info->close_wait);
-		printk("tty%02d at 0x%08x (irq = %d)", info->line, 
+		printk("ttyS%02d at 0x%08x (irq = %d)", info->line, 
 		       info->port, info->irq);
 		printk(" is a Z85C30 SCC\n");
 	}

RE: Decstation broken Was: CVS Update@oss.sgi.com: linux

[Harald Koerfgen]

On 03-Oct-00 Maciej W. Rozycki wrote:
> On Tue, 3 Oct 2000, Harald Koerfgen wrote:
> 
>> > since this commit my machines are all broken (5000/260, 5000/150 
>> > and 5000/125) - They all hang in the "Calibrating delay loop ...".
>> 
>> Fixed.
> 
>  Thanks -- I've found the typo yesterday evening, too.  I knew it must
> have been a stupid error.

Exactly this type of error is often enough difficult to find. At least for the
one who wrote it :)

-- 
Regards,
Harald