cdrecord freezes computer completely
Hello. I have been burning CDs with my computer even back in the days of 2.2.14. Back then I was using my SCSI Yamaha 8484sz. I was using Slackware 7.1 back then and everything was cozy. I even ran SETI@home while ripping and burning and everything was great. Upon switching to 2.4.x, however, problems arose. At about the same time, I also got a Plextor 12/10/32S. From there, hell broke loose. Running SETI@home would thrash the hard drive enough for me to hit RESET and upon kernel bootup, the filesystem would be corrupted. This has happened to me around 5 times. At about 2.4.6 (2.4.4 didn't have this problem) ripping or burning a CD would _thrash_ the hard drive (whose throughput via hdparm is around 11MB/s), but SETI@home would no longer be a problem. The FIFO as shown by cdrecord would eventually fall to 1%. This problem was fixed around 2.4.7. Another less common problem was the fact that cdrecord would freeze my computer, but since it would thrash the hard drive anyway, I stopped burning CD's in Linux. Since the problem was fixed around 2.4.7, I started again. Then the freezing problems began _very_ apparent. I currently have around a dozen ruined CDR's because of this. It even froze once blanking a CDRW. The situation improved, but was not fixed, and now I'm using 2.4.14. It still locks the computer completely. I don't know what to do. Everything is fine in Windows 95 (and always was). I think it's the shoddy 2.4 Linux VM. Most would agree that 2.2.19 is way more stable, and I think I fall into that camp. Should I try it out? This is a 4.5 year old machine: should I test my RAM? Should I remove one of my SCSI CDRWs and then find out if the problem exists? -- Karol Pietrzak PGP KeyID: 3A1446A0
Karol Pietrzak wrote:
great. Upon switching to 2.4.x, however, problems arose.
Another less common problem was the fact that cdrecord would freeze my computer, but since it would thrash the hard drive anyway, I stopped burning CD's in Linux. Since the problem was
It still locks the computer completely. I don't know what to do. Everything is fine in Windows 95 (and always was). I think
Try getting the cdrecord source and compiling it yourself, that worked for me once when it gave me problems.
On 11 Nov 2001, zentara wrote:
Try getting the cdrecord source and compiling it yourself, that worked for me once when it gave me problems.
I _always_ compile the cdrtools myself. Hell, you can download the RPM from http://home.earthlink.net/~noodlez84/rpm_packages.html . The current version is 1.11a08. Oh wait... 1.11a09 just popped up on Freshmeat. [ Currently downloading... RPM should be up by the end of the day... ] -- Karol Pietrzak PGP KeyID: 3A1446A0
On Sunday 11 November 2001 08:49, Karol Pietrzak wrote:
Hello.
I have been burning CDs with my computer even back in the days of 2.2.14. Back then I was using my SCSI Yamaha 8484sz. I was using Slackware 7.1 back then and everything was cozy. I even ran SETI@home while ripping and burning and everything was great. Upon switching to 2.4.x, however, problems arose.
At about the same time, I also got a Plextor 12/10/32S. From there, hell broke loose. Running SETI@home would thrash the hard drive enough for me to hit RESET and upon kernel bootup, the filesystem would be corrupted. This has happened to me around 5 times. At about 2.4.6 (2.4.4 didn't have this problem) ripping or burning a CD would _thrash_ the hard drive (whose throughput via hdparm is around 11MB/s), but SETI@home would no longer be a problem. The FIFO as shown by cdrecord would eventually fall to 1%. This problem was fixed around 2.4.7.
Another less common problem was the fact that cdrecord would freeze my computer, but since it would thrash the hard drive anyway, I stopped burning CD's in Linux. Since the problem was fixed around 2.4.7, I started again. Then the freezing problems began _very_ apparent. I currently have around a dozen ruined CDR's because of this. It even froze once blanking a CDRW. The situation improved, but was not fixed, and now I'm using 2.4.14.
It still locks the computer completely. I don't know what to do. Everything is fine in Windows 95 (and always was). I think it's the shoddy 2.4 Linux VM. Most would agree that 2.2.19 is way more stable, and I think I fall into that camp. Should I try it out? This is a 4.5 year old machine: should I test my RAM? Should I remove one of my SCSI CDRWs and then find out if the problem exists?
I think you have analyzed the problem correctly..... the VM. That is why Linus changed to the new VM. Get the kernel that has the new VM in it. Also, why do you hit the RESET button? Why not pop open a new terminal and use kill -9 ??? Jerry
On 11 Nov 2001, Jerry Kreps wrote:
On Sunday 11 November 2001 08:49, Karol Pietrzak wrote:
Hello.
I have been burning CDs with my computer even back in the days of 2.2.14. Back then I was using my SCSI Yamaha 8484sz. I was using Slackware 7.1 back then and everything was cozy. I even ran SETI@home while ripping and burning and everything was great. Upon switching to 2.4.x, however, problems arose.
At about the same time, I also got a Plextor 12/10/32S. From there, hell broke loose. Running SETI@home would thrash the hard drive enough for me to hit RESET and upon kernel bootup, the filesystem would be corrupted. This has happened to me around 5 times. At about 2.4.6 (2.4.4 didn't have this problem) ripping or burning a CD would _thrash_ the hard drive (whose throughput via hdparm is around 11MB/s), but SETI@home would no longer be a problem. The FIFO as shown by cdrecord would eventually fall to 1%. This problem was fixed around 2.4.7.
Another less common problem was the fact that cdrecord would freeze my computer, but since it would thrash the hard drive anyway, I stopped burning CD's in Linux. Since the problem was fixed around 2.4.7, I started again. Then the freezing problems began _very_ apparent. I currently have around a dozen ruined CDR's because of this. It even froze once blanking a CDRW. The situation improved, but was not fixed, and now I'm using 2.4.14.
It still locks the computer completely. I don't know what to do. Everything is fine in Windows 95 (and always was). I think it's the shoddy 2.4 Linux VM. Most would agree that 2.2.19 is way more stable, and I think I fall into that camp. Should I try it out? This is a 4.5 year old machine: should I test my RAM? Should I remove one of my SCSI CDRWs and then find out if the problem exists?
I think you have analyzed the problem correctly..... the VM. That is why Linus changed to the new VM. Get the kernel that has the new VM in it.
2.4.14 is the one with the new VM, right??
Also, why do you hit the RESET button? Why not pop open a new terminal and use kill -9 ??? Jerry
That's simply. It you take a look at the Subject of my post, it will answer your question. cdrecord freezes the computer _completely_. Can't eject the CD because, I presume, it's locked because of the burning process and I can't switch terminals. I can't do _anything_. -- Karol Pietrzak PGP KeyID: 3A1446A0
On Sunday 11 November 2001 12:09, Karol Pietrzak wrote:
On 11 Nov 2001, Jerry Kreps wrote:
On Sunday 11 November 2001 08:49, Karol Pietrzak wrote:
Hello.
I have been burning CDs with my computer even back in the days of 2.2.14. Back then I was using my SCSI Yamaha 8484sz. I was using Slackware 7.1 back then and everything was cozy. I even ran SETI@home while ripping and burning and everything was great. Upon switching to 2.4.x, however, problems arose.
At about the same time, I also got a Plextor 12/10/32S. From there, hell broke loose. Running SETI@home would thrash the hard drive enough for me to hit RESET and upon kernel bootup, the filesystem would be corrupted. This has happened to me around 5 times. At about 2.4.6 (2.4.4 didn't have this problem) ripping or burning a CD would _thrash_ the hard drive (whose throughput via hdparm is around 11MB/s), but SETI@home would no longer be a problem. The FIFO as shown by cdrecord would eventually fall to 1%. This problem was fixed around 2.4.7.
Another less common problem was the fact that cdrecord would freeze my computer, but since it would thrash the hard drive anyway, I stopped burning CD's in Linux. Since the problem was fixed around 2.4.7, I started again. Then the freezing problems began _very_ apparent. I currently have around a dozen ruined CDR's because of this. It even froze once blanking a CDRW. The situation improved, but was not fixed, and now I'm using 2.4.14.
It still locks the computer completely. I don't know what to do. Everything is fine in Windows 95 (and always was). I think it's the shoddy 2.4 Linux VM. Most would agree that 2.2.19 is way more stable, and I think I fall into that camp. Should I try it out? This is a 4.5 year old machine: should I test my RAM? Should I remove one of my SCSI CDRWs and then find out if the problem exists?
I think you have analyzed the problem correctly..... the VM. That is why Linus changed to the new VM. Get the kernel that has the new VM in it.
2.4.14 is the one with the new VM, right??
Also, why do you hit the RESET button? Why not pop open a new terminal and use kill -9 ??? Jerry
That's simply. It you take a look at the Subject of my post, it will answer your question. cdrecord freezes the computer _completely_. Can't eject the CD because, I presume, it's locked because of the burning process and I can't switch terminals. I can't do _anything_.
Ok, by saying 'completely' you are including system commands via the keyboard. I have noticed that being 'locked up' doesn't always mean that the ALT=SHIFT-Fx popup terminals are disabled. JLK
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 11 November 2001 13:09, you wrote:
On 11 Nov 2001, Jerry Kreps wrote:
On Sunday 11 November 2001 08:49, Karol Pietrzak wrote:
Hello.
I have been burning CDs with my computer even back in the days of 2.2.14. Back then I was using my SCSI Yamaha 8484sz. I was using Slackware 7.1 back then and everything was cozy. I even ran SETI@home while ripping and burning and everything was great. Upon switching to 2.4.x, however, problems arose.
At about the same time, I also got a Plextor 12/10/32S. From there, hell broke loose. Running SETI@home would thrash the hard drive enough for me to hit RESET and upon kernel bootup, the filesystem would be corrupted. This has happened to me around 5 times. At about 2.4.6 (2.4.4 didn't have this problem) ripping or burning a CD would _thrash_ the hard drive (whose throughput via hdparm is around 11MB/s), but SETI@home would no longer be a problem. The FIFO as shown by cdrecord would eventually fall to 1%. This problem was fixed around 2.4.7.
Another less common problem was the fact that cdrecord would freeze my computer, but since it would thrash the hard drive anyway, I stopped burning CD's in Linux. Since the problem was fixed around 2.4.7, I started again. Then the freezing problems began _very_ apparent. I currently have around a dozen ruined CDR's because of this. It even froze once blanking a CDRW. The situation improved, but was not fixed, and now I'm using 2.4.14.
It still locks the computer completely. I don't know what to do. Everything is fine in Windows 95 (and always was). I think it's the shoddy 2.4 Linux VM. Most would agree that 2.2.19 is way more stable, and I think I fall into that camp. Should I try it out? This is a 4.5 year old machine: should I test my RAM? Should I remove one of my SCSI CDRWs and then find out if the problem exists?
I think you have analyzed the problem correctly..... the VM. That is why Linus changed to the new VM. Get the kernel that has the new VM in it.
2.4.14 is the one with the new VM, right??
Also, why do you hit the RESET button? Why not pop open a new terminal and use kill -9 ??? Jerry
That's simply. It you take a look at the Subject of my post, it will answer your question. cdrecord freezes the computer _completely_. Can't eject the CD because, I presume, it's locked because of the burning process and I can't switch terminals. I can't do _anything_.
It is my understanding that the new vm appeared around 2.4.10 and that the current 2.4.14 is where Linus and Alan agreed to disagree on the vm and they merged their kernel-tree. Alan will be moving on the develop in the 2.5 tree after some weeks off. 2.4 will now be maintained by Alan's second-in-command. This my understanding and some of the details could be less than accurate. - -- b stephen One of The Board Members: Ottawa Canada Linux Users Group gpg & pgp keys can be found on the pgp.mit.edu or pgpkeys.mit.edu keyservers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE77sMQ6CSA+AcepnIRAoHMAJsEJC5NWTZh6y1P3Y5qVS2COPv+hACgp2Pe 3v1W9C3GONshj0jReFF7OHE= =gEnZ -----END PGP SIGNATURE-----
participants (4)
-
b stephen harding -
Jerry Kreps -
Karol Pietrzak -
zentara