Hi, I recently noticed with 2.4.17 using scsi cdrom emulation my cdrom stop's functioning after monunting it, (and reading from it). I think hafta umount and remount it, I didnt see these problems with 2.4.16, has anyone else had this problem?
--
I'm praying for rain and I'm praying for tidal waves I wanna see the ground give way.
I wanna watch it all go down - tool.
On Wed, 26 Dec 2001, Robert Jameson wrote:
> Hi, I recently noticed with 2.4.17 using scsi cdrom emulation my cdrom stop's functioning after monunting it, (and reading from it). I think hafta umount and remount it, I didnt see these problems with 2.4.16, has anyone else had this problem?
> --
I have no problem with using scsi cdrom emulation ,
using teac 58E RW and ide-scsi emulation.
Only problem I found is when writing TOC (within cdrecord)
I have to wait until it finished (I cannot even change console)
to be more strange, I have that problem only at work
PIII 500Mhz with TEAC 58E but on
PII 633Mhz with TEAC 54E and PPRO 200Mhz with TEAC 58E I haven't
that problem. Note that was for 2.4.14-17
With kernel 2.2.19 there is no such behaviur.
Regards,
Zoran
On Wed, Dec 26, 2001 at 10:22:28AM +0100, Davidovac Zoran wrote:
> I have no problem with using scsi cdrom emulation ,
> using teac 58E RW and ide-scsi emulation.
Mitsumi CR-4804TE here, also no problems with 2.4.15 (with the second
cut of Viro's iput() patch, more or less making it 2.4.16), and a few other
'random' 2.4.x's, 2.4.13 and .14 spring to mind.
> Only problem I found is when writing TOC (within cdrecord)
> I have to wait until it finished (I cannot even change console)
Ah, I'm not the only one seeing this then. During the 'fixating'
stage of burning I see what you describe. I THINK it's more to do with
it hogging the bus (for whatever reason), and nothing being able to be
swapped in. Could be a total interrupt hog?
> to be more strange, I have that problem only at work
> PIII 500Mhz with TEAC 58E but on
> PII 633Mhz with TEAC 54E and PPRO 200Mhz with TEAC 58E I haven't
> that problem. Note that was for 2.4.14-17
PII-400 here, on:
Gigabyte 686BX motherboard (IDE interface: Intel Corp. 82371AB
PIIX4 IDE (rev 01)) ->
http://www.gigabyte.com.tw/products/ga686bx.htm
the aforementioned Mitsumi CR-4804TE CD-R/RW on hdb (my actual
system is on hda, only a pure data drive is on hdc, no hdd)
Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 J?rg
Schilling
> With kernel 2.2.19 there is no such behaviur.
I don't recall this with the various 2.2.x kernels I ran until
switching to 2.4.8 either.
-Ath
--
- Athanasius = Athanasius(at)gurus.tf / http://www.clan-lovely.org/~athan/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
> > Only problem I found is when writing TOC (within cdrecord)
> > I have to wait until it finished (I cannot even change console)
>
> Ah, I'm not the only one seeing this then. During the 'fixating'
> stage of burning I see what you describe. I THINK it's more to do with
> it hogging the bus (for whatever reason), and nothing being able to be
> swapped in. Could be a total interrupt hog?
The drive doesn't disconnect so it does indeed hog the entire bus. However
for non-X11 consoles a console change doesn't need data off the machine so
it doesnt really explain why that would also fail.