[FC2] OT - Desert Combat F-16 bug
by Shockwave
I have been operating a game server for the better part of a year that
runs a very popular mod of BattleField 1942 called Desert Combat. From
the start, I have been using Fedora Core 1 on a hyper-threaded P4 2.8GHz
system using the SMP kernel and have enjoyed fantastic stability and
performance. Just yesterday I upgraded the system to Fedora Core 2 and
have noticed something strange. All of a sudden, every F-16 fighter
that spawns on any map has its right rear wheel sunk into the ground.
The game files are the same exact ones from the system when it was
running FC1 so that can't be the cause.
The game itself has two versions of the executable. One is statically
linked and one is dynamically linked. I have tried both and the problem
still occurs. This seems to indicate to me that the problem lies with
operating system files that both versions require. I did a little
research and ran "ldd" against both the static and dynamic versions of
the executable. Here are the results:
Static build
======================
libdl.so.2 => /lib/libdl.so.2 (0x00c7e000)
libm.so.6 => /lib/tls/libm.so.6 (0x00c59000)
libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03798000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d71000)
libc.so.6 => /lib/tls/libc.so.6 (0x00b3c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b1f000)
Dynamic build
======================
libdl.so.2 => /lib/libdl.so.2 (0x00c7e000)
libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03798000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0023a000)
libm.so.6 => /lib/tls/libm.so.6 (0x00c59000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00191000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d71000)
libc.so.6 => /lib/tls/libc.so.6 (0x00b3c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b1f000)
The only lines that differ between the two are these:
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0023a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00191000)
While it is possible that only the lines in common are to blame, it is
also logical to assume that it may be related to an interface between
them and other system components. Not having a tremendous amount of
experience with C under Linux, I'm not quite sure where to go next but I
am certainly willing to roll up my sleeves and dive in head first.
If determining the specific cause of this problem by someone who isn't a
developer of the game itself is not feasible, then my question is this:
Is it possible to isolate the pieces specific to FC1 and use them in
some sort of artificial environment on FC2? If that is possible,
perhaps the game server could be tricked into believing that the system
was actually FC1. That assumes, of course, that this isn't some kernel
related issue which certainly cannot be circumvented.
The gaming community tends to be fairly picky about this sort of thing
and might not feel comfortable playing on our server for matches if this
bug persists. That would mean I would need to go back to FC1 and lose
the benefits of the advances in FC2. That's something I would obviously
like to avoid. I and others have posted about this problem for some
time now and the developers of the mod probably won't respond because
they have moved on to bigger and better things. If anyone could point me
in the right direction, I would greatly appreciate it.
--
|TF20|Shockwave
http://www.clan-tf20.com/
ICQ# 57671167
#taskforce20 irc.gamesurge.net
19 years, 6 months
syslog-ng to replace syslogd
by seth vidal
Hi all,
I think syslog-ng should probably be brought into Fedora Core to
replace syslogd.
In order to achieve that goal I've been told that making a good case for
why syslog-ng is beneficial to the distro needs to be added to this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113858
I'll be adding my own comments shortly, but if any of you have comments
to that regard please add them.
Thanks
-sv
19 years, 6 months
yum 2.1.0
by seth vidal
Hi All,
I'm only sending this to devel lists b/c using this release should be
for people who are:
1. comfortable with python tracebacks
2. comfortable with things breaking from time to time
3. comfortable with reporting bugs and using bugzilla.
So, with that in mind.
I'm pleased(sorta) to announce yum 2.1.0. This is using the new xml-
based repository metadata (http://linux.duke.edu/metadata).
NB: THIS CAN ONLY BE USED WITH REPOSITORIES THAT ARE USING THE NEW
METADATA FORMAT. THIS WILL NOT WORK WITH OLD-STYLE YUM-ARCH
REPOSITORIES.
What's New:
- all sorts of things, not the least of which is a huge percentage of
the code. :)
- I've not documented all the new things, if someone would like to
point out things, please, do so.
What's Known to be Broken:
- all the docs are wrong or somewhat wrong - if you want to know about
config variables read yum/config.py - that should be VERY clear
- all the groups functions do not work - they're just not hooked up
- all the clean functions do nothing
- the search and provides functions are not hooked up, either.
- when updating a kernel it will not make the new kernel the default
boot kernel.
What's Known to Work:
yum install/update/upgrade/remove/
yum list
yum info
yum generate-rss
What needs to be done:
- translations
- clean up some output
- docs
- group functions
- clean functions
- search/provides/query/etc
- all sorts of goodies I've missed while writing infrastructure.
Where you get it:
http://linux.duke.edu/yum/download/2.1/
Where you report bugs:
https://devel.linux.duke.edu/bugzilla/
Where you send hatemail:
Either yum-devel list or fedora-devel-list.
Thanks,
-sv
19 years, 7 months
Kernel 2.6.8-1.521 breaks Cisco VPN client...
by Kim B. Nielsen
Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN client in
a very odd way.
The current network configuration og the laptop I'm using, is a wireless
network card, and an normal network card (wirefull).
The funny thing is, that when i start the client on the wireless
interface, everything is fine, and everything works as it's supposed to.
If i then shifts to the wire, UDP packages suddently isn't comming
throug, but tcp connections work fine. That is, no name server
resolution, but I'm able to ping and access sites with the ip.
I know that the vpn client is Cisco's responsibility, but I thought I
would mention it to you, in case that it points to something gone bad in
the kernel. I have tried to do the same exercises with the -358 kernel
that ships with Fedora, and everything works in this kernel.
I hope this is of some use (And that a fix can be made :)
Regards
/kbn
----
Ouuh... Everybody here has a six-pack, but all I've got is a keg...
-Homer Simpson
19 years, 7 months
CONFIG_HIGHMEM64G=y for x86_64 SMP kernels
by Ed Hill
Hi folks,
I've been using FC2 and devel kernels for one of our dual-Opteron
systems and am very happy with recent improvements. Everything works
well for us including:
- AMD IDE interface
- tg3 driver (dual Broadcom BCM5704 GigE)
- 3w_9xxx driver (8-port 3ware SATA card)
The only request I have is that the following be added to the x86_64-SMP
kernel config:
CONFIG_HIGHMEM=y
CONFIG_HIGHMEM64G=y
I've been building custom kernels based on the testing SRPMs with just
this one small change and (for us at least) it works well on:
kernel-2.6.7-1.494
kernel-2.6.8-1.524
kernel-2.6.8-1.533
Would it be possible to make "CONFIG_HIGHMEM64G=y" the default for SMP
x86_64 kernels? I bow to the kernel experts, but it does appear to be a
reasonable default given the likelihood of SMP Opterons having more than
4Gig RAM.
And I'll gladly add this to bugzilla if someone will recommend the best
topic for it.
Ed
--
Edward H. Hill III, PhD
office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave.
Cambridge, MA 02139-4307
emails: eh3(a)mit.edu ed(a)eh3.com
URLs: http://web.mit.edu/eh3/ http://eh3.com/
phone: 617-253-0098
fax: 617-253-4464
19 years, 7 months
RFC: Fedora Extras shipping ix86 optimized rpms?
by Ralf Corsepius
Hi,
Question: Shall Fedora Extras support ix86 optimized packages but
i386-compiled packages rsp. under shall circumstances shall Fedora
Extras support such packages?
Background: Some folks have started to add i686-built application
packages in addition to i386-built packages to Fedora Extras, claiming
these i686-built, "optimized packages" would result into much better
performance of these packages ("up to factor 2").
I'd rather prefer all packages to be built with RH/FC standard rpm
compilation flags (-march=i386 -mcpu=i686; rpmbuild --target=i386),
because this avoids a lot of the complexity and potential breakdowns of
shipping such "optimized packages" and to ship non-i386 packages only
where absolutely inevitable.
I.e. I'd like to Fedora Extras packaging policy to be extended to make
RH/FC's compilation flags mandatory to packages and to allow building
packages for other rpm-targets only in very rare exceptional cases.
For details of the discussion cf.
https://bugzilla.fedora.us/show_bug.cgi?id=2033
Ralf
--
Registered Linux User #26 http://counter.li.org
19 years, 7 months
State of Unichrome support
by Jason L Tibbitts III
I just put together a cheap Sempron system with an Abit VA-10 board
that has an onboard S3 Unichrome chipset. I installed FC2 and updated
to the latest rawhide hwdata, system-config-display, Xorg and kernel
packages.
system-config-display doesn't recognize the chipset at all and
suggests the VESA driver. Should I open a bug for this?
I edited xorg.conf and set it straight. X runs fine and 2D seems
accelerated but 3D is not. I thought Unichrome DRM had been merged
but I don't see a kernel module for it; is there any way to turn it
on?
I'm quite happy that 2D is working; thanks to all who have made this
possible. A quick note, though: the video output on this board is
blurry and generally rather poor. I've tried several (Unichrome,
Intel, ProSavage) and have yet to find an onboard chipset that
produces reasonable video output.
lspci shows:
00:00.0 Host bridge: VIA Technologies, Inc. VT8378 [KM400] Chipset Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8378 [S3 UniChrome] Integrated Video (rev 01)
- J<
19 years, 7 months
Re: Kernel 2.6.8-1.521 breaks Cisco VPN client...
by Kim B. Nielsen
I'm using the 4.0.4.B-k9 version of the client. Downloading the latest
from Cisco didn't work either...
/kbn
Denis Leroy wrote:
>Maybe i'm using a different version of vpnclient ? :
>
>
>
>>rpm -qf /usr/sbin/vpnclient
>>
>>
>vpnclient-4.0.4.A_k9-0.fdr.1
>
>
>--- "Kim B. Nielsen" <kbn(a)daimi.au.dk> wrote:
>
>
>
>>That's oddd...
>>
>>I've experienced my behaviour on two different laptops now. For some
>>reasen, the wireless has worked perfectly in both cases, but not the
>>wire...
>>The laptops are from two different manufacturers (Dell and IBM) So
>>somehow I don't think it's a unique problem related to one specific
>>laptop or network card.
>>
>>/kbn
>>
>>Denis Leroy wrote:
>>
>>
>>
>>>I'm also using the Cisco VPN client here at Sun, to connect my
>>>
>>>
>>laptop
>>>from home, but I'm not having the problem, for me things are
>>working
>>
>>
>>>correctly with the 521 kernel, at least on the wire (never quited
>>>worked with the wireless card though). Though i mainly use ssh, dns
>>>resolutions certainly work...
>>>
>>>-denis
>>>
>>>--- "Kim B. Nielsen" <kbn(a)daimi.au.dk> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Just to report it, the 2.6.8-1.521 kernel breaks the Cisco VPN
>>>>
>>>>
>>client
>>
>>
>>>>in
>>>>a very odd way.
>>>>
>>>>The current network configuration og the laptop I'm using, is a
>>>>wireless
>>>>network card, and an normal network card (wirefull).
>>>>
>>>>The funny thing is, that when i start the client on the wireless
>>>>interface, everything is fine, and everything works as it's
>>>>
>>>>
>>supposed
>>
>>
>>>>to.
>>>>If i then shifts to the wire, UDP packages suddently isn't comming
>>>>throug, but tcp connections work fine. That is, no name server
>>>>resolution, but I'm able to ping and access sites with the ip.
>>>>
>>>>I know that the vpn client is Cisco's responsibility, but I thought
>>>>
>>>>
>>I
>>
>>
>>>>would mention it to you, in case that it points to something gone
>>>>
>>>>
>>bad
>>
>>
>>>>in
>>>>the kernel. I have tried to do the same exercises with the -358
>>>>kernel
>>>>that ships with Fedora, and everything works in this kernel.
>>>>
>>>>I hope this is of some use (And that a fix can be made :)
>>>>
>>>>Regards
>>>>/kbn
>>>>
>>>>----
>>>>Ouuh... Everybody here has a six-pack, but all I've got is a keg...
>>>>-Homer Simpson
>>>>
>>>>
>>>>--
>>>>fedora-devel-list mailing list
>>>>fedora-devel-list(a)redhat.com
>>>>http://www.redhat.com/mailman/listinfo/fedora-devel-list
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>"UNIX is user friendly, it's just selective about who its friends
>>are."
>> --Unknown
>>
>>
>>
>>--
>>fedora-devel-list mailing list
>>fedora-devel-list(a)redhat.com
>>http://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>>
>>
19 years, 7 months
callgrind and graphviz
by Caolán McNamara
The kdesdk rpm includes kcachegrind, but callgrind and graphviz are not
in FC3, callgrind is the actual calltree generating backend for
kcachegrind, while graphviz is used to draw the pretty calltree
diagrams.
Are there existing reasons why they are not in FC ? oversights or is
there licence issues, esp with graphviz ?
C.
19 years, 7 months