As a follow up, I had this happen again, without rebooting after running "atacontrol reinit ata4". That worked a few times, but the interval between failed requests was very small... At some point, reiniting the channel simply said "no devices attached" and I went and bought a new disk, fearing the worst. Placing that on the channel, I attempted "atacontrol reinit" again and it still refused to see the new disk. I tested both the new and old disks with a different controller and they worked fine. On the suggestion of ##freebsd, I ran "atacontrol detach ata4" and "atacontrol attach ata4"; the former completed, the latter produced this (via serial console): hydra# atacontrol attach ata4 ata4: [ITHREAD] 60201-4533^[[2;2~Master: no device present Slave: no device present ast data access mmu miss t ra p: f cpuid = 0 which I assume really meant to be "trap: fast data access mmu miss". I amn't sure what that means, but I have this lovely multi-gig core file now... which is potentially of little utility since I get told "GDB can't read core files on this machine." but if somebody wants something out of it, just ask. In any case, I powered the machine off, put the old disk back, and rebooted and am now scrubbing the RAIDZ, but it sees the old disk just fine. Suggestions? --nwf;
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC