RTC and SCSI for PowerStack/2.4.6 Kernel

RTC and SCSI for PowerStack/2.4.6 Kernel

[Jeff Rugen]

I've finally gotten a 2.4.x kernel to boot on my Motorola Powerstack (100MHz
604), but I'm having two problems.  I haven't found any info about them
searching the archives, so I'm wondering if anyone has seen/resolved the
problems I have, or can direct me to more information.

First of all, the boot hangs when executing /sbin/hwclock.  I have (or maybe
'had' now) the real-time-clock built as a module (in
drivers/macintosh/rtc.o), but the only thing I determined before commenting
out that line in rc.sysinit was that the machine hung when reaching that
point.  Is anyone successfully using the realtime clock on a Powerstack with
2.4.x, and if so, is there anything in particular that needs to be
done/patched/whatever?  /sbin/hwclock is from util-linux-2.10m-7c.

Second, I am getting SCSI timeouts when running 2.4.6.  I don't know enough
about SCSI, but the log to the console is the following:

scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 2, lun
0 0x
2a 00 00 0c 40 18 00 00 08 00
ncr53c8xx_abort: pid=0 serial_number=4257 serial_number_at_timeout=4257
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 2, lun
0 0x
2a 00 00 0c 40 48 00 00 08 00
ncr53c8xx_abort: pid=0 serial_number=4258 serial_number_at_timeout=4258
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 2, lun
0 0x
2a 00 00 0f 40 58 00 00 08 00
ncr53c8xx_abort: pid=0 serial_number=4259 serial_number_at_timeout=4259
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 2, lun
0 0x
2a 00 00 11 40 10 00 00 08 00
ncr53c8xx_abort: pid=0 serial_number=4260 serial_number_at_timeout=4260

When booting, the SCSI device is recognized as:
ncr53c8xx: at PCI bus 0, device 12, function 0
ncr53c8xx: 53c810 detected
ncr53c810-0: rev 0x2 on pci bus 0 device 12 function 0 irq 15
ncr53c810-0: ID 7, Fast-10, Parity Checking

Which leads me to believe that I at least have the correct SCSI driver build
(NCR53C8XX, as the revision of 0x2 is less than the 16 that Configure.help
seems to indicate).  Should I instead be using the 53c7,8xx driver?  Or the
sym53c8xx?

Thanks for any help.

Jeff


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Tom Rini]

On Sun, Jul 08, 2001 at 12:49:58AM -0700, Jeff Rugen wrote:

> I've finally gotten a 2.4.x kernel to boot on my Motorola Powerstack (100MHz
> 604), but I'm having two problems.  I haven't found any info about them
> searching the archives, so I'm wondering if anyone has seen/resolved the
> problems I have, or can direct me to more information.

Series E?  Got one right here, and I just booted 2_4_devel too :)

> First of all, the boot hangs when executing /sbin/hwclock.  I have (or maybe
> 'had' now) the real-time-clock built as a module (in
> drivers/macintosh/rtc.o), but the only thing I determined before commenting
> out that line in rc.sysinit was that the machine hung when reaching that
> point.  Is anyone successfully using the realtime clock on a Powerstack with
> 2.4.x, and if so, is there anything in particular that needs to be
> done/patched/whatever?  /sbin/hwclock is from util-linux-2.10m-7c.

That looks like an OK version of util-linux.  Try compiling CONFIG_RTC_PPC in
and not CONFIG_RTC.

> Second, I am getting SCSI timeouts when running 2.4.6.  I don't know enough
> about SCSI, but the log to the console is the following:

Consistant?  I saw this once when booting off the HD but not the next time.
Then I went back to NFS rooted.

> Which leads me to believe that I at least have the correct SCSI driver build
> (NCR53C8XX, as the revision of 0x2 is less than the 16 that Configure.help
> seems to indicate).  Should I instead be using the 53c7,8xx driver?  Or the
> sym53c8xx?

sym53c8xx will tell you unsupported chip.  I don't know if 53c7,8xx will work
but give it a shot, please. :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Jeff Rugen]

> That looks like an OK version of util-linux.  Try compiling CONFIG_RTC_PPC
in
> and not CONFIG_RTC.

That fixed /sbin/hwclock from hanging, thanks.

>
> > Second, I am getting SCSI timeouts when running 2.4.6.  I don't know
enough
> > about SCSI, but the log to the console is the following:
>
> Consistant?  I saw this once when booting off the HD but not the next
time.
> Then I went back to NFS rooted.

