Hi everyone,
I'm still quite new to Mikrotik and RouterOS and ran into following problem:

Every 6 minutes ports 6, 7, 8 ,9 , 10 went link down and came up again (flapping).
First i tried disabling MSTP on the bridge by setting STP to NONE. After that the port flapped a little less regular. Sometimes they stayed up for 10 minutes or so.
The real solution was disabling rx/tx flow-control which was enabled on port 6, 7 and 8. Any idea why flow-control can cause the whole switch chip to reset or how to debug flapping reasons more systematic? It was more or less a coincidence that I found out flow-control seemed to cause it.

In general: I always thought flow control is good to avoid packet loss when several devices try to send/receive data to/from a port that has limited bandwidth by artificially slowing down transmission. Wouldn't that be a good idea for e.g. ports where only 100Mbit devices are connected or servers that are often used by several clients?

Btw: For sure I'll post my config and some logs in case it's required. I just wanted to get a first impression if this is somehow expected by more experienced users and if I understood the feature correct.

i tried disabling MSTP on the bridge

Unless you have multi-path networking in the face of VLANs and need to scope different rules to particular VLANs or sets of them, you should be using RSTP instead.

setting STP to NONE

In my experience, that's usually either a mistake engendered by a misunderstanding of what STP does and what it's for, or done to deal with something that doesn't implement Ethernet properly. Some form of STP should almost always be enabled unless you know for a fact that it's causing problems and that problem can't be fixed some better way.

For instance, I've seen network engineers do this to speed old-school STP up when they should instead be setting ports that can never loop to "Edge", in order to bypass most of the delay involved with the original STP protocol.

Okay, you may say, but it's faster, so it's better, right? That's true as long as that "can never loop" condition remains true. Then some yo-yo moves their VoIP phone to another side of the desk and in the process finds that it has a loop-through feature and decides both ports should be plugged into the room's uplink ports, not realizing that it previously had only one connected for a very good reason. Boom, down goes your network.

I always thought flow control is good

It would be if it were widely supported and obeyed, but it isn't, which is why it's disabled by default.

Most of the time it's pointless since TCP has flow control built into it, and most non-TCP protocols (e.g. DNS, NTP…) can't normally cause the levels of network congestion that make flow control necessary. Unless you're in the rare condition of having high-bandwidth non-TCP flows and you know all of the devices involved properly support hardware flow control, you should leave it disabled.

Wouldn't that be a good idea for e.g. ports where only 100Mbit devices are connected

If you've got slow devices that are getting spammed off the network, there are usually better solutions than Ethernet flow control:

1. use ROS queueing instead
2. enable as much broadcast and multicast filtering as you can on those ports, consistent with maintaining required services
3. put the affected devices into another VLAN, and set up careful routing and firewalling to keep unwanted traffic out of that VLAN
4. for cases where a given network device only needs to talk to one other peer or a small set of them, move them to another physical LAN; for instance, you might have an ancient laser printer that gets spammed off the network by Windows Network Neighborhood broadcast storms, but only one PC actually needs to use that printer still, and it has a second Ethernet port, so you could use that port to set up a private point-to-point network between those two hosts