Re: No disks usable on a P5NE MB (aka regession is r219737)

From: John Baldwin <jhb_at_freebsd.org>
Date: Tue, 15 Nov 2011 12:46:41 -0500
On Friday, November 11, 2011 5:59:07 pm Baptiste Daroussin wrote:
> On Fri, Nov 11, 2011 at 11:10:58PM +0100, Baptiste Daroussin wrote:
> > On Thu, Sep 29, 2011 at 12:22:54AM +0200, Baptiste Daroussin wrote:
> > > On Sun, Sep 11, 2011 at 10:39:38PM +0200, Baptiste Daroussin wrote:
> > > > > > the result is:
> > > > > > db> show intrcnt
> > > > > > cpu0: timer    4510
> > > > > > irq256: hdac0   1
> > > > > > cpu3: timer     29
> > > > > > cpu1: timer     3036
> > > > > > cpu2: timer     31
> > > > > > db>
> > > > > > 
> > > > > > I did break at the mountfrom> prompt
> > > > > > If I break before I only have the cpu0 and irq256 entries.
> > > > > 
> > > > > Hmmm, is there any way you can build a 9 kernel without sound 
support (since 
> > > > > that clutters up bootverbose) and capture a verbose dmesg, using a 
serial 
> > > > > console or PXE booting to an NFS root of some sort?
> > > > > 
> > > > I can't pxe boot, but I can record the build on my camera:
> > > > http://people.freebsd.org/~bapt/9-fail.avi (18MB)
> > > > 
> > > > (this is 9.0-BETA2 memstick)
> > > > 
> > > > Hope that could help
> > > > 
> > > 
> > > Apparently this doesn't help, given that I have no way to netboot this 
box, may
> > > that be from pxe and that there is no serial console, what can I do more 
to help
> > > fixing this?
> > > 
> > > I would love to be able to run 9 on my box
> > > 
> > > regards,
> > > Bapt
> > 
> > After trying lots of different kernel it appears that the regression was
> > introduce in r219737. I'm trying to figure out to solve this.
> > 
> > If you have any clue tell me.
> > 
> > regards,
> > Bapt
> 
> 
> 
> With the help of cognet, I workaround this and have been able to boot both 9 
and
> 10 remove that block :
> http://people.freebsd.org/~bapt/workaround-to-boot-p5ne.diff

Yeah, the problem is that NVIDIA chipsets seem to have really odd behavior in 
that once you turn MSI mapping on for a given node in the HyperTransport tree 
it expects all child devices to only use MSI and not INTx.  Linux has a lot of 
quirk code to try to handle this by only turning on the mapping window when 
MSI is enabled for a given device.  However, it has lots of hacks to try to 
find the right Host-PCI Bridge that a given device is a child of.  I'm mostly 
tempted to just disable MSI on NVIDIA chipsets that have these issues rather 
than adding the same number of quirks.  However I haven't really had time to 
sit down and look at this.

-- 
John Baldwin
Received on Tue Nov 15 2011 - 16:53:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC