Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

[Malcolm Beattie]

Eddie C. Dost writes:
> could you test-boot the appended kernel via network on your Ultra5 and
> tell me if this fixes the bug you are seeing? - This will not get you
> in the Ultrapenguin install, but ultrapenguin will be updated ASAP if
> this works...

It doesn't fix them but there's more debugging telemetry for you:

ebus0: ...
ebus1: ...
'auxio': addresses
fffff9fff1726000
fffff9fff1728000
fffff9fff172a000
fffff9fff172c000
fffff9fff172f000
'power':address
fffff9fff1724000
IRQ c2800025
'SUNW,pll:
fffff9fff1504000
se: fffff9fff1400000
IRQ c580002b
su: fffff9fff13083f8
IRQ c500002a
ecpp: fffff9fff13043bc
fffff9fff130015c
fffff9fff1700000
IRQ c1000022
fdthree: fffff9fff13023f0
fffff9fff1706000
720000
IRQ c3800027
eeprom: fffff9fff1000000
flashprom: fffff9fff0000000 (sic for the f0)
SUNW,CS4231: fffff9fff1200000
fffff9fff1702000
fffff9fff1704000
fffff9fff1722000
IRQs c1800023 c2000024
mach64_init: IOBASE...
mach64_init: chip_type...
bug in for_each_ebusdev, bus 0000000000000000


Thenn, overlayed on the top of the screen by the SUN prom:

Cannot find auxio node, cannot continue...
Program terminated
ok



The owner of the box is wanting to put Solaris on it early next week
so I still have a day or two in which to try things. In case it helps,
the SCSI+ethernet card is the hme (not mentioned above). Thanks for
the quick turnaround for this test kernel.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

[Malcolm Beattie]

Eddie C. Dost writes:
> > Eddie C. Dost writes:
> > > could you test-boot the appended kernel via network on your Ultra5 and
> > > tell me if this fixes the bug you are seeing? - This will not get you
> > > in the Ultrapenguin install, but ultrapenguin will be updated ASAP if
> > > this works...
> > 
> > It doesn't fix them but there's more debugging telemetry for you:
> > 
> > ebus0: ...
> > ebus1: ...
> 
> Hmmm there might be an empty ebus on your HME card, please try the following
> image...

First, here's the data you requested in the previous message:

cd /pci
ls
f00600f8 pci@1
f005fb10 pci@1,1
cd pci@1
ls
f007d690 pci@1
cd pci@1,1
Device not found
cd /pci/pci@1,1       (Playing by ear, I hoped this is what you meant)
ls
f0079ed0 ide@3
f00755d0 SUNW,m64B@2
f006d5c8 network@1,1
f0060e60 ebus@1
cd ebus
ls
f00665b8 SUNW,CS4231@14,200000
....flashprom...
....eeprom...
....
....power...
....auxio...


Then I tried booting the image you sent above.

boot net
....
ebus0: ...
ebus1: ...
mach64_init: IOBASE...
mach64_init: chip_type...


Then the boot PROM overlayed the message:

    clock_probe: Cannot find timer chip
    Program terminated
    ok


Thanks for your continued fast responses. The good news is that
despite this Ultra5 becoming unavailable next week, I'm getting an
Ultra5 of my own RSN in order to continue development of our new mail
server cluster. Though that'll be mainly for Solaris (I lost the
battle to use Linux/Intel...although I'm keeping my options open in
case ultralinux stabilises), I can make it dual boot Linux and help
out somewhat.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

[Malcolm Beattie]

Eddie C. Dost writes:
> OK cd pci@1
> OK ls
> [...]
> 
> I.e. show the listing of /pci/pci@1/pci@1, please?

f008671c SUNW,isptwo@4
f007e438 SUNW,hme@0,1
f007e1e8 pci108e,1000@0

> Also I have another image for you.

This one gets to the same place as the last ones (mach64_init) and
then the boot PROM messages says

    clock_probe: Mostek not probed by EBUS
    Program terminated

The next time round the mulberry bush, the machine's owner will
probably be putting/have put Solaris on it. However, I will probably
be able to schedule a time with him when I can try booting up new
test images. I would guess that, when it arrives, my Ultra5 will
have the problem (it'll be similarly configured: same vendor's
standard academic configuration plus the same add-on SunSwift card
that the current beast has). In that case, I can carry on trying
things out on that one for as long as you're prepared to send me
test images.

Thanks,
--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

[Malcolm Beattie]

Eddie C. Dost writes:
> > f008671c SUNW,isptwo@4
> > f007e438 SUNW,hme@0,1
> > f007e1e8 pci108e,1000@0
> 
> Ahh, this 'pci108e,1000' is the second ebus bugging us...
> 
> >     clock_probe: Mostek not probed by EBUS
> >     Program terminated
> 
> Shit, another image...

Congratulations, this one gets through the entire boot stage
successfully and then gives the VFS "can't mount root" panic.
I assume this is intentional for these test images. It gives
539 BogoMIPS, sees both hme0 and hme1 ethernet cards, finds the
IDE disk partitions OK and generally looks fine. When mine
arrives and the fixes get merged into the UP dist, I can do a
proper install and take things from there. Many thanks for the
quick turnaround of fixes, Eddie.

I'll have access to an Enterprise 450 within the next few days
(destined to use Solaris but I can play with it for a while,
I should thing). Is ultralinux known to work fine with those or
is it worth me trying to boot it and see what happens?

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

[Malcolm Beattie]

Eddie C. Dost writes:
> > I'll have access to an Enterprise 450 within the next few days
> > (destined to use Solaris but I can play with it for a while,
> > I should thing). Is ultralinux known to work fine with those or
> > is it worth me trying to boot it and see what happens?
> 
> Please try, it _should_ work, but has not been tested much...

The first attempt at booting the E450 with pure UltraPenguin 1.0.9:

    OpenBoot 3.7 512 MB memory...
    ...
    Initialising 1 megs of memory at addr 1fe00000
    Initialising 2 megs of memory at addr 1fc02000
    Initialising 508 megs of memory at addr 0
    ...
    boot net
    ...
    Server IP address ...
    Client IP address ...
    TILO
    Couldn't get translation property
    Program terminated
    ok

I then retried with the last test image that you sent me for the Ultra5
and that apparently booted successfully and just panicked at the
"can't mount root fs on 00:00" stage which I assume is intentional.
Amongst the boot messages was a complaint about the NCRc875 SCSI HBA
about sharing fast and slow IRQs followed by a "...detaching" message.
However, it went on to find the "scsi: 1 hosts" and a list of
partitions on sda so it wasn't completely broken.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: [mbeattie@sable.ox.ac.uk: oops booting ultrapenguin-1.0.9 on an

[Malcolm Beattie]

Eddie C. Dost writes:
> > I then retried with the last test image that you sent me for the Ultra5
> > and that apparently booted successfully and just panicked at the
> > "can't mount root fs on 00:00" stage which I assume is intentional.
> > Amongst the boot messages was a complaint about the NCRc875 SCSI HBA
> > about sharing fast and slow IRQs followed by a "...detaching" message.
> > However, it went on to find the "scsi: 1 hosts" and a list of
> > partitions on sda so it wasn't completely broken.
> 
> Ah, the ncr driver uses SA_INTERRUPT, which should never be used on
> Sparc PCI IRQs... Please try this test image:

Looks good to me: it seems to find both busses and the CD-ROM and
disk which are each on a different bus.

ncr53c8xx: at PCI bus 4, device 2, function 0
ncr53c8xx: 53c875 detected
ncr53c8xx: at PCI bus 4, device 3, function 0
ncr53c8xx: 53c875 detected
ncr53c875-0: rev=0x03, base=0x1ff80012000 io_port=0xfffff9fe02010800
  irq=0xc30007e6
ncr53c875-0: NCR clock is 40218 KHz, 40218 KHz
ncr53c875-0: ID 7, Fast-20 Parity Checking
ncr53c875-0: on-board RAM at 0x1ff80013000
ncr53c875-0: restart (scsi reset).
ncr53c875-0: copying script fragments into the on-board RAM...
ncr53c875-1: rev=0x03, base=0x1ff80010000 io_port=0xfffff9fe02010400
  irq=0xc30007e0
ncr53c875-1: NCR clock is 40218 KHz, 40218 KHz
ncr53c875-1: ID 7, Fast-20 Parity Checking
ncr53c875-1: on-board RAM at 0x1ff80011000
ncr53c875-1: restart (scsi reset).
ncr53c875-1: copying script fragments into the on-board RAM...
scsi0 : ncr53c8xx - revision 2.5f
scsi1 : ncr53c8xx - revision 2.5f
scsi: 2 hosts
Vendor: TOSHIBA ...
Type: CD-ROM ...
Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0
ncr53c875-1-<0,0>: using tagged command queuing, opts 12 cmds/lun
Vendor: FUJITSU ...
Type: Direct-Access ...
Detected scsi disk sda at scsi1, channel 0, id 0, lun 0
ncr53c875-0-<6,0>: FAST-10 SCSI 10.0 MB/s (100ns, offset 8)
ncr53c875-1-<0,0>: FAST-10 WIDE SCSI 20.0 MB/s (100ns, offset 16)

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services