On Mon, 5 Sep 2016, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Mon, 5 Sep 2016, Felipe Balbi wrote:
> >
> >> okay, I'm thinking that's a plausible explanation, please correct me if
> >> I'm wrong. What I'm speculating now is that inside a locked region,
> >> reordering can happen (c
Hi,
Alan Stern writes:
> On Mon, 5 Sep 2016, Felipe Balbi wrote:
>
>> okay, I'm thinking that's a plausible explanation, please correct me if
>> I'm wrong. What I'm speculating now is that inside a locked region,
>> reordering can happen (can it?)
>
> Yes, it can.
alright, thanks
>> which mean
On Mon, 5 Sep 2016, Felipe Balbi wrote:
> okay, I'm thinking that's a plausible explanation, please correct me if
> I'm wrong. What I'm speculating now is that inside a locked region,
> reordering can happen (can it?)
Yes, it can.
> which means that our:
>
> spin_lock(&common->lock);
>
On Mon, 5 Sep 2016, Felipe Balbi wrote:
> >> [ 34.123281] ==> bulk_out_complete 484
> >
> > received CBW. Now, bh->state is set to BUF_STATE_FULL, and ...
> >
> >> [ 34.123283] ==> wakeup_thread 403: caller
> >> usb_gadget_giveback_request+0x7/0x10: thread_wakeup_needed = 1
> >
> > wakeup_thr
Hi,
Felipe Balbi writes:
[..]
> okay, I found the one place where changing smp_wmb() to smp_mb() solves
> the problem
>
> @@ -395,7 +395,7 @@ static int fsg_set_halt(struct fsg_dev *fsg, struct
> usb_ep *ep)
> /* Caller must hold fsg->lock */
> static void wakeup_thread(struct fsg_common *c
Hi,
Felipe Balbi writes:
>>> get_next_command() still sees bh->state != BUF_STATE_FULL.
>>>
[ 34.123286] ===> sleep_thread 634: caller fsg_main_thread+0xaa1/0xb00
[usb_f_mass_storage]: going to sleep
[ 34.123289] ===> sleep_thread 634: caller fsg_main_thread+0xaa1/0xb00
Hi,
Felipe Balbi writes:
[...]
>> get_next_command() still sees bh->state != BUF_STATE_FULL.
>>
>>> [ 34.123286] ===> sleep_thread 634: caller fsg_main_thread+0xaa1/0xb00
>>> [usb_f_mass_storage]: going to sleep
>>> [ 34.123289] ===> sleep_thread 634: caller fsg_main_thread+0xaa1/0xb00
>
Hi Alan,
Felipe Balbi writes:
> Hi,
>
> Alan Stern writes:
>> On Sat, 3 Sep 2016, Felipe Balbi wrote:
>>
>>> Hi,
>>>
>>> Alan Stern writes:
>>> > On Fri, 2 Sep 2016, Felipe Balbi wrote:
>>> >
>>> >>
>>> >> Hi,
>>> >>
>>> >> Alan Stern writes:
>>> >>
>>> >> [...]
>>> >>
>>> >> > No, that
Hi,
Alan Stern writes:
> On Sat, 3 Sep 2016, Felipe Balbi wrote:
>
>> Hi,
>>
>> Alan Stern writes:
>> > On Fri, 2 Sep 2016, Felipe Balbi wrote:
>> >
>> >>
>> >> Hi,
>> >>
>> >> Alan Stern writes:
>> >>
>> >> [...]
>> >>
>> >> > No, that would be too late. The barrier needs to go between
On Sat, 3 Sep 2016, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Fri, 2 Sep 2016, Felipe Balbi wrote:
> >
> >>
> >> Hi,
> >>
> >> Alan Stern writes:
> >>
> >> [...]
> >>
> >> > No, that would be too late. The barrier needs to go between the write
> >> > to common->thead_wakeup_
Hi,
Alan Stern writes:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
>>
>> Hi,
>>
>> Alan Stern writes:
>>
>> [...]
>>
>> > No, that would be too late. The barrier needs to go between the write
>> > to common->thead_wakeup_needed and the call to wake_up_process().
>>
>> alright, I tested
On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
> Hi,
>
> Alan Stern writes:
>
> [...]
>
> > No, that would be too late. The barrier needs to go between the write
> > to common->thead_wakeup_needed and the call to wake_up_process().
>
> alright, I tested this but it doesn't work. It still hang
Hi,
Alan Stern writes:
[...]
> No, that would be too late. The barrier needs to go between the write
> to common->thead_wakeup_needed and the call to wake_up_process().
alright, I tested this but it doesn't work. It still hangs :-(
--
balbi
--
To unsubscribe from this list: send the lin
Hi,
Alan Stern writes:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
>> >> I just noticed that the kerneldoc for wake_up_process() says that the
>> >> caller should assume a write memory barrier if and only if any tasks
>> >> are woken up. So if the task is already running, there is no barrier.
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> >> I just noticed that the kerneldoc for wake_up_process() says that the
> >> caller should assume a write memory barrier if and only if any tasks
> >> are woken up. So if the task is already running, there is no barrier.
> >>
> >> This means that in f_
Hi,
Felipe Balbi writes:
> Hi,
>
> Alan Stern writes:
>> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>>
>>> I'm thinking we might have a race WRT our use of memory barriers; could
>>> it be?
>>>
>>> /me goes try
>>>
>>> Yeah, I've converted all smp_[wr]mb() to smp_mb() and the problem went
>>> aw
Hi,
Alan Stern writes:
> On Fri, 2 Sep 2016, Felipe Balbi wrote:
>
>> I'm thinking we might have a race WRT our use of memory barriers; could
>> it be?
>>
>> /me goes try
>>
>> Yeah, I've converted all smp_[wr]mb() to smp_mb() and the problem went
>> away (apparently). It was failing on first
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> I'm thinking we might have a race WRT our use of memory barriers; could
> it be?
>
> /me goes try
>
> Yeah, I've converted all smp_[wr]mb() to smp_mb() and the problem went
> away (apparently). It was failing on first iteration of my test but it
> has no
Hi,
Felipe Balbi writes:
> [ Unknown signature status ]
>
> Hi,
>
> Felipe Balbi writes:
> Any ideas on how to debug this would be apreciated.
You can start by enabling verbose debugging in f_mass_storage.c.
Uncomment the two lines that say:
/* #define VERBOSE_DEBU
Hi,
Felipe Balbi writes:
Any ideas on how to debug this would be apreciated.
>>>
>>> You can start by enabling verbose debugging in f_mass_storage.c.
>>> Uncomment the two lines that say:
>>>
>>> /* #define VERBOSE_DEBUG */
>>> /* #define DUMP_MSGS */
>>>
>>> You'll probably also have to e
Hi,
Felipe Balbi writes:
[...]
>>> Any ideas on how to debug this would be apreciated.
>>
>> You can start by enabling verbose debugging in f_mass_storage.c.
>> Uncomment the two lines that say:
>>
>> /* #define VERBOSE_DEBUG */
>> /* #define DUMP_MSGS */
>>
>> You'll probably also have to en
Hi,
(adding linux-usb which I forgot when I sent the original email, sorry)
Alan Stern writes:
> On Thu, 1 Sep 2016, Felipe Balbi wrote:
>
>> Hi Alan, Michal,
>>
>> I think I have emailed the list about this at some point, but I have
>> much stronger evidence that g_mass_storage is not enqueu
22 matches
Mail list logo
