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