[kde-linux] K3B won't burn right?

[Gaffer.]

Hi Emanoil,

On Saturday 20 September 2008 01:32, Emanoil Kotsev wrote:
> Hello
> 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
> code
>
> > 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
> notebook.
>
> 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?
>
> regards

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 ?


-- 
Best Regards:
             Derrick.