hello, i followed the last thread, "unable to burn DVD", and there was a
patch, which was said to work, but it does not.. (i am running
2.6.11-rc1-bk9)..
the problem started around 2.6.9 (or something like it), when i was only
able to burn 1 dvd, then i had to restart before i could burn another
(or every second dvd i burn would fail), the error i get is input/output
error.. my burner is working perfect, since it works on windows, and on
2.6.9-rcSomething.
it is not a specific place in the burning process it fails, sometimes at
10%, and sometimes at 97%
burning normal cd's works perfectly
now on 2.6.10 and 2.6.11-later i cant burn dvd's at all, every time i
try to burn one, it fails, i have tried different speeds and media, same
thing, i got a Liteon sohw1213S dvd duallayer burner, allthough im not
using duallayer media.
here is a log from a burning i just tried:
/dev/hda: engaging DVD-R DAO upon user request...
/dev/hda: reserving 2149200 blocks
/dev/hda: "Current Write Speed" is 4.1x1385KBps.
0.02% done, estimate finish Tue Jan 25 13:20:53 2005
0.05% done, estimate finish Mon Jan 24 15:13:15 2005
<snip>
83.66% done, estimate finish Sun Jan 23 16:50:47 2005
83.68% done, estimate finish Sun Jan 23 16:50:47 2005
83.71% done, estimate finish Sun Jan 23 16:50:46 2005
:-[ WRITE@LBA=1b7460h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output
error
:-( write failed: Input/output error
/dev/hda: flushing cache
this is simply what happens :(
i have tried with and without pktcdvd loaded, same result, i hope
someone can help me
thanks
On Sun, 23 Jan 2005 17:06:54 +0100, Kasper Sandberg <[email protected]> wrote:
> hello, i followed the last thread, "unable to burn DVD", and there was a
> patch, which was said to work, but it does not.. (i am running
> 2.6.11-rc1-bk9)..
>
> the problem started around 2.6.9 (or something like it), when i was only
> able to burn 1 dvd, then i had to restart before i could burn another
> (or every second dvd i burn would fail), the error i get is input/output
> error.. my burner is working perfect, since it works on windows, and on
> 2.6.9-rcSomething.
>
> it is not a specific place in the burning process it fails, sometimes at
> 10%, and sometimes at 97%
>
> burning normal cd's works perfectly
>
> now on 2.6.10 and 2.6.11-later i cant burn dvd's at all, every time i
> try to burn one, it fails, i have tried different speeds and media, same
> thing, i got a Liteon sohw1213S dvd duallayer burner, allthough im not
> using duallayer media.
>
> here is a log from a burning i just tried:
> /dev/hda: engaging DVD-R DAO upon user request...
> /dev/hda: reserving 2149200 blocks
> /dev/hda: "Current Write Speed" is 4.1x1385KBps.
> 0.02% done, estimate finish Tue Jan 25 13:20:53 2005
> 0.05% done, estimate finish Mon Jan 24 15:13:15 2005
> <snip>
> 83.66% done, estimate finish Sun Jan 23 16:50:47 2005
> 83.68% done, estimate finish Sun Jan 23 16:50:47 2005
> 83.71% done, estimate finish Sun Jan 23 16:50:46 2005
> :-[ WRITE@LBA=1b7460h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output
> error
> :-( write failed: Input/output error
> /dev/hda: flushing cache
>
> this is simply what happens :(
> i have tried with and without pktcdvd loaded, same result, i hope
> someone can help me
FWIW, I happen to experience the same with the latest
FC3 kernel on my Samsung TS-H552 burner; that is,
1. CD burning works 100% of the time
2. DVD burning may fail with EIO (nothing in kernel logs)
3. retrying burning usually works
Yes, I resorted to only use DVD+RW media now since the
ratio of coasters has made +R more expensive than +RW :(
Last night I had to insist quite a lot with my burner's eject
button before it decided to open and let the disc out (this
particular session after failing once at 61% with EIO would
reliably fail at the initial write). After reloading the tray
with the same disc, I successfully burned it.
NB - this happens with Memorex and Verbatim media,
not with el-cheapo discs.
I'm available for eventually testing of the 2.6.11-xx kernels
from kernel.org (another side-effect of moving from RH9
plus kernel.org kernels to FC3 and its own kernel is that I
no longer have a dead machine after the updatedb run,
which would happen about twice a month on my 256MB
RAM k7-800).
--alessandro
"And every dream, every, is just a dream after all"
(Heather Nova, "Paper Cup")
Hi,
have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
is?
I had some probs, solved with a simple chmod +s growisofs :)
Gl?ck Auf
Volker
On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
<[email protected]> wrote:
> Hi,
>
> have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
> is?
>
> I had some probs, solved with a simple chmod +s growisofs :)
Lucky you. Burning as root here, cdrecord not suid. Tried also
burning with a +s growisofs, but...
794034176/4572807168 (17.4%) @2.4x, remaining 18:47
805339136/4572807168 (17.6%) @2.4x, remaining 18:42
:-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
builtin_dd: 396976*2KB out @ average 2.4x1385KBps
:-( write failed: Input/output error
/dev/hdc: flushing cache
/dev/hdc: stopping de-icing
/dev/hdc: writing lead-out
> Gl?ck Auf
> Volker
--alessandro
"And every dream, every, is just a dream after all"
(Heather Nova, "Paper Cup")
On Monday 24 Jan 2005 06:59, Alessandro Suardi wrote:
> On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
>
> <[email protected]> wrote:
> > Hi,
> >
> > have you checked, that cdrecord is not suid root, and
> > growisofs/dvd+rw-tools is?
> >
> > I had some probs, solved with a simple chmod +s growisofs :)
>
> Lucky you. Burning as root here, cdrecord not suid. Tried also
> burning with a +s growisofs, but...
You can test if it's the kernel/growisofs clashing by hacking the
drivers/block/scsi_ioctl.c code
It's around line 193 in 2.6.9, and line 196 in 2.6.10
not sure about 2.6.11
find the code:
/* Write-safe commands just require a writable open.. */
if (type & CMD_WRITE_SAFE) {
if (file->f_mode & FMODE_WRITE)
return 0;
}
edit it to something like:
/* Write-safe commands just require a writable open.. */
if (type & CMD_WRITE_SAFE) {
printk ("Write safe command in ");
if (file->f_mode & FMODE_WRITE)
printk ("write mode.\n");
else
printk ("read mode.\n");
return 0;
}
Compile the kernel with that and that may make it work and burn dvd and let
you know if it's growisofs sending incorrect commands. You'll get messages in
dmesg like
Write safe command in read mode.
which means growisofs is still not right. Maybe later version fixed this?
tim
--
---------------------------------------------------------
Tim & Therese Fairchild
Atchafalaya Border Collies.
Kuttabul, Queensland, Australia.
---------------------------------------------------------
Email mailto:[email protected]
Homepage http://www.bcs4me.com
Photos http://www.pbase.com/amosf
---------------------------------------------------------
On Sun, Jan 23 2005, Alessandro Suardi wrote:
> On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> <[email protected]> wrote:
> > Hi,
> >
> > have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
> > is?
> >
> > I had some probs, solved with a simple chmod +s growisofs :)
>
> Lucky you. Burning as root here, cdrecord not suid. Tried also
> burning with a +s growisofs, but...
>
> 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> :-( write failed: Input/output error
As with the original report, the drive is sending back a write error to
the issuer. Looks like bad media.
--
Jens Axboe
On Mon, 24 Jan 2005 16:07:55 +0100, Jens Axboe <[email protected]> wrote:
> On Sun, Jan 23 2005, Alessandro Suardi wrote:
> > On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> > <[email protected]> wrote:
> > > Hi,
> > >
> > > have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
> > > is?
> > >
> > > I had some probs, solved with a simple chmod +s growisofs :)
> >
> > Lucky you. Burning as root here, cdrecord not suid. Tried also
> > burning with a +s growisofs, but...
> >
> > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > :-( write failed: Input/output error
>
> As with the original report, the drive is sending back a write error to
> the issuer. Looks like bad media.
I'm definitely unconvinced about the possibility of bad media...
Retrying the burn process works, sometimes on first attempt,
sometimes after tray reload, and all checksums from original
files to the burned files are just okay. This happens with different
discs from different brands.
So far I had *one* bad disc - that would keep the light on my
DVD burner blinking forever until I hit the eject button, and
made my laptop (2.6.11-rc2-bk1) DVD player barf:
Jan 24 03:02:13 incident kernel: ATAPI device hdc:
Jan 24 03:02:13 incident kernel: Error: Not ready -- (Sense key=0x02)
Jan 24 03:02:13 incident kernel: No reference position found (media
may be upside down) -- (asc=0x06, ascq=0x00)
Jan 24 03:02:13 incident kernel: The failed "Read Cd/Dvd Capacity"
packet command was:
Jan 24 03:02:13 incident kernel: "25 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 "
Earlier FC3 kernels had another problem (that now isn't surfacing
anymore) that I described on the cdwrite list:
http://lists.debian.org/cdwrite/2004/12/msg00088.html
--alessandro
"And every dream, every, is just a dream after all"
(Heather Nova, "Paper Cup")
On Mon, Jan 24 2005, Alessandro Suardi wrote:
> On Mon, 24 Jan 2005 16:07:55 +0100, Jens Axboe <[email protected]> wrote:
> > On Sun, Jan 23 2005, Alessandro Suardi wrote:
> > > On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> > > <[email protected]> wrote:
> > > > Hi,
> > > >
> > > > have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
> > > > is?
> > > >
> > > > I had some probs, solved with a simple chmod +s growisofs :)
> > >
> > > Lucky you. Burning as root here, cdrecord not suid. Tried also
> > > burning with a +s growisofs, but...
> > >
> > > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > > :-( write failed: Input/output error
> >
> > As with the original report, the drive is sending back a write error to
> > the issuer. Looks like bad media.
>
> I'm definitely unconvinced about the possibility of bad media...
The error is quite clear, sense 0x03/0x0c/0x00 is write error with no
additional specification of what kind. It's 100% certainly a drive
generated error, and I don't see any way that software is involved
there. Sense key 0x03 is a medium error.
> Retrying the burn process works, sometimes on first attempt,
> sometimes after tray reload, and all checksums from original
> files to the burned files are just okay. This happens with different
> discs from different brands.
Could be dirty drive, perhaps it needs cleaning?
> So far I had *one* bad disc - that would keep the light on my
> DVD burner blinking forever until I hit the eject button, and
> made my laptop (2.6.11-rc2-bk1) DVD player barf:
>
> Jan 24 03:02:13 incident kernel: ATAPI device hdc:
> Jan 24 03:02:13 incident kernel: Error: Not ready -- (Sense key=0x02)
> Jan 24 03:02:13 incident kernel: No reference position found (media
> may be upside down) -- (asc=0x06, ascq=0x00)
> Jan 24 03:02:13 incident kernel: The failed "Read Cd/Dvd Capacity"
> packet command was:
> Jan 24 03:02:13 incident kernel: "25 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 "
Could also be a focus problem.
--
Jens Axboe
On Mon, 2005-01-24 at 16:07 +0100, Jens Axboe wrote:
> On Sun, Jan 23 2005, Alessandro Suardi wrote:
> > On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> > <[email protected]> wrote:
> > > Hi,
> > >
> > > have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
> > > is?
> > >
> > > I had some probs, solved with a simple chmod +s growisofs :)
> >
> > Lucky you. Burning as root here, cdrecord not suid. Tried also
> > burning with a +s growisofs, but...
> >
> > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > :-( write failed: Input/output error
>
> As with the original report, the drive is sending back a write error to
> the issuer. Looks like bad media.
when i do the following:
1: get a brand new 25pack box.
2: burn with my 2.6.11-rc1-bk9, and it fails
3: boot 2.6.9-rc1 and -rc4, and it works perfectly
i find it extremely unlikely that the dvd's (of the same pack) i try on
a newer kernel than 2.6.9-rcX just happens to be the faulty ones..
especially since other persons report aswell..
>
On Mon, 2005-01-24 at 11:46 +1000, Tim Fairchild wrote:
> On Monday 24 Jan 2005 06:59, Alessandro Suardi wrote:
> > On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> >
> > <[email protected]> wrote:
> > > Hi,
> > >
> > > have you checked, that cdrecord is not suid root, and
> > > growisofs/dvd+rw-tools is?
> > >
> > > I had some probs, solved with a simple chmod +s growisofs :)
> >
> > Lucky you. Burning as root here, cdrecord not suid. Tried also
> > burning with a +s growisofs, but...
>
> You can test if it's the kernel/growisofs clashing by hacking the
> drivers/block/scsi_ioctl.c code
>
> It's around line 193 in 2.6.9, and line 196 in 2.6.10
> not sure about 2.6.11
at line 196
>
> find the code:
>
> /* Write-safe commands just require a writable open.. */
> if (type & CMD_WRITE_SAFE) {
> if (file->f_mode & FMODE_WRITE)
> return 0;
> }
>
> edit it to something like:
>
> /* Write-safe commands just require a writable open.. */
> if (type & CMD_WRITE_SAFE) {
> printk ("Write safe command in ");
> if (file->f_mode & FMODE_WRITE)
> printk ("write mode.\n");
> else
> printk ("read mode.\n");
> return 0;
> }
>
> Compile the kernel with that and that may make it work and burn dvd and let
> you know if it's growisofs sending incorrect commands. You'll get messages in
> dmesg like
>
> Write safe command in read mode.
>
> which means growisofs is still not right. Maybe later version fixed this?
i got the latest version, and i just did this, nothing of this appeared
in dmesg, but also, i dont see what scsi_ioctl has to do with anything?
i dont use scsi emulation
>
> tim
>
>
On Mon, Jan 24 2005, Kasper Sandberg wrote:
> On Mon, 2005-01-24 at 16:07 +0100, Jens Axboe wrote:
> > On Sun, Jan 23 2005, Alessandro Suardi wrote:
> > > On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> > > <[email protected]> wrote:
> > > > Hi,
> > > >
> > > > have you checked, that cdrecord is not suid root, and growisofs/dvd+rw-tools
> > > > is?
> > > >
> > > > I had some probs, solved with a simple chmod +s growisofs :)
> > >
> > > Lucky you. Burning as root here, cdrecord not suid. Tried also
> > > burning with a +s growisofs, but...
> > >
> > > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > > :-( write failed: Input/output error
> >
> > As with the original report, the drive is sending back a write error to
> > the issuer. Looks like bad media.
> when i do the following:
> 1: get a brand new 25pack box.
> 2: burn with my 2.6.11-rc1-bk9, and it fails
> 3: boot 2.6.9-rc1 and -rc4, and it works perfectly
> i find it extremely unlikely that the dvd's (of the same pack) i try on
> a newer kernel than 2.6.9-rcX just happens to be the faulty ones..
> especially since other persons report aswell..
Perhaps some command earlier is being rejected which causes this later
hardware reported error due to some setting being different? It could be
something like that, one thing is for sure - the error generated as
displayed _is_ a media error and it _is_ being generated by the
hardware.
Someone suggested logging possibly rejected commands, I think that would
be a good idea to try.
--
Jens Axboe
On Mon, Jan 24 2005, Kasper Sandberg wrote:
> On Mon, 2005-01-24 at 11:46 +1000, Tim Fairchild wrote:
> > On Monday 24 Jan 2005 06:59, Alessandro Suardi wrote:
> > > On Sun, 23 Jan 2005 21:26:55 +0100, Volker Armin Hemmann
> > >
> > > <[email protected]> wrote:
> > > > Hi,
> > > >
> > > > have you checked, that cdrecord is not suid root, and
> > > > growisofs/dvd+rw-tools is?
> > > >
> > > > I had some probs, solved with a simple chmod +s growisofs :)
> > >
> > > Lucky you. Burning as root here, cdrecord not suid. Tried also
> > > burning with a +s growisofs, but...
> >
> > You can test if it's the kernel/growisofs clashing by hacking the
> > drivers/block/scsi_ioctl.c code
> >
> > It's around line 193 in 2.6.9, and line 196 in 2.6.10
> > not sure about 2.6.11
> at line 196
> >
> > find the code:
> >
> > /* Write-safe commands just require a writable open.. */
> > if (type & CMD_WRITE_SAFE) {
> > if (file->f_mode & FMODE_WRITE)
> > return 0;
> > }
> >
> > edit it to something like:
> >
> > /* Write-safe commands just require a writable open.. */
> > if (type & CMD_WRITE_SAFE) {
> > printk ("Write safe command in ");
> > if (file->f_mode & FMODE_WRITE)
> > printk ("write mode.\n");
> > else
> > printk ("read mode.\n");
> > return 0;
> > }
> >
> > Compile the kernel with that and that may make it work and burn dvd and let
> > you know if it's growisofs sending incorrect commands. You'll get messages in
> > dmesg like
> >
> > Write safe command in read mode.
> >
> > which means growisofs is still not right. Maybe later version fixed this?
> i got the latest version, and i just did this, nothing of this appeared
> in dmesg, but also, i dont see what scsi_ioctl has to do with anything?
> i dont use scsi emulation
it doesn't have anything to do with ide-scsi scsi emulation,
direct-to-device SG_IO uses drivers/block/scsi_ioctl.c (note the block/
directory, not scsi/).
strange that it doesn't catch anything...
--
Jens Axboe
On Llu, 2005-01-24 at 15:07, Jens Axboe wrote:
> > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > :-( write failed: Input/output error
>
> As with the original report, the drive is sending back a write error to
> the issuer. Looks like bad media.
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.
On Mon, Jan 24 2005, Alan Cox wrote:
> On Llu, 2005-01-24 at 15:07, Jens Axboe wrote:
> > > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > > :-( write failed: Input/output error
> >
> > As with the original report, the drive is sending back a write error to
> > the issuer. Looks like bad media.
>
> 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?
--
Jens Axboe
On Mon, 24 Jan 2005 21:45:29 +0100, Jens Axboe <[email protected]> wrote:
> On Mon, Jan 24 2005, Alan Cox wrote:
> > On Llu, 2005-01-24 at 15:07, Jens Axboe wrote:
> > > > 794034176/4572807168 (17.4%) @2.4x, remaining 18:47
> > > > 805339136/4572807168 (17.6%) @2.4x, remaining 18:42
> > > > :-[ WRITE@LBA=60eb0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
> > > > builtin_dd: 396976*2KB out @ average 2.4x1385KBps
> > > > :-( write failed: Input/output error
> > >
> > > As with the original report, the drive is sending back a write error to
> > > the issuer. Looks like bad media.
> >
> > 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?
>
...my K7-800 is so old that the FC3 kernel disables ACPI itself:
Linux version 2.6.10-1.737_FC3 ([email protected]) (gcc
version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 Mon Jan 10 13:50:10
EST 2005
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ec000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
255MB LOWMEM available.
On node 0 totalpages: 65520
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61424 pages, LIFO batch:14
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 AMI ) @ 0x000fa9e0
ACPI: RSDT (v001 AMIINT 0x00000010 MSFT 0x00000097) @ 0x0fff0000
ACPI: FADT (v001 AMIINT 0x00000010 MSFT 0x00000097) @ 0x0fff0030
ACPI: DSDT (v001 VIA VT8371 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: BIOS age (1997) fails cutoff (2001), acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
But as it stands I'll sacrifice my 11+ days uptime for a -latest
build from kernel.org and try compiling ACPI out :)
--alessandro
"And every dream, every, is just a dream after all"
(Heather Nova, "Paper Cup")
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.
On Mon, 2005-01-24 at 21:44 +0000, Alan Cox 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.
would this mean that i should not use cpu frequency scaling?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 25 Jan 2005 00:02:54 +0100, Alessandro Suardi
<[email protected]> wrote:
> On Mon, 24 Jan 2005 21:44:06 +0000, Alan Cox <[email protected]> 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 :(
Now of course, after Ctrl-C'ing the growisofs session, a new
attempt yielded this
[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'
/dev/hdc: "Current Write Speed" is 2.0x1385KBps.
1409024/4608387072 ( 0.0%) @0.0x, remaining 326:57
1409024/4608387072 ( 0.0%) @0.0x, remaining 544:56
1409024/4608387072 ( 0.0%) @0.0x, remaining 708:25
1409024/4608387072 ( 0.0%) @0.0x, remaining 871:53
1409024/4608387072 ( 0.0%) @0.0x, remaining 1089:52
:-[ WRITE@LBA=2b0h failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error
builtin_dd: 688*2KB out @ average 0.0x1385KBps
:-( write failed: Input/output error
/dev/hdc: flushing cache
/dev/hdc: stopping de-icing
/dev/hdc: writing lead-out
[root@donkey tmpburn]#
Then, ejecting the disc and trying again, it went through.
[root@donkey tmpburn]# growisofs -Z /dev/hdc=myfile.iso
Executing 'builtin_dd if=myfile.iso of=/dev/hdc obs=32k seek=0'
/dev/hdc: "Current Write Speed" is 2.0x1385KBps.
13107200/4608387072 ( 0.3%) @2.4x, remaining 40:54
24412160/4608387072 ( 0.5%) @2.4x, remaining 31:17
35717120/4608387072 ( 0.8%) @2.4x, remaining 29:52
47022080/4608387072 ( 1.0%) @2.4x, remaining 27:29
...
4592205824/4608387072 (99.6%) @2.4x, remaining 0:04
4603510784/4608387072 (99.9%) @2.4x, remaining 0:01
builtin_dd: 2250192*2KB out @ average 2.4x1385KBps
/dev/hdc: flushing cache
/dev/hdc: stopping de-icing
/dev/hdc: writing lead-out
Only thing I note is that after reloading, the WARNING about
disc already carrying isofs disappeared.
I guess my next move will be borrowing a Windows CD and
installing it on my former RedHat 9 partition, then trying
to burn DVDs from there...
--alessandro
"And every dream, every, is just a dream after all"
(Heather Nova, "Paper Cup")
On Mon, 24 Jan 2005 21:44:06 +0000, Alan Cox <[email protected]> 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")
On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote:
> > there are certainly chipset and CPU errata in this area.
> would this mean that i should not use cpu frequency scaling?
Worth an experiment but I'd be suprised if it was your fix. The more
data the better however
On Mon, 2005-01-24 at 23:48 +0000, Alan Cox wrote:
> On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote:
> > > there are certainly chipset and CPU errata in this area.
> > would this mean that i should not use cpu frequency scaling?
>
> Worth an experiment but I'd be suprised if it was your fix. The more
> data the better however
I disabled cpufreq in the kernel, acpi i still have in kernel.. when i
booted i did acpi=off, and changed IO scheduler to anticipatory
i just burned a DVD, and it works ;D pretty neat, im not sure what
caused it. but im glad.. i still have the small change in scsi_ioctl.h,
however nothing appears in dmesg.. gonna burn one more dvd in a little
bit, if it doesent work, i will let you know, if you dont hear more
about it, assume it works :DD
btw: the reason i changed to anticipatory from cfq is that i noticed
that sometimes the speed dropped abit, and thought it might have
something to do with it, and, with as it did not
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Fri, Jan 28 2005, Kasper Sandberg wrote:
> On Mon, 2005-01-24 at 23:48 +0000, Alan Cox wrote:
> > On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote:
> > > > there are certainly chipset and CPU errata in this area.
> > > would this mean that i should not use cpu frequency scaling?
> >
> > Worth an experiment but I'd be suprised if it was your fix. The more
> > data the better however
> I disabled cpufreq in the kernel, acpi i still have in kernel.. when i
> booted i did acpi=off, and changed IO scheduler to anticipatory
> i just burned a DVD, and it works ;D pretty neat, im not sure what
> caused it. but im glad.. i still have the small change in scsi_ioctl.h,
> however nothing appears in dmesg.. gonna burn one more dvd in a little
> bit, if it doesent work, i will let you know, if you dont hear more
> about it, assume it works :DD
>
> btw: the reason i changed to anticipatory from cfq is that i noticed
> that sometimes the speed dropped abit, and thought it might have
> something to do with it, and, with as it did not
That's interesting, a short io starvation could for sure cause it. I
would really appreciate if you could try one change at the time though,
right now it's not really clear if it's acpi or the io scheduler.
--
Jens Axboe
On Fri, 2005-01-28 at 14:47 +0100, Jens Axboe wrote:
> On Fri, Jan 28 2005, Kasper Sandberg wrote:
> > On Mon, 2005-01-24 at 23:48 +0000, Alan Cox wrote:
> > > On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote:
> > > > > there are certainly chipset and CPU errata in this area.
> > > > would this mean that i should not use cpu frequency scaling?
> > >
> > > Worth an experiment but I'd be suprised if it was your fix. The more
> > > data the better however
> > I disabled cpufreq in the kernel, acpi i still have in kernel.. when i
> > booted i did acpi=off, and changed IO scheduler to anticipatory
> > i just burned a DVD, and it works ;D pretty neat, im not sure what
> > caused it. but im glad.. i still have the small change in scsi_ioctl.h,
> > however nothing appears in dmesg.. gonna burn one more dvd in a little
> > bit, if it doesent work, i will let you know, if you dont hear more
> > about it, assume it works :DD
> >
> > btw: the reason i changed to anticipatory from cfq is that i noticed
> > that sometimes the speed dropped abit, and thought it might have
> > something to do with it, and, with as it did not
>
> That's interesting, a short io starvation could for sure cause it. I
> would really appreciate if you could try one change at the time though,
> right now it's not really clear if it's acpi or the io scheduler.
well.. all good things must come to an end.. the second dvd i burned
failed.. :(
this is really frustrating.. but im pretty pretty sure its not media
error..
perhaps i must reboot after each burn again.. anyway, it is nice knowing
everything isnt completely lost :)
>
first, sorry for posting so much :|
On Fri, 2005-01-28 at 15:05 +0100, Kasper Sandberg wrote:
> On Fri, 2005-01-28 at 14:47 +0100, Jens Axboe wrote:
> > On Fri, Jan 28 2005, Kasper Sandberg wrote:
> > > On Mon, 2005-01-24 at 23:48 +0000, Alan Cox wrote:
> > > > On Llu, 2005-01-24 at 23:01, Kasper Sandberg wrote:
> > > > > > there are certainly chipset and CPU errata in this area.
> > > > > would this mean that i should not use cpu frequency scaling?
> > > >
> > > > Worth an experiment but I'd be suprised if it was your fix. The more
> > > > data the better however
> > > I disabled cpufreq in the kernel, acpi i still have in kernel.. when i
> > > booted i did acpi=off, and changed IO scheduler to anticipatory
> > > i just burned a DVD, and it works ;D pretty neat, im not sure what
> > > caused it. but im glad.. i still have the small change in scsi_ioctl.h,
> > > however nothing appears in dmesg.. gonna burn one more dvd in a little
> > > bit, if it doesent work, i will let you know, if you dont hear more
> > > about it, assume it works :DD
> > >
> > > btw: the reason i changed to anticipatory from cfq is that i noticed
> > > that sometimes the speed dropped abit, and thought it might have
> > > something to do with it, and, with as it did not
> >
> > That's interesting, a short io starvation could for sure cause it. I
> > would really appreciate if you could try one change at the time though,
> > right now it's not really clear if it's acpi or the io scheduler.
> well.. all good things must come to an end.. the second dvd i burned
> failed.. :(
> this is really frustrating.. but im pretty pretty sure its not media
> error..
> perhaps i must reboot after each burn again.. anyway, it is nice knowing
> everything isnt completely lost :)
i just rebooted, (and booted with acpi off, anticipatory like before)
and burned a DVD, and it works.. this means that when acpi is disabled,
cpufreq off, i have the same problems i initially had with earlier
kernels (2.6.9-rc*)
that is: i could burn 1 dvd, which works fine, then the next i burn
fails, with io error, then the third i burns works.. in short, every
second works.. unless i reboot after each, then no one fails..
its a insanely strange problem. :) but atleast im able to get abit free
hd space now :)
>
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>