With my px-716a, latest version of Nero and Gentoo with the 2.6.13 kernel the buffer keeps going up and down and the burning pauses (to wait for the buffer to fill up) very often. With gentoo-sources 2.6.12-r9 I don’t have the this problem. The buffer fluxuations is also present with the vanilla-sources-2.6.13.
Burning CD or DVD, and at what burning speed? What processor? ATM I only have 2.6.13 on my laptop which has only a CD-writer, so if it happens with DVD I’ll have to get 2.6.13 to my desktop to test.
Hum… maybe it comes (once again) from a DMA alignment change in the ide-cdrom driver. Have you checked on both side (2.6.12 and 2.6.13) that DMA is correctly enabled on your devices ? (you can check this running hdparm -d /dev/XXX)
I’m burning dvd’s both data and from iso’s. My processor is an Amd athlon 64 4000+. I’m burning Verbatim 16x DVD+R at max (16x).
hdparm /dev/hda reports (hda is px716a)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
HDIO_GETGEO failed: Invalid argument
I get exact the same message with 2.6.12.
Sorry, took me a while… had to compile the kernel and change my system to udev.
I can confirm this (bug?). Here (800MHz) while writing a DVD-RW it ran right the way down to 0%, then filled itself up again. On the one hand I think it’s probably working … as it never left 100% here before, but on the other hand 0%? Actually it did it twice while burning a 1.4GB file at 4x.
hdparm shows: using_dma = 1 (on)
Okay. Will have a look at it as soon as I have time. Hummm stupid stuff, can you revert drivers/ide/ide-cd.c and drivers/ide/ide.h to version 2.6.12 and check if it is still compilable and if it works better ?
I’ll try that. I will also check if K3B has the same problems when I get back home.
Axllent What burner/brand are you using?
I presume you mean drivers/ide/ide.c
There are no differences at all between both ide.c and ide-cd.h betwen those 2 versions:
gentoo_test src # diff -u linux-2.6.12/drivers/ide/ide-cd.h linux-2.6.13/drivers/ide/ide-cd.h gentoo_test src # gentoo_test src # diff -u linux-2.6.12/drivers/ide/ide.c linux-2.6.13/drivers/ide/ide.c gentoo_test src #
Any other ideas?
Hum no. Actually I wanted to say /drivers/ide/ide-cd.c and ide-cd.h. These are the source files for IDE devices. According to kernel.org, ide-cd.c has changed. If the header file is the same, then it should compile without a problem.
I can confirm a difference between these 2 *.c files, however I have just tested this at home on 2.6.13 with the ide-cd.c file from 2.6.12 (which compiles fine btw) and there is no change. The buffer still runs right down to 0% during burning.
Ok… we are currently working on this issue. One point that is, we was able to reproduce the problem with a brand new 126.96.36.199 out of kernel.org. The let’s say “bug” was occuring whatever the interface was. So I suspect something deeper in the kernel
Thanks for the feedback. I confirmed this yesterday too on 188.8.131.52
Have you checked with 184.108.40.206 or with another one ? The last ‘stable’ kernel I have on my machine is 220.127.116.11 so it’s a little bit old
I did have iirc a 2.6.12.x … which worked quite fine, however I’m at work and can’t check which “x” that was as I’m at work I can/will repost when I get home though.
From what I noticed it came with 2.6.13, but then again I don’t normally try every 2.6.x.x version, and it may have been introduced in one of the last 2.6.12.x versions.
Sorry, my bad… 18.104.22.168 was my previous kernel on the machine with a decent burner. On my laptop I had 2.6.12 , but no subversion. If you need me to test a specific 2.6.12.x version just drop a note
No problem, I have compiled a 22.214.171.124 and a 2.6.13. The problem is only in 2.6.13, so I am downgrading step by step to identify the faulty file
Ok got some good news for you… The problem seems to be related to the new timer i/o options. Which freq did you choose when you compile your kernel ?
For me, with 250 Hz, I can reproduce the bug (finally found )
Yepeeah ! Setting the ‘Timer frequency’ in ‘Processor type and features’ to 1000 Hz in the kernel configuration file seems to solve our problem.
Mathf, I salute you
That solved the problem 100%. Now is this a nero “bug” (due to a new feature in the kernel), or a kernel issue?