Searched hist:235014 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-11-stable/sys/dev/mfi/ | ||
| H A D | mfi_tbolt.c | diff 235014 Fri May 04 14:07:40 MDT 2012 ambrisko First fix pr 167226: ThunderBolt cannot read sector >= 2^32 or 2^21 with supplied patch. Second the bigger change, fix RAID operation on ThunderBolt base card such as physically removing a disk from a RAID and replacing it. The current situation is the RAID firmware effectively hangs waiting for an acknowledgement from the driver. This is due to the firmware support of the driver actually accessing the RAID from under the firmware. This is an interesting feature that the FreeBSD driver does not use. However, when the firmare detects the driver has attached it then expects the driver will synchronize LD's with the firmware. If the driver does not sync. then the management part of the firmware will hang waiting for it so a pulled driver will listed as still there. The fix for this problem isn't extremely difficult. However, figuring out why some of the code was the way it was and then redoing it was involved. Not have a spec. made it harder to try to figure out. The existing driver would send a MFI_DCMD_LD_MAP_GET_INFO command in write mode to acknowledge a LD state change. In read mode it gets the RAID map from the firmware. The FreeBSD driver doesn't do that currently. It could be added in the future with the appropriate structures. To simplify things, get the current LD state and then build the MFI_DCMD_LD_MAP_GET_INFO/write command so that it sends an acknowledgement for each LD. The map would probably state which LD's changed so then the driver could probably just acknowledge the LD's that changed versus all. This doesn't seem to be a problem. When a MFI_DCMD_LD_MAP_GET_INFO/write command is sent to the firmware, it will complete later when a change to the LD's happen. So it is very much like an AEN command returning when something happened. When the MFI_DCMD_LD_MAP_GET_INFO/write command completes, we refire the sync'ing of the LD state. This needs to be done in as an event so that MFI_DCMD_LD_GET_LIST can wait for that command to complete before issuing the MFI_DCMD_LD_MAP_GET_INFO/write. The prior code didn't use the call-back function and tried to intercept the MFI_DCMD_LD_MAP_GET_INFO/write command when processing an interrupt. This added a bunch of code complexity to the interrupt handler. Using the call-back that is done for other commands got rid of this need. So the interrupt handler is greatly simplified. It seems that even commands that shouldn't be acknowledged end up in the interrupt handler. To deal with this, code was added to check to see if a command is in the busy queue or not. This might have contributed to the interrupt storm happening without MSI enabled on these cards. Note that MFI_DCMD_LD_MAP_GET_INFO/read returns right away. It would be interesting to see what other complexity could be removed from the ThunderBolt driver that really isn't needed in our mode of operation. Letting the RAID firmware do all of the I/O to disks is a lot faster since it can use its caches. It greatly simplifies what the driver has to do and potential bugs if the driver and firmware are not in sync. Simplify the aen_abort/cm_map_abort and put it in the softc versus in the command structure. This should get merged to 9 before the driver is merged to 8. PR: 167226 Submitted by: Petr Lampa MFC after: 3 days |
| H A D | mfi.c | diff 235014 Fri May 04 14:07:40 MDT 2012 ambrisko First fix pr 167226: ThunderBolt cannot read sector >= 2^32 or 2^21 with supplied patch. Second the bigger change, fix RAID operation on ThunderBolt base card such as physically removing a disk from a RAID and replacing it. The current situation is the RAID firmware effectively hangs waiting for an acknowledgement from the driver. This is due to the firmware support of the driver actually accessing the RAID from under the firmware. This is an interesting feature that the FreeBSD driver does not use. However, when the firmare detects the driver has attached it then expects the driver will synchronize LD's with the firmware. If the driver does not sync. then the management part of the firmware will hang waiting for it so a pulled driver will listed as still there. The fix for this problem isn't extremely difficult. However, figuring out why some of the code was the way it was and then redoing it was involved. Not have a spec. made it harder to try to figure out. The existing driver would send a MFI_DCMD_LD_MAP_GET_INFO command in write mode to acknowledge a LD state change. In read mode it gets the RAID map from the firmware. The FreeBSD driver doesn't do that currently. It could be added in the future with the appropriate structures. To simplify things, get the current LD state and then build the MFI_DCMD_LD_MAP_GET_INFO/write command so that it sends an acknowledgement for each LD. The map would probably state which LD's changed so then the driver could probably just acknowledge the LD's that changed versus all. This doesn't seem to be a problem. When a MFI_DCMD_LD_MAP_GET_INFO/write command is sent to the firmware, it will complete later when a change to the LD's happen. So it is very much like an AEN command returning when something happened. When the MFI_DCMD_LD_MAP_GET_INFO/write command completes, we refire the sync'ing of the LD state. This needs to be done in as an event so that MFI_DCMD_LD_GET_LIST can wait for that command to complete before issuing the MFI_DCMD_LD_MAP_GET_INFO/write. The prior code didn't use the call-back function and tried to intercept the MFI_DCMD_LD_MAP_GET_INFO/write command when processing an interrupt. This added a bunch of code complexity to the interrupt handler. Using the call-back that is done for other commands got rid of this need. So the interrupt handler is greatly simplified. It seems that even commands that shouldn't be acknowledged end up in the interrupt handler. To deal with this, code was added to check to see if a command is in the busy queue or not. This might have contributed to the interrupt storm happening without MSI enabled on these cards. Note that MFI_DCMD_LD_MAP_GET_INFO/read returns right away. It would be interesting to see what other complexity could be removed from the ThunderBolt driver that really isn't needed in our mode of operation. Letting the RAID firmware do all of the I/O to disks is a lot faster since it can use its caches. It greatly simplifies what the driver has to do and potential bugs if the driver and firmware are not in sync. Simplify the aen_abort/cm_map_abort and put it in the softc versus in the command structure. This should get merged to 9 before the driver is merged to 8. PR: 167226 Submitted by: Petr Lampa MFC after: 3 days |
Completed in 173 milliseconds