Re: lockup booting 8.0-CURRENT-200811 snap image

On Thursday 04 December 2008 10:34:06 pm Chris Ruiz wrote:
> On Thu, Dec 4, 2008 at 1:21 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> > On Tuesday 18 November 2008 01:51:47 am Phil Oleson wrote:
> >> Hi, I've been trying to update my system to Current to try out the new
> >> usb stack etc..
> >> and have had some problems.   Initially I attempted to just do a cvsup,
> >> make buildworld,
> >> make kernel and had problems at the reboot.  Ended up having to use the
> >> livecd to swap
> >> out the kernel (loader was strangely hanging before I could type unload;
> >> boot kernel.old)
> >>
> >> Anyways,  I picked up a new drive to split my system up to have a
> >> working 7 & current.
> >> So, I downloaded the 200811 snap iso's for amd64 & i386 and tried to
> >> boot to them.
> >> Same/similar lockup happens.. now since this board currently doesn't
> >> have a serial port
> >> I've had to handtype what was left on the screen.. so hopefully it's
> >> enough for now.
> >>
> >> System: INTEL BLKDG35EC 775 G35  (flashed to the **ECG3510M.86A.0107**
> >> Bios Image)
> >>               INTEL C2Q Q9300 2.5G 775
> >>               2 gigs memory (messed up on original order and havnt fixed
> >> it yet)
> >>               using the built-in Intel video..
> >>
> >> so the i386 and the amd64 dvd image I booted with had the same stopping
> >> screen/output
> >> that I could see.. this is what I was able to get down from a verbose 
boot.
> >>
> >> ------------------------------------------------------
> >>    Initial Probe      0   10    N     0  3 4 5 7 9 10 11 12
> >>    Validation         0   10    N     0  3 4 5 7 9 10 11 12
> >>    After Disable    0  255   N     0  3 4 5 7 9 10 11 12
> >> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> >> acpi0
> >> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 hz: 14318180 opts: legacy_route
> >> 64-bit Timecounter "HPET" frequency 143181800 Hz quality 900
> >> acpi_button0: <Sleep Button> on acpi0
> >> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> >> pci0: <ACPI PCI bus> on pcib0
> >> pci0: domain=0, physical bus=0
> >> found-> vendor=0x8086, dev=0x2980,  revid=0x03
> >>              domain=0, bus=0, slot=0, func=0
> >>              class=06-00-00, hdrtype=0x00, mfdev=0
> >>              cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords)
> >>              lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns)
> >> found-> vendor=0x8086, dev=0x2982,  revid=0x03
> >>              domain=0, bus=0, slot=2, func=0
> >>              class=03-00-00, hdrtype=0x00, mfdev=1
> >>              cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords)
> >>              lattimer=0x00 (0 ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns)
> >>              intpin=a,  irq=11
> >>              powerspec 2   supports D0 D3  current D0
> >>              MSI supports 1 message
> >>              map[10]: type Memory, range32, base 0x90200000, size 20,
> >> enabled
> >> --------------------------------
> >>
> >>
> >> Any suggestions on how to proceed?
> >>
> >> I'll see about installing the new install on the new drive starting at
> >> RELENG_7
> >> and updating to HEAD from there.. so any source changes will have to wait 
on
> >> completing that.. but anything would help.
> >
> > Try setting hw.pci.mcfg=0
> 
> I also have an Intel board (INTEL DQ35JO) and had posted last month
> with a boot hang in the same place.   I recieved a quick reply from
> the list and setting hw.pci.mcg=0 fixed everything.
> 
> Should this be marked as a known problem somewhere on the wiki?  It
> appears to happen to Intel boards with onboard graphics and I imagine
> that as more people migrate from 7.x to CURRENT that this will happen
> to more users.
> 
> Thanks,
> 
> Chris Ruiz

Well, we probably need to come up with a better way to determine which 
machines to actually use it on.  It's a shame that MCFG is apparently busted 
on so many machines (either that or we are not doing something correctly).

-- 
John Baldwin