Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Sat, 27 Feb 1999 19:20:34 +1100, Bruce Evans wrote: I sent this in for review a year or so ago, but received no reply. The main points are that it honours ATA timing in atapi_wait() and checks for ARS_BUSY in atapi_wait(). I guess we'll need to wait and see whether this is still an issue with Soren's new driver. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Nope, that code snippet is in atapi.c its not in any of the drivers...
(and newer has been).
You're right. Goes to show how long I haven't touched this part of
the code. Alas, just reviewed it out of curiosity. It sure got more
readable... :-) But I still hate those inb loops without DELAY...
There's only one, at least in my version.
I sent this in for review a year or so ago, but received no reply.
The main points are that it honours ATA timing in atapi_wait() and
checks for ARS_BUSY in atapi_wait(). This hopefully makes bogus checks
like the one in rev.1.22 unnecessary (status 0xff has ARS_BSY set so it
is invalid). I haven't tested the PC98 case. I removed PC98 code that
seems to only compensate for bugs in atapi_wait().
Bruce
diff -c2 atapi.c~ atapi.c
*** atapi.c~Sat Feb 27 19:05:47 1999
--- atapi.c Tue Dec 29 01:17:34 1998
***
*** 229,234
*/
if (ata-accel ata-intrcmd) {
! ata-intrcmd = 0;
! ata-slow = 1;
}
--- 229,234
*/
if (ata-accel ata-intrcmd) {
! ata-intrcmd = 0;
! ata-slow = 1;
}
***
*** 399,414
struct atapi_params *ap;
char tb [DEV_BSIZE];
- #ifdef PC98
- int cnt;
- outb(0x432,unit%2);
- print((unit = %d,select %d\n,unit,unit%2));
- #endif
/* Wait for controller not busy. */
- #ifdef PC98
- outb (port + AR_DRIVE, unit / 2 ? ARD_DRIVE1 : ARD_DRIVE0);
- #else
- outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
- #endif
if (atapi_wait (port, 0) 0) {
print ((atapiX.%d at 0x%x: controller busy, status=%b\n,
--- 399,404
***
*** 417,461
}
! /* Issue ATAPI IDENTIFY command. */
#ifdef PC98
! outb (port + AR_DRIVE, unit/2 ? ARD_DRIVE1 : ARD_DRIVE0);
!
! /* Wait for DRQ deassert. */
! for (cnt=2000; cnt0; --cnt)
! if (! (inb (port + AR_STATUS) ARS_DRQ))
! break;
!
! outb (port + AR_COMMAND, ATAPIC_IDENTIFY);
! DELAY(500);
#else
outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
- outb (port + AR_COMMAND, ATAPIC_IDENTIFY);
#endif
! /* Check that device is present. */
! if (inb (port + AR_STATUS) == 0xff) {
! print ((atapiX.%d at 0x%x: no device\n, unit, port));
! if (unit == 1)
! /* Select unit 0. */
! outb (port + AR_DRIVE, ARD_DRIVE0);
return (0);
}
/* Wait for data ready. */
if (atapi_wait (port, ARS_DRQ) != 0) {
print ((atapiX.%d at 0x%x: identify not ready, status=%b\n,
unit, port, inb (port + AR_STATUS), ARS_BITS));
- if (unit == 1)
- /* Select unit 0. */
- outb (port + AR_DRIVE, ARD_DRIVE0);
- return (0);
- }
-
- /* check that DRQ isn't a fake */
- if (inb (port + AR_STATUS) == 0xff) {
- print ((atapiX.%d at 0x%x: no device\n, unit, port));
- if (unit == 1)
- /* Select unit 0. */
- outb (port + AR_DRIVE, ARD_DRIVE0);
return (0);
}
--- 407,434
}
! /* Select the drive. */
#ifdef PC98
! /* XXX what is this? */
! outb(0x432,unit%2);
! print((unit = %d,select %d\n,unit,unit%2));
! outb (port + AR_DRIVE, unit / 2 ? ARD_DRIVE1 : ARD_DRIVE0);
#else
outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
#endif
! /* Wait for controller not busy again. Necessary? */
! if (atapi_wait (port, 0) 0) {
! print ((atapiX.%d at 0x%x: controller busy, status=%b\n,
! unit, port, inb (port + AR_STATUS), ARS_BITS));
return (0);
}
+ /* Issue ATAPI IDENTIFY command. */
+ outb (port + AR_COMMAND, ATAPIC_IDENTIFY);
+
/* Wait for data ready. */
if (atapi_wait (port, ARS_DRQ) != 0) {
print ((atapiX.%d at 0x%x: identify not ready, status=%b\n,
unit, port, inb (port + AR_STATUS), ARS_BITS));
return (0);
}
***
*** 499,503
u_char s;
! /* Wait 5 sec for BUSY deassert. */
for (cnt=50; cnt0; --cnt) {
s = inb (port + AR_STATUS);
--- 472,479
u_char s;
! /* Wait at least 400 nsec for BSY to become valid. */
! DELAY(1);
!
! /* Wait 5 sec for BSY deassert. */
for (cnt=50; cnt0; --cnt) {
s = inb (port + AR_STATUS);
***
*** 511,518
return (s ARS_CHECK);
! /* Wait 50 msec for bits wanted. */
for (cnt=5000; cnt0; --cnt) {
s = inb (port + AR_STATUS);
! if ((s bits_wanted) == bits_wanted)
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Bruce Evans wrote: There's only one, at least in my version. There is the PC98 one you removed, and then this one in atapi_request_immediate(): /* Wait for data i/o phase. */ for (cnt=2; cnt0; --cnt) if (((inb (ata-port + AR_IREASON) (ARI_CMD | ARI_IN)) | (inb (ata-port + AR_STATUS) ARS_DRQ)) != PHASE_CMDOUT) break; I sent this in for review a year or so ago, but received no reply. The main points are that it honours ATA timing in atapi_wait() and checks for ARS_BUSY in atapi_wait(). This hopefully makes bogus checks like the one in rev.1.22 unnecessary (status 0xff has ARS_BSY set so it is invalid). I haven't tested the PC98 case. I removed PC98 code that seems to only compensate for bugs in atapi_wait(). Looks reasonable to me, but I haven't read the specs in two years. Still, from the symptoms people described, I would urge anyone with trouble to test this patch. I realize sos is introducing a new driver soon, but, at the very least, this would be a -stable material. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Fri, 26 Feb 1999 16:27:52 +0900, Daniel C. Sobral wrote: It was somehow distressing, though, that the new code had the exact same bug as the old, even though it was quite different code. When you say the new code, are you referring to the newer acd driver as opposed to the older wcd driver? If so, do you think it'll be worth my while trying to mangle into the acd code your diffs against the wcd code? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Sheldon Hearn wrote: It was somehow distressing, though, that the new code had the exact same bug as the old, even though it was quite different code. When you say the new code, are you referring to the newer acd driver as opposed to the older wcd driver? If so, do you think it'll be worth my while trying to mangle into the acd code your diffs against the wcd code? No. As I said, that was ages ago... :-) Once we had a wd.c whose code path was quite different from what we have (had) in wd.c now. i368/1730. Funny that did doesn't seem to be the original PR that was fixed, but one applying to the new (then :) code. Didn't have much success searching for my own PRs. It ought to do substring searching on the web pages, but it doesn't. :-( OTOH, it seems some of my PRs were filed as confidential, even though they were not, so that my also explain why I couldn't find the other PR. Relevant parts: This happens because a DELAY is missing in one loop, and ARS_BSY flag is being ignored in another (atapi_request_immediate and atapi_wait_cmd functions). On the code: ireason = inb (ata-port + AR_IREASON); ac-result.status = inb (ata-port + AR_STATUS); phase = (ireason (ARI_CMD | ARI_IN)) | - (ac-result.status ARS_DRQ); + (ac-result.status (ARS_DRQ|ARS_BSY)); if (phase == PHASE_CMDOUT) break; DELAY (10); The missing delay is not relevant. (Or, at least, I hope acd is not missing delays in wait loops!) The problem is the ARS_BSY signal. If my memory doesn't fail me, if ARS_BSY is active, then the other signals may contain trash. In this particular loop, ARS_BSY could be active, but it wasn't being checked for, on the assumption that ARS_DRQ would only be up (down?) when the operation completed. M Found my PRs now. It definitely looks like a PR went confidential... :-( I think I explained the bug a lot better on the other one... :-( Oh, well. Well, feel free to search for ARS_DRQ and ARS_BSY on acd (if it uses the same defines...). The ATAPI document I used was SFF8020. It might have been obsoleted by now. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
It seems Daniel C. Sobral wrote: On the code: ireason = inb (ata-port + AR_IREASON); ac-result.status = inb (ata-port + AR_STATUS); phase = (ireason (ARI_CMD | ARI_IN)) | - (ac-result.status ARS_DRQ); + (ac-result.status (ARS_DRQ|ARS_BSY)); if (phase == PHASE_CMDOUT) break; DELAY (10); The missing delay is not relevant. (Or, at least, I hope acd is not missing delays in wait loops!) The problem is the ARS_BSY signal. If my memory doesn't fail me, if ARS_BSY is active, then the other signals may contain trash. In this particular loop, ARS_BSY could be active, but it wasn't being checked for, on the assumption that ARS_DRQ would only be up (down?) when the operation completed. This has been in there for ages, if the PR is still open it should be closed. Be patient though, I'm working as much as I can on the (really) new subsystem, and I hope to release the first snaps soon... -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Søren Schmidt wrote: The problem is the ARS_BSY signal. If my memory doesn't fail me, if ARS_BSY is active, then the other signals may contain trash. In this particular loop, ARS_BSY could be active, but it wasn't being checked for, on the assumption that ARS_DRQ would only be up (down?) when the operation completed. This has been in there for ages, if the PR is still open it should be closed. It is closed. We were discussing (actually, I was wondering) whether it might have resurfaced with acd. Be patient though, I'm working as much as I can on the (really) new subsystem, and I hope to release the first snaps soon... Hey, my cd-rom works fine. *I* am in no hurry. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
It seems Daniel C. Sobral wrote: Søren Schmidt wrote: The problem is the ARS_BSY signal. If my memory doesn't fail me, if ARS_BSY is active, then the other signals may contain trash. In this particular loop, ARS_BSY could be active, but it wasn't being checked for, on the assumption that ARS_DRQ would only be up (down?) when the operation completed. This has been in there for ages, if the PR is still open it should be closed. It is closed. We were discussing (actually, I was wondering) whether it might have resurfaced with acd. Nope, that code snippet is in atapi.c its not in any of the drivers... (and newer has been). -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Søren Schmidt wrote: Nope, that code snippet is in atapi.c its not in any of the drivers... (and newer has been). You're right. Goes to show how long I haven't touched this part of the code. Alas, just reviewed it out of curiosity. It sure got more readable... :-) But I still hate those inb loops without DELAY... -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, Feb 25, 1999 at 02:09:31PM +1030, Greg Lehey wrote: Wow. Thanks a million! I didn't even have to go so far, I just deleted wd2 and wd3 and acd0 now appears as if by magic. I can't tell you how extremely stupid I now feel... You shouldn't do. What you did shouldn't have any effect on the problem. Yet it definitely has. The CDROM never probed before, now it does (at least every time I tried: only about half a dozen reboots for the moment). So there's probably something strange with the probe code and how it interacts with wd[0-3] declarations. So the CDROM now probes correctly, but OTOH I didn't manage to use it. I get the following message every time: bofh /kernel: atapi1.0: controller not ready for cmd The machine then seems to hang, more or less (X11 kindly moves the mouse pointer, but the network is dead). FreeBSD still has difficulties with some ATAPI CD-ROM drives. If you continue to have trouble (and I suspect you will), you should enter a PR with send-pr or at http://www.freebsd.org/send-pr.html. Make sure to give exact details of your hardware and software configuration. I tried to find out why it worked with a Linux kernel by comparing our IDE code and theirs, but it was way beyond my comprehension. I'm not trained for the black magic of IDE probing. I'll try to investigate some more, then I'll try a bug report. -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, Feb 25, 1999 at 04:20:20PM +1100, Bruce Evans wrote: doesn't see the slave, and control passes to the atapi probe which does support cdrom drives. It works worst with a cdrom master and no slave. Sadly, that's exactly the out-of-the-box Dell configuration: 2 disks on the first IDE, just a CDROM on the second IDE. I'd have changed the hardware configuration to swap the second disk with the CDROM, but I thought it would be much better if it could be made to work, since it apparently can... -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, 25 Feb 1999 17:16:53 +0100, Pierre Beyssac wrote: I tried to find out why it worked with a Linux kernel by comparing our IDE code and theirs, but it was way beyond my comprehension. I'm not trained for the black magic of IDE probing. I used this particular issue for the launch of my first adventure into serial console kernel debugging. Multo fun. I can offer you two interesting points: 1) I have an ATAPI drive that FreeBSD 2.2-STABLE won't detect on boot if it contains a disc. 2) I found that stepping through the kernel caused exactly the same problems I was having with accessing my one ATAPI drive that I experience just running normally with my other drive. So it looks like at least one problem regarding ATAPI has to do with timings. So far, the conversations I've had with clueful FreeBSD hackers have led me to accept the following: A) The ATAPI standard is weak and the variety of implimentations thereof is even worse. B) The odds that your ATAPI CDROM drive will behave predictably in accordance with said standards are directly proportional to its age. It seems that newer (24xspeed+) drives suck. C) The ATAPI code in FreeBSD is about as good as our hackers care to make it, given the demotivating impact of A and B above. I spent a good few days stepping around my kernel over serial connection, using a working 4xspeed drive and a broken 36xspeed drive and testing a reproducible fault with cdcontrol. I'm a pretty stubborn guy, but I gave up. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, 25 Feb 1999 17:26:14 +0100, Pierre Beyssac wrote: I'd have changed the hardware configuration to swap the second disk with the CDROM, but I thought it would be much better if it could be made to work, since it apparently can... Nope, it's almost certainly better to have your random access disks on two different controllers. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: IDE CDROM not found with PIIX4 chipset, -current kernel
-Original Message- From: Sheldon Hearn [SMTP:sheld...@iafrica.com] Sent: Thursday, February 25, 1999 5:40 PM To: Pierre Beyssac Cc: Greg Lehey; freebsd-current@FreeBSD.ORG Subject: Re: IDE CDROM not found with PIIX4 chipset, -current kernel On Thu, 25 Feb 1999 17:16:53 +0100, Pierre Beyssac wrote: I tried to find out why it worked with a Linux kernel by comparing our IDE code and theirs, but it was way beyond my comprehension. I'm not trained for the black magic of IDE probing. I used this particular issue for the launch of my first adventure into serial console kernel debugging. Multo fun. I can offer you two interesting points: 1) I have an ATAPI drive that FreeBSD 2.2-STABLE won't detect on boot if it contains a disc. 2) I found that stepping through the kernel caused exactly the same problems I was having with accessing my one ATAPI drive that I experience just running normally with my other drive. So it looks like at least one problem regarding ATAPI has to do with timings. So far, the conversations I've had with clueful FreeBSD hackers have led me to accept the following: A) The ATAPI standard is weak and the variety of implimentations thereof is even worse. B) The odds that your ATAPI CDROM drive will behave predictably in accordance with said standards are directly proportional to its age. It seems that newer (24xspeed+) drives suck. C) The ATAPI code in FreeBSD is about as good as our hackers care to make it, given the demotivating impact of A and B above. I spent a good few days stepping around my kernel over serial connection, using a working 4xspeed drive and a broken 36xspeed drive and testing a reproducible fault with cdcontrol. I'm a pretty stubborn guy, but I gave up. [ML] Heh, it would seem that the prevailing OS is not really ATAPI compliant and the manufacturers try to make their hardware more easily detectable for the prevailing OS family. How about this brilliant idea: put a logic analyzer on the IDE cable and measure the timings the prevailing OS family/BIOS uses? Sadly, I don't have access to a logic analyzer :( Anyone with (good) connections to a (university) hardware lab? /Marino Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, 25 Feb 1999 18:07:39 +0100, Ladavac Marino wrote: How about this brilliant idea: put a logic analyzer on the IDE cable and measure the timings the prevailing OS family/BIOS uses? My understanding from previous conversations is that the situation you're often faced with is that you'll break support for one set of drives by fixing support for another. Ciao, Sheldon. PS: It's not usually necessary to quote back the entire content of a message you reply to when you're replying less than 30 minutes after the original was posted. :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, Feb 25, 1999 at 06:40:35PM +0200, Sheldon Hearn wrote: I'd have changed the hardware configuration to swap the second disk with the CDROM, but I thought it would be much better if it could be made to work, since it apparently can... Nope, it's almost certainly better to have your random access disks on two different controllers. Oh yes, I won't try to argue against that since I quite agree. I'll try this once I get tired trying my current config :-). I was just considering that the more configurations that work, the better for FreeBSD's ease of installation/configuration. The problem is bound to happen again since this is a configuration (CDROM by itself on a second IDE controller) currently sold by Dell. Don't ask me why, Dell always tends to make weird choices regarding how they install IDE devices and controllers. I suspect this has to do with this weird, differently abled stuff sold by a major company which lost the source code for it, arrogant enough to call it an OS. -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Sheldon Hearn wrote: 2) I found that stepping through the kernel caused exactly the same problems I was having with accessing my one ATAPI drive that I experience just running normally with my other drive. So it looks like at least one problem regarding ATAPI has to do with timings. FreeBSD code has had it share of bugs due to spec violation, generally showing up as timing problems. One can search the PR for HITACHI or ATAPI (I can't quite recall what subject I choose) PRs from me. First time, someone found the bug, I incorporated it in my code, sent PR, and distributed the patch to anyone who complained about it (on the lists I read). Then, the code was changed (the whole code), and my PR was closed because it did not apply anymore. Alas, the new code had the same bug. I don't quite recall if I opened a new PR or just sent the patch to (probably) Soren. It was somehow distressing, though, that the new code had the exact same bug as the old, even though it was quite different code. This was ages ago, though. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Wed, 24 Feb 1999 23:51:17 +0100, Pierre Beyssac wrote: Here's an excerpt from my kernel config. Did I miss something obvious? controller wdc0[...] diskwd0 at wdc0 drive 0 diskwd1 at wdc0 drive 1 controller wdc1[...] diskwd2 at wdc1 drive 0 diskwd3 at wdc1 drive 1 options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC#Don't do it as an LKM device acd0#IDE CD-ROM Um... Do you really have 4 wd devices plugged in? If so, where on earth are you plugging the CDROM device in? :) Assuming you don't have 4 drives, I'd suggest you slave your ATAPI CDROM device on your primary IDE controller. So you'd do something like: controller wdc0 controller wdc1 diskwd0 at wdc0 drive 0 diskwd1 at wdc1 drive 0 diskwd2 at wdc1 drive 1 ...followed by your acd device, naturally. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thu, Feb 25, 1999 at 01:01:09AM +0200, Sheldon Hearn wrote: controller wdc1[...] diskwd2 at wdc1 drive 0 diskwd3 at wdc1 drive 1 Um... Do you really have 4 wd devices plugged in? Uh, well, no, just 2 (on the first IDE controller). Assuming you don't have 4 drives, I'd suggest you slave your ATAPI CDROM device on your primary IDE controller. So you'd do something like: Wow. Thanks a million! I didn't even have to go so far, I just deleted wd2 and wd3 and acd0 now appears as if by magic. I can't tell you how extremely stupid I now feel... OTOH, I copied this from the GENERIC kernel config file, assuming it recognizes an ATAPI CDROM when it finds one. So my puzzled question is now: how can the GENERIC kernel work in that case, since it declares wd[0-3] ? -- Pierre Beyssac p...@enst.fr To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
On Thursday, 25 February 1999 at 1:04:48 +0100, Pierre Beyssac wrote: On Thu, Feb 25, 1999 at 01:01:09AM +0200, Sheldon Hearn wrote: controller wdc1[...] diskwd2 at wdc1 drive 0 diskwd3 at wdc1 drive 1 Um... Do you really have 4 wd devices plugged in? Uh, well, no, just 2 (on the first IDE controller). Assuming you don't have 4 drives, I'd suggest you slave your ATAPI CDROM device on your primary IDE controller. So you'd do something like: Wow. Thanks a million! I didn't even have to go so far, I just deleted wd2 and wd3 and acd0 now appears as if by magic. I can't tell you how extremely stupid I now feel... You shouldn't do. What you did shouldn't have any effect on the problem. You may find that sometimes it gets recognized, other times it doesn't. FreeBSD still has difficulties with some ATAPI CD-ROM drives. If you continue to have trouble (and I suspect you will), you should enter a PR with send-pr or at http://www.freebsd.org/send-pr.html. Make sure to give exact details of your hardware and software configuration. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
I've been having problems with an IDE controller on my motherboard. I can't seem to be able to get it to recognize a CDROM drive (it's the only device plugged on the second IDE controller). The kernel seems to timeout on that second controller during the probe phase. Maybe that's one of the infamous PIIX 4 bugs... The machine is a Dell Optiplex. That's one of the infamous FreeBSD bugs :-). The wd probe has never really supported cdrom drives. It works best when there is an ordinary drive on the master and a cdrom drive on the slave. Then it essentially doesn't see the slave, and control passes to the atapi probe which does support cdrom drives. It works worst with a cdrom master and no slave. Then it at first sees the master as a broken ordinary drive and times out attempting to reset it. Then it does a quick subprobe for a cdrom drive, and if it sees a cdrom drive then it doesn't see an ordinary drive and control passes to the atapi probe ... The subprobe apparently doesn't work for new drives. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
