2.4.16 success on Decstation 5000/150

2.4.16 success on Decstation 5000/150

[Florian Lohoff]

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


Hi,
the current cvs (as of a couple hours ago) works without additional
patches on my Decstation 5000/150 like a charm:

record:/lib/modules/2.4.16# uname -a
Linux record.rfc822.org 2.4.16 #2 Sun Dec 2 22:24:58 CET 2001 mips
unknown
record:/lib/modules/2.4.16# cat /proc/cpuinfo 
processor		: 0
cpu model		: R4000SC V3.0  FPU V0.0
BogoMIPS		: 50.52
wait instruction	: no
microsecond timers	: yes
extra interrupt vector	: no
hardware watchpoint	: yes
VCED exceptions		: 10036
VCEI exceptions		: 65122

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ian Chilton]

Hello,

> the current cvs (as of a couple hours ago) works without additional
> patches on my Decstation 5000/150 like a charm:

It also worked for me earlier on an Indy R4600 - 1st kernel I have had
properly boot since 2.4-test9 IIRC.


/proc/cpuinfo output:

processor               : 0
cpu model               : R4600 V2.0  FPU V2.0
BogoMIPS                : 100.23
wait instruction        : yes
microsecond timers      : yes
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available


Bye for Now,

Ian

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Florian Lohoff]

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

On Mon, Dec 03, 2001 at 12:00:36AM +0000, Ian Chilton wrote:
> Hello,
> 
> > the current cvs (as of a couple hours ago) works without additional
> > patches on my Decstation 5000/150 like a charm:
> 
> It also worked for me earlier on an Indy R4600 - 1st kernel I have had
> properly boot since 2.4-test9 IIRC.

It basically comes up for me but is endlessly slow because i am getting
a mad interrupt - Putting an printk("I%d", irq) into do_IRQ shows 
IRQ 8 going mad ...

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ian Chilton]

Hello,

> It basically comes up for me but is endlessly slow because i am getting
> a mad interrupt - Putting an printk("I%d", irq) into do_IRQ shows 
> IRQ 8 going mad ...


Interesting. Does anyone know what IRQ 8 is?


Thanks

Ian

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ladislav Michl]

On Mon, 3 Dec 2001, Ian Chilton wrote:

> Hello,
> 
> > It basically comes up for me but is endlessly slow because i am getting
> > a mad interrupt - Putting an printk("I%d", irq) into do_IRQ shows 
> > IRQ 8 going mad ...
> 
> Interesting. Does anyone know what IRQ 8 is?

sure :-) IRQ 8 is FIFO full and was never used (and to be honest, i don't
know what that irq is used for). before Wed, 21 Nov 2001 17:49:32 +0100
it was General purpose local interrupt - this one was also never
used. see include/asm-mips/sgi/sgint23.h for more info.

i have no clue, why you're getting this interrupt. it works pretty well
for me...

laďa

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Florian Lohoff]

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

On Mon, Dec 03, 2001 at 05:34:40PM +0100, Ladislav Michl wrote:
> sure :-) IRQ 8 is FIFO full and was never used (and to be honest, i don't
> know what that irq is used for). before Wed, 21 Nov 2001 17:49:32 +0100
> it was General purpose local interrupt - this one was also never
> used. see include/asm-mips/sgi/sgint23.h for more info.
> 
> i have no clue, why you're getting this interrupt. it works pretty well
> for me...

Ok - the IRQ8 get enabled because i have CONFIG_RTC set and in
drivers/char/rtc.c around line 730 it requests:

if(request_irq(RTC_IRQ, rtc_interrupt, SA_INTERRUPT, "rtc", NULL))

Immediatly afterwards the massive ammount of IRQs. With 100Hz and 160
Chars across the screen - I would expect 1-2 lines/s on the screen.
Instead the screen fills up within tens of seconds which seems to me
like non acked IRQ.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ian Chilton]

Hello,

> Immediatly afterwards the massive ammount of IRQs. With 100Hz and 160
> Chars across the screen - I would expect 1-2 lines/s on the screen.
> Instead the screen fills up within tens of seconds which seems to me
> like non acked IRQ.

Weird..

Has any changes been made to the IRQ code lately?

Ralf - any ideas?


Bye for Now,

Ian

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ladislav Michl]

On Mon, 3 Dec 2001, Florian Lohoff wrote:

> Ok - the IRQ8 get enabled because i have CONFIG_RTC set and in
> drivers/char/rtc.c around line 730 it requests:
> 
> if(request_irq(RTC_IRQ, rtc_interrupt, SA_INTERRUPT, "rtc", NULL))

ehh, you compiled MC146818 driver for Indy... that's not good idea - IP22
uses Dallas DS1286 RAMified Watcgdog Timekeeper. Enable CONFIG_SGI_DS1286
if you want RTC driver.

> Immediatly afterwards the massive ammount of IRQs. With 100Hz and 160
> Chars across the screen - I would expect 1-2 lines/s on the screen.
> Instead the screen fills up within tens of seconds which seems to me
> like non acked IRQ.

strange... you enabled FIFO full interrupt and it really arrived!(?) I'm
really curious what that means. Unfortunately only few SGI engeneers know
how Indy works and they don't tell it anyone :-(

	laďa

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Florian Lohoff]

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

On Tue, Dec 04, 2001 at 08:41:40AM +0100, Ladislav Michl wrote:
> On Mon, 3 Dec 2001, Florian Lohoff wrote:
> 
> > Ok - the IRQ8 get enabled because i have CONFIG_RTC set and in
> > drivers/char/rtc.c around line 730 it requests:
> > 
> > if(request_irq(RTC_IRQ, rtc_interrupt, SA_INTERRUPT, "rtc", NULL))
> 
> ehh, you compiled MC146818 driver for Indy... that's not good idea - IP22
> uses Dallas DS1286 RAMified Watcgdog Timekeeper. Enable CONFIG_SGI_DS1286
> if you want RTC driver.

CONFIG_RTC is set by "Enhanced Real Time Clock Support" - It seems
there is something broken in the config system then ...

tristate 'Enhanced Real Time Clock Support' CONFIG_RTC
if [ "$CONFIG_IA64" = "y" ]; then
   bool 'EFI Real Time Clock Services' CONFIG_EFI_RTC
fi
if [ "$CONFIG_OBSOLETE" = "y" -a "$CONFIG_ALPHA_BOOK1" = "y" ]; then
   bool 'Tadpole ANA H8 Support'  CONFIG_H8
fi

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Geert Uytterhoeven]

On Tue, 4 Dec 2001, Florian Lohoff wrote:
> On Tue, Dec 04, 2001 at 08:41:40AM +0100, Ladislav Michl wrote:
> > On Mon, 3 Dec 2001, Florian Lohoff wrote:
> > 
> > > Ok - the IRQ8 get enabled because i have CONFIG_RTC set and in
> > > drivers/char/rtc.c around line 730 it requests:
> > > 
> > > if(request_irq(RTC_IRQ, rtc_interrupt, SA_INTERRUPT, "rtc", NULL))
> > 
> > ehh, you compiled MC146818 driver for Indy... that's not good idea - IP22
> > uses Dallas DS1286 RAMified Watcgdog Timekeeper. Enable CONFIG_SGI_DS1286
> > if you want RTC driver.
> 
> CONFIG_RTC is set by "Enhanced Real Time Clock Support" - It seems
> there is something broken in the config system then ...

Was something changed there?

I read a report from an APUS (PPC Amiga) user who suddenly had a PC-style RTC
in his kernel, causing crashes. Could of course still be a user problem, but
since you got bitten by the same thing...

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: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ladislav Michl]

On Tue, 4 Dec 2001, Florian Lohoff wrote:

