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

[Emanoil Kotsev]

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

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
> :)

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.

> 
> 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.

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