I've booted 2.4.6 successfully 4 times so far -- 2 times it crashed with
SCSI timeouts, and 2 times it hung for unknown reasons (with no oops output
or anything).  The second time it might have been framebuffer or network
related (I'd installed clgenfb, changed video modes, and then did 'dir' in
an ftp session to a site with a long directory listing twice -- the second
time it hung).

Did anything change in regards to oops output on crashes since 2.2.x?  I'm
not suprised that the kernel would crash/hang without producing any, but I
thought I'd ask to make sure.

> > Which leads me to believe that I at least have the correct SCSI driver
build
> > (NCR53C8XX, as the revision of 0x2 is less than the 16 that
Configure.help
> > seems to indicate).  Should I instead be using the 53c7,8xx driver?  Or
the
> > sym53c8xx?
>
> sym53c8xx will tell you unsupported chip.  I don't know if 53c7,8xx will
work
> but give it a shot, please. :)

53c7,8xx compiled after fixing two lines, but didn't work.  I emailed the
(old) driver supporter with the information (some of the output indicated to
email him, so I did).  I did try with the 10MHz support, and plan to try it
without, but haven't had the opportunity yet.

Jeff Rugen


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Benjamin Herrenschmidt]

>Did anything change in regards to oops output on crashes since 2.2.x?  I'm
>not suprised that the kernel would crash/hang without producing any, but I
>thought I'd ask to make sure.

2.4 can Oops instead of always panic'ing, but it's frequent that you
are too much locked up already to be able to read the oops report.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Tom Rini]

On Mon, Jul 09, 2001 at 07:38:58AM -0700, Jeff Rugen wrote:

> I've booted 2.4.6 successfully 4 times so far -- 2 times it crashed with
> SCSI timeouts, and 2 times it hung for unknown reasons (with no oops output
> or anything).  The second time it might have been framebuffer or network
> related (I'd installed clgenfb, changed video modes, and then did 'dir' in
> an ftp session to a site with a long directory listing twice -- the second
> time it hung).

Did you do any fixes/cleanups to clgenfb?  I took a stab and trying to
re-do your PReP fixes in it a while back, but I don't think it ever got
into the main tree.

> Did anything change in regards to oops output on crashes since 2.2.x?  I'm
> not suprised that the kernel would crash/hang without producing any, but I
> thought I'd ask to make sure.

Don't think so..  Network _should_ be fine.  The tulip driver is having
issues on some chipsets as of 2.4.5, but it'll either not work or work fine.
de4x5 still works great tho.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Geert Uytterhoeven]

On Mon, 9 Jul 2001, Tom Rini wrote:
> On Mon, Jul 09, 2001 at 07:38:58AM -0700, Jeff Rugen wrote:
> > I've booted 2.4.6 successfully 4 times so far -- 2 times it crashed with
> > SCSI timeouts, and 2 times it hung for unknown reasons (with no oops output
> > or anything).  The second time it might have been framebuffer or network
> > related (I'd installed clgenfb, changed video modes, and then did 'dir' in
> > an ftp session to a site with a long directory listing twice -- the second
> > time it hung).
>
> Did you do any fixes/cleanups to clgenfb?  I took a stab and trying to
> re-do your PReP fixes in it a while back, but I don't think it ever got
> into the main tree.

There's still an off-by-one error in the PCI probing. Patch below from the m68k
tree (which needs other fixes for Zorro boards).

Hmmm, perhaps you still need the <asm/io.h> for PCI. Please let me know...

--- linux-2.4.6/drivers/video/clgenfb.c	Fri Mar 30 14:27:05 2001
+++ linux-m68k-2.4.6/drivers/video/clgenfb.c	Thu Jul  5 14:52:08 2001
@@ -46,7 +46,7 @@
 #include <linux/init.h>
 #include <linux/selection.h>
 #include <asm/pgtable.h>
-#include <asm/io.h>
+
 #ifdef CONFIG_ZORRO
 #include <linux/zorro.h>
 #endif
