>>
>> The events are not lost.
>
> In sas_queue_event(), if there is a particular event pending for a port/PHY,
> we cannot queue further same event types for that port/PHY. I think my
> colleagues found issue where we try to enqueue multiple complementary events.
Yes, we found this issue in
>>
>> The events are not lost.
>
> In sas_queue_event(), if there is a particular event pending for a port/PHY,
> we cannot queue further same event types for that port/PHY. I think my
> colleagues found issue where we try to enqueue multiple complementary events.
Yes, we found this issue in
On 21/11/2016 17:13, Dan Williams wrote:
On Mon, Nov 21, 2016 at 7:16 AM, John Garry wrote:
@Maintainers, would you be willing to accept this patch as an interim
fix
for the dastardly WARN while we try to fix the flutter issue?
To me this adds a bug to quiet a
On 21/11/2016 17:13, Dan Williams wrote:
On Mon, Nov 21, 2016 at 7:16 AM, John Garry wrote:
@Maintainers, would you be willing to accept this patch as an interim
fix
for the dastardly WARN while we try to fix the flutter issue?
To me this adds a bug to quiet a benign, albeit noisy,
On Mon, Nov 21, 2016 at 7:16 AM, John Garry wrote:
> @Maintainers, would you be willing to accept this patch as an interim
> fix
> for the dastardly WARN while we try to fix the flutter issue?
To me this adds a bug to quiet a benign, albeit
On Mon, Nov 21, 2016 at 7:16 AM, John Garry wrote:
> @Maintainers, would you be willing to accept this patch as an interim
> fix
> for the dastardly WARN while we try to fix the flutter issue?
To me this adds a bug to quiet a benign, albeit noisy, warning.
>>>
@Maintainers, would you be willing to accept this patch as an interim fix
for the dastardly WARN while we try to fix the flutter issue?
To me this adds a bug to quiet a benign, albeit noisy, warning.
What is the bug which is being added?
The bug where we queue a port teardown, but see a
@Maintainers, would you be willing to accept this patch as an interim fix
for the dastardly WARN while we try to fix the flutter issue?
To me this adds a bug to quiet a benign, albeit noisy, warning.
What is the bug which is being added?
The bug where we queue a port teardown, but see a
On Fri, Nov 18, 2016 at 1:00 AM, John Garry wrote:
> On 18/11/2016 01:53, Dan Williams wrote:
>>
>> On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
>>>
>>> On 11/11/2016 08:49, wangyijing wrote:
>>>
>>>
>>> I have not seen the flutter
On Fri, Nov 18, 2016 at 1:00 AM, John Garry wrote:
> On 18/11/2016 01:53, Dan Williams wrote:
>>
>> On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
>>>
>>> On 11/11/2016 08:49, wangyijing wrote:
>>>
>>>
>>> I have not seen the flutter issue. I am just trying to solve the
>>>
On 18/11/2016 01:53, Dan Williams wrote:
On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
On 11/11/2016 08:49, wangyijing wrote:
I have not seen the flutter issue. I am just trying to solve the
horrible WARN dump.
However I do understand that there may be a issue
On 18/11/2016 01:53, Dan Williams wrote:
On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
On 11/11/2016 08:49, wangyijing wrote:
I have not seen the flutter issue. I am just trying to solve the
horrible WARN dump.
However I do understand that there may be a issue related to how we
queue
On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
> On 11/11/2016 08:49, wangyijing wrote:
>
> I have not seen the flutter issue. I am just trying to solve the
> horrible WARN dump.
> However I do understand that there may be a issue related to how we
>
On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
> On 11/11/2016 08:49, wangyijing wrote:
>
> I have not seen the flutter issue. I am just trying to solve the
> horrible WARN dump.
> However I do understand that there may be a issue related to how we
> queue the events;
> "John" == John Garry writes:
John> @Maintainers, would you be willing to accept this patch as an
John> interim fix for the dastardly WARN while we try to fix the flutter
John> issue?
I'll defer to James since I don't have much libsas experience.
--
Martin K.
> "John" == John Garry writes:
John> @Maintainers, would you be willing to accept this patch as an
John> interim fix for the dastardly WARN while we try to fix the flutter
John> issue?
I'll defer to James since I don't have much libsas experience.
--
Martin K. Petersen Oracle Linux
On 11/11/2016 08:49, wangyijing wrote:
I have not seen the flutter issue. I am just trying to solve the horrible WARN
dump.
However I do understand that there may be a issue related to how we queue the
events; there was a recent attempt to fix this, but it came to nothing:
On 11/11/2016 08:49, wangyijing wrote:
I have not seen the flutter issue. I am just trying to solve the horrible WARN
dump.
However I do understand that there may be a issue related to how we queue the
events; there was a recent attempt to fix this, but it came to nothing:
>>> I have not seen the flutter issue. I am just trying to solve the horrible
>>> WARN dump.
>>> However I do understand that there may be a issue related to how we queue
>>> the events; there was a recent attempt to fix this, but it came to nothing:
>>>
>>> I have not seen the flutter issue. I am just trying to solve the horrible
>>> WARN dump.
>>> However I do understand that there may be a issue related to how we queue
>>> the events; there was a recent attempt to fix this, but it came to nothing:
>>>
On 11/11/2016 08:12, wangyijing wrote:
They're not the same. I don't see how your solution properly deals with remote
sas_port deletion.
When we unplug a device connected to an expander, can't the sas_port be deleted
twice, in sas_unregister_devs_sas_addr() from domain revalidation and also
On 11/11/2016 08:12, wangyijing wrote:
They're not the same. I don't see how your solution properly deals with remote
sas_port deletion.
When we unplug a device connected to an expander, can't the sas_port be deleted
twice, in sas_unregister_devs_sas_addr() from domain revalidation and also
>
> They're not the same. I don't see how your solution properly deals with
> remote sas_port deletion.
>
> When we unplug a device connected to an expander, can't the sas_port be
> deleted twice, in sas_unregister_devs_sas_addr() from domain revalidation and
> also now in
>
> They're not the same. I don't see how your solution properly deals with
> remote sas_port deletion.
>
> When we unplug a device connected to an expander, can't the sas_port be
> deleted twice, in sas_unregister_devs_sas_addr() from domain revalidation and
> also now in
On 09/11/2016 20:35, Dan Williams wrote:
On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams wrote:
On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote:
On 09/11/2016 12:28, John Garry wrote:
On 03/11/2016 14:58, John Garry wrote:
The following
On 09/11/2016 20:35, Dan Williams wrote:
On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams wrote:
On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote:
On 09/11/2016 12:28, John Garry wrote:
On 03/11/2016 14:58, John Garry wrote:
The following patch introduces an annoying WARN
when a device is
On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams wrote:
> On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote:
>> On 09/11/2016 12:28, John Garry wrote:
>>>
>>> On 03/11/2016 14:58, John Garry wrote:
The following patch introduces an annoying
On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams wrote:
> On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote:
>> On 09/11/2016 12:28, John Garry wrote:
>>>
>>> On 03/11/2016 14:58, John Garry wrote:
The following patch introduces an annoying WARN
when a device is removed from the SAS
On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote:
> On 09/11/2016 12:28, John Garry wrote:
>>
>> On 03/11/2016 14:58, John Garry wrote:
>>>
>>> The following patch introduces an annoying WARN
>>> when a device is removed from the SAS topology:
>>> [SCSI] libsas: prevent
On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote:
> On 09/11/2016 12:28, John Garry wrote:
>>
>> On 03/11/2016 14:58, John Garry wrote:
>>>
>>> The following patch introduces an annoying WARN
>>> when a device is removed from the SAS topology:
>>> [SCSI] libsas: prevent domain rediscovery
On 03/11/2016 14:58, John Garry wrote:
The following patch introduces an annoying WARN
when a device is removed from the SAS topology:
[SCSI] libsas: prevent domain rediscovery competing with ata error handling
Are there any views on this patch? I would have thought that the parties
who use
On 03/11/2016 14:58, John Garry wrote:
The following patch introduces an annoying WARN
when a device is removed from the SAS topology:
[SCSI] libsas: prevent domain rediscovery competing with ata error handling
Are there any views on this patch? I would have thought that the parties
who use
32 matches
Mail list logo