LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 04-15-2007, 02:50 PM   #1
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Rep: Reputation: 0
Why can't I get MFM support working when I recompile the kernel on slack 8.1


I'm using the stock kernel off the cd *8.1 slack - 2.4.18 , which works perfectly, picks up the drive:

Quote:
Detected a Western Dig. 1002-27X controller (type 4) at address 0ca000
Detected 1 hard drive (using IRQ5 & DMA3)
xda: CHS=612/4/17
xda: xda1

But I want to recompile with a newer kernel 2.4.30. I have copied the .config for that 2.4.18 kernel from the slackware CD, and only changed the "smp options" (kernel compile would fail compile without doing this).

Did:
make clean
make dep && make && make modules && make modules_install && make bzImage


I built the kernel with the same config as the previous 2.4.18. When I boot now I get this :
Quote:
XD: Out of Memory.
If I force the kernel to load the driver, with this I mean by appending the option to find the hard disk ctrlr, I get

Quote:
Detected a Western Dig. 1002-27X controller (type 4) at address 000000
Detected 0 hard drives (using IRQ5 & DMA3)
So it now sees the controller but no hard drive.

Im stuck where to go now! I have tried appending these to the kernel in hopes it would go again
Quote:
# notes xd= card type, card IRQ, card IO, card DMA
append = "xd=4,5,0x320,3"
and
append = "xd=4,5,0x320,3 xd_geo=612,4,17"
# notes for xd_geo=cyl_xda,head_xda,sec_xda"
I noticed when I boot off the stock kernel I see : " address 0ca000" (from either the hard drive or CDrom)

===> Address 0ca000

And the one I compile, I get address 000000. I know the card is jumpered for 0x320. I tried fiddling with the numbers a bit for 0ca000, and decided to try 0x202, with no luck. How do I interpret 0ca000 ?

Can anyone help me get this going again ! I liked having this ancient hard drive still running 20 years later !

Thanks so much for anyone who has helpful advice!

Regards,

Jonathan
 
Old 04-16-2007, 04:31 AM   #2
johneb47
LQ Newbie
 
Registered: Aug 2003
Location: Kingswood NSW Australia
Distribution: Slackware, ArchLinux
Posts: 19

Rep: Reputation: 1
Hi Jonathan,
Methinks you are trying to go too far. If you want to upgrade your kernel you may have to upgrade the the distro to at least version 10.0. Version 8.1 is pretty ancient circa 2001/2 and if you upgraded the kernel so far you would have to at least upgrade binutils package, and probably several other packages to get it to work correctly and it may be wiser to do the version upgrade instead. Check out the kernel documentation for what version of binutils you need.

John
 
Old 04-16-2007, 10:44 PM   #3
wartstew
Member
 
Registered: Apr 2002
Location: Albuquerque, NM USA
Distribution: Slackware, Ubuntu, Debian, Maemo
Posts: 464

Rep: Reputation: 30
Wow, and I thought I used old computers! An old WD MFM controller? I guess you must have a still functioning hard drive for it as well!

