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
9 matches
Mail list logo
