[kde-linux] K3B won't burn right?
derrick_s at tesco.net
Sat Sep 20 13:34:07 UTC 2008
On Saturday 20 September 2008 01:32, Emanoil Kotsev wrote:
> you won't believe but this thread helped me find something I've
> been missing all the time for may be about an year now. I am
> booting from usb disk at home so when I start k3b it always
> complain dma is not enabled for the cdrom device that's in the
> notebook. I have compiled custom kernel and disabled most of the
> drivers or compiled them as modules. I enabled some generic ide
> drivers and compiled them in the kernel, so at once the SATA drive
> showed up as hda and the cd/dvd as hdc. I don't mind because I
> never had to use the hard drive really at home because there is
> some buziness data and I have external dvd burner. Anyway the
> discussion brought me to the idea to check dma on those drives and
> it was not enabled on both. I new this for the dvd burner and was
> wondering how to change it. I even played once with hdparm with no
> effect, but never touched the hard disk. It seems it was captured
> by those ide_generic drivers and did not load the sata.
> I've recompiled the kernel and now read buffer speed is gone from 6
> to 128MB/s :-D
That is interesting in so much that its a remarkable improvement in
performance ! Certainly worth the trouble
> Thanks for the explanations in your mails it helped a lot, because
> now I can really use the burner in my notebook.
> here few comments
> --- On Sat, 9/13/08, kde-linux-request at kde.org
<kde-linux-request at kde.org> wrote:
> > As a side issue a DVD will not verify unless the
> > "Eject after burn" is
> It's not DVD related same happens with CDs too
> > turned off on that machine either. I originally ignored
> > verifying failures thinking that it had something to do with the
> > machine being all SCSI. I've never had a bad burn on that machine
> > either ! Having
> Its not machine or SCSI related. I would bet chipset or chipset
> > said that I've not had a bad burn on this one yet.
> I think its some underlaying system issue that reports to k3b wrong
> track, or may be k3b interprets it the wrong way.
> > Aha!, that happened to me on the notebook... the problem is
> > simple: the hardware is able to eject, but there is no motor to
> > reload
> > :)
Its probable that because laptops/notebooks were not mainstream at the
time the original code was written, that no account of this inability
to pull back the tray was taken.
> Earlier after eject on the notebook I did push the tray back and
> k3b would start verifying automatically, as David said.
> After an upgrade I've experienced this error, so then David (see
> below) came to the conclusion that it is the re-eject that causes
> the trouble. I even think the problem started when I changed my
> It would be great if we could find the issue.
Yes it would ! But I suspect that most people live with the problems
hoping that it will be fixed next time around.
> > Mine was the same way. But when I would push the drive tray
> > back in (as instructed) it would proceed indicating that it was
> > verifying, but there would be no drive activity, no timeout,
> > nothing. Once (in a log somewhere) I noticed that while it had
> > *burned* track 0, it was trying to *verify* track 1. I think that
> > had or has something to do with it, but cannot prove that.
In programming terms this could just be an "off by one" error ! Where
instead of starting counting from zero, it starts at one !
> OK, so we can gather information somewhere which models and
> chipsets are affected. What do you think. May be put it in a wiki
> somewhere. Than find (or not) a pattern. This would be a prove and
> as no one takes care of the bug, I think it's worth doing it.
> What do you think?
I'm all for documenting the bugs and logging the affected hardware in
some place that is accessible to both the developers and users. What
do you suggest ?
More information about the kde-linux