(Well actually I think I may still have a couple of MFM drives I haven't thrown away yet. They worked last time I tried them, over 10 years ago!)

What size drive have you got anyway? Back in those days, an 80-Meg drive was considered big. Are you running Zipslack?

Anyway. I'm probably not much help but you might see if "make oldconfig" exists with that kernel, it might more properly use that old config file. It could be that are some changed defaults or other options that might need tweaked going from -18 to -30.

The idea that it only compiles an SMP kernel might be of concern. I wonder if anyone bothered to update that old XD disk driver for SMP kernels? I'll bet nobody ever thought someone would use that combination!

Worse case I would start over with the config file ("make menuconfig", or even "make config"). I can't imagine that your vintage hardware would be very complicated to figure out again. You can always use your old config file for reference purposes.

I'm assuming that you are staying with Slack 8.1 to save memory. I can't remember that was that an old libc5 distro. If not you could fall back further (Slack 7.x maybe) to save more memory if you need. I'm sure SMP added quite a bulk to that kernel as well.

I just noticed I still have a purchased-from-Slackware CD set of 8.1 in my drawer. I was really impressed with Slackware back then. A little less so now, I just did a very painful upgrade from Slack-11.0 to -current. Debian does this sort of thing much better.
 
Old 04-17-2007, 10:26 AM   #4
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Original Poster
Rep: Reputation: 0
hey guys

thanks for taking the time to reply;

johneb47 - I think i might have gotten lucky here, I was able to compile the kernel and boot successfully

wartstew - I have 2 st-251 drives to start with (RLL 40 meg, MFM 32 meg), their old-ish. I wanted to get the old Wd 20 going, its like 2 5 & 1/4 bays ... and only 20 megs, and much older. I just thought it would be a cool testiment to their design to run them on the logging side, where the snort logs and other various logs are kept. One is handling smaller logs, and the other is being used for squid cache.. of all of 17 megs ( other 17 meg is being used in I-nodes, because we are using ext2 for the bad sector managment here ! ) Anyways to the point

I took the .config file off the slackware 8.1 cd from the xt directory, and used that to recompile my kernel on my box... (compile kak'd at SMP not defined, so I flipped it on, its a dual P3 box anyways).. and I was re checking through everything and it appears I messed up with the addressing. checked in debug at C8000 and CA000, and the string was found at CA000, and I took a peak in the source code
vola:

switch (address) {
case 0x00000:
case 0xC8000:
break; /*initial: 0x320 */
case 0xCA000:
xd_iobase = 0x324;
case 0xD0000: /*5150CX*/
case 0xD8000:
break; /*5150CX & 5150XL*/
default:

xd_iobase=0x324 ... smooth real smooth, before I was using 0x320. I think exams have fried my brain.

If anyone wants jumper configs for the old crtlrs or hdd's see:
http://artofhacking.com/th99/

Anyways on boot I still had problems, so I issues a reserved in the kernel boot params; Here is my append statement which got this all going

Kernel command line: auto BOOT_IMAGE=new ro root=304 no-scroll panic=30 xd=4,5,0x324,3 reserve=0x324 xd_geo=939,4,17,939

Without using the "xd=" I would just get out of memory error. Without specifying the xd_geo I would just get a smaller 20 meg hard drive, seems to default to 615c, 4heads, 17 sectors. Theres a proggie on driverworld.com or whatever called diskman.zip which has dm.exe that will preformat the drive to whatever ... helps ! (If I didn't spec these right the entire 2nd half of the drive would just be bad block with tonnes of trash like:

end_request: I/O error, dev 0d:01 (xt disk), sector 63716
xda: reading - command error, code = 0x1 - CHS = 612/3/18
xda: reading - command error, code = 0x1 - CHS = 612/3/18
xda: reading - command error, code = 0x1 - CHS = 612/3/18
xda: reading - command error, code = 0x1 - CHS = 612/3/18
end_request: I/O error, dev 0d:01 (xt disk), sector 63718
xda: reading - command error, code = 0x1 - CHS = 612/3/12
xda: reading - command error, code = 0x1 - CHS = 612/3/12
xda: reading - command error, code = 0x1 - CHS = 612/3/12
xda: reading - command error, code = 0x1 - CHS = 612/3/12

.. so if your going to do this make sure you preformat it right!)

Anyways after all this jazz,


Detected a Western Dig. 1002-27X controller (type 4) at address 000000
Detected 2 hard drives (using IRQ5 & DMA3)
xda: CHS=939/4/17
xdb: CHS=939/4/17
Partition check:
xda: xda1
xdb: xdb1

mounted:

/dev/xdb1 30M 19M 10M 64% /var/squid/cache
/dev/xda1 30M 14M 14M 48% /xda


Only annoying thing is it STILL says address 000000 ... at this point im like meh. However maybe its attributed to my next problem. The drives seem to only write ONE at a time, and while one is writing the other one cannot be access'd. I may have to re think my logging, as the squid, believe it or not seems to load down that one hard drive pretty good with a few people browsing. The funny thing is .. when you write to the drive the handle is like yup thats good, and does nothing. Its not until you request that file does it do the write and then read it back... very annoying and taxing . Have to get around that, other than that next small bug, its working good.

Its pretty neat to hear them going, I am really curious to see how long the drive will last. They were designed to last 5 years from production. These are 1988, week 16 and 24. I know their duty cycle wasn't that high during their time of use, but it sure is now! Im guessing they will still continue to hold up considering their 19 years old already, and they have a lot of power on hours (brown circuit board by power connector)

Anyways guys let me know if you have any ideas about forcing a write instantly instead of delayed!

Cheers,

JC

Last edited by jc179; 04-17-2007 at 10:30 AM.
 
Old 04-17-2007, 02:56 PM   #5
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,775

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Using the 'sync' option in your fstab should cause the writes to be done -make sure you use a file system that supports it.

Slackware-8.1 was maybe the best and most trouble free release ever -closely followed by 9.1. I wish the following releases would come closer to that level -If only Pat would forget about the timed-release cycle and be a little more like Debian and release when it's right -not when its' time. There is no way that a very small team can keep up with current changes across a few hundred packages, especially when they are not functionally stable or have constant API changes. Keeping up with Kernel-2.6, gcc and glibc alone are bad enough -much less the rest of the software. Where's time for doing distro-specific stuff? Pat doesn't even have time to recompile all the packages for a given release. Do you realize that there are packages in current that were created for Slack-8.1 and have never been touched again?
 
Old 04-17-2007, 03:24 PM   #6
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Original Poster
Rep: Reputation: 0
Hey

Thanks for the reply. Im currently not mounting these things by fstab, as if the power goes out and It restarts, it takes ~ 10 minutes for e2fs to check them, their that slow..lol. Can I change anything in proc or in my mount command ?

... I started using slackware 8.0 years ago one a P1 200 mhz mmx machine, that was where all this learning started. That release had been running for years, and I had never had an issue with it. I know what you mean by meeting the time period for releases, I can see small boo-boo's every now and then... I think slackware is one of the distributions that should be exempt from that in the communities pov, as it has always in my mind been one of the most reliable releases. I do find that my only problem is not having a package tool like apt-get, emerge, yum, to pull packages off the internet, I hate spending hours and hours (well maybe thats a bit much) installing simple apps. LOL.


JC
 
Old 04-19-2007, 04:32 PM   #7
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Original Poster
Rep: Reputation: 0
So I had some more time to waste, and got it going.

I decided Async wasn't the way to go, as the amount of info being written is so small it gets cached, and when its requested, then it is written to the drive, and read back. Not good when your peak read rate is 1.3 megabytes/min! AH. lol. I could do a sync in the crontab every minute, but I just mounted them sync (yes I know sync will write slower..but atleast its consistent) like you suggested. Anyhow works good. No more lagging now.

If anyone else using these drives, the 8bit MFM controllers are much easier to setup than the 16 bit isa ones. The 8 bit you can load a module at the address and it goes. The 16 bit AT version, you need to set the user type hdd in bios, disable one of your ide controllers, blah blah blah , a pita.

For now they are formatted MFM, maybe ill try RLL if I find a card, but for now its working great. Now to see how long they last!

/dev/xdb1 30M 5.2M 23M 18% /var/squid/cache
/dev/xda1 30M 9.9M 18M 35% /xda

Last edited by jc179; 04-19-2007 at 04:35 PM.
 
Old 04-20-2007, 10:28 PM   #8
wartstew
Member
 
Registered: Apr 2002
Location: Albuquerque, NM USA
Distribution: Slackware, Ubuntu, Debian, Maemo
Posts: 464

Rep: Reputation: 30
Thanks for clearing up all the bad assumptions I made about your hardware. I assumed that since you had old drives and controller, you must also have an old computer (Yea, I know most people consider a P3 and old computer, but I'm actually using an old P3 family (Overclocked Celeron 600E at 900Mhz) machine right now. Anyway, obviously SMP makes since for your hardware, and you probably have enough RAM, or at least the machine can take it as opposed to a 368 or 486 based machine.

Quote:
The drives seem to only write ONE at a time, and while one is writing the other one cannot be access'd.
Yes this it the way the master/slave arrangement of these controllers worked. To save cost one controller would could control two drives because in their day these controllers cost about $200 USD each. The controller would switch back and forth between the drives channeling the raw drive data through a single data separator that existed on the controller. The dreadful thing is that IDE drives emulated this behavior when in the master/slave combination even though they really didn't have to since the entire servo systems and data separators were on the drive (hence it name [I]ntegrated [D]rive [E]lectronics). This is why to do drive arrays in those days, you needed to go with SCSI.

Quote:
when you write to the drive the handle is like yup thats good, and does nothing. Its not until you request that file does it do the write and then read it back... very annoying and taxing.
I think there is some way to tell the kernel to do sync tranfers, probably something you send to the VFS layer in /proc or something, but I don't think you want to do it. The fact that it isn't writing the data in a timely fashioned probably says the drive really isn't keeping up, and going to sync mode will probably bring your system to a halt, or at least slow it to a crawl as everything else will wait for that drive to write its data.

I can't remember what kind of data rate these drives were capable of, probably only about 1 MB/s or less, but some of the bottle-neck could be in the controller and ISA bus itself. That old thing is certainly doing PIO transfers (which should be slowing your whole system down quite a bit all by itself, another reason SCSI was the way to go: an AHA1542 was the hot thing to have), but then there is that slow 8-Mhz 16-bit ISA bus. On many machines in those days I was able to greatly improve performance by cranking up the speed of that bus to 12, 16 or even 20 Mhz by tweaking that ISA/PCI clock divider in the BIOS. I actually had an ISA-only 40 Mhz 386 system running Windows NT4-server that could actually play those sample AVI video files that came with Windows-95 smoothly to an ISA Trident TGA9000 video card and original Soundblaster) by speeding that bus up to 20 Mhz. Anyway, you might try the same. If you go too far the machine will start having random lockups, which of course Linux doesn't normally do, so you'll know what the problem is. I'll bet you could get at least 12-16 Mhz out of it and that might speed up your drive subsystem a little bit.

Another idea is to try to plug another MFM controller in that system jumpered to a different address and IRQ and run the second drive from there. Knowing Linux, it will probably work even though you weren't suppose to be able to run two MFM controllers in a machine. The BIOS won't support it, but who cares, you aren't trying to boot on them anyway.

[QUOTE]Its pretty neat to hear them going, I am really curious to see how long the drive will last. They were designed to last 5 years from production. These are 1988, week 16 and 24. I know their duty cycle wasn't that high during their time of use, but it sure is now! Im guessing they will still continue to hold up considering their 19 years old already, and they have a lot of power on hours (brown circuit board by power connector)[\QUOTE]

At the age of those things, I would expect that you would start seeing failures of electrolytic capacitors on the circuit board. ... I just remembered I actually still have an ST-251, I wonder if it works? ... Anyway I just pulled it out of a box and I can't see any of those, but they might be hidden under the circuit board somewhere. The lack of them may be one reason the drive is still running.

Oh all the bad memories of manually entering those bad track numbers, Low-level formatting, drive terminations, RLL compatibility issues, and all those ribbon cables (two per drive). SATA is sure nice in comparison!
 
Old 04-20-2007, 11:27 PM   #9
wartstew
Member
 
Registered: Apr 2002
Location: Albuquerque, NM USA
Distribution: Slackware, Ubuntu, Debian, Maemo
Posts: 464

Rep: Reputation: 30
Somehow I missed this last post before I did my previous lengthy one. Oh well ...

Quote:
Originally Posted by jc179
So I had some more time to waste, and got it going.

I decided Async wasn't the way to go [...] [the] peak read rate is 1.3 megabytes/min!
Hmmm. That seems too slow, maybe some of the suggestions in my last post might work after all.

Quote:
(yes I know sync will write slower..)
The actual writing isn't slower, in fact it may be faster, it's just that is slows your host process way down as it has to wait until completion.

Quote:
... the 8bit MFM controllers are much easier to setup than the 16 bit isa ones. The 8 bit you can load a module at the address and it goes. The 16 bit AT version, you need to set the user type hdd in bios, disable one of your ide controllers, blah blah blah , a pita.
Yea but 8-bits is 8-bits instead of 16 and slows things down even more. Your bus may actually be slower than the drive. I never liked the AT BIOS drive support either. I liked the geekiness of jumping to ROM addresses in the 8-bit XT controller using MSDOS debug and running the low level formatter from there. It seemed like it worked better anyway.

Quote:
For now they are formatted MFM, maybe ill try RLL if I find a card
RLL will speed things up 50% because you get 50% more useful data out of the raw stream. The controllers are rare, I had an old Adaptec 8-bit one that worked great, but then upgraded to a higher preforming 16-bit Perstor ARRL controller that was very tempermental and I wouldn't wish it on anyone (actually I think the last version they ever made was probably okay). Omti made one that I think was pretty good but I never had one. I think Western Digital did make one for a short while but that was about when the whole industry got fed up with the whole separate drive + controller idea with all of its problems and went IDE where they could do all this RLL plus variable sector/track and other magic tricks then hide it all from all of us with virtual addressing.

Quote:
but for now its working great.
Which is unbelievable enough to make it worth bragging about!

Quote:
we'll see how long they last
My experience with these drives is that the failure mode is "creeping bad sectors", or the drive will last as long as you are willing to keep re-formatting it and map out additional bad sectors. You might have some right now, which is why the slow drive performance (lots of retries and re-indexing).

Last edited by wartstew; 04-20-2007 at 11:44 PM.
 
Old 04-21-2007, 05:52 AM   #10
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Original Poster
Rep: Reputation: 0
[QUOTE=wartstew]Somehow I missed this last post before I did my previous lengthy one. Oh well ...

Its all good. you made some good points. Theres a pile of this old stuff at work they were tossing, so Ill see whats there. I have a WD1002-27X and a Wd1004-27x card. Their suppost to be RLL capable, one of them? I also have a 16 bit 1006 WD card. But its such a pain to make work I said meh. The drives are slow, but they dont need to be fast for what im doing with them ... I think you've got the idea right, I could use the wd1002 on one drive, and the wd1004 on another drive and get more speed that way. I've only had one bad sector creep up on me so far, and its ext2 so I was able to use fsck to get rid of it. I did a similar test with ext3, and it did not reallocate to another sector and mark that one as bad. I could have done something wrong, it was late .


Hmmm. That seems too slow, maybe some of the suggestions in my last post might work after all.

Yes I think so too, at 5 Mbits /sec .. I think thats what their rated for?
you'd end up with 625k / second, or 37.5 meg an hour (approx). I will try fiddling with the motherboard, but It doesn't seem apparent there are options for ISA tuning. Its an ASUS p2b with the onboard scsi which as 3 drives on it as well. Im also using the SUN QFE 4x100 port nics (2 of them). I also run vmware on it..lol. Its a dual 450 with 1 gig of ram, for now the logging doesn't seem to hang it up, but can I change the ISA clock w/o messing up the 33 mhz pci ? If so yes lets do it. !




So lets see to speed things up a bit for now, without adjusting the clock ? Any ideas why they are going so slow. Same speeds on the Wd1002 and Wd1004 card here. Would like to get them going faster in mfm for now .. if you have any more ideas or things to check ? Is the transfer io 5 mhz ?




Quote:
The actual writing isn't slower, in fact it may be faster, it's just that is slows your host process way down as it has to wait until completion.
... Async seemed to write constantly to the drive, no real seeking back and forth. When I did sync the drive head was constantly going back and forth, very audiable, and noisy, but sounded cool.

Quote:
Yea but 8-bits is 8-bits instead of 16 and slows things down even more. Your bus may actually be slower than the drive. I never liked the AT BIOS drive support either. I liked the geekiness of jumping to ROM addresses in the 8-bit XT controller using MSDOS debug and running the low level formatter from there. It seemed like it worked better anyway.
If I can get the actual speed out of it ill be really happy with 8bit speed I think. . .


Quote:
RLL will speed things up 50% because you get 50% more useful data out of the raw stream. The controllers are rare, I had an old Adaptec 8-bit one that worked great, but then upgraded to a higher preforming 16-bit Perstor ARRL controller that was very tempermental and I wouldn't wish it on anyone (actually I think the last version they ever made was probably okay). Omti made one that I think was pretty good but I never had one. I think Western Digital did make one for a short while but that was about when the whole industry got fed up with the whole separate drive + controller idea with all of its problems and went IDE where they could do all this RLL plus variable sector/track and other magic tricks then hide it all from all of us with virtual addressing.
Scsi can still be a pita too . I have weird problems on another system with the adaptec pm1554 card and drives not appearing all the time. Attach them to the ibm serveraid card, perfect. All Se/LVD drives and term.

Quote:
Which is unbelievable enough to make it worth bragging about!
It is cool !

Quote:
My experience with these drives is that the failure mode is "creeping bad sectors", or the drive will last as long as you are willing to keep re-formatting it and map out additional bad sectors. You might have some right now, which is why the slow drive performance (lots of retries and re-indexing).
So far just one boo boo , but im sure more are to come, its not like the info on them is anything critical .. It can be tolerated if its lost . Besides I can rsync it or cp it somewhere else too ... maybe look into syslog send to another machine!

Thanks for all the info

Jonathan
 
Old 04-21-2007, 03:53 PM   #11
wartstew
Member
 
Registered: Apr 2002
Location: Albuquerque, NM USA
Distribution: Slackware, Ubuntu, Debian, Maemo
Posts: 464

Rep: Reputation: 30
Quote:
Originally Posted by jc179
I have a WD1002-27X and a Wd1004-27x card. Their suppost to be RLL capable, one of them?
Yes that "27X" suffix probably means 2-7 mode [R]un [L]ength [L]imited.
Note that those ST-drives weren't rated for RLL use, but I always ignored that and found only a few drives that I couldn't get to run on my RLL controllers, Seagates seemed to aways work for me.

Quote:
I've only had one bad sector creep up on me so far, and its ext2 so I was able to use fsck to get rid of it. I did a similar test with ext3, and it did not reallocate to another sector and mark that one as bad. I could have done something wrong, it was late .
I think when fsck sees an ext3 filesystem it just checks if the journal file appears valid and moves on. To really check it, I end up converting it back to ext2 using "tune2fs ^hasjournal ..." command, running fsck, then converting it back to ext3 using tune2fs again. With Slack 8.1, you are dealing with early versions of ext3 and associated utils, so things might be a little different.

Quote:
I change the ISA clock w/o messing up the 33 mhz pci ? If so yes lets do it. !
If you have some sort of PCI to ISA divider option you can. All it did was derive the ISA speed from the 33Mhz PCI clock by dividing it down. Typical defaults were "4" or 33/4 = 8.25 Mhz but usually at least "3" was an option for 33/3 = 11 Mhz. Sometimes the numbers were doubled, but were derived from 66 Mhz instead. With newer motherboards ISA began being abandoned so I stopped seeing tuning options in BIOS. This does not mean that these options are not possible. There are 3rd party programs available that know how to reprogram these things on some BIOSes, I'm not sure what can be done with Linux, but there is a Linux program called powertweak that can do a lot of stuff.

Quote:
So lets see to speed things up a bit for now, without adjusting the clock ? Any ideas why they are going so slow. Same speeds on the Wd1002 and Wd1004 card here.
You might also want to make sure there wasn't a "wait state" enabled on the controller via some jumper somewhere. A lot of cards back then were shipped default with very conservative settings to avoid compatibility problems with all the flakey hardware that was around in those days.

Quote:
Is the transfer io 5 mhz ?
I don't know. Actually I really don't know as much about these old controllers as I've probably lead you to believe. Mostly I'm glad they're in my past. I once had 2 ST-251's (2x40Megs) on my Perstor controller (which made them 2x80=160 Megs) then ran software compression on the drives averaging 2:1 (2X160=320 Megs), and put up with this mess for several years before breaking down an buying a brand new 320 Meg WD IDE drive (for about $400 USD) that I thought was the most wonderful thing in comparison.

Quote:
Scsi can still be a pita too . I have weird problems on another system with the adaptec pm1554 card and drives not appearing all the time. Attach them to the ibm serveraid card, perfect. All Se/LVD drives and term.
Yes, it seemed the longer you made those SCSI cables and the more devices you hung on it, the more unstable things became. Sometimes I had to add extra termination in places or remove some where they were suppose to go (on the ends). I had most problems with any kind of external drives. They should work better if you can get them all running LVD mode and not SE mode. There is a huge difference in signal-to-noise quality running LV[D]ifferiential verses just running [S]ingle [E]nded. I don't know anything about the PM1554 but maybe it only does SE verses the IBM that might be LVD (?)

Quote:
So far just one boo boo , but im sure more are to come, its not like the info on them is anything critical .. It can be tolerated if its lost . Besides I can rsync it or cp it somewhere else too ... maybe look into syslog send to another machine!
Yes I agree this is one place where old unreliable drives make sense (well not really, but of course I understand this is more of a hobby and curiosity project for you).
 
Old 04-24-2007, 05:31 AM   #12
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Original Poster
Rep: Reputation: 0
Hey

thanks for the info. I haven't had much luck yet, I don't have an such adjustments, but I think I can kick the fsb forward and see how everything goes. The 440BX was pretty easy going for that, and as long as the nic cards stay working, everything is good. Experienc with these drives is what counts !

I did manage to find a copy of the spinrite app, but Im not sure its going to accomplish what I need, since it only will deal with fat file systems.. and make changes to those, it wouldn't even let me select the drive if it didn't have a FAT. So im going to see how else I can set the interleave .... Im thinking thats the problem, atleast for now.

Not much documentation of getting these setup in linux .. perhaps there was never any controls to adjust the interleave.. although that should be set when its preformattted from what I gather? In that case the adjustment made in the debug G=C800:5 should have made the correct change. Is there an equavilient command to msdos debug that I can run from within linux without emulating msdos ? Have to see

Will keep you guys upto date... should anyone else be bothered in doing this

Cheers,

JC
 
Old 04-24-2007, 03:55 PM   #13
wartstew
Member
 
Registered: Apr 2002
Location: Albuquerque, NM USA
Distribution: Slackware, Ubuntu, Debian, Maemo
Posts: 464

Rep: Reputation: 30
Quote:
Originally Posted by jc179
... but I think I can kick the fsb forward and see how everything goes. The 440BX was pretty easy going for that, and as long as the nic cards stay working, everything is good.
I'm not completely sure the PCI clock is tied to the FSB clock, on the BX440 but I could be wrong. I've always liked BX440 MB's and typically OC Celerons to whatever by going 66Mhz FSB to 100Mhz. I've haven't played much with going above 100Mhz, Although I remember running something at 112Mhz. Anyway, it sounds like you might be stuck on the ISA bus speed. This might not be as bad as I first thought. Back in the ISA-only days that bus was shared with video, sound, other I/O and whatever. with only a controller (or two) on it, maybe it will be fast enough to not be the bottle neck, at your current speed of thing I don't think it is.

Quote:
I did manage to find a copy of the spinrite app, but ... didn't have a FAT. So im going to see how else I can set the interleave .... Im thinking thats the problem, at least for now.
Oh yes, I forgot all about interleave. (Things were really horrible back in those days!) You need to check to see what interleave the controller is capable of. The drive can do what ever, it was just that some controllers could not keep up with all of its housekeeping while reading adjacent sectors.

Quote:
Not much documentation of getting these setup in linux .. perhaps there was never any controls to adjust the interleave.. although that should be set when its preformattted from what I gather?
It's really not an OS thing. It is internal to the drive and the controller and set during the low level format.

Quote:
In that case the adjustment made in the debug G=C800:5 should have made the correct change.
Yes, exactly. When you do the low-level format.

Quote:
Is there an equavilient command to msdos debug that I can run from within linux without emulating msdos? Have to see
I don't think you have to worry about it once it is low-level formatted. From that point on, the drive sectors are accessed in the order depending on where the interleave is set, regardless of what OS or other programs are trying to access it. So if you already low-level formatted the drive with the lowest ratio that the controller can do for optimum speed, then you are done worrying about interleave. 1:1 is ideal. Spinrite can help determine the optimum interleave, just put a FAT format on it for awhile and let it run it's test. Spinrite should also give you an idea of what speed you can get from your hardware combination before Linux gets a hold of it. That should help you determine if it is a Linux problem or not.

If I'm wrong, then look for an interleave setting with the Linux driver, In this case it is up to the OS to tell the controller to access the drive sectors in the specified order for best speed. After all, those early controllers weren't very smart.

BTW: that g=c800:5 debug stuff is simply running a little assembly language program that exists in the controller's ROM at that address. The program runs in the processor "Real Mode" which is not allowed in Linux, but maybe it will run in the DOSEMU emulator with settings to allow access to the ROM, and perhaps some old BIOS interrupt vectors. I kind of doubt it however.

Quote:
Will keep you guys upto date... should anyone else be bothered in doing this
You'll probably be the only one in this century!
 
Old 04-25-2007, 09:04 AM   #14
jc179
LQ Newbie
 
Registered: Apr 2007
Location: Ontario, Canada
Distribution: Gentoo, slackware
Posts: 15

Original Poster
Rep: Reputation: 0
Hey

thanks for all the help. I tried setting the interleave to 1:1, didn't change a thing in terms of transfer speed, so I suppose their already maxed out or as you say the card won't take it. I'm not gonna fiddle too much more ill just leave it going as is

Cheers,

Jonathan
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
need to recompile kernel to support this hardware? mrjshum Debian 5 12-25-2005 04:39 AM
recompile kernel for hfs support peok Linux - Software 5 10-20-2004 09:42 PM
Recompile of Kernel, Slack 10: i've lost device support sganarelle Slackware 2 08-14-2004 07:48 AM
No sound support after kernel recompile abu_a_m Red Hat 1 02-10-2004 11:06 AM
slack kernel recompile Goatdemon Slackware 11 08-20-2002 05:41 AM


All times are GMT -5. The time now is 02:32 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration