Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Fwd: port-amd64/43309: VX800 and CN896-VT8237S is not configured in RAID mode



Since I noticed that pcictl dump identifies IDE controller as CX700
one, I decided to rework patch a bit and it seems it doesn't duplicate
viaide anymore (and I think this patch is likely OK to apply from my
testing):

iff --git a/sys/dev/pci/viaide.c b/sys/dev/pci/viaide.c
index 27f1c70a1eb..ed62dde6f4d 100644
--- a/sys/dev/pci/viaide.c
+++ b/sys/dev/pci/viaide.c
@@ -302,7 +302,7 @@ static const struct pciide_product_desc
pciide_via_products[] =  {
        { PCI_PRODUCT_VIATECH_CX700_IDE,
          0,
          NULL,
-         via_chip_map,
+         via_sata_chip_map_new,
        },
        { PCI_PRODUCT_VIATECH_CX700M2_IDE,
          0,
@@ -349,6 +349,11 @@ static const struct pciide_product_desc
pciide_via_products[] =  {
          "VIA Technologies VT8237S SATA Controller",
          via_sata_chip_map_7,
        },
+       { PCI_PRODUCT_VIATECH_VT8237S_SATA_2,
+         0,
+         "VIA Technologies VT8237S SATA Controller",
+         via_sata_chip_map_7,
+       },
        { 0,
          0,
          NULL,
@@ -546,6 +551,14 @@ via_chip_map(struct pciide_softc *sc, const
struct pci_attach_args *pa)
                                aprint_normal("VT8251 ATA133 controller\n");
                                sc->sc_wdcdev.sc_atac.atac_udma_cap = 6;
                                break;
+                       case PCI_PRODUCT_VIATECH_VX800:
+                               aprint_normal("VX800 ATA133 controller\n");
+                               sc->sc_wdcdev.sc_atac.atac_udma_cap = 6;
+                               break;
+                       case PCI_PRODUCT_VIATECH_VX855:
+                               aprint_normal("VX855 ATA133 controller\n");
+                               sc->sc_wdcdev.sc_atac.atac_udma_cap = 6;
+                               break;
                        default:
                unknown:
                                aprint_normal("unknown VIA ATA controller\n");


RAID mode:

viaide0 at pci0 dev 15 function 0
viaide0: autoconfiguration error: couldn't map SATA regs
viaide0: bus-master DMA support present
viaide0: using ioapic0 pin 21 for native-PCI interrupt
atabus0 at viaide0 channel 0
atabus1 at viaide0 channel 1
atabus2 at viaide0 channel 2
...
pcib0 at pci0 dev 17 function 0: vendor 1106 product 8353 (rev. 0x00)
...
isa0 at pcib0
...
wd0 at atabus0 drive 0
wd0: <ST3000DM001-1CH166>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors
wd0: GPT GUID: 3954a983-ae2c-44b4-929a-a6f25b77cd1b
...
dk0 at wd0: "primary", 5860530176 blocks at 2048, type: ntfs
wd0: 32-bit data port
dk0 at wd0: "primary", 5860530176 blocks at 2048, type: ntfs
wd0: 32-bit data port
IPsec: Initialized Security Association Processing.
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6
(Ultra/133), WRITE DMA FUA, NCQ (32 tags)
wd1 at atabus0 drive 1
wd1: <TOSHIBA DT01ACA300>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6
(Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO
wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133)
(using DMA), WRITE DMA FUA EXT
wd1(viaide0:0:1): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133)
(using DMA), WRITE DMA FUA EXT
...
WARNING: 1 error while detecting hardware; check system log.


IDE mode:

viaide0 at pci0 dev 15 function 0
viaide0: VIA Technologies VX800 ATA133 controller
viaide0: bus-master DMA support present
viaide0: primary channel configured to compatibility mode
wd0 at atabus0 drive 0
wd0: <ST3000DM001-1CH166>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors
wd0: GPT GUID: 3954a983-ae2c-44b4-929a-a6f25b77cd1b
dk0 at wd0: "primary", 5860530176 blocks at 2048, type: ntfs
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6
(Ultra/133), WRITE DMA FUA, NCQ (32 tags)
wd1 at atabus0 drive 1
wd1: <TOSHIBA DT01ACA300>
wd1: drive supports 16-sector PIO transfers, LBA48 addressing
wd1: 2794 GB, 5814021 cyl, 16 head, 63 sec, 512 bytes/sect x 5860533168 sectors
wd1: 32-bit data port
wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6
(Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO
wd0(viaide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133)
(using DMA), WRITE DMA FUA EXT
wd1(viaide0:0:1): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133)
(using DMA), WRITE DMA FUA EXT
viaide0: primary channel interrupting at ioapic0 pin 14
atabus0 at viaide0 channel 0
viaide0: secondary channel configured to compatibility mode
viaide0: secondary channel interrupting at ioapic0 pin 15
atabus1 at viaide0 channel 1

On Fri, May 31, 2019 at 9:52 AM matthew green <mrg%eterna.com.au@localhost> wrote:
>
> Michael van Elst writes:
> > On Fri, May 31, 2019 at 09:21:38AM +0300, Andrius V wrote:
> > > Attached list and dumps
> >
> > >     Base address register at 0x10
> > >       not implemented
> > >     Base address register at 0x14
> > >       not implemented
> > >     Base address register at 0x18
> > >       not implemented
> > >     Base address register at 0x1c
> > >       not implemented
> > >     Base address register at 0x20
> > >       not implemented
> > >     Base address register at 0x24
> > >       not implemented
> >
> > That basically tells you that viaide1 doesn't really exist.
> >
> > I fear someone with more PCI knowledge than me needs to explain why there
> > is a config entry at all.
>
> probably laziness.
>
> eg, the hme(4) chipset also includes an ebus(4) and so sometimes
> on hme(4) plugin cards you can see an broken ebus(4) that fails
> to attach.
>
> this happens when the device answers enough config cycles to
> appear to exist, but doesn't really exist because it is some how
> disabled.
>
> at best, we can probably make the driver fail sanely if there
> are no required BARs.
>
>
> .mrg.


Home | Main Index | Thread Index | Old Index