Current-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ahcisata and WDCTL_RST
On Jul 12, 9:38pm, John Klos wrote:
}
} I have an older MSi MS-7511 motherboard (it just happens to be the one
} that the NetBSD Foundation gave to certain developers). It has run fine
} for years, but with NetBSD-7 and -current, ahcisata will only recognize
} SATA drives every tenth boot or so. There's no discernible pattern:
}
} ahcisata0 at pci0 dev 9 function 0: vendor 0x10de product 0x0ad0 (rev. 0xa2)
} LSA0: Picked IRQ 21 with weight 1
} ahcisata0: interrupting at ioapic0 pin 21
} ahcisata0: 64-bit DMA
} ahcisata0: ignoring broken port multiplier support
} ahcisata0: AHCI revision 1.20, 6 ports, 32 slots, CAP 0xe3209f05<PMD,ISS=0x2=Gen2,SCLO,SAL,SSNTF,SNCQ,S64A>
} atabus0 at ahcisata0 channel 0
[trimming essentially duplicate lines]
} ...
} ahcisata0 port 1: device present, speed: 3.0Gb/s
} ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0
}
}
} With NetBSD 7.0.1 installation kernel, I get the same as above but:
}
} ahcisata0 port 3: device present, speed: 3.0Gb/s
} atabus0: Unrecognized signature 0x00000001 on port 0. Assuming it's a disk.
[haven't seen this before]
} wd0 at atabus0 drive 0
} wd0: <SanDisk SDSSDH120GG25>
} wd0: drive supports 16-sector PIO transfers, LBA48 addressing
} wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
} wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
} wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA)
} ... (and other three disks)
}
} However, booting a NetBSD 6.1.5 kernel, all drives are recognized and are
} usable with no problems at all. The only difference is that the "ignoring
} broken port multiplier support" message isn't reported by the 6.1.5
} kernel.
}
} While trying to figure out what was wrong, I tried completely different
} drives, different SATA cables, a different power supply, et cetera, and
} nothing mattered except changing the kernel.
}
} Does anyone have ideas about what may've broken this?
I don't know what it is happening, but it does appear to be
related to PRs 49448 and/or 50030.
}-- End of excerpt from John Klos
Home |
Main Index |
Thread Index |
Old Index