AS500/266 trouble

From: Kurt Garloff (garloff@suse.de)
Date: Mon Apr 15 2002 - 11:53:06 EST


Hi,

I have some trouble with an AlphaStation 500/266 and would like to ask
for hints.
Hardware: AS500 with 21164-266, Bret MoBo (Alcor), 288MB Ram, qlogic isp
1020 connected to two hard disks and CD-Rom, S3virge PCI video hardware.
It has the latest available firmware (7.2-2, ARC 4.58)

I have three problems:

(1) I can't get the machine to boot via ARC/MILO
    "Swapping to palcode at 0x0" is the last thing I see.
    Afterwards, I need the reset button.
    This happens with both SL7.1 AXP milo and with a self-compiled one.
    (milo-2.2.18 with 2.2.19 kernel)
    So I have to boot via SRM from a floppy. (I dislike the VMS/OSF
    partitioning scheme even more than the DOS one.)

(2) I can't get a 2.4.18 kernel to work:
    The qlogicisp driver/hardware seems to trigger some weird machine check.
    
 Linux version 2.4.18 (root@pebbles) (gcc version 2.96 20000731 (SuSE Linux 7.1/Alpha)) #16 Mon Apr 15 19:28:18 CEST 2002
 Booting on Alcor variation Alcor using machine vector Alcor from SRM
 Command line: ro root=/dev/sda6 console=ttyS0,115200 console=tty0
 [...]
 pci: cia revision 1
 On node 0 totalpages: 36747
 [...]
 pci: passed tb register update test
 pci: failed sg loopback i/o read test (0xac8000 != 0xdeadbeef)
 pci: disabling sg translation window
 [...]
 SCSI subsystem driver Revision: 1.00
 qlogicisp : new isp1020 revision ID (2)
 scsi0 : QLogic ISP1020 SCSI on PCI bus 00 device 48 irq 28 I/O base 0x9400
 CIA machine check NOT expected!!!
 CIA machine check: vector=0x660 pc=0xfffffc00003124a4 code=0x0
 machine check type: unknown
 pc = [<fffffc00003124a4>] ra = [<fffffc00003124c0>] ps = 0007 Not tainted
 v0 = 0000000000000000 t0 = ffffffffffffffff t1 = 0000000000000000
 t2 = 0000000000000001 t3 = 0000000000000001 t4 = fffffc000056c640
 t5 = fffffffffffffc18 t6 = fffffc00005b0d90 t7 = fffffc0000568000
 a0 = 0000000000000019 a1 = 0000000000000032 a2 = 0000000000000100
 a3 = 0000000000000000 a4 = fffffc0000470ab0 a5 = 0000000000001800
 t8 = 0000000000000000 t9 = 000000002a7d999b t10= 0000000000000000
 t11= fffffc000061a798 pv = fffffc000031e440 at = 0000000000000000
 gp = fffffc000060fc20 sp = fffffc000056bf90
   + 0 00000000000 0000000000000000 0000000000000000
   + 30 0000000000000000 0000000000000000
   + 40 0000000000000000 0000000000000000
   + 50 0000000000000000 0000000000000000
   + 60 ffffffffffffffff fffffc0000310b20
   + 70 0000000000005200 0000000000000001
   + 80 fffffc000056c640 fffffffffffffc18
   + 90 fffffc0000310780 1f1e161514020100
   + a0 fffffc0000310d58 fffffc00003124a4
   + b0 fffffc00003105c0 fffffc0000310700
   + c0 0000000000000a0d 00000000000000e8
   + d0 00000000000001e8 0000000006600001
   + e0 0000000000000000 0000000000000000
   + f0 fffffc0000adb8a0 0000000000300000
   + 100 fffffc0000310640 fffffc000060fc20
   + 110 00000000005683e8 fffffc00003124a4
   + 120 0000000000000000 0000000000000000
   + 130 0000000000018000 0000000000000000
   + 140 0000004164000000 0000000000000000
   + 150 0000000000000000 0000000010130b88
   + 160 00000000000148d0 ffffff0000644d6f
   + 170 0000000000000000 ffffff80002d6fff
   + 180 ffffffffffffffff 0000000000002880
   + 190 fffffff004ffffff ffffff000056802f
   + 1a0 ffffffffffe00000 0000000000001087
   + 1b0 0000000000000000 0000000000000018
   + 1c0 0000000000000c12 0000000000000000
   + 1d0 ffffffffffe00000 0000000002100000
   + 1e0 000000000e010806 0000000040008840
   + 1f0 0000000000000000 ffffffff80b62000
    
    Compiling a generic SRM kernel does not help.
    Under 2.2.19 (from SL7.1 AXP), it behaves:
    
 Inspecting /boot/System.map-2.2.19
 Loaded 10635 symbols from /boot/System.map-2.2.19.
 Symbols match kernel version 2.2.19.
 No module symbols loaded.
 klogd 1.3-3, log source = ksyslog started.
 Linux version 2.2.19 (root@Fullinst.suse.de) (gcc version 2.96 20000731 (SuSE Linux 7.1/Alpha)) #2 Tue Apr 24 08:57:32 GMT 2001
 Booting GENERIC on Alcor variation Alcor using machine vector Alcor from SRM
 Command line: ro root=/dev/sda6
 [...]
 Alpha PCI BIOS32 revision 0.04
 PCI: Probing PCI hardware
 [...]
 qlogicisp : new isp1020 revision ID (2)
  scsi0 : QLogic ISP1020 SCSI on PCI bus 00 device 48 irq 28 I/O base 0xa000
 scsi : 1 host.
   Vendor: DEC Model: RRD45 (C) DEC Rev: 1645
   Type: CD-ROM ANSI SCSI revision: 02
 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 4, lun 0
   Vendor: IBM Model: DDRS-34560W Rev: S97B
   Type: Direct-Access ANSI SCSI revision: 02
 Detected scsi disk sda at scsi0, channel 0, id 6, lun 0
   Vendor: QUANTUM Model: ATLAS_V__9_WLS Rev: 0230
   Type: Direct-Access ANSI SCSI revision: 03
 Detected scsi disk sdb at scsi0, channel 0, id 8, lun 0
 scsi : detected 1 SCSI cdrom 2 SCSI disks total.
 Uniform CD-ROM driver Revision: 3.11
 SCSI device sda: hdwr sector= 512 bytes. Sectors= 8925000 [4357 MB] [4.4 GB]
 SCSI device sdb: hdwr sector= 512 bytes. Sectors= 17930694 [8755 MB] [8.8 GB]
 Partition check:
  sda: sda1 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 >
  sdb: sdb4 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 >
 md.c: sizeof(mdp_super_t) = 4104
    
    A few things are remarkable:
    * 2.2.19 uses irq 28 I/O base 0xa000 whereas 2.4.18
      tries to use irq 28 I/O base 0x9400.
      I'd think that these things are setup by SRM, no?
    * The machine check does not always occur. Especially, if I enable
      serial console or enable DEBUG printks in qlogicisp, the SCSI
      command tends to endlessly time out instead.
    * The pc (ffff fc00 0031 24c0) is near the end of cpu_idle
      (and probably unrelated to the machine check, as it's coming from
       the CIA.)
    * I enabled DEBUG_MCHECK, as you can see ...
    
(3) Using 2.2.19 (from SL7.1, booted via SRM), I can't get
    XFree86-4.2 to work. I did not (yet) try any other version
    of XF86.
    XFree86.0.log is attached.

Any hints would be appreciated.

Regards,

-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security



- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html



This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 22:00:01 EST