Date: Tue, 26 Nov 2002 00:29:40 -0800 From: "Ronald F. Guilmette" <rfg@monkeys.com> To: freebsd-scsi@freebsd.org Subject: Upgrade from Adaptec 2940UW to 29160N - Problem solved! Message-ID: <83843.1038299380@monkeys.com>
next in thread | raw e-mail | index | archive | help
[[ I just posted the article below to comp.periphs.scsi, but I felt that it might be appropriate to post it to freebsd-scsi also. So here it is. ]] =================== I just wanted to post a short report here on a problem that caused me some considerable grief recently, and then describe what the final resolution was, in the hopes of saving someone else from the same grief. (If you read this message and it helps you, please do drop me a short ``thank you'' e-mail.) The story... Not long ago, I got this swell idea to switch to a SCSI hard drive (from IDE) in my primary x86 system. The prices on all types of equipment have come down a lot (since the tech bubble burst) and it seemed like a good time to go for it. The access times were irresistible. So I bought myself an IBM 18GB 10,000 RPM Ultra160 drive off eBay (for a song) and I was ready to go. Well, not quite. Initially, I attached the thing with an old Adaptec 2940UW controller I had lying around, partitioned it, and installed FreeBSD. All was well until I decided that it might be nice to get a nice super-fast SCSI controller to go with that super-fast drive. So I bought a used Adaptec 29160N (Ultra160) off eBay, swapped out the old 2940UW and swapped in the 29160N. No go. Now the FreeBSD BootManager refused to boot from my one and only partition on the drive. It would just prompt me enticingly with that "F1" prompt but then just beep whenever I tried to hit return or the F1 key. Bummer. At first I figured that I might have bought a bad controller, but I ruled that out by booting instead off an old IDE drive that had FreeBSD installed. Once booted, I was able to mount the FreeBSD partition on the IBM SCSI drive, even though it was still connected to the system via the (suspect) 29160N controller. Obviously, the 29160N controller was just fine, and so was the IBM drive. I tried sticking the 29160N controller and the IBM drive in a different system with a different motherboard. No go. Same problem. The FreeBSD BootManager would load, but then it would beep and refused to boot my bootable FreeBSD partition that was already present on the drive. I believe that I now understand what the problem was. I knew, based on past (bad) experience, that when the FreeBSD Boot Manager beeps at one and refuses to boot some partition that one believes is perfectly bootable, it is almost always due to a ``geometry'' problem, which is to say that one has screwed up, and that one has failed to properly partition the drive such that the partition one is attempting to boot resides entirely within the first 1024 (logical) cylinders of the drive. (For those who don't already know, this is an obscure but annoying limitation of older motherboard BIOSes... they require that your boot partition resides within what the BIOS itself thinks of as the first 1024 cylinders of your drive. This is covered very well at http://www.win.tue.nl/~aeb/linux/Large-Disk-4.html. Accord- ing to this web page... part of the well written Linux Large Disk HOWTO... newer motherboard BIOSes don't have this silly restriction, but older ones, like the two I was using... an ASUS P5A and a FIC VA-503A... have older BIOSes in which this limit is still present.) Anyway, after alternatively scratching by head and another part of my anatomy for awhile, and after running the FreeBSD fdisk program on the IBM drive, I realized that the partition that I was attempting to boot from was most definitely _not_ contained within the first 1024 logical cylinders of the drive. I backed everything up, repartitioned the drive so that my boot par- tition was in fact wholly within the first 1024 logical cylinders, and then reinstalled FreeBSD on that partition and viola! Everything is now hunky dory with my new 29160N controller happily booting from the IBM 18GB Ultra160 10K RPM drive on my clunky old ASUS P5A mother- board (with its highly stale/archaic Award BIOS). The only mystery that still remains after this whole ordeal is ``Why was it possible to boot from the mis-allocated partition back when I was using the Adaptec 2940UW, even though it was clearly _not_ possible to boot from the exact same bleedin' partition when using a newer and ``more advanced'' Adaptec 29160N ? I have no answer, at present, for this mystery, and I can only attribute it to either sunspots or gremlins. By all rights, I really should not have been able to boot that partition (which was _not_ contained within the first 1024 cylinders) no matter what SCSI controller I was using, because my motherboard BIOS just wasn't up to the task. But for some strange reason, it worked anyway... a perplexing fact that I still can't explain. (If anybody has any theories about what the 2940UW would boot that partition, even when it seems that it should not have been able to do so, I'm all ears.) Anyway, I just wanted to write up my experiences with all this, and post them, in the hopes of maybe helping somebody else to avoid being totally perplexed, as I was, when upgrading from an Adaptec 2940UW to an Adaptec 29160N or (29160 or 29160LC). If you perform such an upgrade, and if a formerly bootable partition will no longer boot, don't blame your new 29160 controller. Check your partitioning first... especially if the motherboard you're using was manufactured prior to, say, 1999. Regards, rfg P.S. Oh yea, and one more thing... Part of the reason that my boot partition _wasn't_ fully contained within the first 1024 logical cylinders of the drive in question was because the geometry of the drive itself was kinda snafued. And that was partly my fault. As described in http://www.win.tue.nl/~aeb/linux/Large-Disk.html, these days, the whole notion of ``drive geometry'' is pretty much just a fantasy that is nowadays preserved only for the convenience of backwards compatibility. The ``drive geometry'' can be set in multiple different ways, at different times, by software, for the same single physical drive. And how the (logical) geometry gets set is really important, *if* you are dealing with one of these old motherboard BIOSes that only wants to boot from something that's within the first 1024 logical cylinders. In these cases, you want to make sure that the BIOS and (and your Boot Monitor) believe that your drive has 255 heads and 63 sectors per track. You want that because that ``geometry'' maximizes the amount of the disk that you'll be able to put a bootable partition in (thus maximizing your flexibility when it comes to partitioning). Unfortunately, as I learned, on a ``clean'' disk that has just been low-level formatted, and which has _no_ partition information on it (not even an initial MBR + partition table) if you just use the relevant FreeBSD tools to partition such a drive, they will screw up and give you a yucky logical drive geometry that will only allow you VERY little room at the very start of the drive for a bootable parti- tion. Good advice, when partitioning a ``clean'' virgin drive, either with FreeBSD or Linux (where I picked up this trick initially) is to drag out an ancient crusty MS DOS bootable floppy... if you still have one... and use that to place _one_ ``dummy'' MS DOS partition on the drive before using any Linux or FreeBSD partitioning tool on the drive. Doing this seems cause the drive geometry to be set the way we would like it to be set, i.e. to `N' cylinders, 255 heads, and 63 sectors per track. Once that (desired) drive geometry is set, _then_ you can go in with your FreeBSD or Linux partitioning tool, delete the useless MS DOS partition, and then setup your FreeBSD or Linux partitions. Even when you delete the (useless) MS DOS partitioning, the desirable setting for the drive geometry will still stick, and they will be used by your FreeBSD or Linux partitioning tool, just as we would like. P.P.S. I apologize to all of the old hands for whom all of the above is already well know. I posted this message for the (possible) benefit of people for whom some of this info may not be so well known. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83843.1038299380>