Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Todd Denniston wrote: [snip] > > > as Brandon indicated DRBD is doing the correct thing by panicking, when the > scsi device goes nuts. > > This looks very much like a hardware problem. Assuming no hardware has > intentionally changed on the scsi bus I would [no warranties on my > procedures] > 1) disconnect and reconnect each connection in the scsi bus (too often I > have seen corrosion muck up a scsi bus) , including the terminator(s) if > they are not built into the device logically. > > 2) verify the last device on the buss is either a proper terminator (that is > working) or the last device has internal termination turned on. > > seeing the 'ata3:' above the scsi error makes me want to think you have SATA > hardware, which IIRC current linux is presenting as scsi devices. > > 3) in either case, backup any data and run badblocks in full write mode and > Brandon's suggestions on the physical device. > Thanks for the ideas, ive been testing the underlying with `badblocks -sw /dev/sdb1` and `sdc1` all weekend long, and havent found nothing at all. About that SATA thing - that's true, ive got two sata devices on which drbd resides, so i pressume that there aint problems with connectors, and corrosion is the second thing we can exclude from problem causers ;) Actually it seems like some weird HW problem, cuz the secondary node is running fine for about 4 days w/o problems instead of the primary which crashed 8h after bootup. Any ideas and thoughts about this will be greatly appreciated ;)