Boot hangs on v9 system at CD device probe

Marius Strobl marius at alchemy.franken.de
Sat Jun 9 12:13:37 UTC 2012


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 at gmail.com> wrote:
> > On Thu, May 31, 2012 at 4:02 AM, Marius Strobl
> > <marius at alchemy.franken.de> wrote:
> >> On Wed, May 30, 2012 at 05:13:44PM -0600, Ian Lepore wrote:
> >>> 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.
> >>>
> >>
> >> Note that hw.ata.atapi_dma isn't honored by 9.0 with options ATA_CAM
> >> (default in GENERIC). Support for that loader tuneable was only
> >> resurrected rather recently (but is available in stable/9). The
> >> equivalent for 9.0 would be setting hint.ata.X.mode to PIO4 where
> >> X is the number of the ata(4) device attached for the channel the
> >> CDROM is connected to.
> >> ATA_CAM is indeed known to break ATAPI DMA for some ATA controllers
> >> though. What's the `pciconf -lv` output for this one?
> >
> > Good point. I had forgotten about the hw.ata.atapi_dma removal and was
> > not even awarethat it had been recently re-enabled.
> > My controller is:
> > atapci0 at pci0:17:4:0: ? ?class=0x010185 card=0x82131283 chip=0x82131283
> > rev=0x00 hdr=0x00
> > ? ?vendor ? ? = 'Integrated Technology Express (ITE) Inc'
> > ? ?device ? ? = 'IDE Controller (IT8213F)'
> > ? ?class ? ? ?= mass storage
> > ? ?subclass ? = ATA
> >
> > It is used ONLY for the CD/DVD as all other disks use the 3ware RAID controller.
> >
> > Unfortunately, the system is not located where I am, so I can't really
> > try anything until I get over there. Maybe later today I can run into
> > that office and try some of the suggestions. I can certainly build a
> > kernel without ATA_CAM.
> 
> 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

Marius



More information about the freebsd-stable mailing list