I sent a note about this a couple of weeks ago, but have not heard anything. I'm really getting a bit desperate. I have a system that I am trying to upgrade from 8.2 to 9.0. I have built it and installed the kernel, but it fails to boot. The boot freezes after probing for my hard drives during the probe of the CDROM. It just sits there, seemingly forever, though I have never waited longer then a few minutes. The system is a SuperMicro C25BX mother board. The DVD is PATA, reported on boot of 8-Stable as: acd0: DVDR <ATAPI DVD A DH20A4P/9P59> at ata2-master UDMA66 If I unplug the CDROM, it boots fine, but I really need the device on the system, so I really can't leave it unplugged. Also, after the 9 kernel is installed, my Mk file have been updated so that I can't build some ports if I boot the 8.2 kernel. Does anyone remember this being reported by others? It was most likely on current, as it was probably prior to the release of 9. I googled around, but could not find it. I'd really appreciate it if anyone can point me toward a solution. Thanks, -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com
On Wed, May 30, 2012 at 4:54 PM, Kevin Oberman <kob6558@gmail.com> wrote:> I sent a note about this a couple of weeks ago, but have not heard > anything. I'm really getting a bit desperate. > > I have a system that I am trying to upgrade from 8.2 to 9.0. I have > built it and installed the kernel, but it fails to boot. The boot > freezes after probing for my hard drives during the probe of the > CDROM. It just sits there, seemingly forever, though I have never > waited longer then a few minutes. > > The system is a SuperMicro C25BX mother board. The DVD is PATA, > reported on boot of 8-Stable as: > acd0: DVDR <ATAPI DVD A DH20A4P/9P59> at ata2-master UDMA66 > > If I unplug the CDROM, it boots fine, but I really need the device on > the system, so I really can't leave it unplugged. Also, after the 9 > kernel is installed, my Mk file have been updated so that I can't > build some ports if I boot the 8.2 kernel. Does anyone remember this > being reported by others? It was most likely on current, as it was > probably prior to the release of 9. I googled around, but could not > find it. > > I'd really appreciate it if anyone can point me toward a solution. >http://lists.freebsd.org/pipermail/freebsd-current/2010-October/020336.html -- Adam Vande More
On Wed, 2012-05-30 at 14:54 -0700, Kevin Oberman wrote:> I sent a note about this a couple of weeks ago, but have not heard > anything. I'm really getting a bit desperate. > > I have a system that I am trying to upgrade from 8.2 to 9.0. I have > built it and installed the kernel, but it fails to boot. The boot > freezes after probing for my hard drives during the probe of the > CDROM. It just sits there, seemingly forever, though I have never > waited longer then a few minutes. > > The system is a SuperMicro C25BX mother board. The DVD is PATA, > reported on boot of 8-Stable as: > acd0: DVDR <ATAPI DVD A DH20A4P/9P59> at ata2-master UDMA66 > > If I unplug the CDROM, it boots fine, but I really need the device on > the system, so I really can't leave it unplugged. Also, after the 9 > kernel is installed, my Mk file have been updated so that I can't > build some ports if I boot the 8.2 kernel. Does anyone remember this > being reported by others? It was most likely on current, as it was > probably prior to the release of 9. I googled around, but could not > find it. > > I'd really appreciate it if anyone can point me toward a solution. > > Thanks,When faced with a mystery like this I sometimes go into the mode of "poke it with a stick and see if it twitches." If you can get it to twitch at all, maybe that's a starting point. In this case, I guess I might start with seeing if setting hw.ata.atapi_dma=0 in the loader makes any difference. -- Ian
On Tue, Jun 12, 2012 at 03:17:47PM -0700, Kevin Oberman wrote:> On Sat, Jun 9, 2012 at 3:29 PM, Marius Strobl <marius@alchemy.franken.de> wrote: > > On Sat, Jun 09, 2012 at 02:38:53PM -0700, Kevin Oberman wrote: > >> On Sat, Jun 9, 2012 at 5:13 AM, Marius Strobl <marius@alchemy.franken.de> wrote: > >> > On Fri, Jun 08, 2012 at 10:11:48PM -0700, Kevin Oberman wrote: > >> >> On Thu, May 31, 2012 at 9:10 AM, Kevin Oberman <kob6558@gmail.com> wrote: > >> >> I just did the obvious as suggested and built a kernel without ATA_CAM > >> >> and with atapicam. It boots fine and I have my CD/DVD working on 9.0. > >> >> Clearly, there is some issue with ATAPI drives with ATA_CAM as others > >> >> have seen the same thing. It is entirely possible that a serial > >> >> connected drives don't have this issue. It does look like there is > >> >> some locking issue between CAM and GEOM under some circumstances. I > >> >> worry that 10 will lose support for other than ATA_CAM and that the > >> >> work-around will no longer be available. Of course, if ahci fixes it, > >> >> the problem will go away on systems that support it. > >> >> > >> >> Next time I get to the system I will try putting ATA_CAM back and > >> >> adding ahci and report on the results. > >> >> > >> > > >> > I don't think that the latter test makes much sense as the above > >> > mentioned controller doesn't support AHCI. If you could test > >> > whether the following patch works around the issue when using > >> > ATA_CAM that would be more useful. > >> > http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff > >> > >> Will do. It will be a couple of days, though, as I am currently in the > >> process of updating the 1000 ports installed on that system for the > >> major version update. When that is complete, I'll try to get to the > >> location of the system and see if it does the job. Mondy has several > >> meetings, so it will probably be at least Tuesday. > > > > No hurry ... > > I installed the patch and it worked. 9.0-Stable system with ATA_CAM > and cdrom now boot correctly. > > Thanks! > > Will this be committed to head and MFCed soon?I've committed it to head in r237107 as a band-aid for now as it's a sufficiently severe problem. Obviously, fixing ATA_CAM to not break ATAPI CAM instead is the right thing to do. I've already spent quite some time trying to find the underlying but didn't get anywhere with that so far though (granted, most of that wasted time was because of me thinking that this would be due to an endian bug only seen on big endian machines, which turned out to not be the case). AFAICT, mav@ also has ALI hardware affected by this issue, maybe he'll have a look at it eventually ... Marius