Searched hist:187993 (Results 1 - 4 of 4) sorted by relevance
| /freebsd-11-stable/sys/dev/firewire/ | ||
| H A D | fwohci_pci.c | diff 187993 Sun Feb 01 21:40:34 MST 2009 sbruno Some updates and bug squashing in the firewire stack. Move the interupt handler to a driver_intr_t type function as it was trying to do way to much for a lightweight filter interrupt function. Introduce much more locking around fc->mtx. Tested this for lock reversals and other such lockups. Locking seems to be working better, but there is much more to do with regard to locking. The most significant lock is in the BUS RESET handler. It was possible, before this checkin, to set a bus reset via "fwcontrol -r" and have the BUS RESET handler fire before the code responsible for asserting BUS RESET was complete. This locking fixes that issue. Move some of the memory allocations in the fc struct to the attach function in firewire.c Rework the businfo.generation indicator to be merely a on/off bit now. It's purpose according to spec is to notify the bus that the config ROM has changed. That's it. Catch and squash a possible panic in SBP where in the SBP_LOCK was held during a possible error case. The error handling code would definitely panic as it would try to acquire the SBP_LOCK on entrance. Catch and squash a camcontrol/device lockup when firewire drives go away. When a firewire device was powered off or disconnected from the firewire bus, a "camcontrol rescan all" would hang trying to poll removed devices as they were not properly detached. Don't do that. Approved by: scottl MFC after: 2 weeks |
| H A D | fwohci.c | diff 187993 Sun Feb 01 21:40:34 MST 2009 sbruno Some updates and bug squashing in the firewire stack. Move the interupt handler to a driver_intr_t type function as it was trying to do way to much for a lightweight filter interrupt function. Introduce much more locking around fc->mtx. Tested this for lock reversals and other such lockups. Locking seems to be working better, but there is much more to do with regard to locking. The most significant lock is in the BUS RESET handler. It was possible, before this checkin, to set a bus reset via "fwcontrol -r" and have the BUS RESET handler fire before the code responsible for asserting BUS RESET was complete. This locking fixes that issue. Move some of the memory allocations in the fc struct to the attach function in firewire.c Rework the businfo.generation indicator to be merely a on/off bit now. It's purpose according to spec is to notify the bus that the config ROM has changed. That's it. Catch and squash a possible panic in SBP where in the SBP_LOCK was held during a possible error case. The error handling code would definitely panic as it would try to acquire the SBP_LOCK on entrance. Catch and squash a camcontrol/device lockup when firewire drives go away. When a firewire device was powered off or disconnected from the firewire bus, a "camcontrol rescan all" would hang trying to poll removed devices as they were not properly detached. Don't do that. Approved by: scottl MFC after: 2 weeks |
| H A D | firewire.c | diff 187993 Sun Feb 01 21:40:34 MST 2009 sbruno Some updates and bug squashing in the firewire stack. Move the interupt handler to a driver_intr_t type function as it was trying to do way to much for a lightweight filter interrupt function. Introduce much more locking around fc->mtx. Tested this for lock reversals and other such lockups. Locking seems to be working better, but there is much more to do with regard to locking. The most significant lock is in the BUS RESET handler. It was possible, before this checkin, to set a bus reset via "fwcontrol -r" and have the BUS RESET handler fire before the code responsible for asserting BUS RESET was complete. This locking fixes that issue. Move some of the memory allocations in the fc struct to the attach function in firewire.c Rework the businfo.generation indicator to be merely a on/off bit now. It's purpose according to spec is to notify the bus that the config ROM has changed. That's it. Catch and squash a possible panic in SBP where in the SBP_LOCK was held during a possible error case. The error handling code would definitely panic as it would try to acquire the SBP_LOCK on entrance. Catch and squash a camcontrol/device lockup when firewire drives go away. When a firewire device was powered off or disconnected from the firewire bus, a "camcontrol rescan all" would hang trying to poll removed devices as they were not properly detached. Don't do that. Approved by: scottl MFC after: 2 weeks |
| H A D | sbp.c | diff 187993 Sun Feb 01 21:40:34 MST 2009 sbruno Some updates and bug squashing in the firewire stack. Move the interupt handler to a driver_intr_t type function as it was trying to do way to much for a lightweight filter interrupt function. Introduce much more locking around fc->mtx. Tested this for lock reversals and other such lockups. Locking seems to be working better, but there is much more to do with regard to locking. The most significant lock is in the BUS RESET handler. It was possible, before this checkin, to set a bus reset via "fwcontrol -r" and have the BUS RESET handler fire before the code responsible for asserting BUS RESET was complete. This locking fixes that issue. Move some of the memory allocations in the fc struct to the attach function in firewire.c Rework the businfo.generation indicator to be merely a on/off bit now. It's purpose according to spec is to notify the bus that the config ROM has changed. That's it. Catch and squash a possible panic in SBP where in the SBP_LOCK was held during a possible error case. The error handling code would definitely panic as it would try to acquire the SBP_LOCK on entrance. Catch and squash a camcontrol/device lockup when firewire drives go away. When a firewire device was powered off or disconnected from the firewire bus, a "camcontrol rescan all" would hang trying to poll removed devices as they were not properly detached. Don't do that. Approved by: scottl MFC after: 2 weeks |
Completed in 158 milliseconds