| 2008-08-30 02:21:37 |
Daniel Hollocher |
bug |
|
|
added bug |
| 2008-09-02 15:09:28 |
Pedro Villavicencio |
brasero: status |
New |
Invalid |
|
| 2008-09-02 15:09:28 |
Pedro Villavicencio |
brasero: statusexplanation |
|
alright thanks you , closing the bug then. |
|
| 2008-10-01 23:44:27 |
Daniel Hollocher |
brasero: status |
Invalid |
New |
|
| 2008-10-01 23:44:27 |
Daniel Hollocher |
brasero: statusexplanation |
alright thanks you , closing the bug then. |
reopening this bug, because I figured out whats going on. Brasero uses /tmp for its scratch work space, whatever, whereas RAM should be used. This is a bug. I don't understand why brasero uses /tmp.
I'm going to redo the summary to reflect my findings. |
|
| 2008-10-01 23:58:15 |
Daniel Hollocher |
description |
I am having lots of trouble burning a cd image. The default tool makes my computer INCREDIBLY laggy. It always lags, and watching the memory, it looks like it has NO method of caching at all. I figured the lag stems from IO wait stemming from dispersed harddrive requests.
This was past experience.
I tried it again to see if it was still happening that way, and it was, so I canceled and rebooted.
After that I opened up Brasero. Brasero I think inadvertently caches because it does a scan of the image before starting again. Thats a little better, and works fine for me, since I have 2g of ram, which is of course plenty to cache a cd image.
At some point, I selected to just run a simulation. I started it. I lost my mouse. At the time, I thought that my system was just grinding to a halt, since, it was grinding to a halt. Later, I realized that my keyboard was responding to certain keystrokes, and magically, an alt-tab brought everything back to life. I could click again!
(Note, I said my keyboard was only responding to certain keystrokes. Here is what happened. I happened to have a terminal open. I learned that I could type in it. I have a shortcut key that can open gnome-terminals, but that wasn't working. anyway)
After the simulation, Brasero decides to burn the cd automatically, giving me 10 seconds to cancel. This frustrated me, since I hadn't recovered my mouse at the time.
After it finishes recording, it ejects the cd, and then declares that is going to run a checksum on the cd. Except, it never pulls the cd back in. Great... I push it back in.
Now, at the time of this writing, it is stuck at %93 of the checksum process. (annd... I'm hitting cancel)
This is all to burn intrepid alpha 4, so I will check that out, and see if I get better results. But, on hardy, this is very buggy. |
Brasero uses /tmp for its temporary work space. /tmp is just a directory on the harddrive, its not RAM. Thus, when brasero tries to do a bunch of work, it ends up swapping to the harddrive, even though you have plenty of ram.
The work around is to go into properties, and use any tmpfs mount point, which uses the RAM, like /dev/shm
I guess /tmp is for temporary files that you aren't doing allot of I/O on. Anyway, I don't really know whats going on. I don't know why brasero is using files in the first place. I switched, and saw no noticeable increase in my ram usage, so its not like brasero needs a large working space. I don't understand why brasero isn't just allocating the memory it needs, like every other program does. |
|
| 2008-10-01 23:58:15 |
Daniel Hollocher |
title |
cd burning causes severe unresponsiveness, and other foul smells |
brasero hashes the harddrive, causing slowdowns |
|
| 2008-10-10 16:40:20 |
Pedro Villavicencio |
brasero: status |
New |
Incomplete |
|
| 2008-10-10 16:40:20 |
Pedro Villavicencio |
brasero: assignee |
|
desktop-bugs |
|
| 2008-10-10 16:40:20 |
Pedro Villavicencio |
brasero: importance |
Undecided |
Low |
|
| 2008-10-10 16:40:20 |
Pedro Villavicencio |
brasero: statusexplanation |
reopening this bug, because I figured out whats going on. Brasero uses /tmp for its scratch work space, whatever, whereas RAM should be used. This is a bug. I don't understand why brasero uses /tmp.
I'm going to redo the summary to reflect my findings. |
feel free to forward it upstream then to bugzilla.gnome.org ; leaving this as incomplete until that, thanks. |
|
| 2008-11-03 18:06:43 |
Pedro Villavicencio |
brasero: status |
Incomplete |
Invalid |
|
| 2008-11-03 18:06:43 |
Pedro Villavicencio |
brasero: statusexplanation |
feel free to forward it upstream then to bugzilla.gnome.org ; leaving this as incomplete until that, thanks. |
|
|
| 2009-11-30 23:54:27 |
Daniel Hollocher |
bug task added |
|
linux |
|
| 2009-11-30 23:55:15 |
Daniel Hollocher |
summary |
brasero hashes the harddrive, causing slowdowns |
cd burning io locks the cpu |
|
| 2009-12-01 00:09:28 |
Daniel Hollocher |
description |
Brasero uses /tmp for its temporary work space. /tmp is just a directory on the harddrive, its not RAM. Thus, when brasero tries to do a bunch of work, it ends up swapping to the harddrive, even though you have plenty of ram.
The work around is to go into properties, and use any tmpfs mount point, which uses the RAM, like /dev/shm
I guess /tmp is for temporary files that you aren't doing allot of I/O on. Anyway, I don't really know whats going on. I don't know why brasero is using files in the first place. I switched, and saw no noticeable increase in my ram usage, so its not like brasero needs a large working space. I don't understand why brasero isn't just allocating the memory it needs, like every other program does. |
I reported this bug thinking that it was an issue with /tmp, as you can see below. But since then, I have tested much more, and the issue "feels" like DMA is turned off.
I recently tested burning on Windows, and I realized that I had forgotten how fast a computer I have. On windows, I can burn the cd without any slow downs; I can even defrag my harddrive without a hiccup.
The cd that I burn is a rw, and it burns quote slow, only 4x. But, on linux, that is enough to drag to a stand still, and the system monitor reports the cpu burning away in io wait.
I have tested with brasero of course, but also allot with k3b, on several clean installs including a 64bit.
I have a P5B motherboard: http://asus.com/product.aspx?P_ID=YwIVDOTcvIMHZdTy
My cd rom and HDD are both hooked into the IDE cable, which I believe is the jmicron controller. (the mobo is geared toward SATA, but I built this as an upgrade from a computer geared towards PATA, and just used the HDD and CD from that)
--old--
Brasero uses /tmp for its temporary work space. /tmp is just a directory on the harddrive, its not RAM. Thus, when brasero tries to do a bunch of work, it ends up swapping to the harddrive, even though you have plenty of ram.
The work around is to go into properties, and use any tmpfs mount point, which uses the RAM, like /dev/shm
I guess /tmp is for temporary files that you aren't doing allot of I/O on. Anyway, I don't really know whats going on. I don't know why brasero is using files in the first place. I switched, and saw no noticeable increase in my ram usage, so its not like brasero needs a large working space. I don't understand why brasero isn't just allocating the memory it needs, like every other program does.
|
|
| 2009-12-01 22:41:01 |
Daniel Hollocher |
attachment added |
|
AlsaDevices.txt http://launchpadlibrarian.net/36313166/AlsaDevices.txt |
|
| 2009-12-01 22:41:04 |
Daniel Hollocher |
attachment added |
|
AplayDevices.txt http://launchpadlibrarian.net/36313168/AplayDevices.txt |
|
| 2009-12-01 22:41:07 |
Daniel Hollocher |
attachment added |
|
ArecordDevices.txt http://launchpadlibrarian.net/36313172/ArecordDevices.txt |
|
| 2009-12-01 22:41:10 |
Daniel Hollocher |
attachment added |
|
BootDmesg.txt http://launchpadlibrarian.net/36313174/BootDmesg.txt |
|
| 2009-12-01 22:41:13 |
Daniel Hollocher |
attachment added |
|
Card0.Amixer.values.txt http://launchpadlibrarian.net/36313177/Card0.Amixer.values.txt |
|
| 2009-12-01 22:41:17 |
Daniel Hollocher |
attachment added |
|
Card0.Codecs.codec.0.txt http://launchpadlibrarian.net/36313178/Card0.Codecs.codec.0.txt |
|
| 2009-12-01 22:41:20 |
Daniel Hollocher |
attachment added |
|
CurrentDmesg.txt http://launchpadlibrarian.net/36313180/CurrentDmesg.txt |
|
| 2009-12-01 22:41:23 |
Daniel Hollocher |
attachment added |
|
IwConfig.txt http://launchpadlibrarian.net/36313181/IwConfig.txt |
|
| 2009-12-01 22:41:26 |
Daniel Hollocher |
attachment added |
|
Lspci.txt http://launchpadlibrarian.net/36313182/Lspci.txt |
|
| 2009-12-01 22:41:32 |
Daniel Hollocher |
attachment added |
|
Lsusb.txt http://launchpadlibrarian.net/36313184/Lsusb.txt |
|
| 2009-12-01 22:41:34 |
Daniel Hollocher |
attachment added |
|
PciMultimedia.txt http://launchpadlibrarian.net/36313185/PciMultimedia.txt |
|
| 2009-12-01 22:41:37 |
Daniel Hollocher |
attachment added |
|
ProcCpuinfo.txt http://launchpadlibrarian.net/36313186/ProcCpuinfo.txt |
|
| 2009-12-01 22:41:39 |
Daniel Hollocher |
attachment added |
|
ProcInterrupts.txt http://launchpadlibrarian.net/36313187/ProcInterrupts.txt |
|
| 2009-12-01 22:41:40 |
Daniel Hollocher |
attachment added |
|
ProcModules.txt http://launchpadlibrarian.net/36313188/ProcModules.txt |
|
| 2009-12-01 22:41:45 |
Daniel Hollocher |
attachment added |
|
UdevDb.txt http://launchpadlibrarian.net/36313189/UdevDb.txt |
|
| 2009-12-01 22:41:49 |
Daniel Hollocher |
attachment added |
|
UdevLog.txt http://launchpadlibrarian.net/36313190/UdevLog.txt |
|
| 2009-12-01 22:42:12 |
Daniel Hollocher |
attachment added |
|
WifiSyslog.txt http://launchpadlibrarian.net/36313211/WifiSyslog.txt |
|
| 2009-12-01 22:42:17 |
Daniel Hollocher |
tags |
|
apport-collected |
|
| 2010-05-14 01:22:15 |
Daniel Hollocher |
description |
I reported this bug thinking that it was an issue with /tmp, as you can see below. But since then, I have tested much more, and the issue "feels" like DMA is turned off.
I recently tested burning on Windows, and I realized that I had forgotten how fast a computer I have. On windows, I can burn the cd without any slow downs; I can even defrag my harddrive without a hiccup.
The cd that I burn is a rw, and it burns quote slow, only 4x. But, on linux, that is enough to drag to a stand still, and the system monitor reports the cpu burning away in io wait.
I have tested with brasero of course, but also allot with k3b, on several clean installs including a 64bit.
I have a P5B motherboard: http://asus.com/product.aspx?P_ID=YwIVDOTcvIMHZdTy
My cd rom and HDD are both hooked into the IDE cable, which I believe is the jmicron controller. (the mobo is geared toward SATA, but I built this as an upgrade from a computer geared towards PATA, and just used the HDD and CD from that)
--old--
Brasero uses /tmp for its temporary work space. /tmp is just a directory on the harddrive, its not RAM. Thus, when brasero tries to do a bunch of work, it ends up swapping to the harddrive, even though you have plenty of ram.
The work around is to go into properties, and use any tmpfs mount point, which uses the RAM, like /dev/shm
I guess /tmp is for temporary files that you aren't doing allot of I/O on. Anyway, I don't really know whats going on. I don't know why brasero is using files in the first place. I switched, and saw no noticeable increase in my ram usage, so its not like brasero needs a large working space. I don't understand why brasero isn't just allocating the memory it needs, like every other program does.
|
This happens when you have both your burner and your HDD connected to the same IDE cable. It can also happen in some notebooks. Here is the fix:
In K3b:
Settings > Configure K3b... > Programs > User Parameters
Click near cdrecord, and add the option -immed.
You may need to ensure that cdrecord is selected by:
Settings > Configure K3b... > Advanced > Show advanced GUI elements
During the burning setup, you will have an option to select cdrecord.
|
|
| 2010-05-14 01:22:33 |
Daniel Hollocher |
bug watch added |
|
http://bugzilla.kernel.org/show_bug.cgi?id=15884 |
|
| 2010-05-14 01:22:33 |
Daniel Hollocher |
linux: importance |
Undecided |
Unknown |
|
| 2010-05-14 01:22:33 |
Daniel Hollocher |
linux: status |
New |
Unknown |
|
| 2010-05-14 01:22:33 |
Daniel Hollocher |
linux: remote watch |
|
Linux Kernel Bug Tracker #15884 |
|
| 2011-01-24 08:23:04 |
Bug Watch Updater |
linux: status |
Unknown |
Invalid |
|
| 2011-02-03 13:55:13 |
Bug Watch Updater |
linux: importance |
Unknown |
Medium |
|
