Regarding the sata_promise.c patch, I think I have found a bug in the
interrupt handler:
Just before the 'try_hotplug' label, you provide a check that will
kick us out of the interrupt handler if the interrupt was just handled
by a DMA command completing successfully.
However, I have seen the
Another interesting issue with hotplug which may need SCSI-layer changes:
If you unplug a device that some process already has open (for
example, md), the device is removed, but the internal scsi_device
struct is not actually freed until ALL references to this device
(including that still held
On 8/24/05, Stefan Richter [EMAIL PROTECTED] wrote:
Timers appear to operate in an atomic context, so timers should not be
allowed to call scsi_remove_device, which eventually schedules.
Any suggestions on the best way to fix this?
Workqueue, perhaps.
Perhaps. Actually, of course :)
On 8/24/05, Lukasz Kosewski [EMAIL PROTECTED] wrote:
On 8/24/05, Stefan Richter [EMAIL PROTECTED] wrote:
Timers appear to operate in an atomic context, so timers should not be
allowed to call scsi_remove_device, which eventually schedules.
Any suggestions on the best way to fix this?
On 8/24/05, Jim Ramsay [EMAIL PROTECTED] wrote:
On 8/24/05, Lukasz Kosewski [EMAIL PROTECTED] wrote:
On 8/24/05, Stefan Richter [EMAIL PROTECTED] wrote:
Timers appear to operate in an atomic context, so timers should not be
allowed to call scsi_remove_device, which eventually schedules.
On 8/23/05, Jim Ramsay [EMAIL PROTECTED] wrote:
Then I must have found an undocumented feature! I've applied this set
of patches to a 2.6.11 kernel (with few problems) and ran into a bunch
of scheduling while atomic errors when hotplugging a drive, culprit
being probably scsi_sysfs.c where
Jim Ramsay wrote:
On 8/23/05, Jim Ramsay [EMAIL PROTECTED] wrote:
Then I must have found an undocumented feature! I've applied this set
of patches to a 2.6.11 kernel (with few problems) and ran into a bunch
of scheduling while atomic errors when hotplugging a drive, culprit
being probably
On 8/1/05, Lukasz Kosewski [EMAIL PROTECTED] wrote:
Patch 03: Have sata_promise use the perfect, flawless API from the
previous patch
Hmmm... Flawless :)
Then I must have found an undocumented feature! I've applied this set
of patches to a 2.6.11 kernel (with few problems) and ran into a
Patch 03: Have sata_promise use the perfect, flawless API from the
previous patch
As described in the archives, this patch build on patch 02 in the
series to actually allow the sata_promise controller to hotswap. Be
careful, untested!
This version comes with all of Jeff's suggestions
