On Saturday, June 09, 2012 3:06:19 pm Andrey Zonov wrote:
> On 6/9/12 9:35 PM, Marius Strobl wrote:
> > On Sat, Jun 09, 2012 at 12:58:05PM +0400, Andrey Zonov wrote:
> >> On 6/8/12 10:27 PM, John Baldwin wrote:
> >>> On Friday, June 08, 2012 11:48:50 am Andrey Zonov wrote:
> >>>> On Fri, Jun 8, 2012 at 7:19 PM, John Baldwin<j...@freebsd.org> wrote:
> >>>>> On Friday, June 08, 2012 3:14:19 am Andrey Zonov wrote:
> >>>>>> On 6/7/12 10:02 PM, Andrey Zonov wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I just upgraded a few machines from 8.2-STABLE (r221983) to 9.0-
STABLE
> >>>>>>> (r234600) and now they can't find any disk because SAS controller
> >>>>>>> cannot
> >>>>>>> initialize with the following diagnostic:
> >>>>>>>
> >>>>>>> mpt0:<LSILogic SAS/SATA Adapter> port 0xd000-0xd0ff irq 26 at
device
> >>>>>>> 3.0 on pci6
> >>>>>>> mpt0: 0x4000 bytes of rid 0x14 res 3 failed (0, 0xffffffffffffffff).
> >>>>>>> mpt0: Unable to memory map registers.
> >>>>>>> mpt0: Giving Up.
> >>>>>>>
> >>>>>>> pciconf -lv:
> >>>>>>> mpt0@pci0:6:3:0: class=0x010000 card=0x81dd1043 chip=0x00541000
> >>>>>>> rev=0x02
> >>>>>>> hdr=0x00
> >>>>>>> vendor = 'LSI Logic / Symbios Logic'
> >>>>>>> device = 'SAS1068 PCI-X Fusion-MPT SAS'
> >>>>>>> class = mass storage
> >>>>>>> subclass = SCSI
> >>>>>>>
> >>>>>>> I tried to boot to latest HEAD and found the same problem. I also
tried
> >>>>>>> to build kernel with mpt driver from my 8.2. Controller didn't
> >>>>>>> initialize with the same diagnostic. So it looks like the problem is
> >>>>>>> not
> >>>>>>> in mpt driver.
> >>>>>>>
> >>>>>>> Any help would be appreciated.
> >>>>>>>
> >>>>>>
> >>>>>> +jhb@
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> Could you please help me with the problem above? It looks like the
> >>>>>> problem is in PCI code and you changed things there.
> >>>>>
> >>>>> Can you get a verbose dmesg?
> >>>>>
> >>>>
> >>>> Yes, it's in attach.
> >>>
> >>> Can you get the output of 'devinfo -u' and 'devinfo -rv' from a broken
> >>> kernel?
> >>>
> >>
> >> Attached.
> >>
> >>> Can you also try setting 'debug.acpi.disable=sysres' in the loader?
> >>>
> >>
> >> Didn't help.
> >>
> >
> > That's probably due to a typo, the corret loader tunable is
> > debug.acpi.disabled=sysres (note the 'd').
> >
>
> This helps, thanks! Please explain what this means.
Well, it's working around a bug in your BIOS, but in this case FreeBSD should
have coped fine and it didn't. Please try using this patch without that
tunable and get a verbose dmesg please:
Index: sys/dev/pci/pci_pci.c
===================================================================
--- pci_pci.c (revision 236888)
+++ pci_pci.c (working copy)
@@ -893,9 +893,9 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
if (start < rman_get_start(w->res)) {
if (rman_first_free_region(&w->rman, &start_free, &end_free) !=
0 || start_free != rman_get_start(w->res))
- end_free = rman_get_start(w->res) - 1;
+ end_free = rman_get_start(w->res);
if (end_free > end)
- end_free = end;
+ end_free = end + 1;
/* Move end_free down until it is properly aligned. */
end_free &= ~(align - 1);
--
John Baldwin
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
