Searched hist:157354 (Results 1 - 5 of 5) sorted by relevance
| /freebsd-9.3-release/sys/dev/mpt/ | ||
| H A D | mpt_debug.c | diff 157354 Sat Apr 01 05:12:18 MST 2006 mjacob Fix some of the previus changes 'better'. There's something strange going on with async events. They seem to be be treated differently for different Fusion implementations. Some will really tell you when it's okay to free the request that started them. Some won't. Very disconcerting. This is particularily bad when the chip (FC in this case) tells you in the reply that it's not a continuation reply, which means you can free the request that its associated with. However, if you do that, I've found that additional async event replies come back for that message context after you freed it. Very Bad Things Happen. Put in a reply register debounce. Warn about out of range context indices. Use more MPILIB defines where possible. Replace bzero with memset. Add tons more KASSERTS. Do a *lot* more request free list auditting and serial number usages. Get rid of the warning about the short IOC Facts Reply. Go back to 16 bits of context index. Do a lot more target state auditting as well. Make a tag out of not only the ioindex but the request index as well and worry less about keeping a full serial number. |
| H A D | mpt.c | diff 157354 Sat Apr 01 05:12:18 MST 2006 mjacob Fix some of the previus changes 'better'. There's something strange going on with async events. They seem to be be treated differently for different Fusion implementations. Some will really tell you when it's okay to free the request that started them. Some won't. Very disconcerting. This is particularily bad when the chip (FC in this case) tells you in the reply that it's not a continuation reply, which means you can free the request that its associated with. However, if you do that, I've found that additional async event replies come back for that message context after you freed it. Very Bad Things Happen. Put in a reply register debounce. Warn about out of range context indices. Use more MPILIB defines where possible. Replace bzero with memset. Add tons more KASSERTS. Do a *lot* more request free list auditting and serial number usages. Get rid of the warning about the short IOC Facts Reply. Go back to 16 bits of context index. Do a lot more target state auditting as well. Make a tag out of not only the ioindex but the request index as well and worry less about keeping a full serial number. |
| H A D | mpt.h | diff 157354 Sat Apr 01 05:12:18 MST 2006 mjacob Fix some of the previus changes 'better'. There's something strange going on with async events. They seem to be be treated differently for different Fusion implementations. Some will really tell you when it's okay to free the request that started them. Some won't. Very disconcerting. This is particularily bad when the chip (FC in this case) tells you in the reply that it's not a continuation reply, which means you can free the request that its associated with. However, if you do that, I've found that additional async event replies come back for that message context after you freed it. Very Bad Things Happen. Put in a reply register debounce. Warn about out of range context indices. Use more MPILIB defines where possible. Replace bzero with memset. Add tons more KASSERTS. Do a *lot* more request free list auditting and serial number usages. Get rid of the warning about the short IOC Facts Reply. Go back to 16 bits of context index. Do a lot more target state auditting as well. Make a tag out of not only the ioindex but the request index as well and worry less about keeping a full serial number. |
| H A D | mpt_pci.c | diff 157354 Sat Apr 01 05:12:18 MST 2006 mjacob Fix some of the previus changes 'better'. There's something strange going on with async events. They seem to be be treated differently for different Fusion implementations. Some will really tell you when it's okay to free the request that started them. Some won't. Very disconcerting. This is particularily bad when the chip (FC in this case) tells you in the reply that it's not a continuation reply, which means you can free the request that its associated with. However, if you do that, I've found that additional async event replies come back for that message context after you freed it. Very Bad Things Happen. Put in a reply register debounce. Warn about out of range context indices. Use more MPILIB defines where possible. Replace bzero with memset. Add tons more KASSERTS. Do a *lot* more request free list auditting and serial number usages. Get rid of the warning about the short IOC Facts Reply. Go back to 16 bits of context index. Do a lot more target state auditting as well. Make a tag out of not only the ioindex but the request index as well and worry less about keeping a full serial number. |
| H A D | mpt_cam.c | diff 157354 Sat Apr 01 05:12:18 MST 2006 mjacob Fix some of the previus changes 'better'. There's something strange going on with async events. They seem to be be treated differently for different Fusion implementations. Some will really tell you when it's okay to free the request that started them. Some won't. Very disconcerting. This is particularily bad when the chip (FC in this case) tells you in the reply that it's not a continuation reply, which means you can free the request that its associated with. However, if you do that, I've found that additional async event replies come back for that message context after you freed it. Very Bad Things Happen. Put in a reply register debounce. Warn about out of range context indices. Use more MPILIB defines where possible. Replace bzero with memset. Add tons more KASSERTS. Do a *lot* more request free list auditting and serial number usages. Get rid of the warning about the short IOC Facts Reply. Go back to 16 bits of context index. Do a lot more target state auditting as well. Make a tag out of not only the ioindex but the request index as well and worry less about keeping a full serial number. |
Completed in 191 milliseconds