I asked earlier, but I never saw an answer: are your NIC lights indicating 100Mbit on the WAN interface?
I can only answer that question on Monday…
I just got off the phone to my friend that debugs for Redhat. He says that 6.6.51 is the version to use and 6.6.47 still had a lot of bugs in it.
I’m sure 6.6.51 is out there for you to download. But if it isn’t, I’ll have him upload his copy to my Dropbox and share it.
We only download the versions from the kernel site.
I am sure if there are new kernel versions available that @arne_f will be evaluating them for use.
1 Like
Which NIC controls the WAN?
Bottom pic, it’s easy to tell it’s operating at gigabit. Top pic, I don’t know if those colors indicate gigabit or 100Mb. It should say in the motherboard manual.
It’s not going to be easy, I don’t have this information, I’ll try to find it with the PC reference…
I was able to retrieve information
l Green - A good connection is established between the 10 Mb/s network and the computer.
l Orange - A good connection is established between the 100 Mb/s network and the computer.
l Yellow - A good connection is established between the 1 Gb/s (or 1000 Mb/s) network and the computer.
I’m just reminding you that the card is configured to work at 100mbps by ethtool, if I switch it to 1000mbps the connection drops out.
Physical power down / restart of PC, or is that not possible in work hours?
it changes nothing
ethtool -s green0 speed 100 duplex full autoneg off
OK
ethtool -s green0 speed 1000 duplex full autoneg off
DOWN
Please test kernel 6.6.54 if you run on x86_64 :
wget https://people.ipfire.org/~arne_f/highly-experimental/kernel/kernel-6.6.56-ipfire-x86_64.tar.xz
tar xvf kernel-6.6.56-ipfire-x86_64.tar.xz -C /
rm kernel-6.6.56-ipfire-x86_64.tar.xz
dracut --regenerate-all
grub-mkconfig -o /boot/grub/grub.cfg
2 Likes
Is there a risk of a general crash on a machine protecting a site in production by making this manipulation?
With it being in Arne’s “highly-experimental” folder, I would say there’s definitely a risk.
Thanks,
A G
My folder is called highly-experimental because sometimes i upload much more experimental builds. In case of kernel 6.6.54 it is a simple version update without other changes but of course there is a risk.
If it not work you can select the original kernel in grub.
1 Like
I’ll give it a try, but I’ll have to get out there and it won’t be in the next few days, sorry.
For information. I noticed another related problem.
The ADL boss called me to say that no downloads over 100mo were working. I had to configure the green card with ethtool
ethtool -s green0 speed 10 duplex half autoneg off
to ensure “normal” operation.
I tested the red side with a download and it works at the speed provided by the ISP. (400mo)
For @arne_f’s request, I don’t have the time to travel, so it’ll probably be next week.
I’ll test it on the AMD 6600FX system I have here later on this afternoon. (~8hrs from now) since it acted up within minutes after updating 187 to 188 or do you want me to test it with a 188 iso install instead?
good question. I cannot reproduce this at all.
I also have updated the post above from 6.6.54 to 6.6.56
ok, I’m going to update the 187 install to 188 and then apply the kernel update. above. It fell apart about a minute after I updated last time.even though bugs like this can stay dormant for a while because failures like that are unpredictable.
so far so good on updating 187->188 and swapping the kernel out.
There is a couple of things I see on the console that I want to point out:.
Disabling Simultaneous Multi-threading (smt)
retrying failed uevents if any....
chown: warning: '.' should be ':' 'nobody.root'
do I need to disable smt and hyperthreading on this AM3 processor in bios? (6600fx)