(IDE) Iomega ZIP 250 troubles on SUSE 10.0
Hi, I have a SUSE 10.0 system, having an internal Iomega 250Mb ZIP drive as secondary slave. Writing to any FAT-formatted ZIP disk the transfer was extremely SLOW and after I checked up the corresponding bug- reports and the list archive, saw two possibilities to move to higher writing speed. First I attempted to deactivate the sync writing, but that particular drive had no uuid under lshal, so couldn't define the async writing exclusively for that device. (I took the info from the SDB for 9.3.) Then I decided to move on automounting generally deactivated, but this with both sync and async didn't solve my problem. Of course async was seemingly quicker, but then attempting to umount the disk caused still 12-15 minutes waiting... I also checked the DMA settings, but the max. DMA/4.3 or similar I could activate, there was no other possibility. I don't think that it really counts, but the drive was not originally there in the comp, but was added later. Probably that's why an extra problem used to happen, when booting up with no ZIP disk in the drive I get only /dev/hdd, but no /dev/hdd4, so generally I can't even later manually mount the device! If I boot up with disk in the drive, the /dev/hdd4 is there or if was not there, alternatively I plug the disk in and then do _eject_ for it, then on a ridiculous way /dev/hdd4 appears suddenly... So I put back the disk and then I can really mount it. Is that bug or feature that SUSE recognizes the ZIP and doesn't put the corresponding device file there for manual mounting?! Of course /media/zip I made also by myself, but after deactivating automounter it is very OK. So at present I don't know, what is wrong; I read already, that the "slow-writing" bug should be gone by now. FYI: it is not with all the newest updates... Please is there anyone out there using internal ZIP drive and not having the above or very similar problems?! Thank you, Pelibali PS. Personal comment. I read the thread SUSE back and similar. For me SUSE means always _less_ and makes me worrying why I should load an earlier SUSE 9.x variant or use another distro everytime when I wish to do backup to a common ZIP-disk with no issues and/or speed-con- cerns.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-03-12 at 13:01 +0100, pelibali wrote:
Then I decided to move on automounting generally deactivated, but this with both sync and async didn't solve my problem. Of course async was seemingly quicker, but then attempting to umount the disk caused still 12-15 minutes waiting...
Because write operations were buffered in memory and waiting, till they could actually be written. Umount forces writing, so you have to wait. But that time seems excesive.
I also checked the DMA settings, but the max. DMA/4.3 or similar I could activate, there was no other possibility.
What does hdparm say on the device?
I don't think that it really counts, but the drive was not originally there in the comp, but was added later. Probably that's why an extra problem used to happen, when booting up with no ZIP disk in the drive I get only /dev/hdd, but no /dev/hdd4, so generally I can't even later manually mount the device!
Add it in /etc/udev/static_devices.txt - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEFWoqtTMYHG2NR9URAuIEAJ4lbD6T4/ESNZAAt3L8scrqB4+BAACfRtYx 7u47f4qRr4fHoRaDzihVZa0= =X1he -----END PGP SIGNATURE-----
Hi, On Mon, 13 Mar 2006 13:48:30 +0100 (CET) "Carlos E. R." <.> wrote:
I also checked the DMA settings, but the max. DMA/4.3 or similar I could activate, there was no other possibility.
What does hdparm say on the device?
Without DMA it says trinity:~ # hdparm /dev/hdd /dev/hdd: IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 239/64/32, sectors = 0, start = 0 trinity:~ # With DMA enabled it says <...> using_dma = 1 (on) <...> I don't know hdparm more, so I'm afraid this is not the info you really asked for... Maybe you would need these: trinity:~ # hdparm -i /dev/hdd /dev/hdd: Model=IOMEGA ZIP 250 ATAPI, FwRev=51.G, SerialNo= Config={ SpinMotCtl Removeable nonMagnetic } RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=0kB, MaxMultSect=0 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0 IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:180,rec:180} PIO modes: pio0 pio1 pio2 pio3 DMA modes: *mdma0 AdvancedPM=no * signifies the current active mode trinity:~ # hdparm -I /dev/hdd /dev/hdd: ATAPI Direct-access device, with removable media Model Number: IOMEGA ZIP 250 ATAPI Serial Number: Firmware Revision: 51.G Standards: Likely used: 4 Configuration: DRQ response: <=10ms with INTRQ Packet size: 12 bytes Capabilities: LBA, IORDY(can be disabled) Queue depth: 1 DMA: *mdma0 Cycle time: min=180ns recommended=180ns PIO: pio0 pio1 pio2 pio3 Cycle time: no flow control=500ns IORDY flow control=180ns Removable Media Status Notification feature set supported
I don't think that it really counts, but the drive was not originally there in the comp, but was added later. Probably that's why an extra problem used to happen, when booting up with no ZIP disk in the drive I get only /dev/hdd, but no /dev/hdd4, so generally I can't even later manually mount the device!
Add it in /etc/udev/static_devices.txt Hmmm. The format used there is completely new for me! As first I added "hdd4 b 22 68 640", making the device's permissions good, but owned by root:root and not root:disk. Any idea to fix this please?! (After I mount a disk, the permissions get fixed and both root:root and root:disk works. Independently of that I would like to fix...)
Regards & many thanks Carlos, Pelibali
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-03-14 at 19:56 +0100, pelibali wrote:
What does hdparm say on the device?
Without DMA it says trinity:~ # hdparm /dev/hdd
/dev/hdd: IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) geometry = 239/64/32, sectors = 0, start = 0 trinity:~ #
With DMA enabled it says <...> using_dma = 1 (on) <...>
Ah, so it allows you to enable dma. It looks correct to me, except that as I don't have a zip drive on IDE, I can't compare. Perhaps somebody else can :-? I just noticed another one, for two of my HD: IO_support = 0 (default 16-bit) The other one and the DVD shows: IO_support = 1 (32-bit) I'll have to investigate that one, but I don't think that one would make such a big difference for you.
I don't know hdparm more, so I'm afraid this is not the info you really asked for... Maybe you would need these:
No, that's what I asked for, but the next data you send is also interesting.
trinity:~ # hdparm -i /dev/hdd
/dev/hdd:
Model=IOMEGA ZIP 250 ATAPI, FwRev=51.G, SerialNo= Config={ SpinMotCtl Removeable nonMagnetic } RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
No multiple sector read. That's bad - but you can't do anything about it, I think. It is that way.
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0 IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:180,rec:180} PIO modes: pio0 pio1 pio2 pio3 DMA modes: *mdma0
And this is worse: it only accepts the lowests of the DMA modes, but then, the device is, after all, an improved floppy, so it is slow.
AdvancedPM=no
* signifies the current active mode
I wonder if you can test that data with an older 9.x distro? To compare. Perhaps just booting the rescue system on dvd would allow to run hdparm and see. If you see "multisector" is not "0", then that would be it.
Add it in /etc/udev/static_devices.txt
Hmmm. The format used there is completely new for me!
Me too - I don't use 10.0, I just have it on a test partition.
As first I added "hdd4 b 22 68 640", making the device's permissions good, but owned by root:root and not root:disk. Any idea to fix this please?!
nop.
(After I mount a disk, the permissions get fixed and both root:root and root:disk works. Independently of that I would like to fix...)
Change the ownership of the mount point or the directories once mounted. Hold on, it is fat, no? Then the ownership is fixed in /etc/fstab options. It's late, I'm disconecting, but you can find that in many posts. If not, I'll comment tomorrow.
Regards & many thanks Carlos,
Welcome. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEF4dotTMYHG2NR9URAjHfAJ9r+nKJpE0jdva/CE4HD9WP/hTHgQCfTI4b /sEknhHyiXDLHzGWiozD4g8= =oWyj -----END PGP SIGNATURE-----
Hi, I travelled home and installed a similar, 100Mb ZIP drive (IDE) into my mom's SUSE 8.2 for backup purposes. There were really no issues I detailed last time... I checked it's hdparm thingies and there were just _slight_ differen- ces, but surprisingly
I just noticed another one, for two of my HD:
IO_support = 0 (default 16-bit)
The other one and the DVD shows:
IO_support = 1 (32-bit)
is the same, so 16-bit... The only differences I could find, which were resulted not by the 250Mb vs. 100Mb and of course firmware-related variations: 250Mb drive (SUSE 10.0) readahead = 256 (on) <..> IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:180,rec:180} PIO modes: pio0 pio1 pio2 pio3 DMA modes: *mdma0 100Mb drive (SUSE 8.2) readahead = 8 (on) <..> IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:150,rec:150} PIO modes: pio0 pio1 pio2 pio3 DMA modes: mdma0 *mdma1 At present no further comments, but at least I'm glad that I could confirm, that a ZIP-drive causes no problems for older SUSE releases! Even if later installed. Another good test-candidate would be to get out my 250Mb "slow" drive and try to install it next time into my mom's compi or put another 100Mb drive into our SUSE 10.0 machine. Regards, Pelibali
On 21/03/06, pelibali <pelibali@freemail.hu> wrote:
Hi,
I travelled home and installed a similar, 100Mb ZIP drive (IDE) into my mom's SUSE 8.2 for backup purposes. There were really no issues I detailed last time... I checked it's hdparm thingies and there were just _slight_ differen- ces, but surprisingly
I just noticed another one, for two of my HD:
IO_support = 0 (default 16-bit)
The other one and the DVD shows:
IO_support = 1 (32-bit)
is the same, so 16-bit...
The only differences I could find, which were resulted not by the 250Mb vs. 100Mb and of course firmware-related variations:
250Mb drive (SUSE 10.0) readahead = 256 (on) <..> IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:180,rec:180} PIO modes: pio0 pio1 pio2 pio3 DMA modes: *mdma0
100Mb drive (SUSE 8.2) readahead = 8 (on) <..> IORDY=on/off, tPIO={min:500,w/IORDY:180}, tDMA={min:150,rec:150} PIO modes: pio0 pio1 pio2 pio3 DMA modes: mdma0 *mdma1
At present no further comments, but at least I'm glad that I could confirm, that a ZIP-drive causes no problems for older SUSE releases! Even if later installed. Another good test-candidate would be to get out my 250Mb "slow" drive and try to install it next time into my mom's compi or put another 100Mb drive into our SUSE 10.0 machine.
I'll be interested to hear the results if you do try this experiment. I too run a 250mb IDE internal Iomega Zip drive on my SuSE 10 PC. -- ============================================== I am only human, please forgive me if I make a mistake it is not deliberate. ============================================== Xmas may be over but, PLEASE DON'T drink and drive you'll make it to the next one that way. Kevan Farmer Linux user #373362 Cheslyn Hay Staffordshire WS6 7HR
Hi, On Tue, 21 Mar 2006 22:02:19 +0000 Kevanf1 <.> wrote:
On 21/03/06, pelibali <.> wrote:
... At present no further comments, but at least I'm glad that I could confirm, that a ZIP-drive causes no problems for older SUSE releases! Even if later installed. Another good test-candidate would be to get out my 250Mb "slow" drive and try to install it next time into my mom's compi or put another 100Mb drive into our SUSE 10.0 machine.
I'll be interested to hear the results if you do try this experiment. I too run a 250mb IDE internal Iomega Zip drive on my SuSE 10 PC.
I did both the tests I mentioned last time! To start from the very beginning I had troubles (SUSE 10.0) with an inter- nal 250MB ZIP drive and wanted to show that it is not because the drive capabilities ("less" DMA modes) and not because corrupted drive. Another internal, 100MB ZIP-drive worked flawlessly on my mom's SUSE 8.2... I simply swapped the two drives; SUSE 8.2 kept working very well with the 250MB drive; a 95MB backup took reasonable time, but SUSE 10.0 performed sh*t, I got ~7.5kb per second! I couldn't wait, until 5Mb finishes:( (Additionally I knew that for backup purposes on the SUSE 10.0 machine I had to bootup e.g. SUSE 9.1 live distro and that one worked with both drives very well.) I know about the bug-reports and the work-arounds, which should ensure full FAT-writing speed on various media, but the official tips didn't solve anything. I'm lucky to have a 9.3 image somewhere and will rewrite that; SUSE 10.0 is not suitable for my own needs. Likely try to go back to 9.3 or prefe- rably to 9.1 Pro. Regards, Pelibali
On 10/04/06, pelibali <pelibali@freemail.hu> wrote:
Hi,
On Tue, 21 Mar 2006 22:02:19 +0000 Kevanf1 <.> wrote:
On 21/03/06, pelibali <.> wrote:
... At present no further comments, but at least I'm glad that I could confirm, that a ZIP-drive causes no problems for older SUSE releases! Even if later installed. Another good test-candidate would be to get out my 250Mb "slow" drive and try to install it next time into my mom's compi or put another 100Mb drive into our SUSE 10.0 machine.
I'll be interested to hear the results if you do try this experiment. I too run a 250mb IDE internal Iomega Zip drive on my SuSE 10 PC.
I did both the tests I mentioned last time!
To start from the very beginning I had troubles (SUSE 10.0) with an inter- nal 250MB ZIP drive and wanted to show that it is not because the drive capabilities ("less" DMA modes) and not because corrupted drive. Another internal, 100MB ZIP-drive worked flawlessly on my mom's SUSE 8.2...
I simply swapped the two drives; SUSE 8.2 kept working very well with the 250MB drive; a 95MB backup took reasonable time, but SUSE 10.0 performed sh*t, I got ~7.5kb per second! I couldn't wait, until 5Mb finishes:( (Additionally I knew that for backup purposes on the SUSE 10.0 machine I had to bootup e.g. SUSE 9.1 live distro and that one worked with both drives very well.)
I know about the bug-reports and the work-arounds, which should ensure full FAT-writing speed on various media, but the official tips didn't solve anything. I'm lucky to have a 9.3 image somewhere and will rewrite that; SUSE 10.0 is not suitable for my own needs. Likely try to go back to 9.3 or prefe- rably to 9.1 Pro.
Regards, Pelibali
Thank you for the follow up on that. I still have not been able to gain proper access to my SuSE 10 PC :-((( long story and I'm not going into it here. Let's hope that this problem is sorted in 10.1 -- ============================================== I am only human, please forgive me if I make a mistake it is not deliberate. ============================================== Xmas may be over but, PLEASE DON'T drink and drive you'll make it to the next one that way. Kevan Farmer Linux user #373362 Cheslyn Hay Staffordshire WS6 7HR
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-03-21 at 21:44 +0100, pelibali wrote:
The only differences I could find, which were resulted not by the 250Mb vs. 100Mb and of course firmware-related variations:
.... I think these diferences are because the 100 Mb drive is older technology.
Another good test-candidate would be to get out my 250Mb "slow" drive and try to install it next time into my mom's compi or put another 100Mb drive into our SUSE 10.0 machine.
Yes, that would be interesting. There might be something with SuSE 10, though: quite some people complain of slow usb drives, for instance. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEIeuptTMYHG2NR9URAl06AJ428HB15hayP5rkvJ4OChf+tQ4kQwCfWzOx 3VLfDil8auFmE+ArwbioC6U= =UnM1 -----END PGP SIGNATURE-----
participants (3)
-
Carlos E. R. -
Kevanf1 -
pelibali