@@ -286,22 +286,28 @@
 static const struct {
 	clgen_board_t btype;
 	zorro_id id, id2;
+	unsigned long size;
 } clgen_zorro_probe_list[] __initdata = {
 	{ BT_SD64,
 		ZORRO_PROD_HELFRICH_SD64_RAM,
-		ZORRO_PROD_HELFRICH_SD64_REG },
+		ZORRO_PROD_HELFRICH_SD64_REG,
+		0x400000 },
 	{ BT_PICCOLO,
 		ZORRO_PROD_HELFRICH_PICCOLO_RAM,
-		ZORRO_PROD_HELFRICH_PICCOLO_REG },
+		ZORRO_PROD_HELFRICH_PICCOLO_REG,
+		0x200000 },
 	{ BT_PICASSO,
 		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_RAM,
-		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_REG },
+		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_II_II_PLUS_REG,
+		0x200000 },
 	{ BT_SPECTRUM,
 		ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_RAM,
-		ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_REG },
+		ZORRO_PROD_GVP_EGS_28_24_SPECTRUM_REG,
+		0x200000 },
 	{ BT_PICASSO4,
 		ZORRO_PROD_VILLAGE_TRONIC_PICASSO_IV_Z3,
-		0 },
+		0,
+		0x400000 },
 };
 #endif /* CONFIG_ZORRO */

@@ -1479,7 +1485,8 @@
 		WGen (fb_info, VGA_PEL_MSK, 0xff);	/* pixel mask: pass-through all planes */
 #ifdef CONFIG_PCI
 		WHDR (fb_info, 0xc0);	/* Copy Xbh */
-#elif CONFIG_ZORRO
+#elif defined(CONFIG_ZORRO)
+		/* FIXME: CONFIG_PCI and CONFIG_ZORRO may be defined both */
 		WHDR (fb_info, 0xa0);	/* hidden dac reg: nothing special */
 #endif
 		vga_wseq (fb_info->regs, VGA_SEQ_MEMORY_MODE, 0x0a);	/* memory mode: chain4, ext. memory */
@@ -1918,16 +1925,7 @@
 		break;
 	}

-#ifdef CLGEN_USE_HARDCODED_RAM_SETTINGS
-	/* "pre-set" a RAMsize; if the test succeeds, double it */
-	if (fb_info->btype == BT_SD64 ||
-	    fb_info->btype == BT_PICASSO4)
-		fb_info->size = 0x400000;
-	else
-		fb_info->size = 0x200000;
-#else
 	assert (fb_info->size > 0); /* make sure RAM size set by this point */
-#endif

 	/* assume it's a "large memory" board (2/4 MB) */
 	fb_info->smallboard = FALSE;
@@ -2434,7 +2432,7 @@
 		while ((pdev = pci_find_device (PCI_VENDOR_ID_CIRRUS,
 				clgen_pci_probe_list[i].device, pdev)) != NULL) {
 			if (pci_enable_device(pdev) == 0) {
-				*btype = clgen_pci_probe_list[i - 1].btype;
+				*btype = clgen_pci_probe_list[i].btype;
 				DPRINTK ("EXIT, returning pdev=%p\n", pdev);
 				return pdev;
 			}
@@ -2572,7 +2570,7 @@
 #ifdef CONFIG_ZORRO
 static int __init clgen_zorro_find (struct zorro_dev **z_o,
 				    struct zorro_dev **z2_o,
-				    clgen_board_t *btype)
+				    clgen_board_t *btype, unsigned long *size)
 {
 	struct zorro_dev *z = NULL;
 	int i;
@@ -2590,7 +2588,8 @@
 			*z2_o = zorro_find_device(clgen_zorro_probe_list[i].id2, NULL);
 		else
 			*z2_o = NULL;
-		*btype = clgen_zorro_probe_list[i - 1].btype;
+		*btype = clgen_zorro_probe_list[i].btype;
+		*size = clgen_zorro_probe_list[i].size;

 		printk (KERN_INFO "clgen: %s board detected; ",
 			clgen_board_info[*btype].name);
@@ -2621,12 +2620,12 @@
 				     clgen_board_t *btype)
 {
 	struct zorro_dev *z = NULL, *z2 = NULL;
-	unsigned long board_addr, board_size;
+	unsigned long board_addr, board_size, size;

 	assert (info != NULL);
 	assert (btype != NULL);

-	if (clgen_zorro_find (&z, &z2, btype))
+	if (clgen_zorro_find (&z, &z2, btype, &size))
 		return -1;

 	assert (z > 0);
@@ -2635,6 +2634,7 @@

 	info->board_addr = board_addr = z->resource.start;
 	info->board_size = board_size = z->resource.end-z->resource.start+1;
+	info->size = size;

 	if (!request_mem_region(board_addr, board_size, "clgenfb")) {
 		printk(KERN_ERR "clgen: cannot reserve region 0x%lx, abort\n",
@@ -2704,7 +2704,8 @@
 		return -ENXIO;
 	}

-#elif CONFIG_ZORRO
+#elif defined(CONFIG_ZORRO)
+	/* FIXME: CONFIG_PCI and CONFIG_ZORRO may be defined both */
 	if (clgen_zorro_setup (fb_info, &btype)) {
 		DPRINTK ("EXIT, returning -ENXIO\n");
 		return -ENXIO;
@@ -2966,7 +2967,7 @@
 #ifdef CONFIG_ZORRO
 	assert (fb_info->regs != NULL);
 	fb_info->SFR = val;
-	writeb (val, fb_info->regs + 0x8000);
+	z_writeb (val, fb_info->regs + 0x8000);
 #endif
 }

@@ -2978,7 +2979,7 @@
 	/* to flip to Amiga display */
 	assert (fb_info->regs != NULL);
 	fb_info->SFR = val;
-	writeb (val, fb_info->regs + 0x9000);
+	z_writeb (val, fb_info->regs + 0x9000);
 #endif
 }

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Tom Rini]

