Re: 100% system CPU usage with cdrecord
Joerg Schilling wrote: From: Rob Bogus mail account [EMAIL PROTECTED] I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. I have not had any problems with ide-scsi under 2.6 kernels since 2.6.2 or so, but the ATAPI interface is much easier on the CPU for audio burn. The ATAPI: interface has no DMA at all The ATA: fixes a DMA bug that should be ficed the same way for ide-scsi. It is just annoing to see that the Linux kernel folks first copied the code from ide-scsi just to create this unneeded new interface and later onlu fixed the bug in the copy but not in the original Thank you for catching this! The original post had ATAPI and I read it as ATA (brain fart). What he said, what I meant, not what I said. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
On Wed, Jun 30, 2004 at 06:02:52PM -0500, Charles Steinkuehler wrote: Dma *IS* enabled: With Linux 2.4, it's only enabled if the sector size is a multiple of 512. So you can have DMA for writing data CDs, but not audio or VCD, for example. So this could be your problem. I don't see if you mentioned what exactly you are burning? Without DMA, it seems your southbridge pretty much determines how fast your burns can go and there's a point where things really start to tax the CPU. For example, with the old VIA 686b I got about 14x max and a totally bogged down system. At 12x, no problems. Swapped motherboard to a SiS745 based and 16x burns were suddenly no problem. Due to some other mysterious 2.4 Linux problem, I went to 2.6 soon after, DMA works there if you use the ATAPI interface for burning. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
From: Rob Bogus mail account [EMAIL PROTECTED] I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. I have not had any problems with ide-scsi under 2.6 kernels since 2.6.2 or so, but the ATAPI interface is much easier on the CPU for audio burn. The ATAPI: interface has no DMA at all The ATA: fixes a DMA bug that should be ficed the same way for ide-scsi. It is just annoing to see that the Linux kernel folks first copied the code from ide-scsi just to create this unneeded new interface and later onlu fixed the bug in the copy but not in the original Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
From: Ambrose Li [EMAIL PROTECTED] But note that if you use ide-scsi on 2.4, don't try to create HFS/ISO9660 hybrid disks. Otherwise your computer will lock up when you mount your disk to verify it. ? I would not believe this unless you give an explanation. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
From: Anssi Saari [EMAIL PROTECTED] On Wed, Jun 30, 2004 at 06:02:52PM -0500, Charles Steinkuehler wrote: Dma *IS* enabled: With Linux 2.4, it's only enabled if the sector size is a multiple of 512. So you can have DMA for writing data CDs, but not audio or VCD, for example. So this could be your problem. I don't see if you mentioned what exactly you are burning? WORSE: ATAPI: never gives DMA. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
Charles Steinkuehler [EMAIL PROTECTED] wrote: [...] Just so I'm clear, for best results... If using a 2.6 kernel, I should use the ATAPI interface, ie: cdrecord dev=ATAPI:0,0,0 ... with no special kernel options at boot No. Quoting README.ATAPI: - Linux-2.4.xx includes a CDROM Packet interface in the IDE CD driver. For this driver libscg now includes support in pre-alpha status. Use cdrecord dev=ATAPI - Starting with Linux-2.5.45, there is a new experimental ATAPI interface [...] Cdrecord allows to use this interface by calling e.g. cdrecord dev=ATA:1,0,0 [...] You want dev=ATA:x,y.z. ...but if I'm using a 2.4 kernel, even though the ATAPI interface is there (and seems to be working), I should use SCSI emulation, ie: cdrecord dev=0,0,0 ... with hdX=ide-scsi in kernel command line at boot Correct. Because quoting README.ATAPI again: All Linux ATAPI transport implementations do not support DMA. Current execptions are: - ide-scsi with block size 2048 and if DMA has been enabled - The new experimental No DMA = 100% CPU. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
On Fri, Jul 02, 2004 at 03:15:31PM +0200, Joerg Schilling wrote: From: Ambrose Li [EMAIL PROTECTED] But note that if you use ide-scsi on 2.4, don't try to create HFS/ISO9660 hybrid disks. Otherwise your computer will lock up when you mount your disk to verify it. [...] I would not believe this unless you give an explanation. [...] I mentioned this in a previous post. It is a kernel bug in 2.4, and from what I found at that time through Google, it has something to do with sector sizes, and the Linux developers are not interested in fixing this serious bug. In fact, you answered my posting at that time: From [EMAIL PROTECTED] Tue Oct 14 11:54:55 2003 Date: Tue, 14 Oct 2003 17:54:34 +0200 (CEST) From: Joerg Schilling [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: linux kernel error reading end of cd/dvd Return-Path: [EMAIL PROTECTED] From: Ambrose Li [EMAIL PROTECTED] (From someone who doesn't know much about CD's) I used to checksum all the files (after finding that checksumming the whole disk doesn't work -- something beyond my understanding). This stopped abruptly after I upgraded my Linux kernel to 2.4, when mounting a hfs disk started to crash the kernel. I had to simply give people disks that I could not verify as having been written correctly. If your kernel did crash, then you definitely found a kernel bug. So if I might add something to the efficiency argument, I might add that for me to checksum my disk, I'll need to checksum all the files twice (once for iso9660, once for hfs), and all this is provided that checksumming all the files would actually work (which is not the case right now). IF you write in SAO mode and your drive is not broken (use -raw96r with Lite-ON drives for this reason), then you may simply checksum the complete content of the session. The CD definitely gives you exactly the same content back that has been in the *.iso file. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
On Wed, 30 Jun 2004, Charles Steinkuehler wrote: The only kind of odd thing I'm doing is using the ATA support in cdrecord to talk to the burner rather than SCSI emulation (I was having problems getting that going...apparently I don't yet fully understand the interaction of the new libata and the hda=scsi kernel command line parameter), but trolling the mailing list seems to indicates this should be faster than the older scsi emulation. The actual cdrecord command I'm using: cdrecord dev=ATAPI:0,0,0 driveropts=burnfree speed=48 -dao -v image.iso I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. I have not had any problems with ide-scsi under 2.6 kernels since 2.6.2 or so, but the ATAPI interface is much easier on the CPU for audio burn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
On Thu, Jul 01, 2004 at 04:21:24PM -0400, Rob Bogus mail account wrote: I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. But note that if you use ide-scsi on 2.4, don't try to create HFS/ISO9660 hybrid disks. Otherwise your computer will lock up when you mount your disk to verify it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
Rob Bogus mail account wrote: On Wed, 30 Jun 2004, Charles Steinkuehler wrote: The only kind of odd thing I'm doing is using the ATA support in cdrecord to talk to the burner rather than SCSI emulation (I was having problems getting that going...apparently I don't yet fully understand the interaction of the new libata and the hda=scsi kernel command line parameter), but trolling the mailing list seems to indicates this should be faster than the older scsi emulation. The actual cdrecord command I'm using: cdrecord dev=ATAPI:0,0,0 driveropts=burnfree speed=48 -dao -v image.iso I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. I have not had any problems with ide-scsi under 2.6 kernels since 2.6.2 or so, but the ATAPI interface is much easier on the CPU for audio burn. Just so I'm clear, for best results... If using a 2.6 kernel, I should use the ATAPI interface, ie: cdrecord dev=ATAPI:0,0,0 ... with no special kernel options at boot ...but if I'm using a 2.4 kernel, even though the ATAPI interface is there (and seems to be working), I should use SCSI emulation, ie: cdrecord dev=0,0,0 ... with hdX=ide-scsi in kernel command line at boot Is this correct? -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
100% system CPU usage with cdrecord
HELP!! I've burned CD's in linux before with great success, but I've upgraded my hardware and am now having speed problems. Previously, the fastest burner I had was an HP 16x, which worked fine at full speed as long as DMA was enabled. I've recently purchased a Plextor 712A, which will burn CDs at up to 48X (along with DVDs at up to 12X, but one thing at a time!). When running cdrecord, I now have to enable 'burnproof' to prevent making coasters, and I never seem to be able to write at more than about 25-28x. If I watch the output of 'top' while burning, the system CPU usage gradually increases to 100% as the image is burned, until burn-proof starts kicking in with system CPU usage hovering near 100% and write speed in the high 20's (around 27/28x). Note that's it's *NOT* cdrecord itself that's eating CPU cycles, but something inside the kernel (or whatever else goes into the 'system' bin for CPU usage). There's also very little other load on the system (just a couple virtual terminals...no X windows running). Dma *IS* enabled: naibed:~# cat /proc/ide/hda/settings namevalue min max mode - --- --- breada_readahead4 0 127 rw current_speed 66 0 70 rw dsc_overlap 0 0 1 rw file_readahead 0 0 2097151 rw init_speed 12 0 70 rw io_32bit1 0 3 rw keepsettings0 0 1 rw max_kb_per_request 64 1 127 rw nice1 1 0 1 rw number 0 0 3 rw pio_modewrite-only 0 255 w slow0 0 1 rw unmaskirq 1 0 1 rw using_dma 1 0 1 rw I've verified reads from the Plextor are fast and take little CPU by running iostat while doing an md5sum of the device (kind of hard to test writes, other than with something like cdrecord). The write data is coming off a SATA drive (mounted as /tmp...no other system activity to this drive) which should have more than enough bandwidth (53M/s reads): naibed:~# bonnie++ -u root -d /tmp Version 1.03 --Sequential Output-- --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP naibed 1G 12878 67 41023 8 22196 4 19980 70 53342 8 238.4 0 --Sequential Create-- Random Create -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 11134 19 + +++ 5433 11 4758 26 + +++ 1942 8 System HW specs: 2.4G Athlon Asus A7N8X (NForce2) motherboard 512M Ram (dual-channel) Plextor 712A burner as the primary PATA master (no other PATA devices) 4x Seagate SATA 160G drives on a Promise TX4 controller On-board Silicon Image SATA controller is diabled via jumper I'm running debian-testing (sarge) with the stock debian kernel: 2.4.26-1-386 cdrecord is version: 4:2.0+a30.pre1-1 The only kind of odd thing I'm doing is using the ATA support in cdrecord to talk to the burner rather than SCSI emulation (I was having problems getting that going...apparently I don't yet fully understand the interaction of the new libata and the hda=scsi kernel command line parameter), but trolling the mailing list seems to indicates this should be faster than the older scsi emulation. The actual cdrecord command I'm using: cdrecord dev=ATAPI:0,0,0 driveropts=burnfree speed=48 -dao -v image.iso ...after which I get a report typically listing ~30 predicted buffer underruns that were prevented. It seems like this system ought to be fast enough to burn at 48x without breaking a sweat...any suggestions for settings I can tweak or other tests I can run? -- Charles Steinkuehler [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
