Re: DVD burning still have problems

[Alessandro Suardi]

On Mon, 24 Jan 2005 21:44:06 +0000, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> On Llu, 2005-01-24 at 20:45, Jens Axboe wrote:
> > > I've got several reports like this that only happen with ACPI, and one
> > > user whose burns report fine but are corrupted if ACPI is allowed to do
> > > power manglement.
> >
> > Really weird, I cannot begin to explain that. Perhaps the two reporters
> > in this thread can try it as well?
> 
> I can sort of guess - the CPU frequency changes (either from ACPI or
> perhaps also from cpuspeed if in use ?) involve the CPU disconnecting
> from the bus and reconnecting. There is much magic involved in this and
> there are certainly chipset and CPU errata in this area.

Well, booted into 2.6.11-rc2-bk2 (ACPI config'd out) and my
 first growisofs session decided to die at 60% with the usual EIO :/

The fun thing is that retrying now shows growisofs calling a
 HUGE amount of these babies...

[root@donkey tmpburn]# strace -p 2337
...
ioctl(5, SG_IO, 0xbffff7d8)             = 0
ioctl(5, SG_IO, 0xbffff7d8)             = 0
ioctl(5, SG_IO <unfinished ...>
Process 2337 detached
[root@donkey tmpburn]# strace -c -p 2337
Process 2337 attached - interrupt to quit
Process 2337 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    7.762805         239     32445           ioctl
------ ----------- ----------- --------- --------- ----------------
100.00    7.762805                 32445           total

 while sitting in its initial prompt:

[root@donkey tmpburn]# growisofs -Z /dev/hdc=myfile.iso
WARNING: /dev/hdc already carries isofs!
About to execute 'builtin_dd if=myfile.iso of=/dev/hdc obs=32k seek=0'
Sleeping for 0 sec...

It looks like every kernel has its own :(

--alessandro
 
 "And every dream, every, is just a dream after all"
  
    (Heather Nova, "Paper Cup")
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/