Buggy network connection causes very low system responsiveness
by Martin Sourada
Hi,
first, I am not entirely sure this the right list for this kind of
issue, so I apologise in advance in case it isn't. And now for the
problem:
At home I am connected to home network, most of the time wireless, but
when wired the issue seems to be same. The connection of the home
network to outside is quite buggy and traffic drops quite often to zero
or near zero values, and sometimes the connection is even lost (it's via
wifi, unfortunately with low visibility to the router we connect to).
What bugs me is that when the connection is in its near-dead state my
Fedora is very low responsive. For example I tried to open terminal (via
key shortcut) and it didn't pop up at least for ten seconds, and then
instantly when I disabled my network connections. This low
responsiveness happens whenever the traffic drops to zero or near zero
(and a lot of packets is lost). CPU load is at normal during the 'lags'.
Also already loaded applications seems to behave decently.
My question is:
Is this behaviour to be expected or is it a bug? I don't know exactly
how these things work, but I fail to imagine how can network problems
affect system responsiveness...
Thanks for your thoughts,
Martin
Versions of the components I think might be relevant to this issue:
kernel-2.6.24.3-34.fc8
NetworkManager-0.7.0-0.6.7.svn3235.fc8
Gnome 2.20.3
16 years, 1 month
updated cross-gcc rpm
by Aron Griffis
[sorry for the dups, third try w/ fedora-devel-list subscribed]
Hi Lennert,
Referring to your post at
http://www.redhat.com/archives/fedora-devel-list/2007-October/msg00045.html
Thanks a lot for posting those rpms. I was able to use those with
--define='cross_target ia64-linux-gnu' to build a cross-compiler that
builds xen-unstable.hg including the userland tools. I posted that
information today to the xen-devel mailing list, see
http://lists.xensource.com/archives/html/xen-devel/2008-01/msg01105.html
I had to make some changes, first to build the gcc rpm successfully on
x86_64 targetting ia64, and second to include some files that were
missing. The missing files were due to %ifarch tests which were
looking at the build arch instead of the target arch. I came up with
a solution for that... though I wouldn't be surprised if you're able
to come up with something more elegant.
The patch is below. Thanks again for your work which enabled me to
get this running.
Aron
diff -r 8c95cc711df2 SPECS/gcc41.spec
--- a/SPECS/gcc41.spec Fri Jan 18 08:51:45 2008 -0500
+++ b/SPECS/gcc41.spec Wed Jan 30 02:56:35 2008 +0000
@@ -1,8 +1,10 @@
%if "%{?cross_target}" == ""
%define gcc_target %{_target_platform}
+%define target_arch %{_arch}
%define isnative 1
%else
%define gcc_target %{cross_target}
+%define target_arch %{expand:%%(echo "%{cross_target}" | sed 's/-.*//')}
%define isnative 0
%define cross %{gcc_target}-
%define crosspost -%{gcc_target}
@@ -12,6 +14,8 @@
%define __find_requires %{nil}
%define __find_provides %{nil}
%endif
+
+%define inlist() %{expand:%%(case '%* ' in (%{1}*' '%1' '*) echo 1 ;; (*) echo 0 ;; esac)}
%define DATE 20070925
%define gcc_version 4.1.2
@@ -1234,6 +1238,7 @@ rm -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/
rm -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/{libffi*,libiberty.a}
rm -f $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/%{_lib}/{libffi*,libiberty.a}
rm -f $FULLEPATH/install-tools/{mkheaders,fixincl}
+rm -f $FULLPATH/install-tools/mkheaders.conf
rm -f $RPM_BUILD_ROOT%{_prefix}/lib/{32,64}/libiberty.a
rm -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libssp*
rm -f $FULLPATH/libssp*
@@ -1428,8 +1433,7 @@ fi
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/syslimits.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/omp.h
-%if %{isnative}
-%ifarch %{ix86} x86_64
+%if %{inlist %{target_arch} %{ix86} x86_64}
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/xmmintrin.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/emmintrin.h
@@ -1439,14 +1443,13 @@ fi
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mm_malloc.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mm3dnow.h
%endif
-%ifarch ia64
+%if %{inlist %{target_arch} ia64}
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/ia64intrin.h
%endif
-%ifarch ppc ppc64
+%if %{inlist %{target_arch} ppc ppc64}
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/ppc-asm.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/altivec.h
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spe.h
-%endif
%endif
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/README
%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2
@@ -1458,8 +1461,7 @@ fi
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.spec
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.a
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.so
-%if %{isnative}
-%ifarch sparc ppc
+%if %{inlist %{target_arch} sparc ppc}
%dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/crt*.o
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/libgcc.a
@@ -1473,7 +1475,7 @@ fi
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/libmudflap.so
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/libmudflapth.so
%endif
-%ifarch %{multilib_64_archs}
+%if %{inlist %{target_arch} %{multilib_64_archs}}
%dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/crt*.o
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgcc.a
@@ -1487,12 +1489,13 @@ fi
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflap.so
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflapth.so
%endif
-%ifarch sparc sparc64 ppc ppc64
+%if %{inlist %{target_arch} sparc sparc64 ppc ppc64}
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflap.a
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflapth.a
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflap.so
%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflapth.so
%endif
+%if %{isnative}
%dir %{_prefix}/libexec/getconf
%{_prefix}/libexec/getconf/default
%endif
16 years, 1 month
kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide
by Alexandre Oliva
Hi,
I've stripped non-Free firmware bits from Fedora kernels for F8 and
rawhide, starting from tools developed by the gNewSense folks and now
in use by BLAG developers, and built alternate kernels that I've
successfully booted up and used on my x86_64 notebook.
You'd be surprised at how little it takes to get to a Free Software
kernel. It's just a few drivers that need firmware removed.
Nevertheless, I may have tentatively removed too much, and I'd
appreciate if someone would defend some of the bits I removed to be on
the safe (freedom-wise) side.
The first experimental kernels should be landing at
http://www.lsd.ic.unicamp.br/~oliva/snapshots/kernel-libre soon. The
version for Fedora 8 is based on 2.6.24.3-51 (one SCSI patch on top of
the just-released 2.6.24.3-50). The version for devel is based on
2.6.25-0.139.rc6.git5 in CVS.
Once I get some positive feedback and I'm happy with this arrangement,
I'll figure out how to track and number kernel-libre such that the
version it's based on becomes entirely obvious, and then I'll submit
it for integration into Fedora proper. I realize it's a bit late for
Fedora 9, but if it can be added to CVS, this will already make things
much easier. And then, once it's in CVS, and considering that it
doesn't add features (if anything, it removes features, unless you
count the possibility of 100% freedom as a feature, like me :-), maybe
it could go into Fedora 9, and maybe even Fedora 8.
Have fun, and please send feedback my way. If you respond to the
list, please Cc: me such that I don't miss the answers in all the
traffic of this list. Private replies are fine as well.
Thanks,
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
16 years, 1 month
RE: Some things to focus testing on for F9Beta
by Shawn Starr
>
> With respect to PackageKit, please test it, and please also update to
> the 0.1.10 version that is going to be released on Friday and should
> appear in rawhide at the same time. We have worked really hard on
> smoothing some of the rough edges, it should be much better.
>
I've been using it for the last three days, looks good, but some dialog box statuses are blank, when doing some upgrades to new packages.
I also note, when I get new kernel updates it is not prompting me to reboot system or give me the option to do so (as the screenshots do show this).
It seems very usable however
>
> gdm. Areas of interest for testing this: reliability - does gdm always
> come back, no matter how you end your session or kill the X server ?
> lockdown - we run some 'ordinary' applications on the login
gdm fails to load anything once you attempt to login if you do not have any DE installed. If you start with a @base system and then yum groupinstall "X Window System" gdm will load (it looks rather odd the theme) but it fails to go into the default twm environment (this was from rawhide).
Anyone can confirm this?
> screen, such
> as gnome-power-manager and metacity. The are locked down in various
> ways, and it would be good to know if that is successful - eg it would
> be bad if someone were able to run a web browser on the login screen.
Any reason gnome-power-manager wants to eat 1.0-1.3% CPU when the system is in use?
>
> Matthias
>
> --
--
Shawn Starr
Software Developer, Open Source Grid Development Center (OSGDC)
Platform Computing
3760 14th Avenue
Markham, ON L3R3T7
direct: 905.948.4229
http://www.platform.com
16 years, 1 month
disk devices in F9 interchanged
by Joachim Backes
I my actual F8, I have 2 disk devices: One Sata-Disk: /dev/sda, and 1 IDE-Disk: /dev/sdb.
But in F9 Beta, these two disks seem to be interchanged (/dev/sda <--> /dev/sdb). Is this true, and
if yes, why?
Regards
--
Joachim Backes <joachim.backes(a)rhrk.uni-kl.de>
University of Kaiserslautern,Computer Center [RHRK],
Systems and Operations, High Performance Computing,
D-67653 Kaiserslautern, PO Box 3049, Germany
--------------------------------------------------
Phone: +49-631-205-2438, FAX: +49-631-205-3056
16 years, 1 month
Too many default services on
by Harald Hoyer
Trying a yum everything install, I found out, that booting now takes endlessly.
# ls /etc/rc.d/rc5.d/S*|wc -l
95
Please review, if the packages really need to be "on" after an install.
# for i in /etc/rc.d/rc5.d/S*; do rpm -qf /etc/init.d/${i/*S[0-9][0-9]/};done | sort -u
acpid-1.0.6-6.fc9.i386
anacron-2.3-59.fc9.i386
apmd-3.2.2-7.i386
apt-0.5.15lorg3.94-3.fc9.i386
at-3.1.10-22.fc9.i386
audio-entropyd-1.0.1-2.fc9.i386
audit-1.6.9-1.fc9.i386
autofs-5.0.3-7.i386
avahi-0.6.22-9.fc9.i386
bcfg2-0.9.5.7-1.fc9.noarch
bcfg2-server-0.9.5.7-1.fc9.noarch
bluez-utils-3.26-1.fc9.i386
Canna-3.7p3-23.fc9.i386
certmaster-0.19-1.fc9.noarch
cman-2.0.60-3.fc7.i386
cobbler-0.8.2-1.fc9.noarch
condor-7.0.0-6.fc9.i386
cpuspeed-1.2.1-5.fc9.i386
cronie-1.0-5.fc9.i386
dbus-1.1.20-1.fc9.i386
dkms-2.0.17.6-1.fc9.noarch
firestarter-1.0.3-18.fc9.i386
fnfx-0.3-11.fc9.i386
func-0.18-1.fc9.noarch
fuse-2.7.3-2.fc9.i386
fyre-1.0.1-5.fc9.i386
hal-0.5.11-0.2.rc2.fc9.i386
heartbeat-2.1.3-1.fc9.i386
i8kutils-1.25-14.i386
ices-2.0.1-6.fc9.i386
ifplugd-0.28-7.fc8.i386
initscripts-8.67-1.i386
iptables-ipv6-1.4.0-4.fc9.i386
irqbalance-0.55-9.fc9.i386
iscsi-initiator-utils-6.2.0.868-0.3.fc9.i386
kerneloops-0.10-8.fc9.i386
kexec-tools-1.102pre-6.fc9.i386
koji-builder-1.2.3-1.fc9.noarch
koji-utils-1.2.3-1.fc9.noarch
ldirectord-2.1.3-1.fc9.i386
libvirt-0.4.1-4.fc9.i386
mcstrans-0.2.7-2.fc9.i386
microcode_ctl-1.17-1.42.fc9.i386
nas-1.9.1-3.fc9.i386
nessus-server-2.2.10-4.fc9.i386
NetworkManager-0.7.0-0.9.1.svn3476.fc9.i386
nfs-utils-1.1.1-4.fc9.i386
oki4linux-2.1gst-3.fc9.i386
openct-0.6.14-4.fc9.i386
openser-1.3.1-3.fc9.i386
openslp-server-1.2.1-9.fc9.i386
openssh-server-4.7p1-9.fc9.i386
openswan-2.6.09-2.fc9.i386
pcsc-lite-1.4.4-3.fc9.i386
plague-0.4.4.1-4.fc7.noarch
plague-builder-0.4.4.1-4.fc7.noarch
policycoreutils-2.0.46-2.fc9.i386
pop-before-smtp-1.41-2.fc6.noarch
qemu-0.9.1-4.fc9.i386
qpidd-0.2-17.fc9.i386
readahead-1.4.2-5.fc9.i386
rpcbind-0.1.4-14.fc9.i386
rsyslog-3.12.3-1.fc9.i386
sagator-1.0.0-1.fc9.noarch
sendmail-8.14.2-3.fc9.i386
ser-0.9.6-14.fc9.i386
ser2net-2.4-2.fc9.1.i386
setroubleshoot-server-2.0.6-1.fc9.noarch
smolt-1.1.1.1-1.fc9.noarch
snort-2.7.0.1-6.fc9.i386
sysstat-8.0.4-3.fc9.i386
tog-pegasus-2.7.0-6.fc9.i386
torque-mom-2.1.10-5.fc9.i386
torque-scheduler-2.1.10-5.fc9.i386
torque-server-2.1.10-5.fc9.i386
udev-118-11.fc9.i386
util-vserver-sysv-0.30.214-2.fc8.i386
uuidd-1.40.8-1.fc9.i386
wine-core-0.9.56-1.fc9.i386
xen-3.2.0-10.fc9.i386
xen-runtime-3.2.0-10.fc9.i386
xguest-1.0.6-6.fc9.noarch
xinetd-2.3.14-18.fc9.i386
yum-updatesd-0.9-1.fc9.noarch
zoneminder-1.22.3-12.fc9.i386
16 years, 1 month
Java packages, guidelines, ...
by Kevin Kofler
There are a bunch of packages blocking F-GUIDELINES on the ground of being Java
packages and the Java guidelines not being finalized. Yet there are another
bunch of Java packages which have been in Fedora for years. This is
inconsistent and just generally doesn't make sense. If what we have now is good
enough for all the existing packages, why wouldn't it be for new ones? And once
the guidelines are finalized, the packages can always be fixed to conform to
them.
Kevin Kofler
16 years, 1 month
RE: few ideas how to make fedora better as a desktop
by Shawn Starr
>
> There is also a similar case for /usr/bin vs /bin (e.g. some OSs
> traditionally had very stripped down versions of a few command in
> /sbin or /bin, then fuller ones in /usr/bin - trivial example would be
> "vi" of course).
>
This is because /sbin was for 'static' binaries (static-bin). We needed this back when live CDs didn't exist, or if you somehow foobared your GNU libc you had /sbin/sln (static link) to fix a system, now a days you pop in a CD, chroot to the saddened Linux system and repair it easily. You used /sbin as your emergency kit and superuser tools.
Shawn.
16 years, 1 month
