mps(4) blocks panic-reboot

Harry Schmalzbauer freebsd at omnilan.de
Thu Jun 1 18:03:27 UTC 2017


Bezüglich Stephen Mcconnell's Nachricht vom 01.06.2017 19:36 (localtime):
> Can you try the attached patch and let me know how it goes? I didn't test
> it, but since you know how, it might be easier this way. This was diff'd
> from the latest mps files in stable/11, which I recently updated (today).

Thanks a lot, I noticed the highly appreciated MFC!
Things are cooking... There were sysdecode userland changes, so I need
to buidl world also, before my rollout system provides the update for
this machine – will be ready in an hour.

Since I have expert's attention, I'd like to ask a another mps(4)
related question:

I had unionfs deadlocks.  (I'm aware of the broken status of unionfs,
and since I'm not able to fix it myself at the moment, I already
replaced it with nullfs where possible, true for the following event)

Since this machine has a memory-disk as rootfs (and 5 SSDs via mps(4)
for bootpool and a separate syspool, where /var e.g. lives), I guess the
deadlock is responsible for simultanious disappearance of all mps(4)
attached drives.

Is that plausable? (meaning, does the mps(4) driver depend on filesystem
subsystem?)

Or do you have any idea what else could lead to disapearance of all
drives simultaniously? Other ata drives, via on-board ahci (C203) were
not affected! UNfortunately, I haven't been able to record any kernel
messages when that happened (3 times as far as I remember, no occurence
since abandoning unionfs yet)

Thanks,

-harry


More information about the freebsd-scsi mailing list