> CONFIG_RTC is set by "Enhanced Real Time Clock Support" - It seems
> there is something broken in the config system then ...
> 
> tristate 'Enhanced Real Time Clock Support' CONFIG_RTC
> if [ "$CONFIG_IA64" = "y" ]; then
>    bool 'EFI Real Time Clock Services' CONFIG_EFI_RTC
> fi
> if [ "$CONFIG_OBSOLETE" = "y" -a "$CONFIG_ALPHA_BOOK1" = "y" ]; then
>    bool 'Tadpole ANA H8 Support'  CONFIG_H8
> fi

look to the drivers/sgi/Config.in instead

comment 'SGI devices'
bool 'SGI Zilog85C30 serial support' CONFIG_SGI_SERIAL
if [ "$CONFIG_SGI_SERIAL" = "y" ]; then
   bool '  Support for console on serial port' CONFIG_SERIAL_CONSOLE
fi
bool 'SGI DS1286  RTC support' CONFIG_SGI_DS1286

i know... we have special driver for SGI, special driver for some ARM
based boards, for some ...(a lot of clocks to list :-)). but, that's
living ;-) search linux-mips archives, there was long debate about this
month ago. personaly i don't like way how it works now, but i haven't time
nor knowledges to change it without breaking anything, so i'm happy that
it works somehow.

	laďa

Re: 2.4.16 success on Decstation 5000/150

[Houten K.H.C. van (Karel)]

Florian wrote:
> Hi,
> the current cvs (as of a couple hours ago) works without additional
> patches on my Decstation 5000/150 like a charm:
> 

I got the current CVS 2.5.0 kernel running on my 5000/260 too. Without any
patches. I hope to be able to compile a new root image, and update my
website in the next weeks.

-- 
Karel van Houten

----------------------------------------------------------
The box said "Requires Windows 95 or better."
I can't understand why it won't work on my Linux computer. 
----------------------------------------------------------

Re: 2.4.16 success on Decstation 5000/150

[Maciej W. Rozycki]

On Tue, 4 Dec 2001, Houten K.H.C. van (Karel) wrote:

> > the current cvs (as of a couple hours ago) works without additional
> > patches on my Decstation 5000/150 like a charm:
> 
> I got the current CVS 2.5.0 kernel running on my 5000/260 too. Without any
> patches. I hope to be able to compile a new root image, and update my
> website in the next weeks.

 Not surprising as the only difference between 2.4.16 and 2.5.0 is the
version number. ;-) 

 I'm glad 2.4.16 works sufficiently well for you. 

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

Re: 2.4.16 success on Decstation 5000/150

[Martin Schulze]

Maciej W. Rozycki wrote:
> On Tue, 4 Dec 2001, Houten K.H.C. van (Karel) wrote:
> 
> > > the current cvs (as of a couple hours ago) works without additional
> > > patches on my Decstation 5000/150 like a charm:
> > 
> > I got the current CVS 2.5.0 kernel running on my 5000/260 too. Without any
> > patches. I hope to be able to compile a new root image, and update my
> > website in the next weeks.
> 
>  Not surprising as the only difference between 2.4.16 and 2.5.0 is the
> version number. ;-) 

Err, that was 2.4.15 and 2.5.0, 2.4.16 contains at least the filesystem-uncorruption
feature, no?

Regards,

	Joey

-- 
Unix is user friendly ...  It's just picky about its friends.

Re: 2.4.16 success on Decstation 5000/150

[Maciej W. Rozycki]

On Tue, 4 Dec 2001, Martin Schulze wrote:

> Err, that was 2.4.15 and 2.5.0, 2.4.16 contains at least the filesystem-uncorruption
> feature, no?

 Yep, my mistake.  Better apply a 2.5.1 pre-patch to 2.5.0 or simply don't
run it then. 

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

Re: 2.4.16 success on Decstation 5000/150

[Klaus Naumann]

Morning ppl,

something wonderful happened - the Illegal Instruction Problem
which I had on my I2 magically went away using 2.4.16 from
current cvs.
Boots just fine.

	Cya, Klaus

root@ivy:~# cat /proc/cpuinfo
processor               : 0
cpu model               : R4000SC V6.0  FPU V0.0
BogoMIPS                : 100.44
wait instruction        : no
microsecond timers      : yes
extra interrupt vector  : no
hardware watchpoint     : yes
VCED exceptions         : 7269
VCEI exceptions         : 2267


-- 
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: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Florian Lohoff]

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

On Tue, Dec 04, 2001 at 10:18:45AM +0100, Ladislav Michl wrote:
> look to the drivers/sgi/Config.in instead
> 
> comment 'SGI devices'
> bool 'SGI Zilog85C30 serial support' CONFIG_SGI_SERIAL
> if [ "$CONFIG_SGI_SERIAL" = "y" ]; then
>    bool '  Support for console on serial port' CONFIG_SERIAL_CONSOLE
> fi
> bool 'SGI DS1286  RTC support' CONFIG_SGI_DS1286

I know that - I had that enabled too ...

> i know... we have special driver for SGI, special driver for some ARM
> based boards, for some ...(a lot of clocks to list :-)). but, that's
> living ;-) search linux-mips archives, there was long debate about this
> month ago. personaly i don't like way how it works now, but i haven't time
> nor knowledges to change it without breaking anything, so i'm happy that
> it works somehow.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
Nine nineth on september the 9th              Welcome to the new billenium

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ralf Baechle]

On Mon, Dec 03, 2001 at 10:44:01PM +0000, Ian Chilton wrote:

> > Immediatly afterwards the massive ammount of IRQs. With 100Hz and 160
> > Chars across the screen - I would expect 1-2 lines/s on the screen.
> > Instead the screen fills up within tens of seconds which seems to me
> > like non acked IRQ.
> 
> Weird..
> 
> Has any changes been made to the IRQ code lately?

There indeed were and the guilty person already sent me a few fixes which
I haven't applied yet.

  Ralf

Re: 2.4.16 success on Indy (was Re: 2.4.16 success on Decstation 5000/150)

[Ladislav Michl]

On Fri, 7 Dec 2001, Ralf Baechle wrote:

> > Has any changes been made to the IRQ code lately?
> 
> There indeed were and the guilty person already sent me a few fixes which
> I haven't applied yet.

There is another bug i know about. When you powerup machine calibrating
delay loop takes approx. 70 sec (on Indy 100MHz). It seems that no (timer)
interrupt arrive during this delay. I didn't notice that, because i only
rebooted machine when i was testing it (in this case, everything works
well). I'll fix it as soon (monday) as i return from mountains.

	Laďa

[PATCH] timer fix (was: Re: 2.4.16 success on Indy...)

[Ladislav Michl]

here it is. the only important change is of course in ip22-time.c
the rest is for better look and feel only :-)

Index: linux/arch/mips/sgi-ip22/ip22-reset.c
===================================================================
RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-reset.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 ip22-reset.c
--- linux/arch/mips/sgi-ip22/ip22-reset.c	2001/12/07 15:45:29	1.1.2.1
+++ linux/arch/mips/sgi-ip22/ip22-reset.c	2001/12/10 18:03:12
@@ -180,7 +180,7 @@
 	unsigned int buttons;
 
 	buttons = hpc3mregs->panel;
-	hpc3mregs->panel = 3; /* power_interrupt | power_supply_on */
+	hpc3mregs->panel = 0x03;	/* power_interrupt | power_supply_on */
 
 	if (ioc_icontrol->istat1 & 2) { /* Wait until interrupt goes away */
 		disable_irq(SGI_PANEL_IRQ);
@@ -190,7 +190,7 @@
 		add_timer(&debounce_timer);
 	}
 
