[regression] unable to boot: no GEOM devices found.

[John Baldwin]

On Thursday, April 05, 2012 4:40:32 am David Naylor wrote:
> On Wednesday, 28 March 2012 20:37:35 John Baldwin wrote:
> > On Monday, May 09, 2011 2:24:37 pm David Naylor wrote:
> > > On Friday 15 April 2011 23:29:55 David Naylor wrote:
> > > > On Friday 15 April 2011 18:28:06 John Baldwin wrote:
> > > > > On Wednesday, April 13, 2011 1:07:06 pm David Naylor wrote:
> > > > > > On Tuesday 12 April 2011 22:12:55 Alexander Motin wrote:
> > > > > > > David Naylor wrote:
> > > > > > > > On Tuesday 12 April 2011 08:17:51 Alexander Motin wrote:
> > > > > > > >> David Naylor wrote:
> > > > > > > >>> I am running -current and since a few days ago (at least
> > > > > > > >>> 2011/04/11) I am unable to boot.
> > > > > > > >>> 
> > > > > > > >>> The boot process stops when it looks to find a bootable
> > > > > > > >>> device. The prompt (when pressing '?') does not display any
> > > > > > > >>> device and yielding
> > > > > 
> > > > > one
> > > > > 
> > > > > > > >>> second (or more) to the kernel (by pressing '.') does not
> > > > > > > >>> improve the situation.
> > > > > > > >>> 
> > > > > > > >>> A known working date is 2011/02/20.
> > > > > > > >>> 
> > > > > > > >>> I am running amd64 on a nVidia MCP51 chipset.
> > > > > > > >> 
> > > > > > > >> MCP51... again...
> > > > > > > 
> > > > > > > +ata2: reiniting channel ..
> > > > > > > +ata2: SATA connect time=0ms status=00000113
> > > > > > > +ata2: reset tp1 mask=01 ostat0=58 ostat1=00
> > > > > > > +ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
> > > > > > > +ata2: reset tp2 stat0=50 stat1=00 devices=0x1
> > > > > > > +ata2: reinit done ..
> > > > > > > +unknown: FAILURE - ATA_IDENTIFY timed out LBA=0
> > > > > > > 
> > > > > > > As soon as all devices detected but not responding to commands, I
> > > > > > > would suppose that there is something wrong with ATA interrupts.
> > > > > > > There is a long chain of interrupt problems in this chipset. I
> > > > > > > have already tried to debug one case where ATA wasn't generating
> > > > > > > interrupts at all. Unfortunately, without success -- requests
> > > > > > > were executing, but not generating interrupts, it wasn't looked
> > > > > > > like ATA driver problem.
> > > > > > > 
> > > > > > > What's about possible candidate to revision triggering your
> > > > > > > problem, I would look on this message:
> > > > > > > +pcib0: Enabling MSI window for HyperTransport slave at
> > > > > > > pci0:0:9:0
> > > > > > > 
> > > > > > > At least it is recent (SVN revs 219737,219740 on 2011-03-18 by
> > > > > > > jhb) and it is interrupt related.
> > > > > > 
> > > > > > I reverted those two revs and everything works again.
> > > > > 
> > > > > Hmm, can you provide a full boot verbose dmesg?  Alternatively, can
> > > > > you see if the device at pci0:0:9:0 is a PCI-PCI bridge?
> > > > 
> > > > I can provide a verbose dmesg if the following is not enough:
> > > > 
> > > > none17 at pci0:0:9:0:      class=0x050000 card=0x50011458 chip=0x027010de
> > > > rev=0xa2 hdr=0x00
> > > > 
> > > >     vendor     = 'NVIDIA Corporation'
> > > >     device     = 'MCP51 Host Bridge'
> > > >     class      = memory
> > > >     subclass   = RAM
> > > > 
> > > > I see two PCI-PCI bridges at pci0:0:3:0 and pci0:0:16:0.  I've attached
> > > > the full `pciconf -lv` output.
> > > 
> > > FYI, this issue is still present on current (~24 hours old).  Reverting
> > > the above mentioned revisions still fixes the problem.
> > 
> > I finally had an idea about a way to solve this (at least when using ACPI)
> > that doesn't involve a whole bunch of quirks, etc.  Please try
> > http://www.FreeBSD.org/~jhb/patches/hostb_htmsi.patch
> 
> I am no longer able to test on that machine.  Booting of a USB stick doesn't 
> work, the kernel says: WARNING WITNESS ENABLED then the computer restarts.  
> This is with -current after you committed the patch and with stable-9.  
> 
> I have verified that the USB stick does boot off other computers.  

Hmm, I suspect this is a different issue seeing as it affects stable-9
(assuming you tested stock 9 and not with this patch applied).  It is up
to you how much time you want to spend on this as I do believe based on
other feedback I've gotten that the issue you initially reported should be
fixed.

-- 
John Baldwin