On Fri, Nov 18, 2005 at 10:19:40AM +0100, Poul-Henning Kamp wrote:
> In message <437d6ab5.7020...@root.org>, Nate Lawson writes:
>
> >> +void
> >> +disk_gone(struct disk *dp)
> >> +{
> >> + struct g_geom *gp;
> >> + struct g_provider *pp;
> >> +
> >> + gp = dp->d_geom;
> >> + if (gp != NULL)
>
jdp 2005-11-26 23:20:00 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_5)
sys/cam/scsi scsi_cd.c scsi_da.c
sys/geom geom_disk.c geom_disk.h geom_subr.c
Log:
MFC: Fix a bug that caused some /dev entries to continue to exist after
t
jdp 2005-11-26 22:55:20 UTC
FreeBSD src repository
Modified files:(Branch: RELENG_6)
sys/cam/scsi scsi_cd.c scsi_da.c
sys/geom geom_disk.c geom_disk.h geom_subr.c
Log:
MFC: Fix a bug that caused some /dev entries to continue to exist after
t
On 19-Nov-2005 M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John Polstra <[EMAIL PROTECTED]> writes:
>: This commit may or may not fix those panics -- I don't really know.
>: There is a lot that can go wrong if you remove a mounted filesystem
>: from the system.
>
> Meanin
In message: <[EMAIL PROTECTED]>
John Polstra <[EMAIL PROTECTED]> writes:
: On 19-Nov-2005 Jeremie Le Hen wrote:
: >> This fix adds a new disk_gone() function which is called by CAM when a
: >> drive goes away. It orphans all of the providers associated with the
: >> drive, settin
On 19-Nov-2005 Jeremie Le Hen wrote:
>> This fix adds a new disk_gone() function which is called by CAM when a
>> drive goes away. It orphans all of the providers associated with the
>> drive, setting an error condition of ENXIO in each one. In addition,
>> we prevent a re-taste on last c
Hi, John,
On Fri, Nov 18, 2005 at 02:43:49AM +, John Polstra wrote:
> jdp 2005-11-18 02:43:49 UTC
>
> FreeBSD src repository
>
> Modified files:
> sys/cam/scsi scsi_cd.c scsi_da.c
> sys/geom geom_disk.c geom_disk.h geom_subr.c
> Log:
> Fix a bug
John Polstra wrote:
On 18-Nov-2005 Scott Long wrote:
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Scott Long writes:
Poul-Henning Kamp wrote:
Most drivers seem to detach their internal state from the struct
disk, and therefore they don't need this.
So what makes CAM spe
On 18-Nov-2005 Scott Long wrote:
> Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Scott Long writes:
>>
>>>Poul-Henning Kamp wrote:
>>
>>
Most drivers seem to detach their internal state from the struct
disk, and therefore they don't need this.
>>>
>>>So what makes CAM
In message <[EMAIL PROTECTED]>, Scott Long writes:
>Poul-Henning Kamp wrote:
>Ok. John's fix seems hackish (no offense John). I'll likely look at
>this in the coming months.
Actually it isn't.
It gives the driver a way to say "this disk is gone" as early as
possible, thus preventing the situat
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Scott Long writes:
Poul-Henning Kamp wrote:
Most drivers seem to detach their internal state from the struct
disk, and therefore they don't need this.
So what makes CAM special in this regard?
I dunno. Cam seems to have a diffe
In message <[EMAIL PROTECTED]>, Scott Long writes:
>Poul-Henning Kamp wrote:
>>
>> Most drivers seem to detach their internal state from the struct
>> disk, and therefore they don't need this.
>>
>
>So what makes CAM special in this regard?
I dunno. Cam seems to have a different lifecycle for
Poul-Henning Kamp wrote:
In message <[EMAIL PROTECTED]>, Scott Long writes:
Lukas Ertl wrote:
What does this mean for other drivers? RAID arrays can come and go
at runtime, either due to drive failure or due to actions by the user
via a management app. I don't recall ever seeing a problem
On Fri, 18 Nov 2005, Scott Long wrote:
What does this mean for other drivers? RAID arrays can come and go
at runtime, either due to drive failure or due to actions by the user
via a management app. I don't recall ever seeing a problem like this
with the aac driver and creating/destroying array
In message <[EMAIL PROTECTED]>, Scott Long writes:
>Lukas Ertl wrote:
>What does this mean for other drivers? RAID arrays can come and go
>at runtime, either due to drive failure or due to actions by the user
>via a management app. I don't recall ever seeing a problem like this
>with the aac dri
Lukas Ertl wrote:
On Fri, 18 Nov 2005, John Polstra wrote:
jdp 2005-11-18 02:43:49 UTC
FreeBSD src repository
Modified files:
sys/cam/scsi scsi_cd.c scsi_da.c
sys/geom geom_disk.c geom_disk.h geom_subr.c
Log:
Fix a bug that caused some /dev entries to con
In message <[EMAIL PROTECTED]>, Nate Lawson writes:
>> +void
>> +disk_gone(struct disk *dp)
>> +{
>> +struct g_geom *gp;
>> +struct g_provider *pp;
>> +
>> +gp = dp->d_geom;
>> +if (gp != NULL)
>> +LIST_FOREACH(pp, &gp->provider, provider)
>> +g_orph
On Fri, 18 Nov 2005, John Polstra wrote:
jdp 2005-11-18 02:43:49 UTC
FreeBSD src repository
Modified files:
sys/cam/scsi scsi_cd.c scsi_da.c
sys/geom geom_disk.c geom_disk.h geom_subr.c
Log:
Fix a bug that caused some /dev entries to continue to exist afte
John Polstra wrote:
jdp 2005-11-18 02:43:49 UTC
FreeBSD src repository
Modified files:
sys/cam/scsi scsi_cd.c scsi_da.c
sys/geom geom_disk.c geom_disk.h geom_subr.c
Log:
Fix a bug that caused some /dev entries to continue to exist after
the under
jdp 2005-11-18 02:43:49 UTC
FreeBSD src repository
Modified files:
sys/cam/scsi scsi_cd.c scsi_da.c
sys/geom geom_disk.c geom_disk.h geom_subr.c
Log:
Fix a bug that caused some /dev entries to continue to exist after
the underlying drive had been ho
20 matches
Mail list logo
