the "native" OS of the old HP workstations is HP-UX, but just out of curiosity I've tried to install Linux on one of my C8000. Installing
using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux
PARISC Wiki succeeded without problems, but I couldn't install any
updates. During the installation, the installer asks for the radeon
firmware R300_cp.bin, but I continued the installation without it.
Installing /lib/firmware/radeon/R300_cp.bin afterwards breaks the
system, it crashes during booting.
This is also the case after an "apt-get update;apt-get upgrade".Latest debian-unstable packages do work on the c8000.
I've then tried to install debian-9.0-Stretch-hppa-NETINST-1.iso and debian-10.0-hppa-NETINST-1.iso, but here the installer crashesYes, that's known and is being worked on. That's not c8000 specific.
already shortly after entering the locale information.
Did anybody succeed in installing a more recent version than debian-8.0?
Installing using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux PARISC Wiki succeeded without problems, but I couldn't install
any updates.
For example I can imaginge that you manually need to upgrade the
palo boot code on the hard disc boot sector before reboot
is there a manual or procedure how to do?
I can install debian but after upgrade it doesn't boot anymore...
-------- Original-Nachricht --------
An 12. März 2019, 15:01, Helge Deller schrieb:
Hi Lothar,
On 12.03.19 14 <tel:12031914>:31, Lothar Paltins wrote:
> the "native" OS of the old HP workstations is HP-UX, but just out of
> curiosity I've tried to install Linux on one of my C8000 <tel:8000>. Installing
> using a CD with debian-8.0-hppa-CD-1.iso as described in the Linux
> PARISC Wiki succeeded without problems, but I couldn't install any
> updates. During the installation, the installer asks for the radeon
> firmware R300 <tel:300>_cp.bin, but I continued the installation without it.
Correct, PA-Linux currently doesn't support the Radeon cards in the C8000 <tel:8000>.
> Installing /lib/firmware/radeon/R300 <tel:300>_cp.bin afterwards breaks the
> system, it crashes during booting.
It shouldn't crash with a recent kernel. Can you post the crash dump?
> This is also the case after an "apt-get update;apt-get upgrade".
Latest debian-unstable packages do work on the c8000 <tel:8000>.
Some of the debian buildd servers are c8000 <tel:8000> machines running latest
debian unstable packages.
So, can you maybe also give some more info what happens when you
upgrade?
For example I can imaginge that you manually need to upgrade the
palo boot code on the hard disc boot sector before reboot.
> I've then tried to install debian-9.0-Stretch-hppa-NETINST-1.iso and
> debian-10.0 <tel:100>-hppa-NETINST-1.iso, but here the installer crashes
> already shortly after entering the locale information.
Yes, that's known and is being worked on. That's not c8000 <tel:8000> specific.
> Did anybody succeed in installing a more recent version than debian-8.0?
I do (with upgrades from debian-8).
Helge
Updates are only available for unstable (sid) as hppa isn't a Debian release architecture. You need to edit /etc/apt/sources.list to access
packages
from unstable.
thanks for the answer. Something must have gone wrong here. I'veVery good!
repeated the upgrade and now it works!
I did save the disk partition images directly after the installation
and before the upgrade. I cloned them to a different disk and
repeated the update/upgrade. This time it was successful and it still
works after a reboot. I will now try to reinstall R300_cp.bin and see
what happens.
BTW, I've seen, that the UUID of the root partition is hard coded in
the kernel command line in the first MB of the disk. To avoid
problems with duplicate UUIDs, I've changed the partition UUIDs of
the cloned disk and therefore the boot loader didn't find the root
partition. I've changed it directly on the disk, but what is the
"official" way to change the parameters of the boot loader?
I did save the disk partition images directly after the installationUnless you want to debug why the ring test fails on parisc when loading
and before the upgrade. I cloned them to a different disk and
repeated the update/upgrade. This time it was successful and it still
works after a reboot. I will now try to reinstall R300_cp.bin and see
what happens.
the ATI card driver, I'd suggest to skip that.
Helge is right. Unless you are a ATI graphics card expert, you
won't be able to fix the ring test failure.
I've tried to send a reply to the list with an attachment, but it seems,
that it was silently ignored. I'm now sending it without the attachment.
Am 14.03.19 um 00:17 schrieb John David Anglin:
Helge is right. Unless you are a ATI graphics card expert, you
won't be able to fix the ring test failure.
I don't want to fix it, although my profession as a software engineer
was the development and debugging of hardware control software. But I'm
not an ATI graphics card expert and I think the graphics acceleration
isn't very important. I don't want to do real work on this more than 13
years old machine. It's slow compared to current machines and it
consumes almost 300W of electrical power without any load. All of my HP workstations are just museum pieces and to be authentic, all of them are running HP-UX, except for this one C8000.
But anyway, it's interesting to see that an almost current Linux runs on
it.
But it seems to be a little bit fragile. I booted it today and all
messages on the serial console seemed to be correct, but the connected monitor didn't show the KDE login screen, neither via the DVI nor the
VGA connector. I tried to log in blindly and this worked, but the
desktop was displayed only on the VGA connector. I logged out from the session and logged in again, but then the system freezes up after the
desktop background was drawn.
I had to switch it off and after powering it up again it crashedOf course that's not how it should be. I assume this is based on the fact
during the next booting. But eventually, after booting the machine a
third time, everything works again as before.
There are only a lot of "unaligned access" messages on the console
coming from KDE applications, but I guess, that's a known issue.
I've taken a photo of the console with the backtrace after the crash,
but it doesn't seem to be possible to send a mail with an attachment. If anybody is interested, I could send it directly.
Am 14.03.19 um 00:17 schrieb John David Anglin:
Helge is right. Unless you are a ATI graphics card expert, you[...]
won't be able to fix the ring test failure.
I don't want to do real work on this more than 13
years old machine. It's slow compared to current machines and it
consumes almost 300W of electrical power without any load.
All of my HP
workstations are just museum pieces and to be authentic, all of them are running HP-UX, except for this one C8000.
But anyway, it's interesting to see that an almost current Linux runs on
it. But it seems to be a little bit fragile. I booted it today and all messages on the serial console seemed to be correct, but the connected monitor didn't show the KDE login screen, neither via the DVI nor the
VGA connector.
I tried to log in blindly and this worked, but the
desktop was displayed only on the VGA connector. I logged out from the session and logged in again, but then the system freezes up after the
desktop background was drawn. I had to switch it off and after powering
it up again it crashed during the next booting.
On 15.03.19 10:17, Lothar Paltins wrote:Linux 5.0.1-1~exp1 is available in experimental.
I've tried to send a reply to the list with an attachment, but it seems,
that it was silently ignored. I'm now sending it without the attachment.
Am 14.03.19 um 00:17 schrieb John David Anglin:
Helge is right. Unless you are a ATI graphics card expert, youI don't want to fix it, although my profession as a software engineer
won't be able to fix the ring test failure.
was the development and debugging of hardware control software. But I'm
not an ATI graphics card expert and I think the graphics acceleration
isn't very important. I don't want to do real work on this more than 13
years old machine. It's slow compared to current machines and it
consumes almost 300W of electrical power without any load. All of my HP
workstations are just museum pieces and to be authentic, all of them are
running HP-UX, except for this one C8000.
But anyway, it's interesting to see that an almost current Linux runs on
it.
The very newest Linux (git head, Debian unstable, ...) runs on it,You are correct about the hardware. However, I might suggest that there are other reasons
most times better than older ones.
Same here.But it seems to be a little bit fragile. I booted it today and allI'm astonished that you got some graphical output at all.
messages on the serial console seemed to be correct, but the connected
monitor didn't show the KDE login screen, neither via the DVI nor the
VGA connector. I tried to log in blindly and this worked, but the
desktop was displayed only on the VGA connector. I logged out from the
session and logged in again, but then the system freezes up after the
desktop background was drawn.
But in fact, nobody really tests C8000 with graphics card.
All c8000 machines I own run "server-like" in the datacenter.
The PA-RISC architecture requires accesses to be strictly aligned and unaligned accessesI had to switch it off and after powering it up again it crashedOf course that's not how it should be. I assume this is based on the fact that you used graphics before.
during the next booting. But eventually, after booting the machine a
third time, everything works again as before.
There are only a lot of "unaligned access" messages on the consoleYes, they are non-critical and just show that applications don't
coming from KDE applications, but I guess, that's a known issue.
respect the natural alignments of data.
Kernel related mail should generally be sent to <linux-parisc@vger.kernel.org>.I've taken a photo of the console with the backtrace after the crash,You can send me everything in private mail.
but it doesn't seem to be possible to send a mail with an attachment. If
anybody is interested, I could send it directly.
Nice! Would you be interested in testing these with Debian to see what
works and what does not?
Why not? My 68k workstations are out of topic here, but I've got the following running parisc machines: 710, several 715, one with HCRX-24 graphics, 725, C360, C3600, J5600, C8000. Is there a machine, where I
could help testing?
A boot log of the 710, 725 and C360 would be interesting.
But did you notice how silent the c8000 is at the same time (even with
two dual-core PA-8800/8900 installed)? :-)
And for the hppa port of
Debian GNU/Linux I think it's a very good combination of size and
hardware resources. In addition it has built-in remote control
capabilities (see [1]).
All of my HP
workstations are just museum pieces and to be authentic, all of them are
running HP-UX, except for this one C8000.
Nice! Would you be interested in testing these with Debian to see what
works and what does not?
All of the PA-RISC machines I own, support network booting, so maybe
yours will, too. Testing wouldn't then require an actual on disk installation, so not touching any existing HP/UX installations or
creating the need for a disk. You only need to setup the needed infrastructure services (DNS, DHCP, TFTP, NFS, etc.).
And for the hppa port of
Debian GNU/Linux I think it's a very good combination of size and
hardware resources. In addition it has built-in remote control
capabilities (see [1]).
Interesting for a remote server with modem access to the serial port.
I've tried it out on my machine, but after entering ESC-(, the serial
line simply freezes up. Maybe a BMC-password is set that should be cleared.
All of my HP
workstations are just museum pieces and to be authentic, all of them are >>> running HP-UX, except for this one C8000.
Nice! Would you be interested in testing these with Debian to see what
works and what does not?
Why not? My 68k workstations are out of topic here
, but I've got the
following running parisc machines: 710, several 715, one with HCRX-24 graphics, 725, C360, C3600, J5600, C8000. Is there a machine, where I
could help testing?
All of the PA-RISC machines I own, support network booting, so maybe
yours will, too. Testing wouldn't then require an actual on disk
installation, so not touching any existing HP/UX installations or
creating the need for a disk. You only need to setup the needed
infrastructure services (DNS, DHCP, TFTP, NFS, etc.).
No problem, if you tell me exactly what to do. But be aware, that I do
have a lot of Linux experience, but only with RHEL and openSuse, not
with Debian.
And regarding the crashes and instabilities I see, I'm now sure, that
they are coming from the "apt-get upgrade". The original 8 (jessie) installation works absolutely stable. But after the upgrade, the system either doesn't boot or it crashes sometime later. This doesn't happen
without the upgrade.
Am 16.03.19 um 22:49 schrieb Helge Deller:
A boot log of the 710, 725 and C360 would be interesting.
Would it be possible to install it on a 710 at all? It has the maximum possible RAM, but that's only 64MB.
Great! Actually this is pretty easy to set up as soon as you have found
out all needed details. :-) You only need a lifimage (with palo, Linux
kernel and initramfs), a NFS root FS for the host and - as said - the following infrastructure services in addition:
... (215 lines deleted)
I hope I didn't forget anything important. In case of questions just
make contact.
And the first difficulty is that my C8000 doesn't boot with the new kernel (vmlinuz-4.19.0-4-parisc64-smp). It stops after this message:
Branching to kernel entry point 0x000e0000. If this is the last
message you see, you may need to switch your console. This is
a common symptom -- search the FAQ and mailing list at parisc-linux.org
Of course it has nothing to do with the console setting. Maybe it's caused by the fact that it's a 4 core machine with two 1 GHz dual core PA-8800 processors.
It should boot further than that.
Which palo version are you running?
Did you ran "palo -v" before reboot?
I pulled out any graphics card of this machine though.
Hi Lothar,
On 3/16/19 22:42, Lothar Paltins wrote:
And for the hppa port of
Debian GNU/Linux I think it's a very good combination of size and
hardware resources. In addition it has built-in remote control
capabilities (see [1]).
Interesting for a remote server with modem access to the serial port.
I've tried it out on my machine, but after entering ESC-(, the serial
line simply freezes up. Maybe a BMC-password is set that should be
cleared.
Can't remember seeing something like this on my c8000s, but I can check tomorrow.
And regarding the crashes and instabilities I see, I'm now sure, that
they are coming from the "apt-get upgrade". The original 8 (jessie)
installation works absolutely stable. But after the upgrade, the system
either doesn't boot or it crashes sometime later. This doesn't happen
without the upgrade.
Never noticed a difference in stability for my c8000s depending on the
OS release level, but mostly used rp3440s since I have acquired them. I
can check with a c8000 tomorrow if I notice any differences in behaviour.
Am 18.03.19 um 15:10 schrieb Helge Deller:
It should boot further than that.
Which palo version are you running?
Did you ran "palo -v" before reboot?
No, I didn't know, that this is necessary. After "palo -v" the system
is booting now. Booting continues now with "Uncompressing ...". The
old palo (1.95) seems to be unable to uncompress the kernel.
I pulled out any graphics card of this machine though.
And this seems to be necessary. It's still pure chance, whether the
graphics card is working or not. It may even cause a crash during
booting. Here's a boot log of a crash:
[ 93.621614] [drm] radeon kernel modesetting enabled.
[ 93.871832] radeon 0000:80:00.0: enabling SERR and PARITY (0107 -> 0147) [ 94.010799] [drm] initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002 0x80).
[ 94.179812] ipmi 16: Found new BMC (man_id: 0x00000b, prod_id: 0x8201, dev_id: 0x32)
[ 94.219177] [drm] GPU not posted. posting now...
[ 94.347007] ipmi 16: IPMI kcs interface initialized
[ 94.512299] radeon 0000:80:00.0: putting AGP V3 device into 8x mode
[ 94.599144] radeon 0000:80:00.0: GTT: 512M 0x60000000 - 0x7FFFFFFF
[ 94.599165] [drm] Generation 2 PCI interface, using max accessible memory [ 94.599179] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
[ 94.599496] [drm] Detected VRAM RAM=128M, BAR=128M
[ 94.599504] [drm] RAM width 128bits DDR
[ 94.603570] [TTM] Zone kernel: Available graphics memory: 8218164 kiB
[ 94.603578] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [[ 94.603584] [TTM] Initializing pool allocator
[ 94.887738] [drm] radeon: 128M of VRAM memory ready
OK 94.887756] [drm] radeon: 512M of GTT memory ready.
m] Found device 94.888008] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
;1;39m82540EM Gi[ 94.923120] radeon 0000:80:00.0: WB disabled
gabit Ethernet C[ 94.923159] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0x0000000060000000 and cpu addr 0x000000002cdcd946
ontroller.
[ 94.930972] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 95.807136] [drm] Driver supports precise vblank timestamp query.
[ 95.807402] [drm] radeon: irq initialized.
[ 95.807548] [drm] Loading R300 Microcode
[ 95.835137] radeon 0000:80:00.0: firmware: failed to load radeon/R300_cp.bin (-2)
[ 95.835160] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 95.835172] radeon 0000:80:00.0: Direct firmware load for radeon/R300_cp.bin failed with error -2
[ 95.835558] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware! [ 95.835581] radeon 0000:80:00.0: failed initializing CP (-2).
[ 96.503094] radeon 0000:80:00.0: Disabling GPU acceleration
[ 96.504398] [drm] radeon: cp finalized
[ 96.531896] [drm] radeon: cp finalized
[ 96.683535] [TTM] Finalizing pool allocator
[ 96.735229] [TTM] Zone kernel: Used memory at exit: 0 kiB
[ 96.735229] [TTM] Zone dma32: Used memory at exit: 0 kiB
[ 96.735229] [drm] radeon: ttm finalized
[ 96.735229] [drm] Forcing AGP to PCI mode
[ 96.793669] [drm] Generation 2 PCI interface, using max accessible memory [ 97.099110] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
[ 97.099121] radeon 0000:80:00.0: GTT: 512M 0xFFFFFFFFA0000000 - 0xFFFFFFFFBFFFFFFF
[ 97.099142] [drm] Detected VRAM RAM=128M, BAR=128M
[ 97.099149] [drm] RAM width 128bits DDR
[ 97.203340] [TTM] Zone kernel: Available graphics memory: 8218164 kiB
[ 97.203349] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 97.203356] [TTM] Initializing pool allocator
[ 97.203554] [drm] radeon: 128M of VRAM memory ready
[ 97.203563] [drm] radeon: 512M of GTT memory ready.
[ 97.203683] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 97.396449] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
[ 97.396472] [drm] PCI GART of 512M enabled (table at 0x0000000043D00000). [ 97.396631] radeon 0000:80:00.0: WB enabled
[ 97.396652] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0xffffffffa0000000 and cpu addr 0x00000000e3b927cf
[ 97.396665] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 97.396671] [drm] Driver supports precise vblank timestamp query.
[ 97.396753] [drm] radeon: irq initialized.
[ 97.396763] [drm] Loading R300 Microcode
[ 97.396855] radeo
At this point it crashed with a blinking red LED.
But even if the graphics card works, it's almost unusable now. The
previous version with KDE4 worked reasonable fast, but the new Plasma
desktop is incredibly slow. Even the simple systemsettings5
application uses about 100% CPU time and everything reacts extremely
slow on keyboard and mouse events.
I've never seen the kernel try PCI after AGP as far as I can recall. One as WB enabled and theOk, that needs more analyzing.I pulled out any graphics card of this machine though.And this seems to be necessary. It's still pure chance, whether the
graphics card is working or not. It may even cause a crash during
booting. Here's a boot log of a crash:
[ 93.621614] [drm] radeon kernel modesetting enabled.
[ 93.871832] radeon 0000:80:00.0: enabling SERR and PARITY (0107 -> 0147) >> [ 94.010799] [drm] initializing kernel modesetting (RV350 0x1002:0x4154 0x1002:0x0002 0x80).
[ 94.179812] ipmi 16: Found new BMC (man_id: 0x00000b, prod_id: 0x8201, dev_id: 0x32)
[ 94.219177] [drm] GPU not posted. posting now...
[ 94.347007] ipmi 16: IPMI kcs interface initialized
[ 94.512299] radeon 0000:80:00.0: putting AGP V3 device into 8x mode
[ 94.599144] radeon 0000:80:00.0: GTT: 512M 0x60000000 - 0x7FFFFFFF
[ 94.599165] [drm] Generation 2 PCI interface, using max accessible memory >> [ 94.599179] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
[ 94.599496] [drm] Detected VRAM RAM=128M, BAR=128M
[ 94.599504] [drm] RAM width 128bits DDR
[ 94.603570] [TTM] Zone kernel: Available graphics memory: 8218164 kiB
[ 94.603578] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[[ 94.603584] [TTM] Initializing pool allocator
[ 94.887738] [drm] radeon: 128M of VRAM memory ready
OK 94.887756] [drm] radeon: 512M of GTT memory ready.
m] Found device 94.888008] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
;1;39m82540EM Gi[ 94.923120] radeon 0000:80:00.0: WB disabled
gabit Ethernet C[ 94.923159] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0x0000000060000000 and cpu addr 0x000000002cdcd946
ontroller.
[ 94.930972] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [ 95.807136] [drm] Driver supports precise vblank timestamp query.
[ 95.807402] [drm] radeon: irq initialized.
[ 95.807548] [drm] Loading R300 Microcode
[ 95.835137] radeon 0000:80:00.0: firmware: failed to load radeon/R300_cp.bin (-2)
[ 95.835160] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 95.835172] radeon 0000:80:00.0: Direct firmware load for radeon/R300_cp.bin failed with error -2
[ 95.835558] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware! >> [ 95.835581] radeon 0000:80:00.0: failed initializing CP (-2).
[ 96.503094] radeon 0000:80:00.0: Disabling GPU acceleration
[ 96.504398] [drm] radeon: cp finalized
[ 96.531896] [drm] radeon: cp finalized
[ 96.683535] [TTM] Finalizing pool allocator
[ 96.735229] [TTM] Zone kernel: Used memory at exit: 0 kiB
[ 96.735229] [TTM] Zone dma32: Used memory at exit: 0 kiB
[ 96.735229] [drm] radeon: ttm finalized
[ 96.735229] [drm] Forcing AGP to PCI mode
[ 96.793669] [drm] Generation 2 PCI interface, using max accessible memory >> [ 97.099110] radeon 0000:80:00.0: VRAM: 128M 0xFFFFFFFFC0000000 - 0xFFFFFFFFC7FFFFFF (128M used)
[ 97.099121] radeon 0000:80:00.0: GTT: 512M 0xFFFFFFFFA0000000 - 0xFFFFFFFFBFFFFFFF
[ 97.099142] [drm] Detected VRAM RAM=128M, BAR=128M
[ 97.099149] [drm] RAM width 128bits DDR
[ 97.203340] [TTM] Zone kernel: Available graphics memory: 8218164 kiB
[ 97.203349] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 97.203356] [TTM] Initializing pool allocator
[ 97.203554] [drm] radeon: 128M of VRAM memory ready
[ 97.203563] [drm] radeon: 512M of GTT memory ready.
[ 97.203683] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 97.396449] [drm] radeon: 1 quad pipes, 1 Z pipes initialized
[ 97.396472] [drm] PCI GART of 512M enabled (table at 0x0000000043D00000). >> [ 97.396631] radeon 0000:80:00.0: WB enabled
[ 97.396652] radeon 0000:80:00.0: fence driver on ring 0 use gpu addr 0xffffffffa0000000 and cpu addr 0x00000000e3b927cf
[ 97.396665] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [ 97.396671] [drm] Driver supports precise vblank timestamp query.
[ 97.396753] [drm] radeon: irq initialized.
[ 97.396763] [drm] Loading R300 Microcode
[ 97.396855] radeo
At this point it crashed with a blinking red LED.
But even if the graphics card works, it's almost unusable now. The
previous version with KDE4 worked reasonable fast, but the new Plasma
desktop is incredibly slow. Even the simple systemsettings5
application uses about 100% CPU time and everything reacts extremely
slow on keyboard and mouse events.
Hard to say from here what's wrong.
I can try to debug further when I found time at some point.
BTW, I use `screen` to access the serial console. Maybe you try with
that tool, too, with e.g. `screen /dev/ttyUSB0 9600,cs8` (`<Ctrl>ak` to exit).
The firmware version on the tested c8000 is "2.13" and the BMC firmware revision is "2.32".
I really assume that removing the graphics card will be key to stability
for your c8000. This or maybe blacklisting the radeon module with `modprobe.blacklist=radeon` in the kernel command line.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 91:15:53 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,694 |