installing slink on ss20 trials: lots of Q's.
(I originally wrote this to a local list, but am
also sending it to debian-sparc.)
Background: I have an intel 486 pc, and a sun
sparc station 20. The pc had been connected to my
external modem and that was the machine I was using
to connect to the internet (dialup isp). The SS20
was networked to the pc by ethernet 10baseT.
The PC was running Red Hat 5.1, the SS20 is now
running Debian slink (for sparc) although I also
experimented with RH 6.1 for sparc.
My PC hard disk was reporting an awful lot of
"sector not found" errors all of a sudden, making
the pc unuseable. So I tried to get the modem to
work with the SS20. The SS20 has 2 serial ports
coming out of one db25 connector. I had been
assuming that a null modem cable would be what
was required to connect the serial port to the
modem (as that was what I had heard about sparc
serial ports). However someone eventually suggested
to me to try a straight-through cable and what do
you know, it actually worked! So now I can dial up
to my isp from my sparc. The PC is still busted.
One day I'll try to get the data off the hard disk.
(no backups. blush)
It was later explained to me that perhaps the one
serial port marked (A/B) was really 2 nine-pin serial
ports, stuffed into a DB25 connector. Because it was
non-standard, the people making the hardware were free
to arrange the 9 pins of the A port to work with a
straight-through cable rather than the more traditional
sparc null-modem cable.
I had spent a week trying to debug the stupid serial port,
and it turned out that it was just the wrong cable.
So there you go.
In the meantime, I ran into some questions.
When I run setserial, it fails with "bad parameters". Just
what are the right parameters for this program, anyway?
I have seen the man page, and tried things like setserial
irq 44 port 0xffede004 and it complains about bad parameter
with that. I also looked at /etc/rc.boot/0setserial but
that calls setserial with parms that look suitable for a
pc, not a sparc. It's a good thing it fails, in this case...
In the dmesg output, it says:
...
Sparc Zilog8530 serial driver version 1.38
tty00 at 0xffede004 (irq = 44) is a Zilog 8530
tty01 at 0xffede000 (irq = 44) is a Zilog 8530
tty02 at 0xffede004 (irq = 44) is a Zilog 8530
tty03 at 0xffede000 (irq = 44) is a Zilog 8530
...
But /proc/interrupts says:
4: 739295 Sparc ESP SCSI
6: 637 LANCE
10: 21349319 + timer
12: 6661065 + Zilog8530
and /proc/ioports gives a bunch of addresses, from
fd000000-fd01afff contiguous and then
fff00000-fff0000f and finally
fff01000-fff0d21b.
ie, 0xffede00[04] are not reported in ioports.
Selected devices from /dev:
major minor
cua 5 64
tty0 4 0
ttyS0 4 64
(there is no tty00 in /dev)
So from this my guess is that the hardware is using interrupt
12 for the serial port but the driver is set to interrupt
44. How on earth does it work? And why does dmesg
refer to devices tty0[0-3] when I know my serial port
is attached to ttyS0?
Next question: I wanted to recompile the kernel to debug
the serial port (programmers always do these things the
hard way), and managed to get the intel source code out
of the debian package (argh, that was a trial in itself)
and apply the intel-to-sparc patch (another trial), and
compile a new kernel. I even ran the new kernel... However,
I never did figure out the right file format for multiple
kernels in /etc/silo.conf. It could always boot the first
kernel listed there, but got confused when I told it to
boot from the second kernel. I had to name the path
to the second kernel on the PROM command line in order
to boot the second kernel. So: what _is_ the right
silo file format? I tried looking in /etc/doc and
/etc/silo.conf but there was nothing overly useful.
I've unpacked the silo source and will try to tell
the config file format from the code that reads the
config file.
Also, the version-number extension trick didn't
seem to work for having multiple versions of the
modules directories, on Sparc.
Well this mail is quite long, I guess I'll leave it at
that. Except.... When I installed debian on this
system, 4 packages failed to configure and one
of them was lynx. The error was that dhelp-parse got
a segmentation fault when running. There was no
core file to debug, and trying to debug dhelp-parse
by running it from the command line wasn't very
useful as the symbols have been stripped, and sparc
assembly language is new to me :-) Also, I installed
libstdc++.2.9 at one point because some other package
depended on it, and that broke my X server. (It's
a known problem on the debian-sparc mailing list.) So I
am browser challenged at this point. After I get
the mailer (.muttrc, .procmailrc, .forward) configured
to my liking, I will address the X server by trying
to uninstall that 2.9 lib. I wish I could remember what
package it was that depended on it... Now dselect says
everything depends on it, even though I have a libstdc++.2.8
available.
I hope your computing experiences are better than
mine... Any suggestions you might have to address any of
my problems will be welcome! As I get solutions to them
I will post (summarizing if necessary).
cheerio,
bjb bjb@achilles.net
Reply to: