Hello, Gentoo.
Thanks to everybody who helped me get my video going in the other thread.
I've now got a more puzzling problem: Every time I boot up my new
machine, the 1920x1080 pixel display is offset by around 2 inches from
the left hand side (and aroun 1 cm from the top). It still appears to be 1920x1080 pixels (more precisely, 240 columns x 67 lines of 16x8
characters), but it's not filling the screen.
The screen itself is attached to a KVM box, and it works just fine on the
old machine. So it's not the physical display which is at fault. It's
an around 10 year old Samsung digital monitor, not some ancient CRT, or anything like that. It's interface is a DVI cable.
I seem to remember it filled the screen when it was new (on Monday).
Part of my efforts to make the video work (see other thread) involved
giving the kernel the drm.edid_firmware parameter. This parameter is intended to compensate for the display/KVM box/whatever failing to supply
the correct EDID information to the PC. One of the settings I tried
involved the offsets from the left and top mentioned above. But somehow
they seem to have got stuck in the machine. It seems the BIOS has saved
the offsets in the CMOS or something. I don't know how to undo these
saved settings.
Would somebody please help me on this, too.
Thanks!
On Thursday, 22 August 2024 17:54:19 BST Alan Mackenzie wrote:
Hello, Gentoo.
Thanks to everybody who helped me get my video going in the other thread.
I've now got a more puzzling problem: Every time I boot up my new
machine, the 1920x1080 pixel display is offset by around 2 inches from
the left hand side (and aroun 1 cm from the top). It still appears to be 1920x1080 pixels (more precisely, 240 columns x 67 lines of 16x8 characters), but it's not filling the screen.
The screen itself is attached to a KVM box, and it works just fine on the old machine. So it's not the physical display which is at fault. It's
an around 10 year old Samsung digital monitor, not some ancient CRT, or anything like that. It's interface is a DVI cable.
I seem to remember it filled the screen when it was new (on Monday).
Part of my efforts to make the video work (see other thread) involved giving the kernel the drm.edid_firmware parameter. This parameter is intended to compensate for the display/KVM box/whatever failing to supply the correct EDID information to the PC. One of the settings I tried involved the offsets from the left and top mentioned above. But somehow they seem to have got stuck in the machine. It seems the BIOS has saved the offsets in the CMOS or something. I don't know how to undo these
saved settings.
Would somebody please help me on this, too.
Thanks!
I must have missed the other thread where you had to feed to the kernel an drm.edid_firmware file.
Assuming the file is still available and built in the kernel as
firmware, ....
.... then the problem could well have to do with the DVI cable. It may
be worth unplugging and replugging it.
I'm a bit fed up with all of this. It's a new machine, but the
motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while
and
bugs in its BIOS ought to have been fixed by now.
Jack wrote:
On 2024.08.23 12:21, Alan Mackenzie wrote:
I'm a bit fed up with all of this. It's a new machine, but the
motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and >> bugs in its BIOS ought to have been fixed by now.
Just because the latest available BIOS might have fixed a problem does
not mean the physical mobo you bought actually has the latest BIOS installed. Have you checked, just to be compulsively certain?
I say that because not too many years ago, I bought an MSI mobo and
Ryzen CPU (from the same vendor) and I ended up having to buy (eBay)
an older CPU just to boot the machine so I could update the BIOS to
one which could handle the new CPU, because the installed BIOS was too
old.
When I built my new rig, one of the first things I did after making sure
it wasn't bad out of the box, update the BIOS. Mine was like 2 or 3
versions behind. It booted and all but I did update anyway, just to
prevent weirdness later. Turns out I had enough weirdness with a old
monitor so I needed to rid myself of some for sure.
I might add, I had to do the same thing on my old system when I first
built it. I'm not sure on my very first rig. I think newer mobos will update now even without a CPU. At least mine seems claims that anyway.
Dale
:-) :-)
Hello, Michael.
On Thu, Aug 22, 2024 at 22:44:47 +0100, Michael wrote:
Assuming the file is still available and built in the kernel as
firmware, ....
I used one of the stock options, drm.edid_firmware=edid/1920x1080.bin. There's something in the kernel that recognises these 6 or 7 "file names"
and uses the built in EDID blocks for them rather than reading from /lib/firmware.
But the source code for these has things like XOFFSET parameters, so I'm thinking that one of these took effect and "got stuck", somehow.
.... then the problem could well have to do with the DVI cable. It may
be worth unplugging and replugging it.
I tried pulling the cable (whilst switched on) and replacing it. This
didn't help (but doesn't seem to have done any damage, either ;-).
I haven't tried anything desperate, like clearing the CMOS, yet.
I've sent a support request to the manufacturers, MSI, which they will hopefully answer some time next week. In the mean time, I'll just have
to carry on intalling/configuring Gentoo with a nasty black stripe on my screen.
I'm a bit fed up with all of this. It's a new machine, but the
motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
bugs in its BIOS ought to have been fixed by now.
I'm going to add a tidbit of info here. Might relate, might not. On my
old system and my new system, I installed the sys-kernel/linux-firmware package. During the install of that package, a file magically appeared
in /boot named amd-uc.img
and when I run grub to create the config file,
it sees and adds that the same as it does a init thingy and kernel for booting. I think a few months ago the way firmware works changed. I
think there is a news item. Maybe.
Even if you don't use init thingys, you might could use that file the linux-firmware package creates. Maybe you can put that in your kernel
and include it inside the kernel. Then when you update your kernel,
just include the newer file the package provides in /boot.
If nothing else, that may give you a idea, about something I really
don't understand completely. o_O LOL
Dale
:-) :-)
On Friday, 23 August 2024 17:21:42 BST Alan Mackenzie wrote:
On Thu, Aug 22, 2024 at 22:44:47 +0100, Michael wrote:
Assuming the file is still available and built in the kernel as
firmware, ....
I used one of the stock options, drm.edid_firmware=edid/1920x1080.bin. There's something in the kernel that recognises these 6 or 7 "file names" and uses the built in EDID blocks for them rather than reading from /lib/firmware.
But the source code for these has things like XOFFSET parameters, so I'm thinking that one of these took effect and "got stuck", somehow.
I am not sure a modern BIOS would get stuck as you're describing. I think the
MoBo will detect any graphics chips connected to it, in this case your integrated APU graphics chip, and the graphics chip will in turn prompt for any connected display hardware. In this case your monitor should respond and send the EDID data to the graphics chip, which will adjust its signal to what the monitor requires.
.... then the problem could well have to do with the DVI cable. It may be worth unplugging and replugging it.
I tried pulling the cable (whilst switched on) and replacing it. This didn't help (but doesn't seem to have done any damage, either ;-).
I normally power off peripherals, except for USB devices, before I disconnect/
reconnect cables. Especially legacy IRQ connected kit which is not hot- swappable - e.g. PS/2 connectors. Modern systems don't have such issues, but I'm used to taking this precaution. :-p
I haven't tried anything desperate, like clearing the CMOS, yet.
I've sent a support request to the manufacturers, MSI, which they will hopefully answer some time next week. In the mean time, I'll just have
to carry on intalling/configuring Gentoo with a nasty black stripe on my screen.
Instead of resetting the firmware and losing all your MoBo settings, you'd be better off to flash the latest firmware on the MoBo. UEFI MoBo firmware usually offers the option to back up your settings first. MSI support would probably ask you to do this and reset all settings anyway, before they deal with any issues.
Do you still get this offset problem if you remove the KVM switch and connect the monitor directly to the MoBo?
What may be happening is the KVM causes some distortion to the signal amplitude/frequency, which the monitor interprets as an offset. You could try
to tweak this by feeding a bespoke EDID to the kernel, but sometimes a simple cable swap or operating the KVM a few times can cure it.
I'm a bit fed up with all of this. It's a new machine, but the motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and bugs in its BIOS ought to have been fixed by now.
Well, we don't know if this is caused by a MoBo firmware bug, although the quality of firmware often leaves much to be desired.
On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:
Instead of resetting the firmware and losing all your MoBo settings, you'd be better off to flash the latest firmware on the MoBo. UEFI MoBo
firmware usually offers the option to back up your settings first. MSI support would probably ask you to do this and reset all settings anyway, before they deal with any issues.
I think you're right, there. Unless I've already got the latest firmware installed (the form to fill in for MSI asked for the firmware version,
which I gave).
Do you still get this offset problem if you remove the KVM switch and connect the monitor directly to the MoBo?
I tried that, but got no display signal at all. Maybe I had the wrong
cable plugged into the wrong socket, but I don't think so. There's a veritable rats' nest of cables behind my PCs which is moderately
difficult to get to. I was able to shut the machine down by logging in
as root blind, and typing shutdown -h now, so the machine defintely came
up.
With the new PC connected up through the KVM switch (and also an
HDMI->DVI adapter) I'm still getting the 5cm. gap at the LH side of the screen. I've installed X and xfce, and that displays poorly, with lots
of flickering, shimmering colour threads through the display. I suspect
my HDMI->DVI adapter may be broken. The display goes blank for several seconds then comes back again several times a minute. I saw something
like this when I booted KDE from the live-CD a few days ago to see the firmware files needed.
It's worth noting that my display was also imperfect when I plugged
laptops into it a couple of years back, but not so bad as my xfce is now.
What may be happening is the KVM causes some distortion to the signal amplitude/frequency, which the monitor interprets as an offset. You could try to tweak this by feeding a bespoke EDID to the kernel, but sometimes
a simple cable swap or operating the KVM a few times can cure it.
Maybe, but it's all digital, not analog, isn't it? I remember tweaking timings in .xinit for CRT monitors (a tedious job, indeed), but surely an EDID signal is either going to be read by the OS correctly, or not at
all?
I've already tried swapping the cables to the KVM box, this achieving nothing.
I'm a bit fed up with all of this. It's a new machine, but the motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and bugs in its BIOS ought to have been fixed by now.
Well, we don't know if this is caused by a MoBo firmware bug, although the quality of firmware often leaves much to be desired.
We don't know, no, so I have to guess so as to come up with tests to try.
;-) The firmware on this MB fails to save the boot order when I put the
DVD drive at the start, in front of the NVMEs (which are still called
"hard drives"). Thus the BIOS isn't perfect.
I'm still pretty sure that when I booted the machine for the first time,
the display was correct. In particular, I remember noticing the offset
after I tried booting with the drm.edid_firmware kernel parameter for the first time.
I think I should try to update the firmware, and see if that clears the problem.
On Saturday, 24 August 2024 14:25:31 BST Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:
Instead of resetting the firmware and losing all your MoBo settings, you'd
be better off to flash the latest firmware on the MoBo. UEFI MoBo firmware usually offers the option to back up your settings first. MSI support would probably ask you to do this and reset all settings anyway, before they deal with any issues.
I think you're right, there. Unless I've already got the latest firmware installed (the form to fill in for MSI asked for the firmware version, which I gave).
Do you still get this offset problem if you remove the KVM switch and connect the monitor directly to the MoBo?
I tried that, but got no display signal at all. Maybe I had the wrong cable plugged into the wrong socket, but I don't think so. There's a veritable rats' nest of cables behind my PCs which is moderately
difficult to get to. I was able to shut the machine down by logging in
as root blind, and typing shutdown -h now, so the machine defintely came up.
Hmm ... normally you would have a display coming up, if your PC is indeed connected to the monitor. This would be the first thing I would try to make sure I can get a correct display. :-/
With the new PC connected up through the KVM switch (and also an
HDMI->DVI adapter) I'm still getting the 5cm. gap at the LH side of the screen. I've installed X and xfce, and that displays poorly, with lots
of flickering, shimmering colour threads through the display. I suspect
my HDMI->DVI adapter may be broken. The display goes blank for several seconds then comes back again several times a minute. I saw something
like this when I booted KDE from the live-CD a few days ago to see the firmware files needed.
This reads like an unsuitable refresh rate problem.
It's worth noting that my display was also imperfect when I plugged
laptops into it a couple of years back, but not so bad as my xfce is now.
What may be happening is the KVM causes some distortion to the signal amplitude/frequency, which the monitor interprets as an offset. You could
try to tweak this by feeding a bespoke EDID to the kernel, but sometimes a simple cable swap or operating the KVM a few times can cure it.
Maybe, but it's all digital, not analog, isn't it? I remember tweaking timings in .xinit for CRT monitors (a tedious job, indeed), but surely an EDID signal is either going to be read by the OS correctly, or not at
all?
Yes, the processing is digital, but the noise on the wire may not be. I've seen an LED monitor randomly coming up with a lot of distortion on console or DM (SDDM), everything flickering and double image/shading, only for the display to reset perfectly when a Plasma desktop is launched, or after the PC is rebooted. If the handshake between the card and the monitor is incorrect when hardware is initialised, then you'll need a reset of sorts to start again
with the correct EDID parameters.
I've already tried swapping the cables to the KVM box, this achieving nothing.
I'm a bit fed up with all of this. It's a new machine, but the motherboard, an MSI B650 Tomahawk Wifi, has been around a fair while and
bugs in its BIOS ought to have been fixed by now.
Well, we don't know if this is caused by a MoBo firmware bug, although the
quality of firmware often leaves much to be desired.
We don't know, no, so I have to guess so as to come up with tests to try. ;-) The firmware on this MB fails to save the boot order when I put the DVD drive at the start, in front of the NVMEs (which are still called
"hard drives"). Thus the BIOS isn't perfect.
I'm still pretty sure that when I booted the machine for the first time, the display was correct. In particular, I remember noticing the offset after I tried booting with the drm.edid_firmware kernel parameter for the first time.
I expect, but don't know, the embedded kernel drm.edid_firmware codes offer some default resolution sizes and refresh rates. If your monitor prefers e.g.
59Hz as opposed to a default of 60Hz, you could experience the problems you describe above. I was thinking if you can get a correct display coming up with the monitor connected directly to the graphics port, then you can capture
the EDID reported by the monitor and feed this to the kernel as an EDID file instead.
I think I should try to update the firmware, and see if that clears the problem.
The latest firmware is 7D75v1J and was released very recently. It deals with a security issue too, so it's advisable using this version sooner or later:
https://www.msi.com/Motherboard/MAG-B650-TOMAHAWK-WIFI/support
Besides trying the latest firmware, some other things to try:
1. Use a cable with the appropriate connectors at each end. No KVM, no intermediate adaptors, no extensions, nothing-in-between. Then add one thing at a time to see what makes a difference.
2. Try reseting the monitor itself. Usually there is some OSD menu to adjust monitor settings, see if there is a 'Reset Display' or similar option.
3. Check if the monitor display corrects itself by playing with refresh rates using xrandr/xorg.conf/desktop GUI Display settings after you launch xfce.
4. You should not have to do this, but if the KVM consistently throws out the offset then check if the monitor OSD has a screen adjustment submenu to tweak the screen viewport and shift it to fit the monitor.
Let's hope one of these things delivers a working display for you. :-)
On Sat, Aug 24, 2024 at 16:40:38 +0100, Michael wrote:
On Saturday, 24 August 2024 14:25:31 BST Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:
This reads like an unsuitable refresh rate problem.
I've read the "information" section from my monitor's adjustment panel.
It says 60 Hz. and 1920x1080 (on my current machine). On the new
machine, it reads 60 Hz., 2112x1016. This looks like being at the core
of the problem. 2112 / 1920 = 1.1 (more or less), i.e. 10% too many
pixels.
My monitor is ~52cm wide. 10% of this is the ~5cm. black strip at the
LHS of the monitor.
Is there any convenient way I can display the current EDID information
block?
My hypothesis at the moment is that something in the new machine is
wrongly pumping out 2112x1016 in place of 1980x1080 and this is
diminishing the size of (and reducing the quality of) the displayed
image.
I think the EDID being received from the monitor and KVM-box are correct,
but that the BIOS is applying some "correction" to them, for some reason. Maybe I should try resetting the CMOS ram.
Let's hope one of these things delivers a working display for you. :-)
Thanks!
Alan Mackenzie wrote:
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 7
1 potential busses found: 1
256-byte EDID successfully retrieved from i2c bus 1
Looks like i2c was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "SMB2430L"
ModelName "SMB2430L"
VendorName "SAM"
# Monitor Manufactured week 13 of 2011
# EDID version 1.3
# Digital Display
DisplaySize 520 290
Gamma 2.20
Option "DPMS" "true"
Horizsync 30-81
VertRefresh 56-75
# Maximum pixel clock is 170MHz
#Not giving standard mode: 1280x800, 60Hz
#Not giving standard mode: 1280x960, 60Hz
#Not giving standard mode: 1280x1024, 60Hz
#Not giving standard mode: 1440x900, 60Hz
#Not giving standard mode: 1600x1200, 60Hz
#Not giving standard mode: 1680x1050, 60Hz
#Not giving standard mode: 1152x864, 75Hz
#Not giving standard mode: 1440x900, 75Hz
#Extension block found. Parsing...
Modeline "Mode 0" +hsync +vsync
Modeline "Mode 1" +hsync +vsync
Modeline "Mode 2" +hsync +vsync
Modeline "Mode 3" +hsync +vsync
Modeline "Mode 4" -hsync -vsync
EndSection
Just for giggles, I emerged that package and ran that command on my
system. All my monitors are running at 1920 x 1080. However, this is
my output.
root@Gentoo-1 / # get-edid | parse-edid
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
2 potential busses found: 3 6
Will scan through until the first EDID is found.
Pass a bus number as an option to this program to go only for that one. 256-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "LS32B30"
ModelName "LS32B30"
VendorName "SAM"
# Monitor Manufactured week 13 of 2024
# EDID version 1.3
# Digital Display
DisplaySize 160 90
Gamma 2.20
Option "DPMS" "true"
Horizsync 30-84
VertRefresh 48-75
# Maximum pixel clock is 180MHz
#Not giving standard mode: 1280x720, 60Hz
#Not giving standard mode: 1280x800, 60Hz
#Not giving standard mode: 1280x1024, 60Hz
#Not giving standard mode: 1440x900, 60Hz
#Not giving standard mode: 1600x900, 60Hz
#Not giving standard mode: 1680x1050, 60Hz
#Not giving standard mode: 1152x864, 75Hz
#Extension block found. Parsing...
Modeline "Mode 7" +hsync +vsync
Modeline "Mode 0" +hsync +vsync
Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084
1089 1125 +hsync +vsync
Modeline "Mode 2" 74.250 1280 1390 1420 1650 720 725 730
750 +hsync +vsync
Modeline "Mode 3" 148.500 1920 2448 2492 2640 1080 1084
1089 1125 +hsync +vsync
Modeline "Mode 4" 74.250 1280 1720 1760 1980 720 725 730
750 +hsync +vsync
Modeline "Mode 5" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync
Modeline "Mode 6" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync
Modeline "Mode 8" -hsync -vsync
Modeline "Mode 9" -hsync -vsync
Modeline "Mode 10" +hsync +vsync
Option "PreferredMode" "Mode 7"
EndSection
root@Gentoo-1 / #
Even tho my monitor is working fine, no winking in a while now, the resolution it is running at isn't listed either.
I might also add, I
have three monitors connected but only one is seen by that command.
I'm wondering if there is something wonky with that program. I'd expect
the resolution it is currently running at to be listed. Given it is
not, I'd call that odd. Or wonky. ;-) I might add, there is some differences so it is seeing something. It's not just spitting out the
same info no matter what.
Odd.
Dale
:-) :-)
Hello, Michael.
On Sat, Aug 24, 2024 at 20:36:11 +0000, Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 16:40:38 +0100, Michael wrote:[ .... ]
On Saturday, 24 August 2024 14:25:31 BST Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:
This reads like an unsuitable refresh rate problem.
I've read the "information" section from my monitor's adjustment panel.
It says 60 Hz. and 1920x1080 (on my current machine). On the new
machine, it reads 60 Hz., 2112x1016. This looks like being at the core
of the problem. 2112 / 1920 = 1.1 (more or less), i.e. 10% too many pixels.
My monitor is ~52cm wide. 10% of this is the ~5cm. black strip at the
LHS of the monitor.
Is there any convenient way I can display the current EDID information block?
Yes, there is: there is the package x11-misc/read-edid, which contains
two utilities get-edid and parse-edid. Calling # get-edid | parse-edid produces, on my current machine:
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 7
1 potential busses found: 1
256-byte EDID successfully retrieved from i2c bus 1
Looks like i2c was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "SMB2430L"
ModelName "SMB2430L"
VendorName "SAM"
# Monitor Manufactured week 13 of 2011
# EDID version 1.3
# Digital Display
DisplaySize 520 290
Gamma 2.20
Option "DPMS" "true"
Horizsync 30-81
VertRefresh 56-75
# Maximum pixel clock is 170MHz
#Not giving standard mode: 1280x800, 60Hz
#Not giving standard mode: 1280x960, 60Hz
#Not giving standard mode: 1280x1024, 60Hz
#Not giving standard mode: 1440x900, 60Hz
#Not giving standard mode: 1600x1200, 60Hz
#Not giving standard mode: 1680x1050, 60Hz
#Not giving standard mode: 1152x864, 75Hz
#Not giving standard mode: 1440x900, 75Hz
#Extension block found. Parsing...
Modeline "Mode 0" +hsync +vsync
Modeline "Mode 1" +hsync +vsync
Modeline "Mode 2" +hsync +vsync
Modeline "Mode 3" +hsync +vsync
Modeline "Mode 4" -hsync -vsync
EndSection
.. On my new machine, it is almost identical, just using I2C bus 0,
rather than 1.
It is now clear that EDID contains not an optimal screen setting, but
instead ranges (for example 56-75 Hz. screen refresh rate).
The
question arises, what exactly puts the display into 1920x1080 60Hz. at
boot up time? Something must be chosing that resolution. I've tried grepping the kernel sources, but there are a lot lf "1920x1080"s there.
:-(
[ .... ]
My hypothesis at the moment is that something in the new machine is
wrongly pumping out 2112x1016 in place of 1980x1080 and this is
diminishing the size of (and reducing the quality of) the displayed
image.
I think the EDID being received from the monitor and KVM-box are correct, but that the BIOS is applying some "correction" to them, for some reason.
Maybe I should try resetting the CMOS ram.
On Sunday, 25 August 2024 13:33:14 BST Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 20:36:11 +0000, Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 16:40:38 +0100, Michael wrote:[ .... ]
On Saturday, 24 August 2024 14:25:31 BST Alan Mackenzie wrote:
On Sat, Aug 24, 2024 at 10:44:44 +0100, Michael wrote:
This reads like an unsuitable refresh rate problem.
Ah! I was wrong at my assumption - I had not understood the displayed resolution was not the native/optimal monitor resolution.
I've read the "information" section from my monitor's adjustment panel. It says 60 Hz. and 1920x1080 (on my current machine). On the new machine, it reads 60 Hz., 2112x1016. This looks like being at the core of the problem. 2112 / 1920 = 1.1 (more or less), i.e. 10% too many pixels.
My monitor is ~52cm wide. 10% of this is the ~5cm. black strip at the LHS of the monitor.
Right, for some reason the graphics core is not driving the monitor at the appropriate (optimal) resolution.
Is there any convenient way I can display the current EDID information block?
Yes, there is: there is the package x11-misc/read-edid, which contains
two utilities get-edid and parse-edid. Calling # get-edid | parse-edid produces, on my current machine:
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 7
1 potential busses found: 1
256-byte EDID successfully retrieved from i2c bus 1
Looks like i2c was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "SMB2430L"
ModelName "SMB2430L"
VendorName "SAM"
# Monitor Manufactured week 13 of 2011
# EDID version 1.3
# Digital Display
DisplaySize 520 290
Gamma 2.20
Option "DPMS" "true"
Horizsync 30-81
VertRefresh 56-75
# Maximum pixel clock is 170MHz
#Not giving standard mode: 1280x800, 60Hz
#Not giving standard mode: 1280x960, 60Hz
#Not giving standard mode: 1280x1024, 60Hz
#Not giving standard mode: 1440x900, 60Hz
#Not giving standard mode: 1600x1200, 60Hz
#Not giving standard mode: 1680x1050, 60Hz
#Not giving standard mode: 1152x864, 75Hz
#Not giving standard mode: 1440x900, 75Hz
From the above we can't tell if the monitor will work at 1920x1080@60Hz, but according to the OEM specification sheet it should and the VertRefresh range of 56-75 is broad enough to accommodate anything within it.
#Extension block found. Parsing...
Modeline "Mode 0" +hsync +vsync
Modeline "Mode 1" +hsync +vsync
Modeline "Mode 2" +hsync +vsync
Modeline "Mode 3" +hsync +vsync
Modeline "Mode 4" -hsync -vsync
EndSection
Hmm ... no Modelines shown above and no preferred Mode provided. :-(
.. On my new machine, it is almost identical, just using I2C bus 0,
rather than 1.
It is now clear that EDID contains not an optimal screen setting, but instead ranges (for example 56-75 Hz. screen refresh rate).
The ranges are indicative of what refresh rates the panel is capable of, for different resolutions. As you say, of more concern is it does not provide an optimal Mode.
The question arises, what exactly puts the display into 1920x1080
60Hz. at boot up time? Something must be chosing that resolution.
I've tried grepping the kernel sources, but there are a lot lf
"1920x1080"s there.
:-(
You can try adding the correct video resolution at the kernel cmdline - see below.
[ .... ]
My hypothesis at the moment is that something in the new machine is wrongly pumping out 2112x1016 in place of 1980x1080 and this is diminishing the size of (and reducing the quality of) the displayed image.
Yes, from what you described this appears to be the case.
I think the EDID being received from the monitor and KVM-box are correct, but that the BIOS is applying some "correction" to them, for some reason.
I'm not sure about this, look at the EDID output. The Modelines are incomplete with no preferred resolution as per the OEM's specification.
Maybe I should try resetting the CMOS ram.
I'd be surprised if this has any effect on the displayed resolution.
The EDID/DDC protocol expects a certain DC voltage (+5V). If this is not provided as cleanly and uninterruptedly as expected, the initialisation and communication between monitor & graphics card could go awry. Hence me mumbling about avoiding adaptors and connectors which due to faults, poor manufacture, dirt, oxidation, etc., could add resistance to the I2C wire circuits. Of course the KVM itself may be interfering with what-ever EDID is provided by the monitor itself.
Your approach to specify the resolution via an edid file should work, at least
until it is deprecated from kernel 6.9.x onward and you have to build your own
edid firmware file from the assembly source files in /usr/src/linux/tools/ edid/.
You can enable CONFIG_DRM_LOAD_EDID_FIRMWARE in your kernel and add to the kernel cmdline:
drm_kms_helper.edid_firmware=edid/edid/1920x1080.bin
Before you add the above, I'm not clear if I understand correctly from this document, if first you have to run "make" in /usr/src/linux/tools/edid/ to build the binary EDID blobs in your kernel image, or if they are built anyway when you run make as part of building your kernel from source:
/usr/src/linux/Documentation/admin-guide/edid.rst
Another option to try in case it works with KMS:
video=HDMI-A-1:1920x1080@60D
To find what your card/port string is named as look at:
ls -la /sys/class/drm/* grep HDMI
or
dmesg | grep Connector -A1
Alan Mackenzie wrote:
Somehow I don't think that will work (which doesn't mean I won't try it). There is something in the motherboard which is throwing off the desired resolution by those extra 192 horizontal pixels, even in the BIOS.
Do you have x11-apps/xrandr installed? If you do, see what this says.
xrandr --listmonitors
This is mine:
root@Gentoo-1 / # xrandr --listmonitors
Monitors: 3
0: +*DP-2 1920/698x1080/393+0+1080 DP-2
1: +DP-1 1920/698x1080/393+0+0 DP-1
2: +DP-7 1920/1150x1080/650+1920+1080 DP-7
root@Gentoo-1 / #
DP-2 is my primary display and if you have only one monitor, should be
the only line for you but might be DP-1 instead. Micheal might can
explain this better, or even more correctly, but I think the important
part for this is where mine says +0+. I think, just think, if yours
says something like +192+ instead of 0, that might be a clue. If it
says 0 as it should, then this may be the wrong track to look down.
What I'm wondering, is the monitor set to show a blank, or black,
section on that side for some reason. This could very well not be the
case tho. If it shows correctly like mine does, then ignore this and
know that isn't causing the problem at least.
This is a odd problem. I don't think I ever saw this even during the
old CRT days. o_O
Dale
:-) :-)
Alan Mackenzie wrote:
Hello, Dale
On Sun, Aug 25, 2024 at 13:28:14 -0500, Dale wrote:
Alan Mackenzie wrote:
Somehow I don't think that will work (which doesn't mean I won't try
it).
There is something in the motherboard which is throwing off the desired >>> resolution by those extra 192 horizontal pixels, even in the BIOS.
Do you have x11-apps/xrandr installed? If you do, see what this says.
I didn't, but I do now. After trying (and failing) to run it on the console, I tried in X-Windows (the display of which is miserably
unstable at the moment).
xrandr --listmonitors
This is mine:
root@Gentoo-1 / # xrandr --listmonitors
Monitors: 3
0: +*DP-2 1920/698x1080/393+0+1080 DP-2
1: +DP-1 1920/698x1080/393+0+0 DP-1
2: +DP-7 1920/1150x1080/650+1920+1080 DP-7
root@Gentoo-1 / #
That's one tremendous monitor you've got on DP-7. :-)
I've got just the one monitor. I got back:
0: +*HDMI-A-0 1920/521x1080/293+0+0 HDMI-A-0
If I read that and my thinking is right, that is what it should be.
I
don't completely understand everything that output is saying. But, I technically have three monitors. I have two in front of me that have different displays. Those are DP2 and DP-2. The third, DP-7, is my TV
that I watch. It goes to a splitter which goes to a TV in my bedroom
and one in the living room. I can cook, clean etc while watching TV.
DP-7 is to the right of DP-2 which may be why it shows something larger.
Some of this monitor stuff is a bit confusing.
DP-2 is my primary display and if you have only one monitor, should be
the only line for you but might be DP-1 instead. Micheal might can
explain this better, or even more correctly, but I think the important
part for this is where mine says +0+. I think, just think, if yours
says something like +192+ instead of 0, that might be a clue. If it
says 0 as it should, then this may be the wrong track to look down.
What I'm wondering, is the monitor set to show a blank, or black,
section on that side for some reason. This could very well not be the
case tho. If it shows correctly like mine does, then ignore this and
know that isn't causing the problem at least.
No, I've got the +0+, too.
This is a odd problem. I don't think I ever saw this even during the
old CRT days. o_O
I'm convinced this isn't a problem in Linux. It's something having got wedged in the motherboard's firmware, seeing as how the blank strip
appears even when going into the BIOS.
I suspect I'm going to have to
reinitialise the CMOS ram, which I really don't want to do, though
Michael doesn't think that's the problem. We'll see.
Ahhhhh. If it does it in the BIOS, it's either a monitor or video card,
or mobo if video is built in, problem.
If a monitor isn't right in the
BIOS screen, odds are it won't be when booted either. Can you install a video card and test? If it works, mobo has a video driver problem. If
not, could be monitor or cables or something.
At least we know one thing it isn't. ;-)
Dale
:-) :-)
Alan Mackenzie wrote:
Hello, Dale
On Sun, Aug 25, 2024 at 13:28:14 -0500, Dale wrote:
Alan Mackenzie wrote:I didn't, but I do now. After trying (and failing) to run it on the console, I tried in X-Windows (the display of which is miserably
Somehow I don't think that will work (which doesn't mean I won't try it). >>> There is something in the motherboard which is throwing off the desired >>> resolution by those extra 192 horizontal pixels, even in the BIOS.Do you have x11-apps/xrandr installed? If you do, see what this says.
unstable at the moment).
xrandr --listmonitors
This is mine:
root@Gentoo-1 / # xrandr --listmonitorsThat's one tremendous monitor you've got on DP-7. :-)
Monitors: 3
0: +*DP-2 1920/698x1080/393+0+1080 DP-2
1: +DP-1 1920/698x1080/393+0+0 DP-1
2: +DP-7 1920/1150x1080/650+1920+1080 DP-7
root@Gentoo-1 / #
I've got just the one monitor. I got back:
0: +*HDMI-A-0 1920/521x1080/293+0+0 HDMI-A-0
If I read that and my thinking is right, that is what it should be. I
don't completely understand everything that output is saying. But, I technically have three monitors. I have two in front of me that have different displays. Those are DP2 and DP-2. The third, DP-7, is my TV
that I watch. It goes to a splitter which goes to a TV in my bedroom
and one in the living room. I can cook, clean etc while watching TV.
DP-7 is to the right of DP-2 which may be why it shows something larger.
Some of this monitor stuff is a bit confusing.
DP-2 is my primary display and if you have only one monitor, should beNo, I've got the +0+, too.
the only line for you but might be DP-1 instead. Micheal might can
explain this better, or even more correctly, but I think the important
part for this is where mine says +0+. I think, just think, if yours
says something like +192+ instead of 0, that might be a clue. If it
says 0 as it should, then this may be the wrong track to look down.
What I'm wondering, is the monitor set to show a blank, or black,
section on that side for some reason. This could very well not be the
case tho. If it shows correctly like mine does, then ignore this and
know that isn't causing the problem at least.
This is a odd problem. I don't think I ever saw this even during theI'm convinced this isn't a problem in Linux. It's something having got wedged in the motherboard's firmware, seeing as how the blank strip
old CRT days. o_O
appears even when going into the BIOS. I suspect I'm going to have to reinitialise the CMOS ram, which I really don't want to do, though
Michael doesn't think that's the problem. We'll see.
Dale
:-) :-)
Ahhhhh. If it does it in the BIOS, it's either a monitor or video card,
or mobo if video is built in, problem. If a monitor isn't right in the
BIOS screen, odds are it won't be when booted either. Can you install a video card and test? If it works, mobo has a video driver problem. If
not, could be monitor or cables or something.
At least we know one thing it isn't. ;-)
Dale
:-) :-)
Let's hope this is an MSI/CSM specific issue rather than a hardware fault.
On Sunday, 25 August 2024 20:37:37 BST Dale wrote:
Alan Mackenzie wrote:
I'm convinced this isn't a problem in Linux. It's something having got wedged in the motherboard's firmware, seeing as how the blank strip appears even when going into the BIOS.
The plot thickens! If the resolution in the BIOS menu is also wrong and offset, it sounds like an MSI bug of sorts - "Try disabling CSM" in your UEFI settings:
https://forums.tomshardware.com/threads/low-resolution-boot-uefi-bios.3530375/
https://superuser.com/questions/1209012/uefi-and-therefore-linux-console-isnt-displayed-at-native-resolution
I have no idea why CSM affects the video resolution of the firmware, but it may have to do with how much space is available on the NOR flash chip where the UEFI firmware is stored. Enabling CSM may be eating up some/more resources, leaving less to initialise and run the graphics capability of the MoBo. :-/
I suspect I'm going to have to reinitialise the CMOS ram, which I
really don't want to do, though Michael doesn't think that's the
problem. We'll see.
I wasn't aware this display issue is present *before* the OS has even loaded. This is not a linux issue and the linux driver itself does not seem able to correct it.
OK, in the first instance disable the CMS in the UEFI settings and reboot. Some boards do not lose some of their cached settings when you simply shutdown. Remove the power cable, depress and hold the power button for 10-20
seconds. Any capacitors will discharge. Reconnect the power and boot normally.
If the above gymnastics do not fix it, then you'll have to try resetting the MoBo. Make a note of any changed settings and check the CSM option is left disabled.
Ahhhhh. If it does it in the BIOS, it's either a monitor or video card,
or mobo if video is built in, problem.
On modern APUs video graphics chips are integrated within the CPU die itself as separate graphics cores.
Let's hope this is an MSI/CSM specific issue rather than a hardware fault.
Hello, Michael.
On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
OK, in the first instance disable the CMS in the UEFI settings and reboot. Some boards do not lose some of their cached settings when you simply shutdown. Remove the power cable, depress and hold the power button for 10-20 seconds. Any capacitors will discharge. Reconnect the power and boot normally.
That didn't help either, I'm afraid.
I've had a reply from MSI's support. It's along the lines of "buy new cables, don't use an adapter, and don't use a KVM box". In other words,
not at all useful. I'm trying to work out whether it's worth trying to supply MSI with the extra information about the excess numbers of pixels being multiples of 16 in both the horizontal and vertical directions. I suspect I'll just get the runaround from them, no matter what.
Or, I could go back to the shop that built the machine. Maybe I should
try it connected directly to an HDMI monitor.
If the above gymnastics do not fix it, then you'll have to try resetting the MoBo. Make a note of any changed settings and check the CSM option
is left disabled.
I think this is what I will try next. I don't know which of the settings
has been changed, so I'll need to make a note of practically every
setting. Most of them are still defaults.
Ahhhhh. If it does it in the BIOS, it's either a monitor or video card, or mobo if video is built in, problem.
On modern APUs video graphics chips are integrated within the CPU die itself as separate graphics cores.
It seems such a graphic core is supplying 2112x1116@60Hz, rather than the correct 1920x1080@60Hz. Hopefully the fault is in the firmware, not in
the graphics unit. ;-(
[ .... ]
Let's hope this is an MSI/CSM specific issue rather than a hardware fault.
Given MSI support's attitude, it's looking like my machine is going back
to the shop that made it, unless resetting the CMOS RAM does the job.
That's the thing to try out next.
On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
Hello, Michael.
On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
I've had a reply from MSI's support. It's along the lines of "buy new cables, don't use an adapter, and don't use a KVM box". In other words, not at all useful. I'm trying to work out whether it's worth trying to supply MSI with the extra information about the excess numbers of pixels being multiples of 16 in both the horizontal and vertical directions. I suspect I'll just get the runaround from them, no matter what.
Yes, I suspected this would be their default response. If there is a known problem and a fix or workaround, OEMs will advise of it usually in their FAQs.
On a newly released product they may ask for additional information. Otherwise they are unlikely to engage in troubleshooting with retail users and
tend to point at anything else but their product. ;-)
Or, I could go back to the shop that built the machine. Maybe I should
try it connected directly to an HDMI monitor.
If you have a monitor with the same connector as your graphics card (DP or HDMI) then you can test the health of the new PC with it. However, if you must use the KVM and DVI-HDMI adaptor, then the options are limited.
I think this is what I will try next. I don't know which of the settings has been changed, so I'll need to make a note of practically every
setting. Most of them are still defaults.
Depending on the MoBo you can usually create a backup file with all the firmware settings and reload it later on, after you reset the MoBo and finished with your tests.
Ahhhhh. If it does it in the BIOS, it's either a monitor or video card,
or mobo if video is built in, problem.
On modern APUs video graphics chips are integrated within the CPU die itself as separate graphics cores.
It seems such a graphic core is supplying 2112x1116@60Hz, rather than the correct 1920x1080@60Hz. Hopefully the fault is in the firmware, not in
the graphics unit. ;-(
If this is the problem then you should be able to set your desktop to a 1920x1080 resolution. I am not familiar with xfce but there will be some display setting to adjust the resolution with.
[ .... ]
Let's hope this is an MSI/CSM specific issue rather than a hardware fault.
Given MSI support's attitude, it's looking like my machine is going back
to the shop that made it, unless resetting the CMOS RAM does the job. That's the thing to try out next.
Another thing to try to confirm is if the EDID of the monitor is correct:
Emerge sys-apps/edid-decode, then capture the EDID of the monitor with get- edid in a file and feed it to 'edid-decode -p'. It will parse the file and output a human readable output. Then you can see what the preferred resolution is as far as the monitor EDID content is concerned, or if it is indeed missing as you reported previously.
You can also read Xorg.0.log to find out what your xorg driver reports.
The recurring flickering of the display after you've loaded your desktop shows
the linux OS is trying to re-adjust the display. Usually this happens when the connection/power to the monitor is disrupted, which again points to a connector issue, or it can also happen if you specified in your GUI the wrong resolution/frequency.
Due to my ham-fisted attempts to connect a DVI adaptor behind a monitor without being able to see what I was doing, I recall bending one of the terminals at the DVI connector. This was giving spurious results. I had to straighten the terminal carefully with long nose pliers, before I was able to use the monitor properly. Check if your connectors have suffered something similar.
Other than the above, I'm out of ideas. :-(
On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
I'm beginning to think getting an MSI board was a mistake.
Or, I could go back to the shop that built the machine. Maybe I
should try it connected directly to an HDMI monitor.
Another thing to try to confirm is if the EDID of the monitor is
correct:
Emerge sys-apps/edid-decode, then capture the EDID of the monitor
with get- edid in a file and feed it to 'edid-decode -p'. It will
parse the file and output a human readable output. Then you can see
what the preferred resolution is as far as the monitor EDID content
is concerned, or if it is indeed missing as you reported previously.
The recurring flickering of the display after you've loaded your desktop shows
the linux OS is trying to re-adjust the display. Usually this happens when the connection/power to the monitor is disrupted, which again points to a connector issue, or it can also happen if you specified in your GUI the wrong
resolution/frequency.
Yes. I think the connectors are OK, but maybe we'll see how the machine performs differently at the shop tomorrow.
Hello, everybody.
On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:I'm beginning to think getting an MSI board was a mistake.
On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
I'm still thinking that.
Or, I could go back to the shop that built the machine. Maybe I
should try it connected directly to an HDMI monitor.
OK, I'm just back from the shop. The technician there plugged the
machine into an HDMI monitor, and it just worked. Before leaving, I
assured him that I _would_ get the machine working, even if that might involve buying a new monitor. ;-(
When I got back home again and plugged in the new machine, it was
slightly different. It was still pumping out 2112x1116, but the 2" gap
has become a 1" gap on both the left hand and the right hand sides.
There's still a (smaller) gap at the top. I haven't yet tried booting
into Linux.
At least we now have an indication of something "analog" perhaps not
being in order. I'm thinking that perhaps my HDMI->DVI adapter is
broken. I should have bought a new one while I was at the shop, just to test. I did have trouble with Windows laptops when I plugged them in
via this adapter a couple of years ago. Maybe I'll go back to the shop
to get that new HDMI->DVI adapter tomorrow.
There might still be errors in the MSI's BIOS firmware's handling of the EDID, I still think that.
[ .... ]
Another thing to try to confirm is if the EDID of the monitor is
correct:
Emerge sys-apps/edid-decode, then capture the EDID of the monitor
with get- edid in a file and feed it to 'edid-decode -p'. It will
parse the file and output a human readable output. Then you can see
what the preferred resolution is as far as the monitor EDID content
is concerned, or if it is indeed missing as you reported previously.
After reading the fine manual page, I tried edid-decode -pc, the -c meaninguto check the correctness of the EDID. It output a warning and (attleastdone)efault - something about some indicated resolutions' verticallsyncptimetlying(outside the given bounds.
The diagnostics look like this:
Warnings:
Block 1, CTA-861 Extension Block:
Display Product Serial Number is set, so the Serial Number in the Base
EDID should be 0. Add a Colorimetry Data Block with the sRGB colorimetry
bit set to avoid interop issues.
Failures:
Block 1, CTA-861 Extension Block:
Missing VCDB, needed for Set Selectable RGB Quantization to avoid interop issues. EDID:
Base EDID: Some timings are out of range of the Monitor Ranges:
Vertical Freq: 50.000 - 75.062 Hz (Monitor: 56.000 - 75.000 Hz)
EDID conformity: FAIL
[ .... ]
The recurring flickering of the display after you've loaded your desktop shows the linux OS is trying to re-adjust the display. Usually this happens when the connection/power to the monitor is disrupted, which again points to a connector issue, or it can also happen if you
specified in your GUI the wrong resolution/frequency.
Yes. I think the connectors are OK, but maybe we'll see how the machine performs differently at the shop tomorrow.
I've decided I'm definitely going to get a new HDMI->DVI adapter.
On Tuesday, 27 August 2024 17:05:26 BST Alan Mackenzie wrote:
On Mon, Aug 26, 2024 at 14:49:14 +0000, Alan Mackenzie wrote:
On Mon, Aug 26, 2024 at 12:54:20 +0100, Michael wrote:
On Monday, 26 August 2024 11:40:43 BST Alan Mackenzie wrote:
On Sun, Aug 25, 2024 at 22:04:05 +0100, Michael wrote:
OK, I'm just back from the shop. The technician there plugged the
machine into an HDMI monitor, and it just worked. Before leaving, I assured him that I _would_ get the machine working, even if that
might involve buying a new monitor. ;-(
Well, that's a different monitor and the cable was an HDMI-to-HDMI cable (I assume?).
Since you went to all this trouble it would be better if you dragged
your monitor along with you. Either way, I admire your doggedness to
get to the bottom of this. :-)
When I got back home again and plugged in the new machine, it was
slightly different. It was still pumping out 2112x1116, but the 2" gap
has become a 1" gap on both the left hand and the right hand sides.
There's still a (smaller) gap at the top. I haven't yet tried booting
into Linux.
At least we now have an indication of something "analog" perhaps not
being in order. I'm thinking that perhaps my HDMI->DVI adapter is
broken. I should have bought a new one while I was at the shop, just to test. I did have trouble with Windows laptops when I plugged them in
via this adapter a couple of years ago. Maybe I'll go back to the shop
to get that new HDMI->DVI adapter tomorrow.
It would be best if you could buy a cable with the requisite HDMI on one end and a DVI-D on the other. DVI-DL is capable of higher than 1920x1080 resolutions, although the optimal resolution of your panel is at 1920x1080.
Normally warnings and errors reported by the DDC check can be overcome by the graphics and/or Xorg drivers. I have monitors here which complain about all sorts of warnings and errors and fail the DDC compatibility check, but still work fine *and* display a more accurate picture (chromatically) than other monitors which pass the EDID/DDC check and post no warnings. Go figure ... :-/
The recurring flickering of the display after you've loaded your desktop
shows the linux OS is trying to re-adjust the display. Usually this happens when the connection/power to the monitor is disrupted, which again points to a connector issue, or it can also happen if you specified in your GUI the wrong resolution/frequency.
Yes. I think the connectors are OK, but maybe we'll see how the machine performs differently at the shop tomorrow.
I've decided I'm definitely going to get a new HDMI->DVI adapter.
I suggest you buy an HDMI-to-DVI-D bidirectional adaptor, or a cable with such
connectors on each end. A DVI-DL will be able to display higher resolutions than 1920x1080, if both ends had this connector, but the HDMI is a single link
interface so only one of the dual link connectors on the DVI end will be wired
in.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 146:21:19 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,708 |