I really should have coffeee before replying...<br>Its not ACPI that i disabled but I changed AHCI to ATA in SATA operations in Bios, Just gave it another shot, DMA is enabled and again dmesg shows Bufeer I/O errors and writing an iso to dvd started well at 4x but a few hundred mb into the burn the speed dropped to 0.4x to 1.5x and the device buffer continually emptied while the softwarebuffer stayed at >95%<br>
With AHCI mode no burning at all to cd and dvd at 0.3x sometimes but mostly it fails right away.<br>$ ps -ef | grep udev gives me:<br>root 1224 1 0 13:16 ? 00:00:00 /sbin/udevd --daemon<br>root 3329 1224 0 13:16 ? 00:00:00 /sbin/udevd --daemon<br>
root 3335 1224 0 13:16 ? 00:00:00 /sbin/udevd --daemon<br>sascha 4218 3661 0 13:24 pts/1 00:00:00 grep --color=tty -d skip udev<br>Thanks again<br>Sascha<br>PS<br>what time zone are you in? Pacific here. <br>
<br><div class="gmail_quote">On Sat, Jan 30, 2010 at 12:51 PM, Thomas Schmitt <span dir="ltr"><<a href="mailto:scdbackup@gmx.net">scdbackup@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
> RIP, cant get cdrecord to work, it will not accept my dev=/dev/sr0 or<br>
> dev=scsi:1,0,0 but i did get dmesg errors when inserting disk<br>
<br>
</div>There are my cdrskin (same options as wodim and<br>
cdrecord) and my xorriso (cdrecord emulation<br>
available by xorriso -as cdrecord ...options..).<br>
But well, if dmesg reports read error then they<br>
don't have more chance to succeed than wodim<br>
on the multi-user system.<br>
(I expect one can disable ACPI by some GRUB<br>
boot option, though.)<br>
<div class="im"><br>
<br>
> then rebooted with ACPI changed to ATA.<br>
</div><div class="im">> BUT burning worked altough at low speeds 1x - 3x for DVD.<br>
<br>
</div>Is that with DMA disabled ?<br>
Else there would still be some disturbance.<br>
<br>
(It is cursed, isn't it ?)<br>
<div class="im"><br>
<br>
> Now I am confused.... Why did it work for a few burns under ARCH<br>
> before failing again? If it is another process accessing the drive<br>
> how do i figure out wich?<br>
<br>
</div>If really ACPI alone is to blame then i<br>
understand it is the kernel which runs the<br>
offending code.<br>
(My knowledge about ACPI is strictly wikipedia.<br>
So better don't quote me with that.)<br>
<br>
Normally ACPI does not cause constant drive<br>
molestation. I conclude from the DVD symptoms<br>
that it is polling with high frequency.<br>
There must be some cause for this.<br>
Maybe this cause was not given with the<br>
successful tries.<br>
<br>
Did you see the udev related report of Age Jan<br>
Kuperus ?<br>
What do you get from<br>
ps -ef | grep udev<br>
<br>
I see only<br>
root 1000 1 0 2009 ? 00:00:03 /sbin/udevd --daemon<br>
<br>
(Sorry, i have no idea how to disable udev and<br>
get along with good old mknod device nodes.)<br>
<br>
<br>
As soon as you are sure that ACPI is the decisive<br>
trigger, that soon you should report this to the<br>
distro which you use.<br>
I doubt we find anybody here who can explain ACPI<br>
and kernel and all.<br>
We need experts now.<br>
<div><div></div><div class="h5"><br>
<br>
Have a nice day :)<br>
<br>
Thomas<br>
<br>
<br>
_______________________________________________<br>
Debburn-devel mailing list<br>
<a href="mailto:Debburn-devel@lists.alioth.debian.org">Debburn-devel@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/debburn-devel" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/debburn-devel</a><br>
</div></div></blockquote></div><br>