10:12 a.m.
Welcome to Fedora 7 Test 2
I am please to announce the second test release for Fedora 7.
Downloads
========
DVD and network installation are available.
Please read the Important Warnings below in this announcement for more
details.
http://torrent.fedoraproject.org/
The recommended method of download is via BitTorrent from this site.
http://fedora.redhat.com/Download/mirrors.html
HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors
listed above. Note that not all mirrors may be synced at this time.
***Important Warnings about the Test Release***
Problems with mkinitrd
========
This test release has an rpm ordering issue that seems to affect some people
with regard to mkinitrd being installed correctly. If your install seems to
stall at installing the kernel and never continues, please try the updates
image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to
http://fedoraproject.org/wiki/Anaconda/Updates for more information on using
updates images.
Upgrading with PATA Hard Disks
========
If you are using PATA (parallel or "original" style ATA) hard disks and you
attempt to do a manual yum upgrade to this release, you may be unable to boot
your system when finished. To avoid this problem, use the installer program
(Anaconda) to upgrade your system instead of using yum.
New in Fedora 7 Test 2
========
This test release includes significant new versions of many key components and
technologies. The following sections provide a brief overview of major
changes from the last release of Fedora.
Merger of Core and Extras
========
* The Fedora Core and Extras software repositories are being merged,
resulting in a shared infrastructure and a single repository of packages to
which everyone is invited to contribute.
* Fedora 7 Test 2 is packaged initially as a Desktop/Development
Workstation/Server implementation, called "Prime". This spin is delivered in
DVD iso format only as a trial, see
https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00993....
for the discussion on this.
* Many more packages are available in the development repositories.
* Three targetted spins are now under discussion: Fedora Prime, Fedora
KDE, and Fedora Everything. See
http://fedoraproject.org/wiki/Releases/FeatureFedoraTargettedSpins for more
details.
Live CD
========
* This test release includes an i386 ISO for a Desktop Live CD. This Live
CD features the ability to install to a hard disk using the same graphical
Anaconda installer as the non-live CD variant.
Desktop
========
* This test release features GNOME 2.17.91.
* A brand new Echo icon theme is included as the default in this release.
This icon theme is incomplete, but with appropriate feedback and progress,
may become the default in the general release.
* KDE and Xfce, among several other packages, are included in the
development repositories, but not on the media. They can be installed using
the appropriate software management tools.
* Fast User Switching is now available via the fast-user-switch-applet.
See http://fedoraproject.org/wiki/Releases/FeatureFastUserSwitching for more
details.
Performance
========
* System performance is generally slower in the test releases as compared
to the general release since we enable several options that help with
debugging.
System Administration
========
* System administration tools may be modified under the testing process.
System Level Changes
========
* Fedora 7 Test 2 features a 2.6.21rc1 based kernel. Current release
information is being tracked on the kernel release notes source page.
(http://fedoraproject.org/wiki/Docs/Beats/Kernel)
Amanda
Users who upgrade from older releases need to read the amanda.conf and
amanda-client.conf man pages to learn about the the new syntax for calling
amandad, as well as edit the /etc/xinetd.d/amanda configuration file to
follow the new syntax.
Road Map And Release Schedule
========
* http://fedoraproject.org/wiki/Releases/7/
Intended Audience for Test Releases
========
Test 1 is targeted for developers, who use it "at their own risk", and
contains many bleeding edge packages.
Test 2 is for early adopters. Most things should work and we need to your help
to find what is broken.
Test 3 is for early adopters. Most things should work and we need to your help
to find what is broken.
Test 4 is for beta users. This is the time when we must have full community
participation. Without this participation both hardware and software
functionality suffers.
Quality Assurance for Test Releases
========
The Fedora Project has a process in place for ensuring the highest possible
quality even in our test releases. Many bugs are identified, prioritized and
fixed during the testing process. We also have a list of known bugs in this
release. Refer to http://fedoraproject.org/wiki/QA/7/Test2TreeTesting for
more details.
Translations of Release Notes
========
Due to the rapidly changing nature of test releases, translations of release
notes for test releases are not practical. The initial goal is to have a
translation of the release notes included in the test4 release and to allow
community review and correction before the general release. As always, the
general release is translated following the established practices for
localization (l10n) and internationalization (i18n)
(http://fedoraproject.org/wiki/L10N), which result in comprehensive,
high-quality release notes in a variety of languages.
About Fedora
========
Fedora is a set of projects sponsored by Red Hat and guided by the
contributors. These projects are developed by a large community of people who
strive to provide and maintain the very best in free, open source software
and standards. The central Fedora project is an operating system and platform
based on Linux that is always free for anyone to use, modify, and distribute,
now and forever.
You can help the Fedora Project community continue to improve Fedora if you
file bug reports and enhancement requests. Refer to
http://fedoraproject.org/wiki/BugsAndFeatureRequests for more information.
Thank you for your participation.
To find out more general information about Fedora, refer to the following Web
pages:
* Fedora Overview (http://fedoraproject.org/wiki/Overview)
* Fedora FAQ (http://fedoraproject.org/wiki/FAQ)
* Help and Support (http://fedoraproject.org/wiki/Communicate)
* Participate in the Fedora Project
(http://fedoraproject.org/wiki/HelpWanted)
--
Jesse Keating
Release Engineer: Fedora
10:28 a.m.
Jesse Keating wrote:
Upgrading with PATA Hard Disks
========
If you are using PATA (parallel or "original" style ATA) hard disks and you
attempt to do a manual yum upgrade to this release, you may be unable to boot
your system when finished. To avoid this problem, use the installer program
(Anaconda) to upgrade your system instead of using yum.
"*Manual* yum upgrade" implies that I would prefer some *manual* (not
Anaconda) way to fix this issue...
In other words, what I should do after the "yum upgrade" and before the
reboot?
Dmitry Butskoy
10:35 a.m.
On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote:
Jesse Keating wrote:
> Upgrading with PATA Hard Disks
> ========
> If you are using PATA (parallel or "original" style ATA) hard disks and
> you attempt to do a manual yum upgrade to this release, you may be unable
> to boot your system when finished. To avoid this problem, use the
> installer program (Anaconda) to upgrade your system instead of using yum.
"*Manual* yum upgrade" implies that I would prefer some *manual* (not
Anaconda) way to fix this issue...
In other words, what I should do after the "yum upgrade" and before the
reboot?
you would need to setup modprobe.conf before you do your yum update make
sure
it has the correct entry for the module for your pata controller.
--
Dennis Gilmore, RHCE
10:55 a.m.
Dennis Gilmore wrote:
On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote:
> Jesse Keating wrote:
>> Upgrading with PATA Hard Disks
>> ========
>> If you are using PATA (parallel or "original" style ATA) hard disks
and
>> you attempt to do a manual yum upgrade to this release, you may be unable
>> to boot your system when finished. To avoid this problem, use the
>> installer program (Anaconda) to upgrade your system instead of using yum.
> "*Manual* yum upgrade" implies that I would prefer some *manual* (not
> Anaconda) way to fix this issue...
>
> In other words, what I should do after the "yum upgrade" and before the
> reboot?
you would need to setup modprobe.conf before you do your yum update make sure
it has the correct entry for the module for your pata controller.
Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that
you need to make sure that you're filesystems are mounted by label, and
then after reboot and you know which sdy is your old hdx, fixup
/etc/fstab for swap
Regards,
Hans
10:41 a.m.
On Thu, Mar 01, 2007 at 05:55:25PM +0100, Hans de Goede wrote:
>>In other words, what I should do after the "yum
upgrade" and before the
>>reboot?
>you would need to setup modprobe.conf before you do your yum update make
>sure it has the correct entry for the module for your pata controller.
>
Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that
you need to make sure that you're filesystems are mounted by label, and
then after reboot and you know which sdy is your old hdx, fixup
/etc/fstab for swap
It's probably a good idea to fix up /etc/sysconfig/grub before running
Anaconda too [1]
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229704
10:46 a.m.
Hans de Goede wrote:
Dennis Gilmore wrote:
> On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote:
>> Jesse Keating wrote:
>>> Upgrading with PATA Hard Disks
>>> ========
>>> If you are using PATA (parallel or "original" style ATA) hard disks
and
>>> you attempt to do a manual yum upgrade to this release, you may be
>>> unable
>>> to boot your system when finished. To avoid this problem, use the
>>> installer program (Anaconda) to upgrade your system instead of using
>>> yum.
>> "*Manual* yum upgrade" implies that I would prefer some *manual* (not
>> Anaconda) way to fix this issue...
>>
>> In other words, what I should do after the "yum upgrade" and before
the
>> reboot?
> you would need to setup modprobe.conf before you do your yum update
> make sure it has the correct entry for the module for your pata
> controller.
>
Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that
you need to make sure that you're filesystems are mounted by label, and
then after reboot and you know which sdy is your old hdx, fixup
/etc/fstab for swap
Nope, this is about the PATA drivers being built as modules now.
http://kernelslacker.livejournal.com/72836.html
Paul.
10:46 a.m.
On Thursday 01 March 2007 10:55:25 am Hans de Goede wrote:
Dennis Gilmore wrote:
> On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote:
>> Jesse Keating wrote:
>>> Upgrading with PATA Hard Disks
>>> ========
>>> If you are using PATA (parallel or "original" style ATA) hard
disks and
>>> you attempt to do a manual yum upgrade to this release, you may be
>>> unable to boot your system when finished. To avoid this problem, use
>>> the installer program (Anaconda) to upgrade your system instead of
>>> using yum.
>>
>> "*Manual* yum upgrade" implies that I would prefer some *manual* (not
>> Anaconda) way to fix this issue...
>>
>> In other words, what I should do after the "yum upgrade" and before
the
>> reboot?
>
> you would need to setup modprobe.conf before you do your yum update make
> sure it has the correct entry for the module for your pata controller.
Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that
you need to make sure that you're filesystems are mounted by label, and
then after reboot and you know which sdy is your old hdx, fixup
/etc/fstab for swap
Thats part of it to. the ata drivers are modules now and not
built into the
kernel. I probably missed something else also.
--
Dennis Gilmore, RHCE
10:42 a.m.
On Thu, 2007-03-01 at 19:28 +0300, Dmitry Butskoy wrote:
Jesse Keating wrote:
> Upgrading with PATA Hard Disks
> ========
> If you are using PATA (parallel or "original" style ATA) hard disks and
you
> attempt to do a manual yum upgrade to this release, you may be unable to boot
> your system when finished. To avoid this problem, use the installer program
> (Anaconda) to upgrade your system instead of using yum.
>
"*Manual* yum upgrade" implies that I would prefer some *manual* (not
Anaconda) way to fix this issue...
In other words, what I should do after the "yum upgrade" and before the
reboot?
AFAIK this works now. I upgraded from FC6 to rawhide yesterday on a
PATA laptop with no problems, and no special dancing required.
- ajax
10:59 a.m.
Jesse Keating (jkeating(a)redhat.com) said:
> AFAIK this works now. I upgraded from FC6 to rawhide yesterday
on a
> PATA laptop with no problems, and no special dancing required.
Rawhide yesterday is newer than what Test2 is.
Sure, but nothing changed in that area between test2 and now.
Bill
11:55 a.m.
Dnia 01-03-2007, czw o godzinie 11:12 -0500, Jesse Keating napisał(a):
[..]
Any chanse for fix X server memory leak before final Fedora 7 ?
Anyone working on this ?
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
COMMAND
25851 root 15 0 1941m 729m 7868 S 15 36.2 43:33.34
Xorg
kloczek
11:49 a.m.
On Thu, 2007-03-01 at 18:55 +0100, Tomasz Kłoczko wrote:
Dnia 01-03-2007, czw o godzinie 11:12 -0500, Jesse Keating
napisał(a):
[..]
Any chanse for fix X server memory leak before final Fedora 7 ?
Anyone working on this ?
You say this as though there were only one X server memory leak.
Or as though you had a working testcase.
Or as though it were actually X's fault instead of some boneheaded
application you happen to be running.
- ajax
12:54 p.m.
Dnia 01-03-2007, czw o godzinie 12:49 -0500, Adam Jackson napisał(a):
You say this as though there were only one X server memory leak.
Or as though you had a working testcase.
Or as though it were actually X's fault instead of some boneheaded
application you happen to be running.
[..]
Run any gecko application (firefox, galeon, epiphany) and open page with
short refresh time (I have usualy openned page with system monitoring
like mrtg or zabbix) and start observe groving X server memory
consumption.
Module section from my /etc/X11/xorg.conf:
Section "Module"
Load "bitmap"
Load "dbe"
Load "dbe"
Load "dri"
Load "extmod"
Load "fbdevhw"
Load "freetype"
Load "glx"
Load "record"
Load "type1"
Load "xtrap"
EndSection
Fill free for as for any more details :)
kloczek
1:01 p.m.
On Thu, 2007-03-01 at 19:54 +0100, Tomasz Kłoczko wrote:
Dnia 01-03-2007, czw o godzinie 12:49 -0500, Adam Jackson
napisał(a):
> You say this as though there were only one X server memory leak.
>
> Or as though you had a working testcase.
>
> Or as though it were actually X's fault instead of some boneheaded
> application you happen to be running.
[..]
Run any gecko application (firefox, galeon, epiphany) and open page with
short refresh time (I have usualy openned page with system monitoring
like mrtg or zabbix) and start observe groving X server memory
consumption.
That's Gecko, not the X server. It has pretty aggressive image caching
and stores the pixmaps on the server, not in its own memory. If you
shut down that process and the X server returns to something sane it's
not an X leak. (It's even arguable that if it doesn't shrink it's still
not an X leak but is a fragmented allocator, but that's another
discussion.)
--Chris
1:32 p.m.
Dnia 01-03-2007, czw o godzinie 14:01 -0500, Christopher Blizzard
napisał(a):
That's Gecko, not the X server. It has pretty aggressive image
caching and stores the pixmaps on the server, not in its own memory.
If you shut down that process and the X server returns to something
sane it's not an X leak. (It's even arguable that if it doesn't
shrink it's still not an X leak but is a fragmented allocator, but
that's another discussion.)
I don't think it is in not only gecko bug because after kill all gecko
applications amount of memory reserved by X server not back to start
amount. Also xrestop don't shows anything about allocated big amount of
memory on X server side for pixmaps.
I'm just kill on my system all gecko applications and amount of memory
used by X serwer drop down *only* from ~2.2GB to ~1.9GB. If it is not
ML .. OK. Anyone working on fix X server "fragmented allocator" or so ?
Also another fact: I have on my hands Sunray thin X terminal which uses
own X server and as long I use the same scenario (gecko application with
refreshing page) I never observe for example killing X session by some
symptoms like X server memory leaks (SunRay server it is Solaris 10U2).
X session on SunRay can be runed many days without even growing amount
of memory consumed by gecko application on X client side and X server on
Solaris side. This ML^H^Hfragmentation allocator bug not occurs probably
because Solaris uses older version of Xorg X server (without this nasty
bug) so probably shorter way fo fix this can be some regression tests
observation.
The same gecko application on remote Linux X server in my case can kills
my X session (OOM) in ~2 days (X server is runed on computer with 4GB
memory and 8GB swap).
So IMO it is definitely something wrong on X server side. Even it it is
not my question stays .. Q: anyone working on fix this ?
kloczek
1:31 p.m.
On Thu, 2007-03-01 at 20:32 +0100, Tomasz Kłoczko wrote:
Dnia 01-03-2007, czw o godzinie 14:01 -0500, Christopher Blizzard
napisał(a):
> That's Gecko, not the X server. It has pretty aggressive image
> caching and stores the pixmaps on the server, not in its own memory.
> If you shut down that process and the X server returns to something
> sane it's not an X leak. (It's even arguable that if it doesn't
> shrink it's still not an X leak but is a fragmented allocator, but
> that's another discussion.)
I don't think it is in not only gecko bug because after kill all gecko
applications amount of memory reserved by X server not back to start
amount. Also xrestop don't shows anything about allocated big amount of
memory on X server side for pixmaps.
The memory usage won't always drop back to where it was when you
started, because the allocation arena is shared. Mozilla's pixmaps will
be interleaved with those of other apps, so the highest-address
allocation not belonging to Mozilla will stick around.
I'm just kill on my system all gecko applications and amount of
memory
used by X serwer drop down *only* from ~2.2GB to ~1.9GB. If it is not
ML .. OK. Anyone working on fix X server "fragmented allocator" or so ?
There's nobody working on an allocation repacker for X, no, and it would
be a rather brutal thing to implement. I started hacking some page-out
code for inactive pixmaps, but never got it working, and it's unclear
that it would help.
So IMO it is definitely something wrong on X server side. Even it it
is
not my question stays .. Q: anyone working on fix this ?
It's really hard to fix memory leaks you can't reproduce, and I've left
X and firefox running for months on end without hitting this behaviour.
- ajax
1:59 p.m.
Dnia 01-03-2007, czw o godzinie 14:31 -0500, Adam Jackson napisał(a):
[..]
It's really hard to fix memory leaks you can't reproduce, and
I've left
X and firefox running for months on end without hitting this behaviour.
Moment .. You can't reproduce this bug using my test case on refreshing
pages with big pixmaps ? Are you try this on the same loaded modules
set ? (maybe it is core of problem ?)
Anyone else observe this kind buggy effects with growing X serer
memory ?
kloczek
2:01 p.m.
On Thu, 2007-03-01 at 20:59 +0100, Tomasz Kłoczko wrote:
Dnia 01-03-2007, czw o godzinie 14:31 -0500, Adam Jackson
napisał(a):
[..]
> It's really hard to fix memory leaks you can't reproduce, and I've left
> X and firefox running for months on end without hitting this behaviour.
Moment .. You can't reproduce this bug using my test case on refreshing
pages with big pixmaps ? Are you try this on the same loaded modules
set ? (maybe it is core of problem ?)
Pick any given page on flickr, whack F5 for 10 minutes or so, no change
in VSZ.
I'm almost certain that your module set is irrelevant; you could verify
this claim by deleting your Modules section, since it's autoconfigured
now anyway.
- ajax
6:58 p.m.
On Thu, 2007-03-01 at 20:59 +0100, Tomasz Kłoczko wrote:
Dnia 01-03-2007, czw o godzinie 14:31 -0500, Adam Jackson
napisał(a):
[..]
> It's really hard to fix memory leaks you can't reproduce, and I've left
> X and firefox running for months on end without hitting this behaviour.
Moment .. You can't reproduce this bug using my test case on refreshing
pages with big pixmaps ? Are you try this on the same loaded modules
set ? (maybe it is core of problem ?)
Anyone else observe this kind buggy effects with growing X serer
memory ?
I have habit of opening hundreds of tabs at a time in Galeon. That's a
good way to hit this kind of problem...
Also irritating is millions of javascripts and flash adverts and
animated gifs eating up assloads of CPU in tabs that aren't even
visible.
It would be nice if non-visible tabs were completely taken off the
events list or maybe unloaded entirely. And have a proper LRU cache of
images, images not displayed recently get dumped completely, when
they're needed again, decode them from the original jpeg/gif on disk in
the browser cache.
Crackrock I say, crackrocks everywhere.
2:36 a.m.
Le Lun 5 mars 2007 01:58, Callum Lerwick a écrit :
It would be nice if non-visible tabs were completely taken off the
events list or maybe unloaded entirely.
I'd really love if the desktop variant shipped with a small local
squid/apache proxy enabled by default, instead of doing caching in a
user-by-user and app-by-app basis
Would do wonders for browser responsiveness & resource use
--
Nicolas Mailhot
7:51 a.m.
On Monday 05 March 2007 09:36:58 Nicolas Mailhot wrote:
Le Lun 5 mars 2007 01:58, Callum Lerwick a écrit :
> It would be nice if non-visible tabs were completely taken off the
> events list or maybe unloaded entirely.
I'd really love if the desktop variant shipped with a small local
squid/apache proxy enabled by default, instead of doing caching in a
user-by-user and app-by-app basis
Would do wonders for browser responsiveness & resource use
I have been a longtime user of WWWOFFLE, a proxy whose usage pattern matches
your description above (and overlaps privoxy to some extent). A Fedora RPM
can be found using Google (ATrpms, IIRC). It works well enough for everyday
use. I don't think a local proxy would cause Firefox to behave, however.
Hope this helps,
Davide Bolcioni
--
Paranoia is a survival asset.
8:35 a.m.
Nicolas
I'd really love if the desktop variant shipped with a small local
squid/apache proxy enabled by default, instead of doing caching in a
user-by-user and app-by-app basis
Would do wonders for browser responsiveness & resource use
I doubt that replacing the inbuilt app caching with a local proxy would
improve responsiveness. I'm not sure if that's what you had in mind though.
-Cam
--
camilo(a)mesias.co.uk <--
3:13 a.m.
New subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91))
Dnia 04-03-2007, nie o godzinie 18:58 -0600, Callum Lerwick napisał(a):
[..]
Also irritating is millions of javascripts and flash adverts and
animated gifs eating up assloads of CPU in tabs that aren't even
visible.
But are you talking about refreshing pages ?
In my case problematic refreshing pages contains png but seems it
doesn't matter it is png or gif of jpeg files and I can reproduce this
also on by hand reloaded page. I can reproduce this also on opened png
file in firefox/galeon by refreshing this using ctrl-r.
I'm save single png file from zabbix map page (~40KB 1000x1000 png
file), generate copy of this file in jpeg and gif and open this files in
separated tabs (png, jpeg and gif).
Each time ctrl-r press on each tab causes in my case eats next chunk of
memory by X server.
Before refresh:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3253 root 16 0 1480m 845m 8148 S 12 42.0 787:18.00 Xorg
After five time ctrl-r:
3253 root 15 0 1480m 864m 8148 R 8 42.9 787:30.59
Xorg
RES groves ~19MB. This png file have 1000x1000 pixels and X display
depth is 24bpp. 1000x1000x3 = ~3MB .. so looks like buffer for keep this
previous version of this files was not released.
Can you check this on your system using above scenario ?
Try to open gif/png file which will take big amount of memory in
uncompressed form (1MB or more).
kloczek
7:46 a.m.
New subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91))
Tomasz Kłoczko wrote:
Dnia 04-03-2007, nie o godzinie 18:58 -0600, Callum Lerwick
napisał(a):
[..]
> Also irritating is millions of javascripts and flash adverts and
> animated gifs eating up assloads of CPU in tabs that aren't even
> visible.
But are you talking about refreshing pages ?
In my case problematic refreshing pages contains png but seems it
doesn't matter it is png or gif of jpeg files and I can reproduce this
also on by hand reloaded page. I can reproduce this also on opened png
file in firefox/galeon by refreshing this using ctrl-r.
I'm save single png file from zabbix map page (~40KB 1000x1000 png
file), generate copy of this file in jpeg and gif and open this files in
separated tabs (png, jpeg and gif).
Each time ctrl-r press on each tab causes in my case eats next chunk of
memory by X server.
Before refresh:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3253 root 16 0 1480m 845m 8148 S 12 42.0 787:18.00 Xorg
After five time ctrl-r:
3253 root 15 0 1480m 864m 8148 R 8 42.9 787:30.59
Xorg
RES groves ~19MB. This png file have 1000x1000 pixels and X display
depth is 24bpp. 1000x1000x3 = ~3MB .. so looks like buffer for keep this
previous version of this files was not released.
Can you check this on your system using above scenario ?
Try to open gif/png file which will take big amount of memory in
uncompressed form (1MB or more).
And when you close the web browser what happens? Chances are that the
web browser is leaking pixmaps. That's something not uncommon.
9:31 a.m.
New subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91))
On Tue, 2007-03-06 at 08:46 -0500, Mike A. Harris wrote:
Tomasz Kłoczko wrote:
> Before refresh:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3253 root 16 0 1480m 845m 8148 S 12 42.0 787:18.00 Xorg
>
> After five time ctrl-r:
> 3253 root 15 0 1480m 864m 8148 R 8 42.9 787:30.59
> Xorg
>
> RES groves ~19MB. This png file have 1000x1000 pixels and X display
> depth is 24bpp. 1000x1000x3 = ~3MB .. so looks like buffer for keep this
> previous version of this files was not released.
>
> Can you check this on your system using above scenario ?
> Try to open gif/png file which will take big amount of memory in
> uncompressed form (1MB or more).
And when you close the web browser what happens? Chances are that the
web browser is leaking pixmaps. That's something not uncommon.
What he said. Check firefox's resource usage in xrestop as you do this.
It's probably growing at about the same rate.
X is a server process, it can only do what its clients ask of it. If
the client says "hey, here's a 30M pixmap, hold onto it for me", well,
that's what it'll do.
- ajax
1:25 p.m.
New subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91))
Adam Jackson <ajackson(a)redhat.com> writes:
[...]
What he said. Check firefox's resource usage in xrestop as you do this.
It's probably growing at about the same rate.
[...]
Indeed, mozilla/firefox is infamous for this. See for example this:
<https://bugzilla.mozilla.org/show_bug.cgi?id=259672>;, opened in 2004.
- FChE
10:42 p.m.
New subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91))
On Mon, 2007-03-05 at 10:13 +0100, Tomasz Kłoczko wrote:
Can you check this on your system using above scenario ?
Try to open gif/png file which will take big amount of memory in
uncompressed form (1MB or more).
I do this fairly often. Yes, it will make Galeon (and the X server) eat
up RAM like no tomorrow, and it never gets returned.
2:20 p.m.
On Donnerstag 01 März 2007, Jesse Keating wrote:
System Level Changes
========
* Fedora 7 Test 2 features a 2.6.21rc1 based kernel. Current release
information is being tracked on the kernel release notes source page.
(http://fedoraproject.org/wiki/Docs/Beats/Kernel)
| Kernel Flavors
|
| Fedora 7 test2 includes the following kernel builds:
|
| * kernel-PAE, for use in 32-bit x86 systems with > 4GB of RAM, or with CPUs
| that have a 'NX (No eXecute)' feature. This kernel support both uniprocessor
| and multi-processor systems.
| * Virtualization kernel for use with the Xen emulator package. Configured
| sources are available in the kernel-xen-devel-<version>.<arch>.rpm package.
Afaik the xen kernel also enables PAE / NX, can anybody confirm this? And
unless it gets fixed before the final F7 release, imho it should also be
stressed that software suspend does not work with PAE / NX:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215396
Regards,
Till
2:01 p.m.
New subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img
Jesse Keating said the following on 03/01/2007 08:12 AM Pacific Time:
This test release has an rpm ordering issue that seems to affect some
people
with regard to mkinitrd being installed correctly. If your install seems to
stall at installing the kernel and never continues, please try the updates
image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to
http://fedoraproject.org/wiki/Anaconda/Updates for more information on using
updates images.
What are correct steps to view or access exactly what is in the updates-f7t2.img file ?
# file updates-f7t2.img
updates-f7t2.img: gzip compressed data, from Unix, last modified: Tue Feb 27 11:02:28
2007, max compression
gunzip isn't doing the trick for me.
Coming up empty on google and the last part of this pages implies that it is a simple
image that can be mounted loopback: http://fedoraproject.org/wiki/Anaconda/Updates
Thanks,
John
2:40 p.m.
New subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img
On Fri, 2007-03-09 at 12:01 -0800, John Poelstra wrote:
Jesse Keating said the following on 03/01/2007 08:12 AM Pacific
Time:
> This test release has an rpm ordering issue that seems to affect some people
> with regard to mkinitrd being installed correctly. If your install seems to
> stall at installing the kernel and never continues, please try the updates
> image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to
> http://fedoraproject.org/wiki/Anaconda/Updates for more information on using
> updates images.
What are correct steps to view or access exactly what is in the updates-f7t2.img file ?
# file updates-f7t2.img
updates-f7t2.img: gzip compressed data, from Unix, last modified: Tue Feb 27 11:02:28
2007, max compression
gunzip isn't doing the trick for me.
Coming up empty on google and the last part of this pages implies that it is a simple
image that can be mounted loopback: http://fedoraproject.org/wiki/Anaconda/Updates
Hmm,
$ gunzip -c updates-f7t2.img | file -
/dev/stdin: ASCII cpio archive (SVR4 with CRC)
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project: http://fedoraproject.org/wiki/PaulWFrields
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
11:52 a.m.
New subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img
On Fri, 2007-03-09 at 15:40 -0500, Paul W. Frields wrote:
On Fri, 2007-03-09 at 12:01 -0800, John Poelstra wrote:
> Jesse Keating said the following on 03/01/2007 08:12 AM Pacific Time:
> > This test release has an rpm ordering issue that seems to affect some people
> > with regard to mkinitrd being installed correctly. If your install seems to
> > stall at installing the kernel and never continues, please try the updates
> > image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to
> > http://fedoraproject.org/wiki/Anaconda/Updates for more information on using
> > updates images.
>
> What are correct steps to view or access exactly what is in the updates-f7t2.img
file ?
>
> # file updates-f7t2.img
> updates-f7t2.img: gzip compressed data, from Unix, last modified: Tue Feb 27
11:02:28 2007, max compression
>
> gunzip isn't doing the trick for me.
>
> Coming up empty on google and the last part of this pages implies that it is a
simple image that can be mounted loopback: http://fedoraproject.org/wiki/Anaconda/Updates
Hmm,
$ gunzip -c updates-f7t2.img | file -
/dev/stdin: ASCII cpio archive (SVR4 with CRC)
Yep -- an updates.img can now be a gzipped cpio ball now (handy for
creating/looking at without needing root).
Just 'zcat updates.img |cpio -id' and you should be good
Jeremy
12:38 p.m.
New subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img
Jeremy Katz said the following on 03/19/2007 09:52 AM Pacific Time:
> $ gunzip -c updates-f7t2.img | file -
> /dev/stdin: ASCII cpio archive (SVR4 with CRC)
Yep -- an updates.img can now be a gzipped cpio ball now (handy for
creating/looking at without needing root).
Just 'zcat updates.img |cpio -id' and you should be good
Jeremy
Thanks!
I updated: http://fedoraproject.org/wiki/Anaconda/Updates
6260
days inactive
6278
days old
33 comments
21 participants
participants (21)
-
Adam Jackson -
Bill Nottingham -
Callum Lerwick -
Camilo Mesias -
Christopher Blizzard -
Chuck Anderson -
Davide Bolcioni -
Dennis Gilmore -
Dmitry Butskoy -
Frank Ch. Eigler -
Hans de Goede -
Jeremy Katz -
Jesse Keating -
John Poelstra -
Kłoczko Tomasz -
Mike A. Harris -
Nathan Hruby -
Nicolas Mailhot -
Paul Howarth -
Paul W. Frields -
Till Maas