Fwd: Re: ATA problems with FreeBSD (was Revisiting the semirandom bug/issue in FreeBSD's ATA querying)
--- "James J. Ramsey" <[EMAIL PROTECTED]> wrote: > Date: Tue, 28 Jan 2003 12:23:38 -0800 (PST) > From: "James J. Ramsey" <[EMAIL PROTECTED]> > Subject: Re: Revisiting the semirandom bug/issue in > FreeBSD's ATA querying > To: [EMAIL PROTECTED] > CC: [EMAIL PROTECTED] > > --- "Wojciech S. Czarnecki" <[EMAIL PROTECTED]> wrote: > > James J. Ramsey wrote: > > [on Thu, Jan 23, 2003 at 05:01:05PM -0800] > > (>) Owego dnia James J. Ramsey napisa³(a): > > > ad0: 883634010175MB > > > > > > [16955114026566160/17/63] at ata0-master PIO4 > > Check cables twice. > > For the test: change cable to ATA33 (40wire) > cable. > > I did this and could not get FreeBSD to fail. The > kernel messages were nice and healthy-looking: > > ad0: DMA limited to UDMA33, non-ATA66 cable or > device > ad0: 19595MB > [39813/16/63] > at ata0-master UDMA33 > > (The hard drive was primary master, and my CD-ROM > primary slave.) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: ATA problems with FreeBSD (was Revisiting the semirandom bug/issue in FreeBSD's ATA querying)
Quoting "James J. Ramsey" <[EMAIL PROTECTED]>: > > --- "Gary W. Swearingen" <[EMAIL PROTECTED]> wrote: > > I can't even guess what the problem might be, but > > can you (or do you not > > want to) work around it? > > If you read my e-mail again, you should find this: > > "In the second setup, I scrounged up an ATA cable that > I knew could handle ATA66. I used this newer cable to > attach the hard drive to the motherboard, and I used > the old cable to attach the CD-ROM to the motherboard > as a secondary master. (The jumper for the CD-ROM was > moved accordingly.) In this setup, the ATA querying > problem went away, or at the very least, I could not to be honest with you, I have ran Maxtor ATA/100 (same as promise, just has the label that says "maxtor") and a promise ata/66 controller without any problems at all; however, I have noticed those cards causing weird problems from time to time. - This mail sent through IMP: http://horde.org/imp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: ATA problems with FreeBSD (was Revisiting the semirandom bug/issue in FreeBSD's ATA querying)
--- "Gary W. Swearingen" <[EMAIL PROTECTED]> wrote: > I can't even guess what the problem might be, but > can you (or do you not > want to) work around it? If you read my e-mail again, you should find this: "In the second setup, I scrounged up an ATA cable that I knew could handle ATA66. I used this newer cable to attach the hard drive to the motherboard, and I used the old cable to attach the CD-ROM to the motherboard as a secondary master. (The jumper for the CD-ROM was moved accordingly.) In this setup, the ATA querying problem went away, or at the very least, I could not reproduce it (and I tried to, several times)." So yes, I most definitely can work around the problem, by making my CD-ROM a secondary master rather than a primary slave. Sorry if I wasn't clear about that. Whether I want to simply work around the problem is another matter. I'd rather find out the cause of the problem before working around it. I don't want to do some voodoo that just happens to make FreeBSD work only to find that something I do later (i.e. add a hard drive, change the CD-ROM) undoes the voodoo and causes things to mysteriously fail again. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: ATA problems with FreeBSD (was Revisiting the semirandom bug/issue in FreeBSD's ATA querying)
A hard problem you got there. If at least one other OS doesn't have a problem with your hardware, then I think you're safe in assuming that there's an OS kernel problem, whether by design or coding bug. Theoretically, it should be reported in a formal PR where it won't get lost, especially if you strike out on freebsd-bugs. (I was about to suggest that you take it to freebsd-current and/or freebsd-stable, like I do with such problems, but on second thought, it seems like that is what freebsd-bugs is for and -current & -stable should probably be reserved for other things. Nobody's complained, but I seldom get a satisfactory resolution to tough problems like this; usually I wind up with different hardware or software. Hmmm.) I can't even guess what the problem might be, but can you (or do you not want to) work around it? Maybe I missed something, but doesn't FreeBSD let you specify geometry when it matters. It usually just uses sector numbers and it gets the size of the disks out of the disk labels. Maybe that's true only when not using slices and a boot loader. For that, you need a boot loader that can deal with your hardware, but that shouldn't be hard, even if you can't use FreeBSD's. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
ATA problems with FreeBSD (was Revisiting the semirandom bug/issue in FreeBSD's ATA querying)
[The following was originally posted by me to the FreeBSD bugs list when I was a lot surer that I was dealing with a FreeBSD bug. Now I'm not sure sure if this is a software bug, hardware bug, or a consequence of dubious design decisions. Hence the cross-post to here.] I've been doing my best to sort out the issues with the bug, issue, or whatever that FreeBSD has with identifying my hard drive. The following is mostly a summarizing of previous posts, plus some tidbits of new stuff. Background: I had been trying to switch from Linux to FreeBSD; however, the last time I tried, FreeBSD couldn't get the disk geometry correct; the cylinder count from FreeBSD was wildly inflated and inconsistent from install attempt to install attempt. This was for version 4.5 of FreeBSD. When I posted to comp.unix.bsd.freebsd.misc asking if FreeBSD 4.7 had the same problem, someone suggested that I attempt an install from boot floppies, and if there is still a problem, abort before committing to the install. Ever since then, I've been experimenting with the boot floppies, trying to see if I could find ways of either making the problem disappear or diagnosing it. My hardware: IDE drives are the following: * QUANTUM FIREBALLP LM20.5, ATA DISK drive * Pioneer CD-ROM ATAPI Model DR-A04S 0105, ATAPI CD/DVD-ROM drive The hard drive is primary master, and the CD-ROM the primary slave. Whether the CD-ROM acts as a master or slave depends on a jumper setting. My motherboard is an iWill KA266plus. When I first starting dealing with the problem, the BIOS was the original one installed by the manufacturer, but it has recently been upgraded. The southbridge is a ALi M1535D+ chipset. Symptoms: Almost every time I attempt to install FreeBSD, it complains that the disk geometry is bad, reporting a wildly inflated cylinder count that changes from install attempt to install attempt. A few times, FreeBSD reads the cylinder count correctly, but upon the next install attempt, the inflated count is back. This has been true for FreeBSD versions 4.5, 4.7, and 5.0-RC2. The following kernel message is from a FreeBSD install. I captured it by pressing Scroll Lock and pressing the Page Up key to get to the text: ad0: 883634010175MB [16955114026566160/17/63] at ata0-master PIO4 The garbage between the angle brackets should be the name of the hard drive, "QUANTUM FIREBALLP". Compare this with the kernel message from Linux: hda: QUANTUM FIREBALLP LM20.5, ATA DISK drive The name of the disk drive is reported correctly. This hard drive querying problem has never occured under Linux, Windows XP, or an OpenBSD 3.1 snapshot, although the last one had other problems, namely lack of stability, which was to be expected. (I do not have Windows XP anymore.) The problem seems consistent for both the original and upgraded BIOS. Setting the BIOS to explicitly use LBA disk geometry rather that relying on the automatic BIOS setting seems to make no difference either. However, the problem appears to go away when I make the CD-ROM into a secondary master rather than a primary slave. I've experimented with a couple variants of the master/slave setup. In the first and original setup, the hard drive was the master, and the CD-ROM the slave. I used an IDE cable from I-do-not-remember-where, and at the time I neither knew nor cared whether it could handle ATA66. This was the setup under which the problem first showed up. In the second setup, I scrounged up an ATA cable that I knew could handle ATA66. I used this newer cable to attach the hard drive to the motherboard, and I used the old cable to attach the CD-ROM to the motherboard as a secondary master. (The jumper for the CD-ROM was moved accordingly.) In this setup, the ATA querying problem went away, or at the very least, I could not reproduce it (and I tried to, several times). Instead I got the following healthy-looking kernel message: ad0: 19595MB [39813/16/63] at ata0-master UDMA66 The third setup was just like the first, only I switched IDE cables. The old cable was used to connect the hard drive to the motherboard, while the newer one was used to connect the CD-ROM to the motherboard. I could not reproduce the problem under this setup either, it was just as it was with the second setup. The fourth setup was like the first. The CD-ROM returned to being a primary slave (and the jumper was set accordingly). However, I used the newer IDE cable rather than the old one. The problems from the first setup returned. David Schultz (from the FreeBSD bugs mailing list) has the same make and model of hard drive as I, yet has not been able to reproduce my problem even after duplicating my master/slave setup. To quote him: > I have used the drive with the integrated IDE > controllers on an > ASUS P2B-F motherboard (440BX-based, ATA33) and an > ASUS P3V4X > (VIA 82C596 ATA66 controller), as well as with a > Promise Ultra66 > card. A subset of those controllers have been used > with the drive > in both