On Mon, Jul 09, 2001 at 05:08:50PM +0200, Geert Uytterhoeven wrote:
> On Mon, 9 Jul 2001, Tom Rini wrote:
> > On Mon, Jul 09, 2001 at 07:38:58AM -0700, Jeff Rugen wrote:
> > > I've booted 2.4.6 successfully 4 times so far -- 2 times it crashed with
> > > SCSI timeouts, and 2 times it hung for unknown reasons (with no oops output
> > > or anything).  The second time it might have been framebuffer or network
> > > related (I'd installed clgenfb, changed video modes, and then did 'dir' in
> > > an ftp session to a site with a long directory listing twice -- the second
> > > time it hung).
> >
> > Did you do any fixes/cleanups to clgenfb?  I took a stab and trying to
> > re-do your PReP fixes in it a while back, but I don't think it ever got
> > into the main tree.
>
> There's still an off-by-one error in the PCI probing.

Yeap. :)  Dan Malek found that one a while ago too, but I keep forgetting I've
got it sitting around.  Will this patch be going towards Linus anytime soon?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Jeff Garzik]

thanks, applied
--
Jeff Garzik      | A recent study has shown that too much soup
Building 1024    | can cause malaise in laboratory mice.
MandrakeSoft     |

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Jeff Rugen]

On Mon, 9 Jul 2001, Tom Rini wrote:

> Did you do any fixes/cleanups to clgenfb?  I took a stab and trying to
> re-do your PReP fixes in it a while back, but I don't think it ever got
> into the main tree.
>

No, I don't have any changes from the official 2.4.6 kernel except for
adding __ in front of a couple functions (change_bit and
test_and_change_bit, I think) in one or two places, and some code where I
was experimenting with setting the parallel port in ECP or EPP
mode.  Everything else appears to be whitespace differences or in drivers
that I'm not using or don't seem to work (quickcam and 53c7,8xx).

I did have VGA console be the default, and installed clgenfb as a module.

On a related note, the endianness issue with gpm seems to also show up
when running the VGA console -- any text that is written to a non-visible
virtual terminal is not byte-swapped, so it appears to be garbage when you
switch back to that virtual terminal.  This isn't a problem when running
clgenfb as the terminal though (I don't know how gpm worked in either
mode).

Jeff Rugen


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Olaf Hering]

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

On Mon, Jul 09, Jeff Rugen wrote:

> I did have VGA console be the default, and installed clgenfb as a module.

Is there a way to rmmod the module later?
The colors are wrong in X whit >8bit and the console is slow with fbcon :)

> On a related note, the endianness issue with gpm seems to also show up
> when running the VGA console -- any text that is written to a non-visible
> virtual terminal is not byte-swapped, so it appears to be garbage when you
> switch back to that virtual terminal.  This isn't a problem when running
> clgenfb as the terminal though (I don't know how gpm worked in either
> mode).

The attached patch fix that, but it seems to be wrong.
Geert said the shadow buffer is stored in native endian. The VGA text
console itself is the "shadow buffer" for the foreground console and
little endian.



Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

[-- Attachment #2: y_ppc_2.4.5_vga_console.diff --]
[-- Type: text/plain, Size: 977 bytes --]

--- linux-2.4.5/include/asm-ppc/vga.h	Tue May 22 00:02:06 2001
+++ linux-2.4.5.vgafix/include/asm-ppc/vga.h	Mon May 28 11:50:48 2001
@@ -15,11 +15,11 @@

 #include <linux/config.h>

-#if defined(CONFIG_VGA_CONSOLE) || defined(CONFIG_MDA_CONSOLE)
+#if defined(CONFIG_VGA_CONSOLE)

 #define VT_BUF_HAVE_RW
 /*
- *  These are only needed for supporting VGA or MDA text mode, which use little
+ *  These are only needed for supporting VGA text mode, which use little
  *  endian byte ordering.
  *  In other cases, we can optimize by using native byte ordering and
  *  <linux/vt_buffer.h> has already done the right job for us.
@@ -38,7 +38,11 @@
 #define VT_BUF_HAVE_MEMCPYW
 #define scr_memcpyw	memcpy

-#endif /* !CONFIG_VGA_CONSOLE && !CONFIG_MDA_CONSOLE */
+#define VT_BUF_HAVE_MEMCPYF
+#define scr_memcpyw_from memcpy
+#define scr_memcpyw_to memcpy
+
+#endif /* CONFIG_VGA_CONSOLE */

 extern unsigned long vgacon_remap_base;
 #define VGA_MAP_MEM(x) (x + vgacon_remap_base)

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Jeff Rugen]

On Mon, 9 Jul 2001, Olaf Hering wrote:

> On Mon, Jul 09, Jeff Rugen wrote:
>
> > I did have VGA console be the default, and installed clgenfb as a module.
>
> Is there a way to rmmod the module later?
> The colors are wrong in X whit >8bit and the console is slow with fbcon :)
>

I haven't tried removing it, but as far as I know, support for that still
isn't there.  I tended to use Xbh rather than XFBDev for my X server,
because Xbh it at least had some acceleration in it.  But I am still using
3.3.6 (or something like that) for X.  I don't know if Xbh is downloadable
from anywhere these days, but I had planned on playing with X once 2.4.x
is relatively stable on my machine.  What version of X do people run on
the PowerStack these days (if at all)?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Olaf Hering]

On Mon, Jul 09, Jeff Rugen wrote:

> On Mon, 9 Jul 2001, Olaf Hering wrote:
>
> > On Mon, Jul 09, Jeff Rugen wrote:
> >
> > > I did have VGA console be the default, and installed clgenfb as a module.
> >
> > Is there a way to rmmod the module later?
> > The colors are wrong in X whit >8bit and the console is slow with fbcon :)
> >
>
> I haven't tried removing it, but as far as I know, support for that still
> isn't there.  I tended to use Xbh rather than XFBDev for my X server,
> because Xbh it at least had some acceleration in it.  But I am still using
> 3.3.6 (or something like that) for X.  I don't know if Xbh is downloadable
> from anywhere these days, but I had planned on playing with X once 2.4.x
> is relatively stable on my machine.  What version of X do people run on
> the PowerStack these days (if at all)?

I run 4.1.0 and it appears to be usable with "fbdev" as driver. It
should be faster than3.3.6.
There must be a copy of Xbh somewhere, but it segfaulted for me last
time I tried it (and removed it from the distro ;). Maybe the hardware
didnt match :)
I could put it in pneguinppc.org if needed.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: RTC and SCSI for PowerStack/2.4.6 Kernel

[Tom Rini]

On Sun, Jul 08, 2001 at 12:49:58AM -0700, Jeff Rugen wrote:

> Second, I am getting SCSI timeouts when running 2.4.6.  I don't know enough
> about SCSI, but the log to the console is the following:
>

Boy, I hope you're still around to play with things :)
Can you try the sym-2 driver in recent (2.4.16+ kernels?).  I've been
doing some quick testing of my machine, and things seem OK so far.

> Which leads me to believe that I at least have the correct SCSI driver build
> (NCR53C8XX, as the revision of 0x2 is less than the 16 that Configure.help
> seems to indicate).  Should I instead be using the 53c7,8xx driver?  Or the
> sym53c8xx?

BTW, the sym53c8xx driver won't do the 810 or 825 chipsets, iirc.  The
53c7,8xx driver needs a bit of work (it's still got an hold hack for PPC
that I _think_ can just go, but I'm not sure...).  The sym-2 driver does
all 8xx chipsets and some of the newer 10xx chipsets.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/