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
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
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
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
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.
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, 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.
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
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
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
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
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
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
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
17 matches
Mail list logo
