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 occ
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 eve
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 be
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. Actual
George Anzinger wrote:
Jim Ramsay wrote:
On 8/23/05, Jim Ramsay <[EMAIL PROTECTED]> wrote:
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
...
After f
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/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 w
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 (documente
This patch is an implementation of hotswap on the sata_promise module,
tested on SATA150 and SATAII150 Promise controllers. It depends on
patch 01 from this series of patches to apply, and both 01 and 02 in
order to compile.
We handle hotplug interrupts and call our new API functions in libat
10 matches
Mail list logo