-	if (!(buttons & 2))		/* Power button was pressed */
+	if (!(buttons & 0x02))		/* Power button was pressed */
 		power_button();
 	if (!(buttons & 0x40)) {	/* Volume up button was pressed */
 		init_timer(&volume_timer);
Index: linux/arch/mips/sgi-ip22/ip22-setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 ip22-setup.c
--- linux/arch/mips/sgi-ip22/ip22-setup.c	2001/12/07 15:45:29	1.1.2.1
+++ linux/arch/mips/sgi-ip22/ip22-setup.c	2001/12/10 18:03:13
@@ -61,7 +61,7 @@
 	   indy_setup wouldn't work since kmalloc isn't initialized yet.  */
 	indy_reboot_setup();
 
-	return request_irq(SGI_KEYBOARD_IRQ, handler, 0, "keyboard", NULL);
+	return request_irq(SGI_KEYBD_IRQ, handler, 0, "keyboard", NULL);
 }
 
 static int sgi_aux_request_irq(void (*handler)(int, void *, struct pt_regs *))
Index: linux/arch/mips/sgi-ip22/ip22-time.c
===================================================================
RCS file: /cvs/linux/arch/mips/sgi-ip22/ip22-time.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 ip22-time.c
--- linux/arch/mips/sgi-ip22/ip22-time.c	2001/12/07 15:45:29	1.1.2.1
+++ linux/arch/mips/sgi-ip22/ip22-time.c	2001/12/10 18:03:13
@@ -127,12 +127,11 @@
 	return ((ct1 - ct0) / 5000) * 5000;
 }
 
+/* 
+ * Here we need to calibrate the cycle counter to at least be close. 
+ */
 void indy_time_init(void)
 {
-	/* Here we need to calibrate the cycle counter to at least be close.
-	 * We don't need to actually register the irq handler because that's
-	 * all done in indyIRQ.S.
-	 */
 	struct sgi_ioc_timers *p;
 	volatile unsigned char *tcwp, *tc2p;
 	unsigned long r4k_ticks[3];
@@ -215,8 +214,16 @@
 
 static void indy_timer_setup(struct irqaction *irq)
 {
+	unsigned long count;
+	
 	/* over-write the handler, we use our own way */
 	irq->handler = no_action;
+
+	/* set time for first interrupt */
+	count = read_32bit_cp0_register(CP0_COUNT);
+	count += mips_counter_frequency / HZ;
+	write_32bit_cp0_register(CP0_COMPARE, count);
+
 	/* setup irqaction */
 	setup_irq(SGI_TIMER_IRQ, irq);
 }
Index: linux/include/asm-mips/sgi/sgint23.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/sgi/sgint23.h,v
retrieving revision 1.5
diff -u -r1.5 sgint23.h
--- linux/include/asm-mips/sgi/sgint23.h	2001/11/23 01:06:57	1.5
+++ linux/include/asm-mips/sgi/sgint23.h	2001/12/10 18:04:59
@@ -64,7 +64,7 @@
  * We map them to 0 */
 #define SGI_VERT_IRQ	SGINT_LOCAL2 + 0	/* INT3: newport vertical status */
 #define SGI_EISA_IRQ	SGINT_LOCAL2 + 3	/* EISA interrupts */
-#define SGI_KEYBOARD_IRQ	SGINT_LOCAL2 + 4	/* keyboard */
+#define SGI_KEYBD_IRQ	SGINT_LOCAL2 + 4	/* keyboard */
 #define SGI_SERIAL_IRQ	SGINT_LOCAL2 + 5	/* onboard serial */
 
 /* INT2 occupies HPC PBUS slot 4, INT3 uses slot 6. */
@@ -227,8 +227,5 @@
 extern struct sgi_ioc_ints *ioc_icontrol;
 extern struct sgi_ioc_timers *ioc_timers;
 extern volatile unsigned char *ioc_tclear;
-
-extern void sgint_init(void);
-extern void indy_timer_init(void);
 
 #endif /* _ASM_SGI_SGINT23_H */