"Karol Pietrzak" <[EMAIL PROTECTED]> told us:
> On 4 Sep 2001, Bill Davidsen wrote:
> > First, by current standards the system memory is "modest," a polite
> > way of saying "barely adequate." Depending on what else is running in
> > the system there may be an issue there. I have run happily on 48MB,
> > though, so that's just a thought. Increasing the FIFO might help, but
> > Joerg didn't suggest that, so I just mention that since you can try
> > without touching hardware.
>
> Thank you for not being blunt. :) I have considered getting
> more RAM, but it's not worth it. Windows 95 (my primary OS),
> runs excellent on 32MB (on bootup, 22MB are free) once it is
> optimized. Linux, w/o the GUI stuff of course, plays very
> nicely on just 32MB of RAM. Please note that my Linux
> installation is also "optimized": not even atd runs. My RAM
> used to go for $85 for 32MB of RAM. As I plan on getting a
> completely new computer within the next few months, that's an
> outrageous price to pay, as I can now get 256MB of RAM for the
> same price.
If your system can run on non-parity memory, TC Computers had 512MB of
PC133 for $72. I usually pay a little more for parity, but I come from a
server background and can make enough mistakes without the computer
helping.
> UPDATE:
> Using cdparanoia to rip the contents of the CD does _not_ produe
> the "slow hard drive" problem. It runs perfectly in both 2.4.4
> and 2.4.9. cdda2wav / cdrecord do _not_ suffer from the problem
> in 2.4.4, just 2.4.9. It seems the culprit is either 2.4.9 or
> cdrtools, or both. Although I'm no expert, it could be the way
> cdda2wav and cdrecord access data since cdparanoia is not
> affected.
>
> UPDATE_2:
> Once I disabled DMA (I removed chipset support from kernel
> config), the cdrecord "freeze" problem also has disappeared. I
> will do much more extensive tests in the next few days.
>
> > If that controller has a 2nd bus, such as plain SCSI-2, you might move
> > one device to that and see if it improves the situation. If you have
> > another controller you can plug in that's not a bad idea to try.
>
> Taking into account the new UPDATEs, should I still try this?
I would. If the problem goes away I would suspect a device not getting
off the bus as it should, if it doesn't it could be kernel software,
although if that's the case it is probably the driver, as I have had no
problems with Linux and multi-TB setups.
> > Finally, I assume that the kernel has extended error reporting on in
> > the SCSI code, and that you did look at the logs carefully. Pretty grim
> > to find out that you have a termination problem after you do a lot of
> > other work. The slowness on certain tracks suggests either data
> > dependency or inconsistent hardware. I assume you checked the cables,
> > physical stuff is more likely to "work sometimes" than software or
> > controllers.
And of course the old check to see if you are using termination in the
device rather than a separate terminator, is the terminator the last
(and only) terminated device on the cable?
I think I've made about all the suggestions I have, Joerg said hardware
early on and that seems most likely.
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
