Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Sedat Dilek]

On Tue, Apr 24, 2018 at 5:22 PM, Linus Torvalds
 wrote:
> On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek  wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> Does this now look good?
>
> Looks fine to me. The instruction choice is still pretty odd:
>
>   1a:   f6 c3 fftest   $0xff,%bl
>   1d:   74 02   je 21 
>
> that "test   $0xff,%bl" is a rather odd way of testing the byte for zero, 
> since
>
>   1a:   84 dbtest   %bl,%bl
>   1c:   74 02   je 20 
>
> would have been a byte shorter and is the canonical way on x86 to test
> a register against zero.
>
> But that's just a "looks odd to somebody who is used to x86 asm", not
> a bug or anything really noticeable.
>
>   Linus

Thanks for the quick reply and the confirmation.

Personally, I do not speak x86/asm.
I hope CCed LLVM folks know on how to improve things.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Sedat Dilek]

On Tue, Apr 24, 2018 at 3:28 PM, Sedat Dilek  wrote:
> On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
>  wrote:
>> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek  wrote:
>>>
>>> $ objdump -S clang-eflag.o
>>>
>>> clang-eflag.o: file format elf64-x86-64
>>>
>>>
>>> Disassembly of section .text:
>>>
>>>  :
>>>0:   55  push   %rbp
>>>1:   48 89 e5mov%rsp,%rbp
>>>4:   53  push   %rbx
>>>5:   50  push   %rax
>>>6:   e8 00 00 00 00  callq  b 
>>>b:   ff 0d 00 00 00 00   decl   0x0(%rip)# 11 
>>>   11:   9c  pushfq
>>>   12:   5b  pop%rbx
>>>   13:   e8 00 00 00 00  callq  18 
>>>   18:   b8 01 00 00 00  mov$0x1,%eax
>>>   1d:   53  push   %rbx
>>>   1e:   9d  popfq
>>>   1f:   75 07   jne28 
>>
>>
>> Yeah, the above is pure garbage.
>>
>>> So, the issue is still alive.
>>>
>>> What do you mean by "for the kernel we at a minimum need a way to
>>> disable that code generation"?
>>> Can this be fixed in the Linux-kernel?
>>
>> No. This will never be fixed in the kernel. It's a compiler bug.
>>
>> The compiler generates shit code. It's absolutely atrociously bad even
>> if you ignore any kernel issues, because that kind of code just
>> performs badly (the compiler should have used "setcc" or something
>> similar to just set the comparison value, not save and restore eflags.
>>
>> And quite frankly, any compiler writer that thinks it is good code is
>> not somebody I want touching a compiler that the kernel depends on
>> anyway.
>>
>> But it is not just bad code for the kernel, it's actively buggy code,
>> since it corrupts the IF.
>>
>> Until this gets fixed in LLVM, there's no way in hell that we will
>> ever have a kernel compiled with that piece of shit.
>>
>> Really. If the LLVM developers cannot fix their crap code generation,
>> it's not worth touching that shit with a ten-foot pole.
>>
>> I'd love to be able to compile the kernel with LLVM, but the fact that
>> the broken eflags code apparently _still_ hasn't been fixed makes me
>> just go "not worth it".
>>
>> And if the LLVM developers don't see this as an obvious bug, it's even
>> less worth it - because that shows not just that the compiler is
>> broken, but that the developers involved with it are broken too.
>>
>>   Linus
>
> [ Changed Subject ]
> [ CC Matthias ]
> [ CC Michael test-case ]
> [ CC Chandler ]
>
> Hi Linus,
>
> Matthias pointed me in [0] to [1] in the LLVM-BTS.
>
> ...and I tried again the test-case from Michael from [3] "[LLVMdev]
> optimizer clobber EFLAGS"...
>
> ...with clang-7 (version:
> 7~svn330207-1~exp1+0~20180417201234.1709~1.gbp6fb10d) from
> <https://apt.llvm.org/>.
>
> [ TEST-CASE ]
>
> [ clang-eflag.c ]
> #include 
> #include 
>
> void foo(void);
> int a;
>
> int bar(void)
> {
>  foo();
>
>  bool const zero = a -= 1;
>
>  asm volatile ("" : : : "cc");
>  foo();
>
>  if (zero) {
>  return EXIT_FAILURE;
>  }
>
>  foo();
>
>  return EXIT_SUCCESS;
> }
> - EOF -
>
> $ clang-7 -O2 -c -o clang-eflag.o clang-eflag.c
>
> [ OBJDUMP ]
>
> $ objdump -S clang-eflag.o
>
> clang-eflag.o: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
>  :
>0:   53  push   %rbx
>1:   e8 00 00 00 00  callq  6 
>6:   83 05 00 00 00 00 ffaddl   $0x,0x0(%rip)#
> d 
>d:   0f 95 c3setne  %bl
>   10:   e8 00 00 00 00  callq  15 
>   15:   b8 01 00 00 00  mov$0x1,%eax
>   1a:   f6 c3 fftest   $0xff,%bl
>   1d:   74 02   je 21 
>   1f:   5b  pop%rbx
>   20:   c3  retq
>   21:   e8 00 00 00 00  callq  26 
>   26:   31 c0   xor%eax,%eax
>   28:   5b  pop%rbx
>   29:   c3  retq
>
> Does this now look good?
>
> Thanks.
>
> Kind regards,
&g

Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

[Sedat Dilek]

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
 wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek  wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> clang-eflag.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>>  :
>>0:   55  push   %rbp
>>1:   48 89 e5mov%rsp,%rbp
>>4:   53  push   %rbx
>>5:   50  push   %rax
>>6:   e8 00 00 00 00  callq  b 
>>b:   ff 0d 00 00 00 00   decl   0x0(%rip)# 11 
>>   11:   9c  pushfq
>>   12:   5b  pop%rbx
>>   13:   e8 00 00 00 00  callq  18 
>>   18:   b8 01 00 00 00  mov$0x1,%eax
>>   1d:   53  push   %rbx
>>   1e:   9d  popfq
>>   1f:   75 07   jne28 
>
>
> Yeah, the above is pure garbage.
>
>> So, the issue is still alive.
>>
>> What do you mean by "for the kernel we at a minimum need a way to
>> disable that code generation"?
>> Can this be fixed in the Linux-kernel?
>
> No. This will never be fixed in the kernel. It's a compiler bug.
>
> The compiler generates shit code. It's absolutely atrociously bad even
> if you ignore any kernel issues, because that kind of code just
> performs badly (the compiler should have used "setcc" or something
> similar to just set the comparison value, not save and restore eflags.
>
> And quite frankly, any compiler writer that thinks it is good code is
> not somebody I want touching a compiler that the kernel depends on
> anyway.
>
> But it is not just bad code for the kernel, it's actively buggy code,
> since it corrupts the IF.
>
> Until this gets fixed in LLVM, there's no way in hell that we will
> ever have a kernel compiled with that piece of shit.
>
> Really. If the LLVM developers cannot fix their crap code generation,
> it's not worth touching that shit with a ten-foot pole.
>
> I'd love to be able to compile the kernel with LLVM, but the fact that
> the broken eflags code apparently _still_ hasn't been fixed makes me
> just go "not worth it".
>
> And if the LLVM developers don't see this as an obvious bug, it's even
> less worth it - because that shows not just that the compiler is
> broken, but that the developers involved with it are broken too.
>
>   Linus

[ Changed Subject ]
[ CC Matthias ]
[ CC Michael test-case ]
[ CC Chandler ]

Hi Linus,

Matthias pointed me in [0] to [1] in the LLVM-BTS.

...and I tried again the test-case from Michael from [3] "[LLVMdev]
optimizer clobber EFLAGS"...

...with clang-7 (version:
7~svn330207-1~exp1+0~20180417201234.1709~1.gbp6fb10d) from
<https://apt.llvm.org/>.

[ TEST-CASE ]

[ clang-eflag.c ]
#include 
#include 

void foo(void);
int a;

int bar(void)
{
 foo();

 bool const zero = a -= 1;

 asm volatile ("" : : : "cc");
 foo();

 if (zero) {
 return EXIT_FAILURE;
 }

 foo();

 return EXIT_SUCCESS;
}
- EOF -

$ clang-7 -O2 -c -o clang-eflag.o clang-eflag.c

[ OBJDUMP ]

$ objdump -S clang-eflag.o

clang-eflag.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   53  push   %rbx
   1:   e8 00 00 00 00  callq  6 
   6:   83 05 00 00 00 00 ffaddl   $0x,0x0(%rip)#
d 
   d:   0f 95 c3setne  %bl
  10:   e8 00 00 00 00  callq  15 
  15:   b8 01 00 00 00  mov$0x1,%eax
  1a:   f6 c3 fftest   $0xff,%bl
  1d:   74 02   je 21 
  1f:   5b  pop%rbx
  20:   c3  retq
  21:   e8 00 00 00 00  callq  26 
  26:   31 c0   xor%eax,%eax
  28:   5b  pop%rbx
  29:   c3  retq

Does this now look good?

Thanks.

Kind regards,
- Sedat -

[0] https://marc.info/?l=linux-kernel&m=152450535720279&w=2
[1] https://bugs.llvm.org/show_bug.cgi?id=36028
[2] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html
[3] https://marc.info/?l=linux-kernel&m=152457089205170&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Mon, Jun 27, 2016 at 10:14 PM, Linus Torvalds
 wrote:
> On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek  wrote:
>>
>> $ objdump -S clang-eflag.o
>>
>> clang-eflag.o: file format elf64-x86-64
>>
>>
>> Disassembly of section .text:
>>
>>  :
>>0:   55  push   %rbp
>>1:   48 89 e5mov%rsp,%rbp
>>4:   53  push   %rbx
>>5:   50  push   %rax
>>6:   e8 00 00 00 00  callq  b 
>>b:   ff 0d 00 00 00 00   decl   0x0(%rip)# 11 
>>   11:   9c  pushfq
>>   12:   5b  pop%rbx
>>   13:   e8 00 00 00 00  callq  18 
>>   18:   b8 01 00 00 00  mov$0x1,%eax
>>   1d:   53  push   %rbx
>>   1e:   9d  popfq
>>   1f:   75 07   jne28 
>
>
> Yeah, the above is pure garbage.
>
>> So, the issue is still alive.
>>
>> What do you mean by "for the kernel we at a minimum need a way to
>> disable that code generation"?
>> Can this be fixed in the Linux-kernel?
>
> No. This will never be fixed in the kernel. It's a compiler bug.
>
> The compiler generates shit code. It's absolutely atrociously bad even
> if you ignore any kernel issues, because that kind of code just
> performs badly (the compiler should have used "setcc" or something
> similar to just set the comparison value, not save and restore eflags.
>
> And quite frankly, any compiler writer that thinks it is good code is
> not somebody I want touching a compiler that the kernel depends on
> anyway.
>
> But it is not just bad code for the kernel, it's actively buggy code,
> since it corrupts the IF.
>
> Until this gets fixed in LLVM, there's no way in hell that we will
> ever have a kernel compiled with that piece of shit.
>
> Really. If the LLVM developers cannot fix their crap code generation,
> it's not worth touching that shit with a ten-foot pole.
>
> I'd love to be able to compile the kernel with LLVM, but the fact that
> the broken eflags code apparently _still_ hasn't been fixed makes me
> just go "not worth it".
>
> And if the LLVM developers don't see this as an obvious bug, it's even
> less worth it - because that shows not just that the compiler is
> broken, but that the developers involved with it are broken too.
>

Thanks for the quick answer.

I just grepped for some "buzzwords" people gave me in this
email-thread and I was looking at (llvm.git HEAD - upcoming v3.9
release) and found these comments in [1]

[ lib/Target/X86/X86InstrInfo.cpp ]

void X86InstrInfo::copyPhysReg()
...
// PUSHF/POPF is also potentially incorrect because it affects other flags
// such as TF/IF/DF, which LLVM doesn't model.
...

- Sedat -

[1] 
https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X86/X86InstrInfo.cpp#L4516
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Mon, Jun 27, 2016 at 9:50 PM, Sedat Dilek  wrote:
> On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds
>  wrote:
>> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern  
>> wrote:
>>>
>>> Of course, there are other ways to save a single flag value (such as
>>> setz).  It's up to the compiler developers to decide what they think is
>>> best.
>>
>> Using 'setcc' to save eflags somewhere is definitely the right thing to do.
>>
>> Using pushf/popf in generated code is completely insane (unless done
>> very localized in a controlled area).
>>
>> It is, in fact, insane and wrong even in user space, since eflags does
>> contain bits that user space itself might be modifying.
>>
>> In fact, even IF may be modified with iopl 3 (thing old X server
>> setups), but ignoring that flag entirely, you have AC that acts in
>> very similar ways (system-wide alignment control) that user space
>> might be using to make sure it doesn't have unaligned accesses.
>>
>> It's rare, yes. But still - this isn't really limited to just the kernel.
>>
>> But perhaps more importantly, I suspect using pushf/popf isn't just
>> semantically the wrong thing to do, it's just plain stupid. It's
>> likely slower than the obvious 'setcc' model. Agner Fog's table shows
>> it "popf" as being 25-30 uops on several microarchitectures. Looks
>> like it's often microcode.
>>
>> Now, pushf/popf may well be fairly cheap on *some* uarchitectures, but
>> it really sounds like a bad idea to use it when not absolutely
>> required. And that is completely independent of the fact that is
>> screws up the IF bit.
>>
>> But yeah, for the kernel we at a minimum need a way to disable that
>> code generation, even if the clang guys might have some insane reason
>> to keep it for other cases.
>>
>
> I am testing my new llvm-toolchain v3.8.1 and a pending x86/hweight
> fix [1] encouraged me to look at this again.

Just for the sake of completeness:

I use the latest Linux v4.4.y LTS for testing (here: v4.4.14) with a
custom llvmlinux-amd64 patchset (on demand I can send it to you).
( With CONFIG_TRACING_SUPPORT=n and CONFIG_PARAVIRT=n )

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Mon, Mar 7, 2016 at 7:30 PM, Linus Torvalds
 wrote:
> On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern  wrote:
>>
>> Of course, there are other ways to save a single flag value (such as
>> setz).  It's up to the compiler developers to decide what they think is
>> best.
>
> Using 'setcc' to save eflags somewhere is definitely the right thing to do.
>
> Using pushf/popf in generated code is completely insane (unless done
> very localized in a controlled area).
>
> It is, in fact, insane and wrong even in user space, since eflags does
> contain bits that user space itself might be modifying.
>
> In fact, even IF may be modified with iopl 3 (thing old X server
> setups), but ignoring that flag entirely, you have AC that acts in
> very similar ways (system-wide alignment control) that user space
> might be using to make sure it doesn't have unaligned accesses.
>
> It's rare, yes. But still - this isn't really limited to just the kernel.
>
> But perhaps more importantly, I suspect using pushf/popf isn't just
> semantically the wrong thing to do, it's just plain stupid. It's
> likely slower than the obvious 'setcc' model. Agner Fog's table shows
> it "popf" as being 25-30 uops on several microarchitectures. Looks
> like it's often microcode.
>
> Now, pushf/popf may well be fairly cheap on *some* uarchitectures, but
> it really sounds like a bad idea to use it when not absolutely
> required. And that is completely independent of the fact that is
> screws up the IF bit.
>
> But yeah, for the kernel we at a minimum need a way to disable that
> code generation, even if the clang guys might have some insane reason
> to keep it for other cases.
>

I am testing my new llvm-toolchain v3.8.1 and a pending x86/hweight
fix [1] encouraged me to look at this again.

In [2] I found a simple test program from Michael Hordijk.
( See thread "[LLVMdev] optimizer clobber EFLAGS". )

This is what I see...

$ objdump -S clang-eflag.o

clang-eflag.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   55  push   %rbp
   1:   48 89 e5mov%rsp,%rbp
   4:   53  push   %rbx
   5:   50  push   %rax
   6:   e8 00 00 00 00  callq  b 
   b:   ff 0d 00 00 00 00   decl   0x0(%rip)# 11 
  11:   9c  pushfq
  12:   5b  pop%rbx
  13:   e8 00 00 00 00  callq  18 
  18:   b8 01 00 00 00  mov$0x1,%eax
  1d:   53  push   %rbx
  1e:   9d  popfq
  1f:   75 07   jne28 
  21:   e8 00 00 00 00  callq  26 
  26:   31 c0   xor%eax,%eax
  28:   48 83 c4 08 add$0x8,%rsp
  2c:   5b  pop%rbx
  2d:   5d  pop%rbp
  2e:   c3  retq

So, the issue is still alive.

What do you mean by "for the kernel we at a minimum need a way to
disable that code generation"?
Can this be fixed in the Linux-kernel?

I asked parallelly the people involved in [2] if there are any news on that.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=f5967101e9de12addcda4510dfbac66d7c5779c3
[2] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088766.html
// Using Clang/LLVM 3.6.0 we are observing a case where the optimizations
// are clobbering EFLAGS on x86_64.  This is inconvenient when the status of
// bit 9 (IF), which controls interrupts, changes.
//
// Here's a simple test program.  Assume that the external function foo()
// modifies the IF bit in EFLAGS.
//
// And it's compiled using the following command line:
//
// $ clang -O2 -c -o clang-eflag.o clang-eflag.c
//
// Check objdump output using the following command line:
//
// $ objdump -S clang-eflag.o
//
// For more details see "[LLVMdev] optimizer clobber EFLAGS"
// 

#include 
#include 

void foo(void);
int a;

int bar(void)
{
foo();

bool const zero = a -= 1;

asm volatile ("" : : : "cc");
foo();

if (zero) {
return EXIT_FAILURE;
}

foo();

return EXIT_SUCCESS;
}


clang-eflag.o
Description: application/object

Re: Reset hanging Huawei USB-2.0 Internet stick

[Sedat Dilek]

On Wed, Jun 15, 2016 at 5:51 PM, Alan Stern  wrote:
> On Wed, 15 Jun 2016, Sedat Dilek wrote:
>
>> Hi Alan,
>>
>> I updated my usb-ids on my Ubuntu 12.04 LTS (AMD64).
>> Background was my ASMedia ASM-104x USB-3.0 controller/hub shows no
>> human-readable vendor-string etc.
>>
>> While checking parallelelly a new usbutils release, I saw your
>> "usbreset" example program in the corresponding GitHub repo [1].
>>
>> Sometimes my Internet connection does not get established and I do not
>> want to plug-off it from my hardware (usb-2 port).
>> I hope your usbrest program can do the trick software-technically.
>>
>> So how do I reset my Internet stick?
>>
>> $ lsusb | grep -i huawei
>> Bus 001 Device 005: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband 
>> stick
>>
>> [ Excerpts from my dmesg-outputs ]
>>
>> [   22.352232] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at
>> usb-:00:1a.0-1.2, Mobile Broadband Network Device,
>> 02:50:f3:00:00:00
>> [   22.395891] option 1-1.2:1.0: GSM modem (1-port) converter detected
>> [   22.399676] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB0
>> [   22.37] option 1-1.2:1.3: GSM modem (1-port) converter detected
>> [   22.400557] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB1
>> [   22.400639] option 1-1.2:1.4: GSM modem (1-port) converter detected
>> [   22.401041] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB2
>>
>> Not sure how to usbreset - all three /dev/ttyUSB[0-2] ?
>>
>> $ sudo ./usbreset $DEVFN
>> Usage: usbreset device-filename
>>
>> If you need more informations if my attached linux-config,
>> dmesg-output and 'lsusb -vvv' outputs don't help, please let me know.
>
> sudo ./usbreset /dev/bus/usb/001/005
>
> 001 and 005 are the Bus and Device numbers from the lsusb output.
>

Yes, that worked...

$ sudo usbreset /dev/bus/usb/001/005
Resetting USB device /dev/bus/usb/001/005
Reset successful

...and I liked it.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reset hanging Huawei USB-2.0 Internet stick

[Sedat Dilek]

On Thu, Jun 16, 2016 at 12:16 PM, Bjørn Mork  wrote:
> Sedat Dilek  writes:
>> On Wed, Jun 15, 2016 at 5:51 PM, Alan Stern  
>> wrote:
>>
>>> sudo ./usbreset /dev/bus/usb/001/005
>>>
>>> 001 and 005 are the Bus and Device numbers from the lsusb output.
>>>
>>
>> Thanks, Alan.
>>
>> I will look and test this (or adapt your) line as soon as I get in
>> front of my machine.
>>
>> I have seen that the corresponding "usb-port" provides a usb3-hub and
>> a usb2-hub, so I think I have to reset both?
>> Are those hubs independent?
>> I will re-check my outputs which I had sent here.
>>
>> Can you add an example-line to the "help-text" when invoking usbreset
>> with no (or wrong) device-filename argument?
>
> I noticed a while ago that the OpenWrt guys have made a few useful
> changes to this utility, including the ability to name the device by
> VID:PID. This makes it a lot easier to use:
> http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/utils/usbreset/src/usbreset.c
>
> I've been planning to get that diff submitted to usbutils, but haven't
> gotten around to it yet.  Yes, I move slowly ;)
>

Go Bjørn, go!

- sed@ -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reset hanging Huawei USB-2.0 Internet stick

[Sedat Dilek]

On Wed, Jun 15, 2016 at 5:51 PM, Alan Stern  wrote:
> On Wed, 15 Jun 2016, Sedat Dilek wrote:
>
>> Hi Alan,
>>
>> I updated my usb-ids on my Ubuntu 12.04 LTS (AMD64).
>> Background was my ASMedia ASM-104x USB-3.0 controller/hub shows no
>> human-readable vendor-string etc.
>>
>> While checking parallelelly a new usbutils release, I saw your
>> "usbreset" example program in the corresponding GitHub repo [1].
>>
>> Sometimes my Internet connection does not get established and I do not
>> want to plug-off it from my hardware (usb-2 port).
>> I hope your usbrest program can do the trick software-technically.
>>
>> So how do I reset my Internet stick?
>>
>> $ lsusb | grep -i huawei
>> Bus 001 Device 005: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband 
>> stick
>>
>> [ Excerpts from my dmesg-outputs ]
>>
>> [   22.352232] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at
>> usb-:00:1a.0-1.2, Mobile Broadband Network Device,
>> 02:50:f3:00:00:00
>> [   22.395891] option 1-1.2:1.0: GSM modem (1-port) converter detected
>> [   22.399676] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB0
>> [   22.37] option 1-1.2:1.3: GSM modem (1-port) converter detected
>> [   22.400557] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB1
>> [   22.400639] option 1-1.2:1.4: GSM modem (1-port) converter detected
>> [   22.401041] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB2
>>
>> Not sure how to usbreset - all three /dev/ttyUSB[0-2] ?
>>
>> $ sudo ./usbreset $DEVFN
>> Usage: usbreset device-filename
>>
>> If you need more informations if my attached linux-config,
>> dmesg-output and 'lsusb -vvv' outputs don't help, please let me know.
>
> sudo ./usbreset /dev/bus/usb/001/005
>
> 001 and 005 are the Bus and Device numbers from the lsusb output.
>

Thanks, Alan.

I will look and test this (or adapt your) line as soon as I get in
front of my machine.

I have seen that the corresponding "usb-port" provides a usb3-hub and
a usb2-hub, so I think I have to reset both?
Are those hubs independent?
I will re-check my outputs which I had sent here.

Can you add an example-line to the "help-text" when invoking usbreset
with no (or wrong) device-filename argument?

Thanks in advance.

- Sedat Dilek -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Reset hanging Huawei USB-2.0 Internet stick

[Sedat Dilek]

On Wed, Jun 15, 2016 at 1:53 PM, Greg Kroah-Hartman
 wrote:
> On Wed, Jun 15, 2016 at 08:22:44AM +0200, Sedat Dilek wrote:
>> Hi Alan,
>>
>> I updated my usb-ids on my Ubuntu 12.04 LTS (AMD64).
>> Background was my ASMedia ASM-104x USB-3.0 controller/hub shows no
>> human-readable vendor-string etc.
>>
>> While checking parallelelly a new usbutils release, I saw your
>> "usbreset" example program in the corresponding GitHub repo [1].
>>
>> Sometimes my Internet connection does not get established and I do not
>> want to plug-off it from my hardware (usb-2 port).
>> I hope your usbrest program can do the trick software-technically.
>>
>> So how do I reset my Internet stick?
>>
>> $ lsusb | grep -i huawei
>> Bus 001 Device 005: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband 
>> stick
>>
>> [ Excerpts from my dmesg-outputs ]
>>
>> [   22.352232] cdc_ether 1-1.2:1.1 wwan0: register 'cdc_ether' at
>> usb-:00:1a.0-1.2, Mobile Broadband Network Device,
>> 02:50:f3:00:00:00
>> [   22.395891] option 1-1.2:1.0: GSM modem (1-port) converter detected
>> [   22.399676] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB0
>> [   22.37] option 1-1.2:1.3: GSM modem (1-port) converter detected
>> [   22.400557] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB1
>> [   22.400639] option 1-1.2:1.4: GSM modem (1-port) converter detected
>> [   22.401041] usb 1-1.2: GSM modem (1-port) converter now attached to 
>> ttyUSB2
>>
>> Not sure how to usbreset - all three /dev/ttyUSB[0-2] ?
>
> Nope, you need to point it at your hub.
>
> But be aware that usbreset does not always work, at all, as not all
> hardware hubs support this additional feature.
>
> good luck!
>

Thanks for the feedback.

How do I identify the usb-hub where my Internet stick is plugged in?
IOW, what concrete "device-filename" do I have to pass to usbreset?

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux-v4.6-rc2] atkbd serio0: Unknown key pressed (translated set 2, code 0xa8 on isa0060/serio0).

[Sedat Dilek]

On Wed, Apr 6, 2016 at 11:34 PM, Jiri Kosina  wrote:
> On Wed, 6 Apr 2016, Dmitry Torokhov wrote:
>
>> >>> [  685.425634] atkbd serio0: Unknown key pressed (translated set 2,
>> >>> code 0xa8 on isa0060/serio0).
>> >>> [  685.425648] atkbd serio0: Use 'setkeycodes e028 ' to make it 
>> >>> known.
>> >>>
>> >>> Known issue?
>> >>>
>> >>> Do you need more input?
>> >>>
>> >>> Linux-config and dmesg-output attached.
>> >>>
>> >>> Regards,
>> >>> - Sedat Dilek -
>> >>
>> >> Attached is output of...
>> >>
>> >>$ xmodmap -pke > /tmp/xmodmap-pke.txt
>> >>
>> >
>> > [ CC (USB)HID folks ]
>> >
>> > I forgot to tell that I have some patches on top of vanilla Linux v4.6-rc2.
>> >
>> > Dropping the patches from  makes
>> > the issue go away.
>> > Unsure what is the cause.
>>
>> Hmm, this is quite curious, none of the recent patches in
>> for-4.6/upstream-fixes touches atkbd. I'd be very interested in which
>> one exactly causes this.
>
> It's indeed odd.
>
> Sedat, the kernel in question is compiled by gcc, right? (just making sure
> given the past experience :) ).
>

Oh no, you were that (good | bad | ...) ugly guy :-).
( To answer your question: I currently only use GCC v4.9. )

Thanks for reminding the llvmlinux/irqflags issue. I wanted to contact
LLVM/Clang folks and CC some people out of the Linux world.

- sed@ -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux-v4.6-rc2] atkbd serio0: Unknown key pressed (translated set 2, code 0xa8 on isa0060/serio0).

[Sedat Dilek]

On Thu, Apr 7, 2016 at 10:11 PM, Jiri Kosina  wrote:
> On Wed, 6 Apr 2016, Dmitry Torokhov wrote:
>
>> > I forgot to tell that I have some patches on top of vanilla Linux v4.6-rc2.
>> >
>> > Dropping the patches from  makes
>> > the issue go away.
>> > Unsure what is the cause.
>>
>> Hmm, this is quite curious, none of the recent patches in
>> for-4.6/upstream-fixes touches atkbd. I'd be very interested in which
>> one exactly causes this.
>
> Exactly, I don't see any possible relationship whatsoever.
>
> Sedat, for-4.6/upstream-fixes branch has only a couple of commits, so it
> should take just a very short while to bisect.
>
> Thanks,
>

Hmm, I could not reproduce it again.
Cursor up/down (pageup/pagedown) works again - unsure if the dmesg
outputs are related to this.
( And I have some (rfc) locking patches from PeterZ on top. )

- sed@ -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux-v4.6-rc2] atkbd serio0: Unknown key pressed (translated set 2, code 0xa8 on isa0060/serio0).

[Sedat Dilek]

On Wed, Apr 6, 2016 at 12:33 PM, Jiri Kosina  wrote:
> On Wed, 6 Apr 2016, Sedat Dilek wrote:
>
>> >> I cannot use cursor up and down on my notebook and see this in my dmesg.
>> >>
>> >> [  685.425634] atkbd serio0: Unknown key pressed (translated set 2,
>> >> code 0xa8 on isa0060/serio0).
>> >> [  685.425648] atkbd serio0: Use 'setkeycodes e028 ' to make it 
>> >> known.
>> >>
>> >> Known issue?
>> >>
>> >> Do you need more input?
>> >>
>> >> Linux-config and dmesg-output attached.
>> >>
>> >> Regards,
>> >> - Sedat Dilek -
>> >
>> > Attached is output of...
>> >
>> >$ xmodmap -pke > /tmp/xmodmap-pke.txt
>> >
>>
>> [ CC (USB)HID folks ]
>>
>> I forgot to tell that I have some patches on top of vanilla Linux v4.6-rc2.
>>
>> Dropping the patches from  makes
>> the issue go away.
>
> Thanks for the useful report!
>
>> Unsure what is the cause. On the way, try to look this evening or
>> tommorrow into this.
>
> I don't seem to see the beginning of this thread anywhere.
>
> What hardware is this?
>

OK, OK.
As said I am on the run - my train is going in 40mins-
I try to write some better report.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux-v4.6-rc2] atkbd serio0: Unknown key pressed (translated set 2, code 0xa8 on isa0060/serio0).

[Sedat Dilek]

On Wed, Apr 6, 2016 at 11:35 AM, Sedat Dilek  wrote:
> On Wed, Apr 6, 2016 at 11:27 AM, Sedat Dilek  wrote:
>> Hi,
>>
>> I cannot use cursor up and down on my notebook and see this in my dmesg.
>>
>> [  685.425634] atkbd serio0: Unknown key pressed (translated set 2,
>> code 0xa8 on isa0060/serio0).
>> [  685.425648] atkbd serio0: Use 'setkeycodes e028 ' to make it 
>> known.
>>
>> Known issue?
>>
>> Do you need more input?
>>
>> Linux-config and dmesg-output attached.
>>
>> Regards,
>> - Sedat Dilek -
>
> Attached is output of...
>
>$ xmodmap -pke > /tmp/xmodmap-pke.txt
>

[ CC (USB)HID folks ]

I forgot to tell that I have some patches on top of vanilla Linux v4.6-rc2.

Dropping the patches from  makes
the issue go away.
Unsure what is the cause.
On the way, try to look this evening or tommorrow into this.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Mon, Mar 7, 2016 at 5:41 PM, Alan Stern  wrote:
> On Mon, 7 Mar 2016, Sedat Dilek wrote:
>
>> Hmm, we are there where I was looking at...
>>
>> Please, read the reply of Jiri [1], we did some tweaking.
>> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
>
> Yes, Jiri was looking more or less at the right place but his
> conclusions were wrong.
>
>> *** Part one: ObjectDump of hid-core.o ***
>>
>> $ objdump -D drivers/hid/usbhid/hid-core.o | awk '/<[^>]*>:$/ { p=0; }
>> /:/ { p=1; } { if (p) print $0; }' >
>> ../objdump-D_hid-core_o_usbhid_close_$(uname -r).txt
>
> This reveals the problem, at last...
>
>> $ cat ../objdump-D_hid-core_o_usbhid_close_4.4.4-1-iniza-small.txt
>> 02e0 :
>>  2e0:   55  push   %rbp
>>  2e1:   48 89 e5mov%rsp,%rbp
>>  2e4:   41 57   push   %r15
>>  2e6:   41 56   push   %r14
>>  2e8:   41 54   push   %r12
>>  2ea:   53  push   %rbx
>>  2eb:   49 89 ffmov%rdi,%r15
>>  2ee:   4d 8b b7 e8 1e 00 00mov0x1ee8(%r15),%r14
>>  2f5:   48 c7 c7 00 00 00 00mov$0x0,%rdi
>>  2fc:   31 f6   xor%esi,%esi
>>  2fe:   e8 00 00 00 00  callq  303 
>
> mutex_lock(&hid_open_mut);
>
>>  303:   49 8d 9e 88 28 00 00lea0x2888(%r14),%rbx
>>  30a:   48 89 dfmov%rbx,%rdi
>>  30d:   e8 00 00 00 00  callq  312 
>
> spin_lock_irq(&usbhid->lock);
>
>>  312:   41 ff 8f e4 1d 00 00decl   0x1de4(%r15)
>
> --hid->open
>
>>  319:   9c  pushfq
>>  31a:   41 5c   pop%r12
>>  31c:   48 89 dfmov%rbx,%rdi
>>  31f:   e8 00 00 00 00  callq  324 
>>  324:   41 54   push   %r12
>>  326:   9d  popfq
>
> spin_unlock_irq(&usbhid->lock); while attempting to preserve the Z
> flag.  The problem is that this code sequence will also preserve the
> Interrupt Flag!
>
>>  327:   75 23   jne34c 
>
> if (!--hid->open), testing the Z flag from the decl.
>
>>  329:   4c 89 f7mov%r14,%rdi
>>  32c:   e8 3f 00 00 00  callq  370 
>
> But now hid_cancel_delayed_stuff(usbhid) gets called with interrupts
> disabled.
>
> It's hard to call this a compiler bug, but perhaps it is -- I don't
> know how programmers are supposed to tell CLANG that a subroutine
> modifies the Interrupt Flag in a way that the compiler shouldn't mess
> up.
>

So, if Clang is producing wrong X86 code here, is it possible to turn
interrupts on/off manually?
But, hmm that affects other places as well in the Linux sources, so.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Mon, Mar 7, 2016 at 6:05 PM, Jiri Kosina  wrote:
> On Mon, 7 Mar 2016, Alan Stern wrote:
>
>> >  319:   9c  pushfq
>> >  31a:   41 5c   pop%r12
>> >  31c:   48 89 dfmov%rbx,%rdi
>> >  31f:   e8 00 00 00 00  callq  324 
>> >  324:   41 54   push   %r12
>> >  326:   9d  popfq
>>
>> spin_unlock_irq(&usbhid->lock); while attempting to preserve the Z
>> flag.  The problem is that this code sequence will also preserve the
>> Interrupt Flag!
>
> You are right Alan, thanks a lot, for reason I could not understand I
> completely missed the pushf/popf last time I was looking at the generated
> assembly!
>
> OK, a little bit of googling revealed related discussion on LLVM
> mailinglist:
>
> http://lists.llvm.org/pipermail/llvm-dev/2015-July/088780.html
>
> Seems like it has been reported already, but noone dared to fix it yet.
>
> This basically makes LLVM unusable for compiling the kernel.
>

OK, OK.

Did someone look at the next/follow-ups in this thread?
For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?

- Sedat -

[1] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088874.html
[2] http://reviews.llvm.org/D6629
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Mon, Mar 7, 2016 at 4:59 PM, Sedat Dilek  wrote:
> On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern  wrote:
>> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>>
>>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern  
>>> wrote:
>>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>> >
>>> >> On 3/1/16, Alan Stern  wrote:
>>> >> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
>>> >> >
>>> >> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>>> >> >> wrote:
>>> >> >> > On Sat, 3 Oct 2015 12:05:42 +0200
>>> >> >> > Sedat Dilek  wrote:
>>> >> >> >
>>> >> >> >> So, at the beginning... dunno WTF is causing the problems - no
>>> >> >> >> workaround for CLANG.
>>> >> >> >
>>> >> >> > Probably need to compile with gcc and with clang and look at the 
>>> >> >> > binary
>>> >> >> > differences. Or at least what objdump shows.
>>> >> >> >
>>> >> >>
>>> >> >> [ Hope to address this issue to the correct people - CCed some people
>>> >> >> I taped on their nerves ]
>>> >> >>
>>> >> >> Not sure if I should open a new thread?
>>> >> >> Please, some clear statements on this.
>>> >> >> Thanks.
>>> >> >>
>>> >> >> The issue is still visible and alive.
>>> >
>>> > I think it would be worthwhile to doublecheck the time at which
>>> > interrupts get disabled.  Sedat, please try your plug/unplug the USB
>>> > mouse test with the patch below.
>>> >
>>> > Alan Stern
>>> >
>>> >
>>> >
>>> > Index: usb-4.4/drivers/hid/usbhid/hid-core.c
>>> > ===
>>> > --- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
>>> > +++ usb-4.4/drivers/hid/usbhid/hid-core.c
>>> > @@ -1393,8 +1393,11 @@ static void usbhid_disconnect(struct usb
>>> >
>>> >  static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
>>> >  {
>>> > +   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled A\n");
>>> > del_timer_sync(&usbhid->io_retry);
>>> > +   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled B\n");
>>> > cancel_work_sync(&usbhid->reset_work);
>>> > +   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled C\n");
>>> >  }
>>> >
>>> >  static void hid_cease_io(struct usbhid_device *usbhid)
>>> >
>>>
>>> With your patch I get the dmesg attached.
>>
>>> [   22.234758] usbhid irqs disabled A
>>> [   22.234857] usbhid irqs disabled B
>>> [   22.234912] BUG: sleeping function called from invalid context 
>>> atkernel/workqueue.c:2688
>>
>> That's a smoking gun.  It means everyone has been looking in the wrong
>> place.  Can you provide an objdump listing of usbhid_close()?  The
>> routine starts like this:
>>
>> void usbhid_close(struct hid_device *hid)
>> {
>> struct usbhid_device *usbhid = hid->driver_data;
>>
>> mutex_lock(&hid_open_mut);
>>
>> /* protecting hid->open to make sure we don't restart
>>  * data acquistion due to a resumption we no longer
>>  * care about
>>  */
>> spin_lock_irq(&usbhid->lock);
>> if (!--hid->open) {
>> spin_unlock_irq(&usbhid->lock);
>> hid_cancel_delayed_stuff(usbhid);
>>
>> It appears that the spin_unlock_irq() call isn't working.
>>
>> For extra thoroughness, try putting one of those raw_irqs_disabled()
>> checks just before and one just after the spin_lock_irq() line above.
>> Maybe also before the mutex_lock() line.
>>
>> Alan Stern
>>
>
> Hmm, we are there where I was looking at...
>
> Please, read the reply of Jiri [1], we did some tweaking.
> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
>

Shall I enable CONFIG_TRACE_IRQFLAGS (CONFIG_PROVE_LOCKING=n disables it)?

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern  wrote:
> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>
>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern  wrote:
>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>> >
>> >> On 3/1/16, Alan Stern  wrote:
>> >> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
>> >> >
>> >> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>> >> >> wrote:
>> >> >> > On Sat, 3 Oct 2015 12:05:42 +0200
>> >> >> > Sedat Dilek  wrote:
>> >> >> >
>> >> >> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> >> >> workaround for CLANG.
>> >> >> >
>> >> >> > Probably need to compile with gcc and with clang and look at the 
>> >> >> > binary
>> >> >> > differences. Or at least what objdump shows.
>> >> >> >
>> >> >>
>> >> >> [ Hope to address this issue to the correct people - CCed some people
>> >> >> I taped on their nerves ]
>> >> >>
>> >> >> Not sure if I should open a new thread?
>> >> >> Please, some clear statements on this.
>> >> >> Thanks.
>> >> >>
>> >> >> The issue is still visible and alive.
>> >
>> > I think it would be worthwhile to doublecheck the time at which
>> > interrupts get disabled.  Sedat, please try your plug/unplug the USB
>> > mouse test with the patch below.
>> >
>> > Alan Stern
>> >
>> >
>> >
>> > Index: usb-4.4/drivers/hid/usbhid/hid-core.c
>> > ===
>> > --- usb-4.4.orig/drivers/hid/usbhid/hid-core.c
>> > +++ usb-4.4/drivers/hid/usbhid/hid-core.c
>> > @@ -1393,8 +1393,11 @@ static void usbhid_disconnect(struct usb
>> >
>> >  static void hid_cancel_delayed_stuff(struct usbhid_device *usbhid)
>> >  {
>> > +   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled A\n");
>> > del_timer_sync(&usbhid->io_retry);
>> > +   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled B\n");
>> > cancel_work_sync(&usbhid->reset_work);
>> > +   if (raw_irqs_disabled())  pr_info("usbhid irqs disabled C\n");
>> >  }
>> >
>> >  static void hid_cease_io(struct usbhid_device *usbhid)
>> >
>>
>> With your patch I get the dmesg attached.
>
>> [   22.234758] usbhid irqs disabled A
>> [   22.234857] usbhid irqs disabled B
>> [   22.234912] BUG: sleeping function called from invalid context 
>> atkernel/workqueue.c:2688
>
> That's a smoking gun.  It means everyone has been looking in the wrong
> place.  Can you provide an objdump listing of usbhid_close()?  The
> routine starts like this:
>
> void usbhid_close(struct hid_device *hid)
> {
> struct usbhid_device *usbhid = hid->driver_data;
>
> mutex_lock(&hid_open_mut);
>
> /* protecting hid->open to make sure we don't restart
>  * data acquistion due to a resumption we no longer
>  * care about
>  */
> spin_lock_irq(&usbhid->lock);
> if (!--hid->open) {
> spin_unlock_irq(&usbhid->lock);
> hid_cancel_delayed_stuff(usbhid);
>
> It appears that the spin_unlock_irq() call isn't working.
>
> For extra thoroughness, try putting one of those raw_irqs_disabled()
> checks just before and one just after the spin_lock_irq() line above.
> Maybe also before the mutex_lock() line.
>
> Alan Stern
>

Hmm, we are there where I was looking at...

Please, read the reply of Jiri [1], we did some tweaking.
With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !

*** Part one: ObjectDump of hid-core.o ***

$ objdump -D drivers/hid/usbhid/hid-core.o | awk '/<[^>]*>:$/ { p=0; }
/:/ { p=1; } { if (p) print $0; }' >
../objdump-D_hid-core_o_usbhid_close_$(uname -r).txt

$ cat ../objdump-D_hid-core_o_usbhid_close_4.4.4-1-iniza-small.txt
02e0 :
 2e0:   55  push   %rbp
 2e1:   48 89 e5mov%rsp,%rbp
 2e4:   41 57   push   %r15
 2e6:   41 56   push   %r14
 2e8:   41 54   push   %r12
 2ea:   53  push   %rbx
 2eb:   49 89 ffmov%rdi,%r15
 2ee:   4d 8b b7 e

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Sedat Dilek  wrote:
> On 3/2/16, Peter Zijlstra  wrote:
>> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
>>> 8110f570 :
>>> 8110f570:   55  push   %rbp
>>> 8110f571:   48 89 e5mov%rsp,%rbp
>>> 8110f574:   41 57   push   %r15
>>> 8110f576:   41 56   push   %r14
>>> 8110f578:   53  push   %rbx
>>> 8110f579:   48 83 ec 28 sub$0x28,%rsp
>>
>> stack offset is 0x28 bytes [*]
>>
>>> 8110f57d:   48 89 fbmov%rdi,%rbx
>>> 8110f580:   e8 6b 6e 80 00  callq  819163f0 
>>> 8110f585:   e8 66 6e 80 00  callq  819163f0 
>>> 8110f58a:   e8 61 6e 80 00  callq  819163f0 
>>> 8110f58f:   e8 5c 6e 80 00  callq  819163f0 
>>
>> Your compiler is on drugs!
>>
>>> 8110f594:   9c  pushfq
>>> 8110f595:   8f 45 e0popq   -0x20(%rbp)
>>
>> Saves flags in -0x20(%rbp)
>>
>>> 8110f598:   4c 8b 7d e0 mov-0x20(%rbp),%r15
>>
>> And in %r15
>>
>> /me wonders what's wrong with: popf %r15
>>
>>> 8110f59c:   e8 4f 6e 80 00  callq  819163f0 
>>> 8110f5a1:   e8 4a 6e 80 00  callq  819163f0 
>>> 8110f5a6:   fa  cli
>>> 8110f5a7:   e8 84 cb fc ff  callq  810dc130
>>> 
>>> 8110f5ac:   4c 8d 73 50 lea0x50(%rbx),%r14
>>> 8110f5b0:   48 c7 04 24 b0 f5 10movq
>>> $0x8110f5b0,(%rsp)
>>> 8110f5b7:   81
>>> 8110f5b8:   31 f6   xor%esi,%esi
>>> 8110f5ba:   31 d2   xor%edx,%edx
>>> 8110f5bc:   31 c9   xor%ecx,%ecx
>>> 8110f5be:   41 b8 01 00 00 00   mov$0x1,%r8d
>>> 8110f5c4:   45 31 c9xor%r9d,%r9d
>>> 8110f5c7:   4c 89 f7mov%r14,%rdi
>>> 8110f5ca:   e8 c1 e5 fc ff  callq  810ddb90
>>> 
>>> 8110f5cf:   be 01 00 00 00  mov$0x1,%esi
>>> 8110f5d4:   48 c7 c2 cf f5 10 81mov$0x8110f5cf,%rdx
>>> 8110f5db:   4c 89 f7mov%r14,%rdi
>>> 8110f5de:   e8 8d 08 fd ff  callq  810dfe70
>>> 
>>> 8110f5e3:   e8 08 6e 80 00  callq  819163f0 
>>
>>> 8110f5e8:   4c 89 f8mov%r15,%rax
>>> 8110f5eb:   49 89 c6mov%rax,%r14
>>
>> Moves r15 into r14 through rax
>>
>>
>>> 8110f5ee:   f6 c4 02test   $0x2,%ah
>>> 8110f5f1:   75 19   jne8110f60c
>>> 
>>> 8110f5f3:   e8 f8 6d 80 00  callq  819163f0 
>>> 8110f5f8:   e8 f3 6d 80 00  callq  819163f0 
>>
>>
>>> 8110f5fd:   4c 89 75 d0 mov%r14,-0x30(%rbp)
>>> 8110f601:   ff 75 d0pushq  -0x30(%rbp)
>>> 8110f604:   9d  popfq
>>
>> put r14 into -0x30(rbp) and pushes/pops that, see [*] this is 8 bytes
>> over stack ?!
>>
>>> 8110f605:   e8 26 cb fc ff  callq  810dc130
>>> 
>>> 8110f60a:   eb 17   jmp8110f623
>>> 
>>> 8110f60c:   e8 2f cb fc ff  callq  810dc140
>>> 
>>> 8110f611:   e8 da 6d 80 00  callq  819163f0 
>>> 8110f616:   e8 d5 6d 80 00  callq  819163f0 
>>> 8110f61b:   4c 89 75 d8 mov%r14,-0x28(%rbp)
>>> 8110f61f:   ff 75 d8pushq  -0x28(%rbp)
>>> 8110f622:   9d  popfq
>>
>> puts r14 into -0x28(rbp) and pushes/pops that
>>
>>> 8110f623:   e8 c8 6d 80 00  callq  819163f0 
>>> 8110f628:   65 8b 04 25 d4 ae 00mov%gs:0xaed4,%eax
>>> 8110f62f:   00
>>> 8110f630:   a9 00 00 0f 00  test   $0xf,%eax
>>> 8110f635:   74 25   je 8110f65c

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Peter Zijlstra  wrote:
> On Wed, Mar 02, 2016 at 04:53:36PM +0100, Sedat Dilek wrote:
>> 8110f570 :
>> 8110f570:55  push   %rbp
>> 8110f571:48 89 e5mov%rsp,%rbp
>> 8110f574:41 57   push   %r15
>> 8110f576:41 56   push   %r14
>> 8110f578:53  push   %rbx
>> 8110f579:48 83 ec 28 sub$0x28,%rsp
>
> stack offset is 0x28 bytes [*]
>
>> 8110f57d:48 89 fbmov%rdi,%rbx
>> 8110f580:e8 6b 6e 80 00  callq  819163f0 
>> 8110f585:e8 66 6e 80 00  callq  819163f0 
>> 8110f58a:e8 61 6e 80 00  callq  819163f0 
>> 8110f58f:e8 5c 6e 80 00  callq  819163f0 
>
> Your compiler is on drugs!
>
>> 8110f594:9c  pushfq
>> 8110f595:8f 45 e0popq   -0x20(%rbp)
>
> Saves flags in -0x20(%rbp)
>
>> 8110f598:4c 8b 7d e0 mov-0x20(%rbp),%r15
>
> And in %r15
>
> /me wonders what's wrong with: popf %r15
>
>> 8110f59c:e8 4f 6e 80 00  callq  819163f0 
>> 8110f5a1:e8 4a 6e 80 00  callq  819163f0 
>> 8110f5a6:fa  cli
>> 8110f5a7:e8 84 cb fc ff  callq  810dc130
>> 
>> 8110f5ac:4c 8d 73 50 lea0x50(%rbx),%r14
>> 8110f5b0:48 c7 04 24 b0 f5 10movq   
>> $0x8110f5b0,(%rsp)
>> 8110f5b7:81
>> 8110f5b8:31 f6   xor%esi,%esi
>> 8110f5ba:31 d2   xor%edx,%edx
>> 8110f5bc:31 c9   xor%ecx,%ecx
>> 8110f5be:41 b8 01 00 00 00   mov$0x1,%r8d
>> 8110f5c4:45 31 c9xor%r9d,%r9d
>> 8110f5c7:4c 89 f7mov%r14,%rdi
>> 8110f5ca:e8 c1 e5 fc ff  callq  810ddb90
>> 
>> 8110f5cf:be 01 00 00 00  mov$0x1,%esi
>> 8110f5d4:48 c7 c2 cf f5 10 81mov$0x8110f5cf,%rdx
>> 8110f5db:4c 89 f7mov%r14,%rdi
>> 8110f5de:e8 8d 08 fd ff  callq  810dfe70
>> 
>> 8110f5e3:e8 08 6e 80 00  callq  819163f0 
>
>> 8110f5e8:4c 89 f8mov%r15,%rax
>> 8110f5eb:49 89 c6mov%rax,%r14
>
> Moves r15 into r14 through rax
>
>
>> 8110f5ee:f6 c4 02test   $0x2,%ah
>> 8110f5f1:75 19   jne8110f60c
>> 
>> 8110f5f3:e8 f8 6d 80 00  callq  819163f0 
>> 8110f5f8:e8 f3 6d 80 00  callq  819163f0 
>
>
>> 8110f5fd:4c 89 75 d0 mov%r14,-0x30(%rbp)
>> 8110f601:ff 75 d0pushq  -0x30(%rbp)
>> 8110f604:9d  popfq
>
> put r14 into -0x30(rbp) and pushes/pops that, see [*] this is 8 bytes
> over stack ?!
>
>> 8110f605:e8 26 cb fc ff  callq  810dc130
>> 
>> 8110f60a:eb 17   jmp8110f623
>> 
>> 8110f60c:e8 2f cb fc ff  callq  810dc140
>> 
>> 8110f611:e8 da 6d 80 00  callq  819163f0 
>> 8110f616:e8 d5 6d 80 00  callq  819163f0 
>> 8110f61b:4c 89 75 d8 mov%r14,-0x28(%rbp)
>> 8110f61f:ff 75 d8pushq  -0x28(%rbp)
>> 8110f622:9d  popfq
>
> puts r14 into -0x28(rbp) and pushes/pops that
>
>> 8110f623:e8 c8 6d 80 00  callq  819163f0 
>> 8110f628:65 8b 04 25 d4 ae 00mov%gs:0xaed4,%eax
>> 8110f62f:00
>> 8110f630:a9 00 00 0f 00  test   $0xf,%eax
>> 8110f635:74 25   je 8110f65c
>> 
>> 8110f637:f6 43 2a 20 testb  $0x20,0x2a(%rbx)
>> 8110f63b:75 1f   jne8110f65c
>> 
>> 8110f63d:48 c7 c7 04 54 c5 81mov$0x81c55404,%rdi
>> 8110f644:be 61 04 00 00  mov$0x461,%esi
>> f

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Sedat Dilek  wrote:
> On 3/2/16, Sedat Dilek  wrote:
>> On 3/2/16, Steven Rostedt  wrote:
>>>
>>> [ Resend with reply all, instead of just "reply" ]
>>>
>>> On Wed, 2 Mar 2016 16:53:36 +0100
>>> Sedat Dilek  wrote:
>>>
>>>> 8110f3f0 :
>>>> 8110f3f0:  55  push   %rbp
>>>> 8110f3f1:  48 89 e5mov%rsp,%rbp
>>>> 8110f3f4:  41 57   push   %r15
>>>> 8110f3f6:  41 56   push   %r14
>>>> 8110f3f8:  53  push   %rbx
>>>> 8110f3f9:  50  push   %rax
>>>> 8110f3fa:  48 89 fbmov%rdi,%rbx
>>>> 8110f3fd:  e8 ee 6f 80 00  callq  819163f0
>>>> 
>>>> 8110f402:  e8 e9 6f 80 00  callq  819163f0
>>>> 
>>>> 8110f407:  e8 e4 6f 80 00  callq  819163f0
>>>> 
>>>> 8110f40c:  e8 df 6f 80 00  callq  819163f0
>>>> 
>>>
>>> What is this about?
>>>
>>
>> Dunno.
>>
>> Not sure if this is relevant or not...
>>
>> [ LINUX-CONFIG ]
>>
>> $ ./scripts/diffconfig /boot/config-4.4.3-3-iniza-small
>> /boot/config-4.4.3-3-llvmlinux-amd64
>>  ARCH_HWEIGHT_CFLAGS "-fcall-saved-rdi -fcall-saved-rsi
>> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9
>> -fcall-saved-r10 -fcall-saved-r11" -> ""
>>
>> ...and my patchset on top of Linux v4.4.3 is attached.
>>
>
> That was my full linux-config and now and really the patchset.
> ( If you are ill, stay in your bed. )
>

For the sake of (in)completeness my dmesg after Xorg crashed and my
usbmouse un-/re-plugged.

- Sedat -
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.3-3-llvmlinux-amd64 
(sedat.di...@gmail.com@fambox) (clang version 3.8.0 ) #1 SMP Wed Mar 2 15:36:44 
CET 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.3-3-llvmlinux-amd64 
root=UUID=001AADA61AAD9964 loop=/ubuntu/disks/root.disk ro
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] Disabled fast string operations
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x3fff] usable
[0.00] BIOS-e820: [mem 0x4000-0x401f] reserved
[0.00] BIOS-e820: [mem 0x4020-0xd9c9efff] usable
[0.00] BIOS-e820: [mem 0xd9c9f000-0xdae7efff] reserved
[0.00] BIOS-e820: [mem 0xdae7f000-0xdaf9efff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data
[0.00] BIOS-e820: [mem 0xdafff000-0xdaff] usable
[0.00] BIOS-e820: [mem 0xdb00-0xdf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved
[0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffd8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00011fdf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Sedat Dilek  wrote:
> On 3/2/16, Steven Rostedt  wrote:
>>
>> [ Resend with reply all, instead of just "reply" ]
>>
>> On Wed, 2 Mar 2016 16:53:36 +0100
>> Sedat Dilek  wrote:
>>
>>> 8110f3f0 :
>>> 8110f3f0:   55  push   %rbp
>>> 8110f3f1:   48 89 e5mov%rsp,%rbp
>>> 8110f3f4:   41 57   push   %r15
>>> 8110f3f6:   41 56   push   %r14
>>> 8110f3f8:   53  push   %rbx
>>> 8110f3f9:   50  push   %rax
>>> 8110f3fa:   48 89 fbmov%rdi,%rbx
>>> 8110f3fd:   e8 ee 6f 80 00  callq  819163f0 
>>> 8110f402:   e8 e9 6f 80 00  callq  819163f0 
>>> 8110f407:   e8 e4 6f 80 00  callq  819163f0 
>>> 8110f40c:   e8 df 6f 80 00  callq  819163f0 
>>
>> What is this about?
>>
>
> Dunno.
>
> Not sure if this is relevant or not...
>
> [ LINUX-CONFIG ]
>
> $ ./scripts/diffconfig /boot/config-4.4.3-3-iniza-small
> /boot/config-4.4.3-3-llvmlinux-amd64
>  ARCH_HWEIGHT_CFLAGS "-fcall-saved-rdi -fcall-saved-rsi
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9
> -fcall-saved-r10 -fcall-saved-r11" -> ""
>
> ...and my patchset on top of Linux v4.4.3 is attached.
>

That was my full linux-config and now and really the patchset.
( If you are ill, stay in your bed. )

- Sedat -
Al Viro (1):
  use ->d_seq to get coherency between ->d_inode and ->d_flags

Sedat Dilek (23):
  kbuild: llvmlinux: Add cross compilation support
  kbuild: llvmlinux: Add support for integrated-assembler (IA)
  kbuild: llvmlinux: Add LLVM bitcode support
  kbuild: llvmlinux: Add some more clang compiler-flags
  kbuild: llvmlinux: Add -Werror compiler-flag to cc-options
  kbuild: llvmlinux: Fix ASM defines
  kbuild: llvmlinux: Fix unsupported -fno-delete-null-pointer-checks compiler-flag
  kbuild: llvmlinux: Fix unsupported -fcatch-undefined-behavior compiler-flag
  compiler-gcc: llvmlinux: Add __maybe_unused attribute for inlining
  fs/compat: llvmlinux: Fix warning in COMPATIBLE_IOCTL define
  bcache: llvmlinux: Replace nested function with __bch_cache_cmp()
  megaraid_sas: llvmlinux: Remove inline from megasas_return_cmd()
  scsi: libosd: llvmlinux: Remove __weak and add __maybe_unused attribute
  mpilib: llvmlinux: Fix compilation with clang
  md/raid10: llvmlinux: Remove VLAIS from handle_reshape_read_error()
  apparmor: llvmlinux: Remove VLAIS from aa_calc_profile_hash()
  x86: llvmlinux: Fix unsupported -falign-{jumps,loops} compiler-flags
  xen: llvmlinux: Remove VLAIS from xen_flush_tlb_others()
  um: llvmlinux: Check for clang compiler in memcpy export
  x86: boot: llvmlinux: Workaround LLVM Bug PR3997
  x86/hweight: boot: llvmlinux: Workaround LLVM Bug PR9457
  Merge branch 'for-4.4/vfs-fixes' into 4.4.3-3-iniza-small
  Merge branch 'for-4.4/llvmlinux-amd64-fixes' into 4.4.3-3-llvmlinux-amd64

 .gitignore|  1 +
 Kbuild|  8 +++
 Makefile  | 36 +++
 arch/x86/Kconfig  |  4 ++--
 arch/x86/Makefile |  6 --
 arch/x86/boot/memory.c|  6 ++
 arch/x86/boot/string.h|  3 +++
 arch/x86/include/asm/arch_hweight.h   | 18 
 arch/x86/um/ksyms.c   |  2 +-
 arch/x86/xen/mmu.c| 35 +++---
 drivers/md/bcache/sysfs.c | 10 +
 drivers/md/raid10.c   |  8 +++
 drivers/scsi/megaraid/megaraid_sas_base.c |  2 +-
 fs/compat_ioctl.c |  2 +-
 fs/dcache.c   | 20 +
 include/linux/compiler-gcc.h  | 12 +--
 include/linux/dcache.h|  4 +---
 include/linux/kbuild.h|  6 +++---
 include/scsi/osd_types.h  |  2 +-
 lib/mpi/Makefile  |  2 ++
 lib/mpi/longlong.h|  9 +++-
 lib/mpi/mpi-inline.h  |  2 +-
 lib/mpi/mpi-internal.h| 10 +
 scripts/Kbuild.include|  6 +++---
 scripts/Makefile.build| 14 
 scripts/mod/Makefile  |  8 +++
 security/apparmor/crypto.c| 17 ++-
 27 files changed, 137 insertions(+), 116 deletions(-)

diff --git a/.

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Peter Zijlstra  wrote:
> On Wed, Mar 02, 2016 at 04:00:49PM +0100, Sedat Dilek wrote:
>> >
>> > Right, most odd. Sedat, could you provide objdump -D of the relevant
>> > sections of vmlinux ?
>> >
>>
>> Can you give some clear instructions - for what shall I look for in
>> special?
>
> objdump -D vmlinux | awk '/<[^>]*>:$/ { p=0; } /:/ { p=1; }
> { if (p) print $0; }'
>
> might be a good start, esp. if the output differs between the LLVM and
> GCC cases (+- address muck).
>

Here the most relevant objdumps as single files.

- Sedat -
8109b5d0 :
8109b5d0:   55  push   %rbp
8109b5d1:   48 89 e5mov%rsp,%rbp
8109b5d4:   53  push   %rbx
8109b5d5:   50  push   %rax
8109b5d6:   48 89 fbmov%rdi,%rbx
8109b5d9:   e8 12 ae 87 00  callq  819163f0 
8109b5de:   31 f6   xor%esi,%esi
8109b5e0:   48 89 dfmov%rbx,%rdi
8109b5e3:   e8 08 00 00 00  callq  8109b5f0 
<__cancel_work_timer>
8109b5e8:   48 83 c4 08 add$0x8,%rsp
8109b5ec:   5b  pop%rbx
8109b5ed:   5d  pop%rbp
8109b5ee:   c3  retq   
8109b5ef:   90  nop

8109b5f0 <__cancel_work_timer>:
8109b5f0:   55  push   %rbp
8109b5f1:   48 89 e5mov%rsp,%rbp
8109b5f4:   41 57   push   %r15
8109b5f6:   41 56   push   %r14
8109b5f8:   41 55   push   %r13
8109b5fa:   41 54   push   %r12
8109b5fc:   53  push   %rbx
8109b5fd:   48 83 ec 48 sub$0x48,%rsp
8109b601:   89 f3   mov%esi,%ebx
8109b603:   49 89 fdmov%rdi,%r13
8109b606:   e8 e5 ad 87 00  callq  819163f0 
8109b60b:   4c 8d 65 b8 lea-0x48(%rbp),%r12
8109b60f:   44 0f b6 fb movzbl %bl,%r15d
8109b613:   48 8d 5d a0 lea-0x60(%rbp),%rbx
8109b617:   eb 17   jmp8109b630 
<__cancel_work_timer+0x40>
8109b619:   48 c7 c7 a0 42 e4 81mov$0x81e442a0,%rdi
8109b620:   48 89 demov%rbx,%rsi
8109b623:   e8 28 84 03 00  callq  810d3a50 

8109b628:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
8109b62f:   00 
8109b630:   4c 89 efmov%r13,%rdi
8109b633:   44 89 femov%r15d,%esi
8109b636:   48 8d 55 d0 lea-0x30(%rbp),%rdx
8109b63a:   e8 91 ed ff ff  callq  8109a3d0 

8109b63f:   41 89 c6mov%eax,%r14d
8109b642:   41 83 fe fe cmp$0xfffe,%r14d
8109b646:   74 07   je 8109b64f 
<__cancel_work_timer+0x5f>
8109b648:   45 85 f6test   %r14d,%r14d
8109b64b:   79 7f   jns8109b6cc 
<__cancel_work_timer+0xdc>
8109b64d:   eb e1   jmp8109b630 
<__cancel_work_timer+0x40>
8109b64f:   e8 9c ad 87 00  callq  819163f0 
8109b654:   65 48 8b 04 25 c0 aemov%gs:0xaec0,%rax
8109b65b:   00 00 
8109b65d:   48 89 45 a8 mov%rax,-0x58(%rbp)
8109b661:   48 c7 45 b0 d0 39 0dmovq   
$0x810d39d0,-0x50(%rbp)
8109b668:   81 
8109b669:   e8 82 ad 87 00  callq  819163f0 
8109b66e:   4c 89 65 b8 mov%r12,-0x48(%rbp)
8109b672:   4c 89 65 c0 mov%r12,-0x40(%rbp)
8109b676:   c7 45 a0 00 00 00 00movl   $0x0,-0x60(%rbp)
8109b67d:   48 c7 45 b0 70 f4 09movq   
$0x8109f470,-0x50(%rbp)
8109b684:   81 
8109b685:   4c 89 6d c8 mov%r13,-0x38(%rbp)
8109b689:   48 c7 c7 a0 42 e4 81mov$0x81e442a0,%rdi
8109b690:   ba 02 00 00 00  mov$0x2,%edx
8109b695:   48 89 demov%rbx,%rsi
8109b698:   e8 e3 80 03 00  callq  810d3780 

8109b69d:   e8 4e ad 87 00  callq  819163f0 
8109b6a2:   e8 49 ad 87 00  cal

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/1/16, Peter Zijlstra  wrote:
> On Tue, Mar 01, 2016 at 10:07:40AM -0500, Steven Rostedt wrote:
>> On Tue, 1 Mar 2016 11:05:42 +0100
>> Sedat Dilek  wrote:
>>
>>
>> > [ FACT #3: TEST-CASE #2 ]
>> >
>> > The most reliable test-case is to simply unplug my external Logitech
>> > USB mouse - saw this by accident.
>> > YES, it was so simple.
>>
>> Just to clarify, this happens on gcc and clang?
>
> Just clang from what I gather.
>

YES, gcc, but I can crash my Xorg, but do not see a pile of nothing in
my dmesg-log.

>> > --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
>> > 21:23:56.399691975 +0100
>> > +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
>> > 2016-02-29 21:28:14.401832240 +0100
>> > @@ -832,3 +832,75 @@
>> >  [   66.529779] PPP BSD Compression module registered
>> >  [   66.563013] PPP Deflate Compression module registered
>> >  [   66.978977] usb 2-1.5: USB disconnect, device number 4
>> > +[  321.937369] usb 2-1.4: USB disconnect, device number 3
>> > +[  321.950810] BUG: sleeping function called from invalid context at
>> > kernel/workqueue.c:2785
>> > +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name:
>> > kworker/2:1
>> > +[  321.950819] 9 locks held by kworker/2:1/44:
>> > +[  321.950820]  #0:  ("usb_hub_wq"){.+.+.+}, at: []
>> > process_one_work+0x30f/0x8d0
>> > +[  321.950830]  #1:  ((&hub->events)){+.+.+.}, at:
>> > [] process_one_work+0x33c/0x8d0
>> > +[  321.950836]  #2:  (&dev->mutex){..}, at: []
>> > hub_event+0x50/0x15b0
>> > +[  321.950844]  #3:  (&dev->mutex){..}, at: []
>> > usb_disconnect+0x5f/0x2c0
>> > +[  321.950849]  #4:  (&dev->mutex){..}, at: []
>> > device_release_driver+0x22/0x40
>> > +[  321.950856]  #5:  (&dev->mutex){..}, at: []
>> > device_release_driver+0x22/0x40
>> > +[  321.950862]  #6:  (input_mutex){+.+.+.}, at: []
>> > __input_unregister_device+0x9a/0x190
>> > +[  321.950869]  #7:  (&dev->mutex#2){+.+...}, at:
>> > [] input_close_device+0x27/0x70
>> > +[  321.950875]  #8:  (hid_open_mut){+.+...}, at: []
>> > usbhid_close+0x28/0xb0 [usbhid]
>> > +[  321.950883] irq event stamp: 47770
>> > +[  321.950885] hardirqs last  enabled at (47769):
>> > [] _raw_spin_unlock_irq+0x32/0x60
>> > +[  321.950889] hardirqs last disabled at (47770):
>> > [] del_timer_sync+0x3c/0x110
>>
>> According to lockdep, interrupts were last disabled in del_timer_sync,
>> and they were never enabled. The numbers in parenthesis show the order
>> of events. _raw_spin_unlock_irq() at 47769, then del_timer_sync at
>> 47770.
>>
>> But why did they not get enabled again? We have:
>>
>>  local_irq_save(flags);
>>  lock_map_acquire(&timer->lockdep_map);
>>  lock_map_release(&timer->lockdep_map);
>>  local_irq_restore(flags);
>>
>> If this caused an issue, then you would have a lockdep splat. But
>> perhaps something corrupted "flags", and interrupts were not re-enabled?
>
> Right, most odd. Sedat, could you provide objdump -D of the relevant
> sections of vmlinux ?
>

Can you give some clear instructions - for what shall I look for in special?

I can send you a 300MiB mail-bomb if you like :-).

$ cd linux-git
$ objdump -D vmlinux > ../objdump-D_vmlinux.txt
$ du -m ../objdump-D_vmlinux.txt
294 ../objdump-D_vmlinux.txt

I have now built with the same kernel-config for gcc and clang and
archived the most interesting stuff.
Before sending the stuff out, I would like to have some clear instructions.

Thanks.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Jiri Kosina  wrote:
> On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>
>> static bool start_flush_work(struct work_struct *work, struct wq_barrier
>> *barr)
>> {
>> struct worker *worker = NULL;
>> struct worker_pool *pool;
>> struct pool_workqueue *pwq;
>>
>> might_sleep();
>>
>> local_irq_disable();
>> pool = get_work_pool(work);
>> if (!pool) {
>> local_irq_enable();
>> return false;
>> }
>>
>> spin_lock(&pool->lock); <--- XXX: spin_lock_irq() ???
>
> No, this is fine. IRQs are unconditionally disabled a few lines above.
>

You are right, I tried with a substitution and that does not matter.

What about passing flags to local_irq_XXX?
And how do I do that?

- Sedat -

> --
> Jiri Kosina
> SUSE Labs
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/2/16, Sedat Dilek  wrote:
> On 3/1/16, Alan Stern  wrote:
>> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>>
>>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>>> wrote:
>>> > On Sat, 3 Oct 2015 12:05:42 +0200
>>> > Sedat Dilek  wrote:
>>> >
>>> >> So, at the beginning... dunno WTF is causing the problems - no
>>> >> workaround for CLANG.
>>> >
>>> > Probably need to compile with gcc and with clang and look at the
>>> > binary
>>> > differences. Or at least what objdump shows.
>>> >
>>>
>>> [ Hope to address this issue to the correct people - CCed some people
>>> I taped on their nerves ]
>>>
>>> Not sure if I should open a new thread?
>>> Please, some clear statements on this.
>>> Thanks.
>>>
>>> The issue is still visible and alive.
>>
>> ...
>>
>>> [ FACT #3: TEST-CASE #2 ]
>>>
>>> The most reliable test-case is to simply unplug my external Logitech
>>> USB mouse - saw this by accident.
>>> YES, it was so simple.
>>>
>>> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
>>> 21:23:56.399691975 +0100
>>> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
>>> 2016-02-29 21:28:14.401832240 +0100
>>> @@ -832,3 +832,75 @@
>>>  [   66.529779] PPP BSD Compression module registered
>>>  [   66.563013] PPP Deflate Compression module registered
>>>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
>>> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
>>> +[  321.950810] BUG: sleeping function called from invalid context at
>>> kernel/workqueue.c:2785
>>> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name:
>>> kworker/2:1
>>
>>> +[  321.950885] hardirqs last  enabled at (47769):
>>> [] _raw_spin_unlock_irq+0x32/0x60
>>> +[  321.950889] hardirqs last disabled at (47770):
>>> [] del_timer_sync+0x3c/0x110
>>> +[  321.950894] softirqs last  enabled at (47112):
>>> [] __do_softirq+0x5a2/0x610
>>> +[  321.950898] softirqs last disabled at (47097):
>>> [] irq_exit+0x9c/0x120
>>> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
>>> 4.5.0-rc6-2-llvmlinux-amd64 #1
>>> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> +[  321.950908] Workqueue: usb_hub_wq hub_event
>>> +[  321.950911]  8800d3326948 0092 
>>> 8800d4347568
>>> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
>>> 8800d4347568
>>> +[  321.950919]  810e28fd 0092 0096
>>> 8800d43475a8
>>> +[  321.950923] Call Trace:
>>> +[  321.950927]  [] dump_stack+0xa4/0xf0
>>> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
>>> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
>>> +[  321.950939]  [] __might_sleep+0x4f/0xc0
>>> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
>>> +[  321.950946]  [] flush_work+0x5c/0x80
>>> +[  321.950949]  [] ? flush_work+0x1a/0x80
>>> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
>>> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
>>> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
>>> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
>>> +[  321.950966]  [] cancel_work_sync+0x18/0x20
>>
>> It's possible that this could be a compiler-related error connected
>> with local_irq_save().  __cancel_work_timer() calls
>>
>>  ret = try_to_grab_pending(work, is_dwork, &flags);
>>
>> and try_to_grab_pending() starts this way:
>>
>> static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
>> unsigned long *flags)
>> {
>>  struct worker_pool *pool;
>>  struct pool_workqueue *pwq;
>>
>>  local_irq_save(*flags);
>>
>> Then later on, __cancel_work_timer() does
>>
>>  local_irq_restore(flags);
>>
>> Maybe CLANG doesn't like local_irq_save() applied to a pointer as
>> opposed to a stack variable.
>>
>> As a quick test, try applying the patch below.  (Note that there is a
>> similar construction in kernel/signal.c.)
>>
>> Alan Stern
>>
>>
>>
>> Index: usb-4.4/kernel/workqueue.c
>> 

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/1/16, Alan Stern  wrote:
> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>
>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>> wrote:
>> > On Sat, 3 Oct 2015 12:05:42 +0200
>> > Sedat Dilek  wrote:
>> >
>> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> workaround for CLANG.
>> >
>> > Probably need to compile with gcc and with clang and look at the binary
>> > differences. Or at least what objdump shows.
>> >
>>
>> [ Hope to address this issue to the correct people - CCed some people
>> I taped on their nerves ]
>>
>> Not sure if I should open a new thread?
>> Please, some clear statements on this.
>> Thanks.
>>
>> The issue is still visible and alive.
>
> ...
>
>> [ FACT #3: TEST-CASE #2 ]
>>
>> The most reliable test-case is to simply unplug my external Logitech
>> USB mouse - saw this by accident.
>> YES, it was so simple.
>>
>> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
>> 21:23:56.399691975 +0100
>> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
>> 2016-02-29 21:28:14.401832240 +0100
>> @@ -832,3 +832,75 @@
>>  [   66.529779] PPP BSD Compression module registered
>>  [   66.563013] PPP Deflate Compression module registered
>>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
>> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
>> +[  321.950810] BUG: sleeping function called from invalid context at
>> kernel/workqueue.c:2785
>> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name:
>> kworker/2:1
>
>> +[  321.950885] hardirqs last  enabled at (47769):
>> [] _raw_spin_unlock_irq+0x32/0x60
>> +[  321.950889] hardirqs last disabled at (47770):
>> [] del_timer_sync+0x3c/0x110
>> +[  321.950894] softirqs last  enabled at (47112):
>> [] __do_softirq+0x5a2/0x610
>> +[  321.950898] softirqs last disabled at (47097):
>> [] irq_exit+0x9c/0x120
>> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
>> 4.5.0-rc6-2-llvmlinux-amd64 #1
>> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> +[  321.950908] Workqueue: usb_hub_wq hub_event
>> +[  321.950911]  8800d3326948 0092 
>> 8800d4347568
>> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
>> 8800d4347568
>> +[  321.950919]  810e28fd 0092 0096
>> 8800d43475a8
>> +[  321.950923] Call Trace:
>> +[  321.950927]  [] dump_stack+0xa4/0xf0
>> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
>> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
>> +[  321.950939]  [] __might_sleep+0x4f/0xc0
>> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
>> +[  321.950946]  [] flush_work+0x5c/0x80
>> +[  321.950949]  [] ? flush_work+0x1a/0x80
>> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
>> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
>> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
>> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
>> +[  321.950966]  [] cancel_work_sync+0x18/0x20
>
> It's possible that this could be a compiler-related error connected
> with local_irq_save().  __cancel_work_timer() calls
>
>   ret = try_to_grab_pending(work, is_dwork, &flags);
>
> and try_to_grab_pending() starts this way:
>
> static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
>  unsigned long *flags)
> {
>   struct worker_pool *pool;
>   struct pool_workqueue *pwq;
>
>   local_irq_save(*flags);
>
> Then later on, __cancel_work_timer() does
>
>   local_irq_restore(flags);
>
> Maybe CLANG doesn't like local_irq_save() applied to a pointer as
> opposed to a stack variable.
>
> As a quick test, try applying the patch below.  (Note that there is a
> similar construction in kernel/signal.c.)
>
> Alan Stern
>
>
>
> Index: usb-4.4/kernel/workqueue.c
> ===
> --- usb-4.4.orig/kernel/workqueue.c
> +++ usb-4.4/kernel/workqueue.c
> @@ -1175,12 +1175,14 @@ out_put:
>   * This function is safe to call from any context including IRQ handler.
>   */
>  static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
> -unsigned long *flags)
> +unsigned long *pflags)
>  {
>   struct worker_pool *pool;
>

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

[Sedat Dilek]

On 3/1/16, Alan Stern  wrote:
> On Tue, 1 Mar 2016, Sedat Dilek wrote:
>
>> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt 
>> wrote:
>> > On Sat, 3 Oct 2015 12:05:42 +0200
>> > Sedat Dilek  wrote:
>> >
>> >> So, at the beginning... dunno WTF is causing the problems - no
>> >> workaround for CLANG.
>> >
>> > Probably need to compile with gcc and with clang and look at the binary
>> > differences. Or at least what objdump shows.
>> >
>>
>> [ Hope to address this issue to the correct people - CCed some people
>> I taped on their nerves ]
>>
>> Not sure if I should open a new thread?
>> Please, some clear statements on this.
>> Thanks.
>>
>> The issue is still visible and alive.
>
> ...
>
>> [ FACT #3: TEST-CASE #2 ]
>>
>> The most reliable test-case is to simply unplug my external Logitech
>> USB mouse - saw this by accident.
>> YES, it was so simple.
>>
>> --- dmesg_4.5.0-rc6-2-llvmlinux-amd64.txt   2016-02-29
>> 21:23:56.399691975 +0100
>> +++ dmesg_4.5.0-rc6-2-llvmlinux-amd64_usbmouse-unplugged.txt
>> 2016-02-29 21:28:14.401832240 +0100
>> @@ -832,3 +832,75 @@
>>  [   66.529779] PPP BSD Compression module registered
>>  [   66.563013] PPP Deflate Compression module registered
>>  [   66.978977] usb 2-1.5: USB disconnect, device number 4
>> +[  321.937369] usb 2-1.4: USB disconnect, device number 3
>> +[  321.950810] BUG: sleeping function called from invalid context at
>> kernel/workqueue.c:2785
>> +[  321.950816] in_atomic(): 0, irqs_disabled(): 1, pid: 44, name:
>> kworker/2:1
>
>> +[  321.950885] hardirqs last  enabled at (47769):
>> [] _raw_spin_unlock_irq+0x32/0x60
>> +[  321.950889] hardirqs last disabled at (47770):
>> [] del_timer_sync+0x3c/0x110
>> +[  321.950894] softirqs last  enabled at (47112):
>> [] __do_softirq+0x5a2/0x610
>> +[  321.950898] softirqs last disabled at (47097):
>> [] irq_exit+0x9c/0x120
>> +[  321.950903] CPU: 2 PID: 44 Comm: kworker/2:1 Not tainted
>> 4.5.0-rc6-2-llvmlinux-amd64 #1
>> +[  321.950905] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> +[  321.950908] Workqueue: usb_hub_wq hub_event
>> +[  321.950911]  8800d3326948 0092 
>> 8800d4347568
>> +[  321.950915]  814ba7d4 8800d43474f8 8800d4340cc0
>> 8800d4347568
>> +[  321.950919]  810e28fd 0092 0096
>> 8800d43475a8
>> +[  321.950923] Call Trace:
>> +[  321.950927]  [] dump_stack+0xa4/0xf0
>> +[  321.950931]  [] ? print_irqtrace_events+0xcd/0xe0
>> +[  321.950936]  [] ___might_sleep+0x295/0x2b0
>> +[  321.950939]  [] __might_sleep+0x4f/0xc0
>> +[  321.950943]  [] start_flush_work+0x2f/0x2a0
>> +[  321.950946]  [] flush_work+0x5c/0x80
>> +[  321.950949]  [] ? flush_work+0x1a/0x80
>> +[  321.950953]  [] ? trace_hardirqs_off+0xd/0x10
>> +[  321.950956]  [] ? try_to_grab_pending+0x4a/0x260
>> +[  321.950960]  [] __cancel_work_timer+0x197/0x290
>> +[  321.950963]  [] ? try_to_del_timer_sync+0xad/0xc0
>> +[  321.950966]  [] cancel_work_sync+0x18/0x20
>
> It's possible that this could be a compiler-related error connected
> with local_irq_save().  __cancel_work_timer() calls
>
>   ret = try_to_grab_pending(work, is_dwork, &flags);
>
> and try_to_grab_pending() starts this way:
>
> static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
>  unsigned long *flags)
> {
>   struct worker_pool *pool;
>   struct pool_workqueue *pwq;
>
>   local_irq_save(*flags);
>
> Then later on, __cancel_work_timer() does
>
>   local_irq_restore(flags);
>
> Maybe CLANG doesn't like local_irq_save() applied to a pointer as
> opposed to a stack variable.
>
> As a quick test, try applying the patch below.  (Note that there is a
> similar construction in kernel/signal.c.)
>
> Alan Stern
>
>
>
> Index: usb-4.4/kernel/workqueue.c
> ===
> --- usb-4.4.orig/kernel/workqueue.c
> +++ usb-4.4/kernel/workqueue.c
> @@ -1175,12 +1175,14 @@ out_put:
>   * This function is safe to call from any context including IRQ handler.
>   */
>  static int try_to_grab_pending(struct work_struct *work, bool is_dwork,
> -unsigned long *flags)
> +unsigned long *pflags)
>  {
>   struct worker_pool *pool;
>

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Sun, Nov 16, 2014 at 3:34 AM, Greg KH  wrote:
> On Sun, Nov 16, 2014 at 02:40:15AM +0100, Sedat Dilek wrote:
>> On Sat, Nov 15, 2014 at 9:07 PM, Greg KH  wrote:
>> > On Sat, Nov 15, 2014 at 10:23:55AM +0100, Sedat Dilek wrote:
>> >> On Fri, Nov 14, 2014 at 5:18 PM, Dan Williams  wrote:
>> >> > On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
>> >> >> On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek  
>> >> >> wrote:
>> >> >> > On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams  wrote:
>> >> >> >> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> I wanted to understand what is going on the kernel-side when
>> >> >> >>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> >> >> >>> Generation: UMTS / HSPA).
>> >> >> >>>
>> >> >> >>> Especially the correlation between the diverse USB/NET 
>> >> >> >>> kernel-drivers
>> >> >> >>> and how the networking is setup.
>> >> >> >>
>> >> >> >
>> >> >> > [ Sitting in front of a foreign Windows machine ]
>> >> >> >
>> >> >> > [ CC Aleksander ]
>> >> >> >
>> >> >> > Hi Dan,
>> >> >> >
>> >> >> > sorry for the late (and short) response.
>> >> >> >
>> >> >> > AFAICS you have given a "skeleton" for a "usb-wwan-networking"
>> >> >> > documentation :-).
>> >> >> >
>> >> >> > Personally, I would like to take into account some kernel-config
>> >> >> > options and some more things.
>> >> >> >
>> >> >>
>> >> >> I started with documenting...
>> >> >>
>> >> >> I have still some difficulties in understanding USB WWAN Networking.
>> >> >> So, this is what I revealed...
>> >> >>
>> >> >> # USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
>> >> >>
>> >> >> ### USB-NETWORKING AND WWAN SETUP
>> >> >> CONFIG_USB_USBNET=m<--- usb networking
>> >> >> CONFIG_USB_NET_CDCETHER=m  <--- usb-wwan (net) configuration
>> >> >> CONFIG_USB_SERIAL_WWAN=m   <--- usb-wwan (serial) configuration
>> >> >> CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"
>> >> >
>> >> > Most WWAN devices actually require option, because most WWAN devices
>> >> > have "serial" ports (even if they aren't used for PPP), and 'option' is
>> >> > the driver that handles this.  The 'option' name is historic, but the
>> >> > driver should really be called something like 'wwan-serial-generic' or
>> >> > something like that.
>> >> >ö"
>> >>
>> >> Is there sth. against renaming the "option" driver to 
>> >> "wwan-serial-generic"?
>> >
>> > Yes, people's scripts might break that are hard-coded to use the
>> > "option" driver.
>> >
>>
>> As far as I read on LKML... breaking userspace is a reason not to do
>> such changes.
>
> Exactly.
>
>> That's really a reason not to break "handmade" scripts on some machines?
>
> Yes.
>
>> As this is new to me... is that documented?
>
> It's our "culture" :)
>

OK.

>> Surely, it's fretful to change scripts, but life is change.
>> For me there is a more reasonable thing... Did you grep for "option"
>> pattern in the kernel sources?
>> Try :-).
>
> Oh I know, I wrote the first version of this driver and named it this :)
>

Ah, IIRC the company was called so.

>> > greg "here, have a vowel, they are cheap" k-h
>>
>> Hmm, being a non-English native, I am not sure to get this...
>> What about languages from mostly Eastern countries having so much
>> consonants in a single word like Russian, Polish, etc.
>> Not every language is rich like German which has WOWels like "ä" (ae)
>> "ö" (oe) "ü" (ue).
>
> I was referring to your "sth." abbreviation above.
>

Hmm, I thought this is a "normal" abbreviation.
Maybe I should not mix IRC and Email writing styles.

Thanks for your comments.

- Sedat -

P.S.: /me was reading about the systemd transition (now default
init-system) and reading about Joey Hess leaving Debian, Damn and I
initiated the Debian systemd wiki. If I ever knew... Life is change
and neat and polite people died (I lost my parents the last two
years).

> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Sat, Nov 15, 2014 at 9:07 PM, Greg KH  wrote:
> On Sat, Nov 15, 2014 at 10:23:55AM +0100, Sedat Dilek wrote:
>> On Fri, Nov 14, 2014 at 5:18 PM, Dan Williams  wrote:
>> > On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
>> >> On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek  
>> >> wrote:
>> >> > On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams  wrote:
>> >> >> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I wanted to understand what is going on the kernel-side when
>> >> >>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> >> >>> Generation: UMTS / HSPA).
>> >> >>>
>> >> >>> Especially the correlation between the diverse USB/NET kernel-drivers
>> >> >>> and how the networking is setup.
>> >> >>
>> >> >
>> >> > [ Sitting in front of a foreign Windows machine ]
>> >> >
>> >> > [ CC Aleksander ]
>> >> >
>> >> > Hi Dan,
>> >> >
>> >> > sorry for the late (and short) response.
>> >> >
>> >> > AFAICS you have given a "skeleton" for a "usb-wwan-networking"
>> >> > documentation :-).
>> >> >
>> >> > Personally, I would like to take into account some kernel-config
>> >> > options and some more things.
>> >> >
>> >>
>> >> I started with documenting...
>> >>
>> >> I have still some difficulties in understanding USB WWAN Networking.
>> >> So, this is what I revealed...
>> >>
>> >> # USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
>> >>
>> >> ### USB-NETWORKING AND WWAN SETUP
>> >> CONFIG_USB_USBNET=m<--- usb networking
>> >> CONFIG_USB_NET_CDCETHER=m  <--- usb-wwan (net) configuration
>> >> CONFIG_USB_SERIAL_WWAN=m   <--- usb-wwan (serial) configuration
>> >> CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"
>> >
>> > Most WWAN devices actually require option, because most WWAN devices
>> > have "serial" ports (even if they aren't used for PPP), and 'option' is
>> > the driver that handles this.  The 'option' name is historic, but the
>> > driver should really be called something like 'wwan-serial-generic' or
>> > something like that.
>> >ö"
>>
>> Is there sth. against renaming the "option" driver to "wwan-serial-generic"?
>
> Yes, people's scripts might break that are hard-coded to use the
> "option" driver.
>

As far as I read on LKML... breaking userspace is a reason not to do
such changes.
That's really a reason not to break "handmade" scripts on some machines?
As this is new to me... is that documented?
Surely, it's fretful to change scripts, but life is change.
For me there is a more reasonable thing... Did you grep for "option"
pattern in the kernel sources?
Try :-).

> thanks,
>
> greg "here, have a vowel, they are cheap" k-h

Hmm, being a non-English native, I am not sure to get this...
What about languages from mostly Eastern countries having so much
consonants in a single word like Russian, Polish, etc.
Not every language is rich like German which has WOWels like "ä" (ae)
"ö" (oe) "ü" (ue).

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Fri, Nov 14, 2014 at 5:18 PM, Dan Williams  wrote:
> On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
>> On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek  wrote:
>> > On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams  wrote:
>> >> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> >>> Hi,
>> >>>
>> >>> I wanted to understand what is going on the kernel-side when
>> >>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> >>> Generation: UMTS / HSPA).
>> >>>
>> >>> Especially the correlation between the diverse USB/NET kernel-drivers
>> >>> and how the networking is setup.
>> >>
>> >
>> > [ Sitting in front of a foreign Windows machine ]
>> >
>> > [ CC Aleksander ]
>> >
>> > Hi Dan,
>> >
>> > sorry for the late (and short) response.
>> >
>> > AFAICS you have given a "skeleton" for a "usb-wwan-networking"
>> > documentation :-).
>> >
>> > Personally, I would like to take into account some kernel-config
>> > options and some more things.
>> >
>>
>> I started with documenting...
>>
>> I have still some difficulties in understanding USB WWAN Networking.
>> So, this is what I revealed...
>>
>> # USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
>>
>> ### USB-NETWORKING AND WWAN SETUP
>> CONFIG_USB_USBNET=m<--- usb networking
>> CONFIG_USB_NET_CDCETHER=m  <--- usb-wwan (net) configuration
>> CONFIG_USB_SERIAL_WWAN=m   <--- usb-wwan (serial) configuration
>> CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"
>
> Most WWAN devices actually require option, because most WWAN devices
> have "serial" ports (even if they aren't used for PPP), and 'option' is
> the driver that handles this.  The 'option' name is historic, but the
> driver should really be called something like 'wwan-serial-generic' or
> something like that.
>

Is there sth. against renaming the "option" driver to "wwan-serial-generic"?

> You're missing a few other "net" type drivers:
>
> CONFIG_USB_NET_QMI_WWAN = Qualcomm QMI capable devices (net)
> CONFIG_USB_HSO = "Option High-Speed" (net) devices
> CONFIG_USB_NET_KALMIA = Samsung LTE dongle (net)
> CONFIG_USB_SIERRA_NET = Sierra devices (net)
> CONFIG_USB_NET_CDC_NCM = Ericsson F5321 (?) and some others (net)
> CONFIG_USB_NET_HUAWEI_CDC_NCM = Huawei NCM variant (net)
> CONFIG_USB_VL600 = LG VL600 / AD600 LTE device (net)
> CONFIG_USB_NET_CDC_MBIM = MBIM (net) devices (popular currently)
>
> and maybe even:
>
> CONFIG_USB_CDC_PHONET = Nokia phones and USB sticks, not "net" but
> proprietary protocol that handles both data/control channels
>
> For the "serial" side:
>
> CONFIG_USB_ACM = generic "serial" devices, many are *not* WWAN but many
> WWAN devices use this class/driver
> CONFIG_USB_SERIAL_QCAUX = Various Qualcomm-based devices' "auxiliary"
> ports (DIAG, GPS, etc)
> CONFIG_USB_SERIAL_QUALCOMM = Firmware loading and "auxiliary" ports on
> various Qualcomm Gobi devices
> CONFIG_USB_SERIAL_SIERRAWIRELESS = Older Sierra device serial ports for
> PPP/control and "auxiliary" functions
>
> WWAN devices basically mix & match these drivers depending on what
> interfaces the firmware exposes.
>
> For example, some Sierra devices may require both
> CONFIG_USB_SERIAL_SIERRAWIRELESS and CONFIG_USB_SIERRA_NET.
>
> Older Sierra devices may use only CONFIG_USB_SERIAL_SIERRAWIRELESS and
> do not provide a 'net' port at all, but use only PPP.
>
> Sierra devices based on Icera chips may use CONFIG_USB_ACM and either
> CONFIG_USB_SIERRA_NET or CONFIG_USB_NET_CDCETHER.
>
> Some Huawei devices may use CONFIG_USB_NET_CDCETHER and either
> CONFIG_USB_SERIAL_OPTION or CONFIG_USB_ACM.
>
> Other Huawei devices may use CONFIG_USB_NET_QMI_WWAN and
> CONFIG_USB_SERIAL_OPTION.
>
> Even other Huawei devices may be Qualcomm Gobi type and use
> CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_QUALCOMM.
>
> So you see it really depends on exactly how the firmware is implemented.
> But in general, devices still fall into the categories I originally
> listed, and the drivers fall into specific categories too ("net",
> "serial", "proprietary"), and devices mix & match drivers to achieve the
> end result.
>

Hi Dan,

Hmm, yeah I see more clearly this usb-networking is not that simple.
Anyway, I will face y

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek  wrote:
> On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams  wrote:
>> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>>> Hi,
>>>
>>> I wanted to understand what is going on the kernel-side when
>>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>>> Generation: UMTS / HSPA).
>>>
>>> Especially the correlation between the diverse USB/NET kernel-drivers
>>> and how the networking is setup.
>>
>
> [ Sitting in front of a foreign Windows machine ]
>
> [ CC Aleksander ]
>
> Hi Dan,
>
> sorry for the late (and short) response.
>
> AFAICS you have given a "skeleton" for a "usb-wwan-networking"
> documentation :-).
>
> Personally, I would like to take into account some kernel-config
> options and some more things.
>

I started with documenting...

I have still some difficulties in understanding USB WWAN Networking.
So, this is what I revealed...

# USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK

### USB-NETWORKING AND WWAN SETUP
CONFIG_USB_USBNET=m<--- usb networking
CONFIG_USB_NET_CDCETHER=m  <--- usb-wwan (net) configuration
CONFIG_USB_SERIAL_WWAN=m   <--- usb-wwan (serial) configuration
CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"

### PPP OPTIONS
CONFIG_PPP=y
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_ASYNC=m

Beyond the PPP options, I wanted to understand what
CONFIG_USB_NET_CDCETHER does and why I need it.
Can someone help?

Thanks.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/Kconfig#n189

P.S.: cdc_ether Kconfig option and checking my logs

>From [1]...
...
config USB_NET_CDCETHER
tristate "CDC Ethernet support (smart devices such as cable modems)"
depends on USB_USBNET
default y
help
 This option supports devices conforming to the Communication Device
 Class (CDC) Ethernet Control Model, a specification that's easy to
 implement in device firmware.  The CDC specifications are available
 from <http://www.usb.org/>.

 CDC Ethernet is an implementation option for DOCSIS cable modems
 that support USB connectivity, used for non-Microsoft USB hosts.
 The Linux-USB CDC Ethernet Gadget driver is an open implementation.
   This driver should work with at least the following devices:

   * Dell Wireless 5530 HSPA
 * Ericsson PipeRider (all variants)
   * Ericsson Mobile Broadband Module (all variants)
 * Motorola (DM100 and SB4100)
 * Broadcom Cable Modem (reference design)
   * Toshiba (PCX1100U and F3507g/F3607gw)
   * ...

 This driver creates an interface named "ethX", where X depends on
 what other networking devices you have in use.  However, if the
 IEEE 802 "local assignment" bit is set in the address, a "usbX"
 name is used instead.
...

>From my logs...

$ dmesg | egrep -i 'option|wwan|ppp|3-1.2|huawei|gsm|modem'
[0.00] please try 'cgroup_disable=memory' option if you don't
want memory cgroups
[0.549498] PPP generic driver version 2.4.2
[1.299059] usb 3-1.2: new high-speed USB device number 3 using ehci-pci
[1.394084] usb 3-1.2: New USB device found, idVendor=12d1, idProduct=1436
[1.394095] usb 3-1.2: New USB device strings: Mfr=4, Product=3,
SerialNumber=0
[1.394100] usb 3-1.2: Product: HUAWEI Mobile
[1.394103] usb 3-1.2: Manufacturer: HUAWEI Technology
[2.115424] usb-storage 3-1.2:1.0: USB Mass Storage device detected
[2.125026] usb-storage 3-1.2:1.1: USB Mass Storage device detected
[2.125607] usb-storage 3-1.2:1.2: USB Mass Storage device detected
[2.125888] usb-storage 3-1.2:1.3: USB Mass Storage device detected
[2.126187] usb-storage 3-1.2:1.4: USB Mass Storage device detected
[2.126461] usb-storage 3-1.2:1.5: USB Mass Storage device detected
[2.127098] scsi host11: usb-storage 3-1.2:1.5
[2.129370] usb-storage 3-1.2:1.6: USB Mass Storage device detected
[2.131685] scsi host12: usb-storage 3-1.2:1.6
[3.127317] scsi 11:0:0:0: CD-ROMHUAWEI   Mass Storage
   2.31 PQ: 0 ANSI: 2
[3.137589] scsi 12:0:0:0: Direct-Access HUAWEI   SD Storage
   2.31 PQ: 0 ANSI: 2
[   13.500302] cdc_ether 3-1.2:1.1 wwan0: register 'cdc_ether' at
usb-:00:1a.0-1.2, Mobile Broadband Network Device,
02:50:f3:00:00:00
[   14.160221] usbcore: registered new interface driver option
[   14.160820] usbserial: USB Serial support registered for GSM modem (1-port)
[   14.160940] option 3-1.2:1.0: GSM modem (1-port) converter detected
[   14.163032] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB0
[   14.163305] option 3-1.2:1.3: GSM modem (1-port) converter detected
[   14.163676] usb 3-1.2: GSM modem (1-port) converter now attached to ttyUSB1
[   14.

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Wed, Nov 12, 2014 at 12:51 PM, Aleksander Morgado
 wrote:
>
[...}
> I saw the reporter talk about Ubuntu Precise (12.04) and Trusty (14.04), so
> only in the latter mmcli will be available (if I'm not mistaken). For
> Precise, this Ubuntu page shows how to enable debug logs:
> https://wiki.ubuntu.com/DebuggingModemmanager
>

That wiki needs to be pimped-up (-> clarify on testing tools aka
outdated "mm-test.py", -> Ubuntu releases w/ and w/o upstart, etc.).

- Sedat -

"test: remove testers of the old interface"
[1] 
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=f3f499fcec13e6ffa9a428972c1108e7c23065d2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Wed, Nov 12, 2014 at 12:51 PM, Aleksander Morgado
 wrote:
>
> On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams  wrote:
>>
>> > The next mystery is what is network-manager doing in the background?
>> > I have seen that modem-manager is invoked, but as said I would like to
>> > understand the "internas" (means check the logs, turn on some
>> > debugging kernel-space/user-space, etc.).
>>
>> NetworkManager uses ModemManager for all WWAN control, NM only handles
>> the configuration storage and IP addressing parts of the setup.
>> ModemManager handles modem hardware detection, capability detection,
>> WWAN registration and setup, signal strength reporting, network
>> connection initiation, and bearer IP addressing method determination.
>>
>> If you want more information from ModemManager, you can run "mmcli
>> --help" or "mmcli --set-logging=debug".
>
>
> That (mmcli) will only be available in ModemManager >= 1.x, BTW. And beware
> of --set-logging=debug, as syslog may limit those if MM sends too many too
> fast. In general I usually prefer to ask for --debug output just in case:
> http://www.freedesktop.org/wiki/Software/ModemManager/Debugging/
>
> I saw the reporter talk about Ubuntu Precise (12.04) and Trusty (14.04), so
> only in the latter mmcli will be available (if I'm not mistaken). For
> Precise, this Ubuntu page shows how to enable debug logs:
> https://wiki.ubuntu.com/DebuggingModemmanager
>

Hi Aleksander,

thanks for the web-links.
IMHO both can be placed in the "usb-wwan-networking" documentation I
have in mind.
The fdo-weblink is distro-independant.

Regards,
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams  wrote:
> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> Hi,
>>
>> I wanted to understand what is going on the kernel-side when
>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> Generation: UMTS / HSPA).
>>
>> Especially the correlation between the diverse USB/NET kernel-drivers
>> and how the networking is setup.
>

[ Sitting in front of a foreign Windows machine ]

[ CC Aleksander ]

Hi Dan,

sorry for the late (and short) response.

AFAICS you have given a "skeleton" for a "usb-wwan-networking"
documentation :-).

Personally, I would like to take into account some kernel-config
options and some more things.

> General overview:  there are many different types of WWAN devices and
> they fall into a couple groups:
>
> 1) PPP-only via serial ports; IP packets are transmitted via a PPP
> interface (eg, ppp0) created after sending some AT commands to the modem
> over that serial port.  IP addressing happens via PPP's IPCP/IPV6CP
> protocols.
>
> 2) Net interface with AT commands over serial ports: the modem provides
> a 'net' interface that is activated with proprietary AT commands over a
> serial port. IP addressing happens via either DHCP on that net interface
> after the AT setup, or the IP/DNS details are queried via proprietary AT
> commands.
>
> 3) Net interface with proprietary protocols: the modem provides a 'net'
> interface that is activated via proprietary protocols (QMI, MBIM, CnS,
> etc).  IP addressing happens either via DHCP on the net interface after
> proprietary protocol setup, or the IP/DNS details are queried via
> proprietary protocol commands.
>
> It's often possible to know what category a device fits into, but even
> devices from the same manufacturer with *the same model number* can fall
> into different categories, because the firmware is different, or because
> the firmware can switch between these categories using special commands.
>

As I have a ppp0 network-interface setup, I guess I have the example #1 here.

What about putting these examples into a section "General Overview:
WWAN devices".

>> I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
>> compared the configs to get the stuff run on 3.18-rc2+.
>> Beyond the "option" driver, I required usb_serial / usb_wwan to be
>> activated and some more ("cde-ether" or sth. sound similiar...).
>> ( Currently, I am not sitting (it's a Windows machine) in front of my
>> machine, so I cannot send you my latest kernel-config. )
>>
>> As usually I looked into Documentation directory.
>> So, my 1st question where do I get some informations in general on
>> this topic - usb [1] or net subdirectory (seen from kernel-side)?
>> I found a usb-serial kernel-doc [1].
>> ( I have no Linux Git source so I cannot grep for patterns. )
>
> None of those really have any information about WWAN specific setup, and
> I fear that if documentation was added, it would be quickly out-of-date
> because device manufacturers change things so frequently.
>

Anyway as said above a brief documentation would be nice.
Dunno placed below "networking" or "usb" - what is your POV?

>> The next mystery is what is network-manager doing in the background?
>> I have seen that modem-manager is invoked, but as said I would like to
>> understand the "internas" (means check the logs, turn on some
>> debugging kernel-space/user-space, etc.).
>
> NetworkManager uses ModemManager for all WWAN control, NM only handles
> the configuration storage and IP addressing parts of the setup.
> ModemManager handles modem hardware detection, capability detection,
> WWAN registration and setup, signal strength reporting, network
> connection initiation, and bearer IP addressing method determination.
>

Hmm, as I have a GUI hiding what's going on behind the scenes :-), I
wanted to have a step-by-step understanding - not only in words - also
understanding my logs.

What about putting this section in sth. like a "(General Overview:)
Userland software".

> If you want more information from ModemManager, you can run "mmcli
> --help" or "mmcli --set-logging=debug".
>

That sort of information could be placed in a "Debugging (userland)" section.
Or at least with some links to what Alexander pointed to.

What sort of debugging can I do from kernel-side (-> "Debugging kernel-side")?

>> I am not sure but syncing with 3G network seems to take a while since
>> I really can connect to the Internet.
>
> What do you mean by "syncing"?
>

"

Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)

[Sedat Dilek]

Hi,

I wanted to understand what is going on the kernel-side when
connecting to the Internet via a Huawei E173 USB web-stick (3rd
Generation: UMTS / HSPA).

Especially the correlation between the diverse USB/NET kernel-drivers
and how the networking is setup.

I have tested a Ubuntu trusty kernel on my Ubuntu/precise system and
compared the configs to get the stuff run on 3.18-rc2+.
Beyond the "option" driver, I required usb_serial / usb_wwan to be
activated and some more ("cde-ether" or sth. sound similiar...).
( Currently, I am not sitting (it's a Windows machine) in front of my
machine, so I cannot send you my latest kernel-config. )

As usually I looked into Documentation directory.
So, my 1st question where do I get some informations in general on
this topic - usb [1] or net subdirectory (seen from kernel-side)?
I found a usb-serial kernel-doc [1].
( I have no Linux Git source so I cannot grep for patterns. )

The next mystery is what is network-manager doing in the background?
I have seen that modem-manager is invoked, but as said I would like to
understand the "internas" (means check the logs, turn on some
debugging kernel-space/user-space, etc.).

I am not sure but syncing with 3G network seems to take a while since
I really can connect to the Internet.

I am happy about some fruitful informations or web-links...

Thanks in advance.

Regards,
- Sedat -

[1] https://www.kernel.org/doc/Documentation/usb/usb-serial.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 11:15 PM, Sarah Sharp
 wrote:
> On Wed, Aug 28, 2013 at 07:39:14PM +0200, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 7:24 PM, Dmitry Kasatkin  
>> wrote:
>> Still noone answered me why "drivers/usb/host/xhci-ring.c" does NOT
>> include  (dev_info_ratelimited() and other defines).
>> I am expecting that... even I see...
>>
>>   drivers/usb/host/.xhci-ring.o.cmd:715:  include/linux/device.h \
>>
>> ...where I don't know why this happens.
>>
>> ( For me this is a bit more important than """trimming""" my
>> responses, I keep the history... )
>>
>> - Sedat -
>>
>> P.S.: List of includes in xhci-ring.c
>>
>> $ grep ^'#include' -nr drivers/usb/host/xhci-ring.c
>> 67:#include 
>> 68:#include 
>> 69:#include "xhci.h"
>> 70:#include "xhci-trace.h"
>
> Because a header that xhci-ring.c uses includes device.h instead.
>
> drivers/usb/host/xhci/xhci-ring.c includes
> drivers/usb/host/xhci.h which includes
> include/linux/usb.h which includes
> include/linux/device.h
>
> All USB host controllers depend on including usb.h, so I don't think
> there's a need for the driver to explicitly include device.h.
>

Thanks for the explanations.
On the one hand it is a fine thingie to place include-files at one
single place - think of renamed or moved (uapi) include-files.
Looking at xhci-ring.c means for me to dig through 3 or 4 files as
someone not dealing everyday with USB stuff.

What is the effect of CONFIG_DYNAMIC_DEBUG=[y|n] in the affected code?

- Sedat -

P.S.: The forgotten patch is now in usb-next, but I don't see any
credits, coins, gold, platin...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 7:24 PM, Dmitry Kasatkin  wrote:
> On 28/08/13 19:59, Sarah Sharp wrote:
>> Please trim your replies.
>>
>> On Wed, Aug 28, 2013 at 01:53:49PM +0300, Dmitry Kasatkin wrote:
>> That change seems to cause the problems:
>>
>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>
>> - Sedat -
>>
>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>
> Hello,
>
> [PATCHv2 1/2] was not applied before.
> I pointed this out few hours ago...
>> So commit 0730d52a86919300a39a2be37f6c140997dfb82f 'xhci:prevent
>> "callbacks suppressed" when debug is not enabled' needed to be applied
>> after your first patch?  And basically applying that patch alone breaks
>> the build?
>
> Right...
> May be I had to stress it somehow... sorry.
>

Still noone answered me why "drivers/usb/host/xhci-ring.c" does NOT
include  (dev_info_ratelimited() and other defines).
I am expecting that... even I see...

  drivers/usb/host/.xhci-ring.o.cmd:715:  include/linux/device.h \

...where I don't know why this happens.

( For me this is a bit more important than """trimming""" my
responses, I keep the history... )

- Sedat -

P.S.: List of includes in xhci-ring.c

$ grep ^'#include' -nr drivers/usb/host/xhci-ring.c
67:#include 
68:#include 
69:#include "xhci.h"
70:#include "xhci-trace.h"


>> Ugh.  Sorry about this.  Greg, how do you want to handle this?
>>
>> Sarah "needs a vacation" Sharp
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 1:19 PM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 12:53 PM, Dmitry Kasatkin
>  wrote:
>> On 28/08/13 13:46, Sedat Dilek wrote:
>>> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>>>  wrote:
>>>> On 28/08/13 13:38, Sedat Dilek wrote:
>>>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  
>>>>> wrote:
>>>>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
>>>>>> wrote:
>>>>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>>>>> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Changes since 20130827:
>>>>>>>>
>>>>>>>> The f2fs tree lost its build failure.
>>>>>>>>
>>>>>>>> The md tree gained a conflict against the arm tree.
>>>>>>>>
>>>>>>>> The libata tree lost its build failure.
>>>>>>>>
>>>>>>>> The spi tree lost its build failure.
>>>>>>>>
>>>>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>>>>
>>>>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>>>>
>>>>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>>>>
>>>>>>>> 
>>>>>>>>
>>>>>>>> My build here breaks like this:
>>>>>>>>
>>>>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>>>>   CC  drivers/video/console/softcursor.o
>>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>>>>> (first use in this function)
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>>>>> is reported only once for each function it appears in
>>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>>>>> (first use in this function)
>>>>>>>> cc1: some warnings being treated as errors
>>>>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>>>>
>>>>>>>> My kernel-config is attached.
>>>>>>>>
>>>>>>> Looks like  or  is missing.
>>>>>>>
>>>>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>>>>> linux/include/
>>>>>>> linux/include/linux/device.h:1118:
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>>> linux/include/linux/device.h:1121:
>>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>>>>> _ddebug *descriptor, const char *fmt, ...);
>>>>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>>>>> linux/include/linux/dynamic_debug.h:76:
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>>> linux/include/linux/dynamic_debug.h:78:
>>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>>> linux/include/linux/dynamic_debug.h:84:
>>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>>> linux/include/linux/dynamic_debug

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:53 PM, Dmitry Kasatkin
 wrote:
> On 28/08/13 13:46, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>>  wrote:
>>> On 28/08/13 13:38, Sedat Dilek wrote:
>>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  
>>>> wrote:
>>>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
>>>>> wrote:
>>>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20130827:
>>>>>>>
>>>>>>> The f2fs tree lost its build failure.
>>>>>>>
>>>>>>> The md tree gained a conflict against the arm tree.
>>>>>>>
>>>>>>> The libata tree lost its build failure.
>>>>>>>
>>>>>>> The spi tree lost its build failure.
>>>>>>>
>>>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>>>
>>>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>>>
>>>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> My build here breaks like this:
>>>>>>>
>>>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>>>   CC  drivers/video/console/softcursor.o
>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>>>> (first use in this function)
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>>>> is reported only once for each function it appears in
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>>>> (first use in this function)
>>>>>>> cc1: some warnings being treated as errors
>>>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>>>
>>>>>>> My kernel-config is attached.
>>>>>>>
>>>>>> Looks like  or  is missing.
>>>>>>
>>>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>>>> linux/include/
>>>>>> linux/include/linux/device.h:1118:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/device.h:1121:
>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>>>> _ddebug *descriptor, const char *fmt, ...);
>>>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>>>> linux/include/linux/dynamic_debug.h:76:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:78:
>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>> linux/include/linux/dynamic_debug.h:84:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:92:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:101:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>>>>>
>>>>>> Can't say which one is preferred here.
>>>>>>
>>>>> looks like device.h is preferred or used in the sources, but this does
>>>>> not fix the issue here.
>>>>> sth. wrong with dev_dbg_ratelimited()?
>>>>>
>>>> That change seems to cause the problems:
>>>>
>>>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>>>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>>>
>>>> - Sedat -
>>>>
>>>> [1] 
>>>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>>>
>>> Hello,
>>>
>>> [PATCHv2 1/2] was not applied before.
>>> I pointed this out few hours ago...
>>>
>>> - Dmitry
>>>
>> Yupp, just read it a few seconds ago.
>>
>> Where is that whatever 2nd fix?
>>
>> - Sedat -
>>
>> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
>>
>
> 1/2 - was not applied
> https://patchwork.kernel.org/patch/2850217/
>

Tested-by: Sedat Dilek  (against next-20130828).

- Sedat -

> 2/2 - this one was applied
> https://patchwork.kernel.org/patch/2850218/
>
> - Dmitry
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:53 PM, Dmitry Kasatkin
 wrote:
> On 28/08/13 13:46, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>>  wrote:
>>> On 28/08/13 13:38, Sedat Dilek wrote:
>>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  
>>>> wrote:
>>>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
>>>>> wrote:
>>>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>>>> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20130827:
>>>>>>>
>>>>>>> The f2fs tree lost its build failure.
>>>>>>>
>>>>>>> The md tree gained a conflict against the arm tree.
>>>>>>>
>>>>>>> The libata tree lost its build failure.
>>>>>>>
>>>>>>> The spi tree lost its build failure.
>>>>>>>
>>>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>>>
>>>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>>>
>>>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> My build here breaks like this:
>>>>>>>
>>>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>>>   CC  drivers/video/console/softcursor.o
>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>>>> [-Werror=implicit-function-declaration]
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>>>> (first use in this function)
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>>>> is reported only once for each function it appears in
>>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>>>> (first use in this function)
>>>>>>> cc1: some warnings being treated as errors
>>>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>>>
>>>>>>> My kernel-config is attached.
>>>>>>>
>>>>>> Looks like  or  is missing.
>>>>>>
>>>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>>>> linux/include/
>>>>>> linux/include/linux/device.h:1118:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/device.h:1121:
>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>>>> _ddebug *descriptor, const char *fmt, ...);
>>>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>>>> linux/include/linux/dynamic_debug.h:76:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:78:
>>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>>> linux/include/linux/dynamic_debug.h:84:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:92:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>>> linux/include/linux/dynamic_debug.h:101:
>>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>>>>>
>>>>>> Can't say which one is preferred here.
>>>>>>
>>>>> looks like device.h is preferred or used in the sources, but this does
>>>>> not fix the issue here.
>>>>> sth. wrong with dev_dbg_ratelimited()?
>>>>>
>>>> That change seems to cause the problems:
>>>>
>>>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>>>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>>>
>>>> - Sedat -
>>>>
>>>> [1] 
>>>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>>>
>>> Hello,
>>>
>>> [PATCHv2 1/2] was not applied before.
>>> I pointed this out few hours ago...
>>>
>>> - Dmitry
>>>
>> Yupp, just read it a few seconds ago.
>>
>> Where is that whatever 2nd fix?
>>
>> - Sedat -
>>
>> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
>>
>
> 1/2 - was not applied
> https://patchwork.kernel.org/patch/2850217/
>
> 2/2 - this one was applied
> https://patchwork.kernel.org/patch/2850218/
>
> - Dmitry
>

Thanks for the patchwork-URLs, it's easier to apply from there.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:46 PM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
>  wrote:
>> On 28/08/13 13:38, Sedat Dilek wrote:
>>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
>>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  
>>>> wrote:
>>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20130827:
>>>>>>
>>>>>> The f2fs tree lost its build failure.
>>>>>>
>>>>>> The md tree gained a conflict against the arm tree.
>>>>>>
>>>>>> The libata tree lost its build failure.
>>>>>>
>>>>>> The spi tree lost its build failure.
>>>>>>
>>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>>
>>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>>
>>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>>
>>>>>> 
>>>>>>
>>>>>> My build here breaks like this:
>>>>>>
>>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>>   CC  drivers/video/console/softcursor.o
>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>>> [-Werror=implicit-function-declaration]
>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>>> (first use in this function)
>>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>>> is reported only once for each function it appears in
>>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>>> (first use in this function)
>>>>>> cc1: some warnings being treated as errors
>>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>>
>>>>>> My kernel-config is attached.
>>>>>>
>>>>> Looks like  or  is missing.
>>>>>
>>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>>> linux/include/
>>>>> linux/include/linux/device.h:1118:
>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>> linux/include/linux/device.h:1121:
>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>>> _ddebug *descriptor, const char *fmt, ...);
>>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>>> linux/include/linux/dynamic_debug.h:76:
>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>> linux/include/linux/dynamic_debug.h:78:
>>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>>> linux/include/linux/dynamic_debug.h:84:
>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>> linux/include/linux/dynamic_debug.h:92:
>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>>> linux/include/linux/dynamic_debug.h:101:
>>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>>>>
>>>>> Can't say which one is preferred here.
>>>>>
>>>> looks like device.h is preferred or used in the sources, but this does
>>>> not fix the issue here.
>>>> sth. wrong with dev_dbg_ratelimited()?
>>>>
>>> That change seems to cause the problems:
>>>
>>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>>
>>> - Sedat -
>>>
>>> [1] 
>>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>>
>> Hello,
>>
>> [PATCHv2 1/2] was not applied before.
>> I pointed this out few hours ago...
>>
>> - Dmitry
>>
>
> Yupp, just read it a few seconds ago.
>
> Where is that whatever 2nd fix?
>
> - Sedat -
>
> [1] http://marc.info/?l=linux-usb&m=137767590629869&w=2

Was 1/2 sent to linux-usb, too?

I found your patch in the linux-kernel offline mail-archives.

[PATCHv2 1/2] dev-core: fix build break when DEBUG is enabled

- Sedat -

http://marc.info/?l=linux-kernel&m=137761487111748&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:43 PM, Dmitry Kasatkin
 wrote:
> On 28/08/13 13:38, Sedat Dilek wrote:
>> On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
>>> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
>>>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  
>>>> wrote:
>>>>> Hi all,
>>>>>
>>>>> Changes since 20130827:
>>>>>
>>>>> The f2fs tree lost its build failure.
>>>>>
>>>>> The md tree gained a conflict against the arm tree.
>>>>>
>>>>> The libata tree lost its build failure.
>>>>>
>>>>> The spi tree lost its build failure.
>>>>>
>>>>> The arm-soc tree gained conflicts against the usb tree.
>>>>>
>>>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>>>
>>>>> The akpm-current tree gained a conflict against the net tree.
>>>>>
>>>>> 
>>>>>
>>>>> My build here breaks like this:
>>>>>
>>>>>   CC  drivers/usb/host/xhci-ring.o
>>>>>   CC  drivers/video/console/softcursor.o
>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>>>> [-Werror=implicit-function-declaration]
>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>>>> (first use in this function)
>>>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>>>> is reported only once for each function it appears in
>>>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>>>> (first use in this function)
>>>>> cc1: some warnings being treated as errors
>>>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>>>> make[4]: *** [drivers/usb/host] Error 2
>>>>>
>>>>> My kernel-config is attached.
>>>>>
>>>> Looks like  or  is missing.
>>>>
>>>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>>>> linux/include/
>>>> linux/include/linux/device.h:1118:
>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>> linux/include/linux/device.h:1121:
>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>>>> _ddebug *descriptor, const char *fmt, ...);
>>>> linux/include/linux/dynamic_debug.h:63:#define
>>>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>>>> linux/include/linux/dynamic_debug.h:76:
>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>> linux/include/linux/dynamic_debug.h:78:
>>>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>>>> linux/include/linux/dynamic_debug.h:84:
>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>> linux/include/linux/dynamic_debug.h:92:
>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>>>> linux/include/linux/dynamic_debug.h:101:
>>>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>>>
>>>> Can't say which one is preferred here.
>>>>
>>> looks like device.h is preferred or used in the sources, but this does
>>> not fix the issue here.
>>> sth. wrong with dev_dbg_ratelimited()?
>>>
>> That change seems to cause the problems:
>>
>> commit 0730d52a86919300a39a2be37f6c140997dfb82f
>> "xhci:prevent "callbacks suppressed" when debug is not enabled"
>>
>> - Sedat -
>>
>> [1] 
>> http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
>>
> Hello,
>
> [PATCHv2 1/2] was not applied before.
> I pointed this out few hours ago...
>
> - Dmitry
>

Yupp, just read it a few seconds ago.

Where is that whatever 2nd fix?

- Sedat -

[1] http://marc.info/?l=linux-usb&m=137767590629869&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 12:29 PM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
>> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
>>> Hi all,
>>>
>>> Changes since 20130827:
>>>
>>> The f2fs tree lost its build failure.
>>>
>>> The md tree gained a conflict against the arm tree.
>>>
>>> The libata tree lost its build failure.
>>>
>>> The spi tree lost its build failure.
>>>
>>> The arm-soc tree gained conflicts against the usb tree.
>>>
>>> The dma-mapping tree gained a conflict against the driver-core tree.
>>>
>>> The akpm-current tree gained a conflict against the net tree.
>>>
>>> 
>>>
>>> My build here breaks like this:
>>>
>>>   CC  drivers/usb/host/xhci-ring.o
>>>   CC  drivers/video/console/softcursor.o
>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>>> [-Werror=implicit-function-declaration]
>>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>>> (first use in this function)
>>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>>> is reported only once for each function it appears in
>>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>>> (first use in this function)
>>> cc1: some warnings being treated as errors
>>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>>> make[4]: *** [drivers/usb/host] Error 2
>>>
>>> My kernel-config is attached.
>>>
>>
>> Looks like  or  is missing.
>>
>> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
>> linux/include/
>> linux/include/linux/device.h:1118:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/device.h:1121:
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
>> _ddebug *descriptor, const char *fmt, ...);
>> linux/include/linux/dynamic_debug.h:63:#define
>> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
>> linux/include/linux/dynamic_debug.h:76:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:78:
>> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
>> linux/include/linux/dynamic_debug.h:84:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:92:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
>> linux/include/linux/dynamic_debug.h:101:
>> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>>
>> Can't say which one is preferred here.
>>
>
> looks like device.h is preferred or used in the sources, but this does
> not fix the issue here.
> sth. wrong with dev_dbg_ratelimited()?
>

That change seems to cause the problems:

commit 0730d52a86919300a39a2be37f6c140997dfb82f
"xhci:prevent "callbacks suppressed" when debug is not enabled"

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/xhci-ring.c?h=usb-next&id=0730d52a86919300a39a2be37f6c140997dfb82f
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 11:56 AM, Sedat Dilek  wrote:
> On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
>> Hi all,
>>
>> Changes since 20130827:
>>
>> The f2fs tree lost its build failure.
>>
>> The md tree gained a conflict against the arm tree.
>>
>> The libata tree lost its build failure.
>>
>> The spi tree lost its build failure.
>>
>> The arm-soc tree gained conflicts against the usb tree.
>>
>> The dma-mapping tree gained a conflict against the driver-core tree.
>>
>> The akpm-current tree gained a conflict against the net tree.
>>
>> 
>>
>> My build here breaks like this:
>>
>>   CC  drivers/usb/host/xhci-ring.o
>>   CC  drivers/video/console/softcursor.o
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
>> [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
>> (first use in this function)
>> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
>> is reported only once for each function it appears in
>> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
>> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
>> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
>> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
>> (first use in this function)
>> cc1: some warnings being treated as errors
>> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
>> make[4]: *** [drivers/usb/host] Error 2
>>
>> My kernel-config is attached.
>>
>
> Looks like  or  is missing.
>
> $ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr 
> linux/include/
> linux/include/linux/device.h:1118:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/device.h:1121:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
> _ddebug *descriptor, const char *fmt, ...);
> linux/include/linux/dynamic_debug.h:63:#define
> DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
> linux/include/linux/dynamic_debug.h:76:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:78:
> __dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
> linux/include/linux/dynamic_debug.h:84:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:92:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
> linux/include/linux/dynamic_debug.h:101:
> DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \
>
> Can't say which one is preferred here.
>

looks like device.h is preferred or used in the sources, but this does
not fix the issue here.
sth. wrong with dev_dbg_ratelimited()?

- sedat -


xhci-ring.diff
Description: Binary data

Re: linux-next: Tree for Aug 28 [ xhci build breakage ]

[Sedat Dilek]

On Wed, Aug 28, 2013 at 11:49 AM, Sedat Dilek  wrote:
> Hi all,
>
> Changes since 20130827:
>
> The f2fs tree lost its build failure.
>
> The md tree gained a conflict against the arm tree.
>
> The libata tree lost its build failure.
>
> The spi tree lost its build failure.
>
> The arm-soc tree gained conflicts against the usb tree.
>
> The dma-mapping tree gained a conflict against the driver-core tree.
>
> The akpm-current tree gained a conflict against the net tree.
>
> 
>
> My build here breaks like this:
>
>   CC  drivers/usb/host/xhci-ring.o
>   CC  drivers/video/console/softcursor.o
> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_intr_tx':
> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
> function 'DEFINE_DYNAMIC_DEBUG_METADATA'
> [-Werror=implicit-function-declaration]
> drivers/usb/host/xhci-ring.c:3090:3: error: 'descriptor' undeclared
> (first use in this function)
> drivers/usb/host/xhci-ring.c:3090:3: note: each undeclared identifier
> is reported only once for each function it appears in
> drivers/usb/host/xhci-ring.c:3090:3: error: implicit declaration of
> function '__dynamic_pr_debug' [-Werror=implicit-function-declaration]
> drivers/usb/host/xhci-ring.c: In function 'xhci_queue_isoc_tx_prepare':
> drivers/usb/host/xhci-ring.c:3875:3: error: 'descriptor' undeclared
> (first use in this function)
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/usb/host/xhci-ring.o] Error 1
> make[4]: *** [drivers/usb/host] Error 2
>
> My kernel-config is attached.
>

Looks like  or  is missing.

$ egrep -w '__dynamic_pr_debug|DEFINE_DYNAMIC_DEBUG_METADATA' -nr linux/include/
linux/include/linux/device.h:1118:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/device.h:1121:
__dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
linux/include/linux/dynamic_debug.h:45:int __dynamic_pr_debug(struct
_ddebug *descriptor, const char *fmt, ...);
linux/include/linux/dynamic_debug.h:63:#define
DEFINE_DYNAMIC_DEBUG_METADATA(name, fmt) \
linux/include/linux/dynamic_debug.h:76:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/dynamic_debug.h:78:
__dynamic_pr_debug(&descriptor, pr_fmt(fmt),\
linux/include/linux/dynamic_debug.h:84:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/dynamic_debug.h:92:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
linux/include/linux/dynamic_debug.h:101:
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,   \

Can't say which one is preferred here.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH usb-next] USB: Improve documentation for usbmon

[Sedat Dilek]

This is a give-back to USB folks who helped me in a USB debug issue.

Signed-off-by: Sedat Dilek 
---
 Documentation/usb/usbmon.txt | 87 
 1 file changed, 55 insertions(+), 32 deletions(-)

diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt
index c42bb9c..02f5845 100644
--- a/Documentation/usb/usbmon.txt
+++ b/Documentation/usb/usbmon.txt
@@ -23,35 +23,53 @@ in a text format. This is used for two purposes. First, it 
serves as a
 common trace exchange format for tools while more sophisticated formats
 are finalized. Second, humans can read it in case tools are not available.
 
-To collect a raw text trace, execute following steps.
+To collect a (raw text) usbmon trace, execute the following steps.
 
-1. Prepare
+Step #1: Prerequisites and preperation
 
-Mount debugfs (it has to be enabled in your kernel configuration), and
-load the usbmon module (if built as module). The second step is skipped
-if usbmon is built into the kernel.
+You should enable the following kernel-config options:
 
-# mount -t debugfs none_debugs /sys/kernel/debug
-# modprobe usbmon
-#
+CONFIG_DEBUG_FS=y   <--- Enable DebugFS
+CONFIG_USB_DEBUG=y  <--- Enable USB debugging
+CONFIG_USB_MON=m<--- Build usbmon as kernel-module
 
-Verify that bus sockets are present.
+Mount debugfs and load usbmon module:
 
-# ls /sys/kernel/debug/usb/usbmon
-0s  0u  1s  1t  1u  2s  2t  2u  3s  3t  3u  4s  4t  4u
-#
+   # mount -t debugfs none_debugs /sys/kernel/debug
 
-Now you can choose to either use the socket '0u' (to capture packets on all
+   # modprobe -v usbmon
+   insmod /lib/modules/$(uname -r)/kernel/drivers/usb/mon/usbmon.ko
+
+The second step is skipped if usbmon is built into the kernel.
+
+Verify that the bus sockets are present:
+
+   # ls /sys/kernel/debug/usb/usbmon
+   0s  0u  1s  1t  1u  2s  2t  2u  3s  3t  3u  4s  4t  4u
+
+Now, you can choose to either use the socket '0u' (to capture packets on all
 buses), and skip to step #3, or find the bus used by your device with step #2.
 This allows to filter away annoying devices that talk continuously.
 
-2. Find which bus connects to the desired device
+NOTE: The 'lsusb' utiliy might be helpful for hardware diagnosis.
+
+Step #2: Find which bus connects to the desired/affected USB device
+
+How to find the bus which corresponds to the device?
+Usually, you do it by looking for the vendor and product string.
+
+   # dmesg | grep usb | egrep -i 'vendor|product'
 
-Run "cat /sys/kernel/debug/usb/devices", and find the T-line which corresponds
-to the device. Usually you do it by looking for the vendor string. If you have
-many similar devices, unplug one and compare the two
-/sys/kernel/debug/usb/devices outputs. The T-line will have a bus number.
-Example:
+All USB devices are listed here:
+
+   # cat /sys/kernel/debug/usb/devices
+
+The T-line will have a bus number.
+
+If you have many similar devices, unplug one and compare the two
+/sys/kernel/debug/usb/devices outputs.
+
+EXAMPLE:
 
 T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
 D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
@@ -59,33 +77,38 @@ P:  Vendor=0557 ProdID=2004 Rev= 1.00
 S:  Manufacturer=ATEN
 S:  Product=UC100KM V2.00
 
-"Bus=03" means it's bus 3. Alternatively, you can look at the output from
-"lsusb" and get the bus number from the appropriate line. Example:
+"Bus=03" in the T-line means it's bus 3.
+Alternatively, you can look at the output from "lsusb" and get the bus number
+from the appropriate line.
+
+EXAMPLE:
 
 Bus 003 Device 002: ID 0557:2004 ATEN UC100KM V2.00
 
-3. Start 'cat'
+Step #3: Start a usbmon tracing session
+
+To listen on a single bus (here: 3), run:
 
-# cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out
+   # cat /sys/kernel/debug/usb/usbmon/3u > /tmp/usbmon-3u.txt
 
-to listen on a single bus, otherwise, to listen on all buses, type:
+Otherwise, to listen on all buses, type:
 
-# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
+   # cat /sys/kernel/debug/usb/usbmon/0u > /tmp/usbmon-all.txt
 
 This process will be reading until killed. Naturally, the output can be
 redirected to a desirable location. This is preferred, because it is going
 to be quite long.
 
-4. Perform the desired operation on the USB bus
+Step #4: Perform the desired operation on the USB bus
 
-This is where you do something that creates the traffic: plug in a flash key,
-copy files, control a webcam, etc.
+This is where you do something that creates traffic in the logs:
+Plug in a flash key, copy files, control a webcam, do a suspend-and-resume etc.
 
-5. Kill cat
+Step #5: Stop the usbmon tracing session
 
-Usually it's done with a keyboard interrupt (Control-C).
+Usually, it's done with a keyboard interrupt (Control-C).
 
-At this point the output file (/tmp/1.mon.out in t

Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resume async: error -32 ]

[Sedat Dilek]

On Thu, Apr 25, 2013 at 5:49 PM, Alan Stern  wrote:
> On Thu, 25 Apr 2013, Sedat Dilek wrote:
>
>> [ Run logging on USB-bus #1 ]
>>
>> # cat /sys/kernel/debug/usb/usbmon/1u > /tmp/usbmon-1u.txt <--- USB-bus #01
>>
>> [ Do suspend plus resume ]
>>
>> ...
>>
>> [ Check /tmp/usbmon-1u.txt file ]
>>
>> ...
>>
>> File attached!
>
> That also looks normal.  Did you have CONFIG_USB_DEBUG enabled during
> this test?  If you did, you could try turning it back off to see if the
> original problem returns while still doing a usbmon trace.
>

As my system works as "expected" after suspend-resume and as you
pointed out "this is harmless" I am not really willing to do more
"homework".

The ipc-sem-next issue has stolen quite bit of my time.

Thanks for the usbmon hint, now I know for next USB issues what to do.
And I have never tried my USB-XHCI interface :-).

/me is just an encouraged Linux-kernel hobbyist.

- Sedat -

> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resume async: error -32 ]

[Sedat Dilek]

On Thu, Apr 25, 2013 at 5:44 PM, Alan Stern  wrote:
> On Wed, 24 Apr 2013, Sedat Dilek wrote:
>
>> With CONFIG_USB_DEBUG=y I do not see a PM/async line.
>>
>> Might you have a look at the logs?
>
> They look quite normal.  Except for one thing: The built-in hubs appear
> to have gotten reset during the suspend/resume, for no apparent reason.
> That's probably the reason why the Logitech mouse needed a reset.
>
> I don't know why the mouse reset worked this time but not before,
> unless it's a subtle timing issue (the extra debugging output causes
> the resume to go a little more slowly).
>

Thanks for your patience, help, hints and explanations.

You want me to send a patch against usb-next to clarify a bit on the
kernel-config options to be enabled as prereqs in case of
usbmon-tracing. If you think it's worth or not let me know.

- Sedat -

> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resume async: error -32 ]

[Sedat Dilek]

On Wed, Apr 24, 2013 at 11:17 PM, Alan Stern  wrote:
> On Wed, 24 Apr 2013, Sedat Dilek wrote:
>
>> > Did this work differently under earlier kernels?
>> >
>>
>> Unfortunately, s/r did not work for several Linux-Next releases as
>> there is missing tglx's patch pendinging in tip.git/timers/core.
>
> Have you tried testing under 3.8?  Or earlier releases?
>
>> > This indicates that the optical mouse didn't survive the suspend/resume
>> > sequence and had to be reenumerated.  Without more information, there's
>> > no way to tell specifically what went wrong during the initial reset at
>> > timestamp 62.353997.
>> >
>> > If you want to pursue this farther, you could enable CONFIG_USB_DEBUG.
>> > You could also collect a usbmon trace for bus 1 showing what happens
>> > during the suspend and resume.
>> >
>>
>> Hmm, I can try to enable CONFIG_USB_DEBUG and build a new kernel.
>>
>> Can you give me more hints how to do a usbmon-trace?
>
> See Documentation/usb/usbmon.txt.
>

Grrr, that docs do not mention which kernel-configs have to be set!

CONFIG_USB_DEBUG=y is not enough.

# modprobe -v usbmon
FATAL: Module usbmon not found.

# CONFIG_USB_MON is not set <--- Grrr!!!

Doing a -4 build...

- Sedat -

>> > On the other hand, what difference does it really make if a mouse has
>> > to be reenumerated?
>> >
>>
>> As a non-USB-expert it's hard to interprete such "bogus" lines in your logs.
>> I am curious enough to ask which is fair :-).
>> AFAICS in your eyes this is "harmless"?
>
> If the device continues to work normally after the resume and none of
> your programs are affected, then it is harmless.
>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resume async: error -32 ]

[Sedat Dilek]

On Wed, Apr 24, 2013 at 10:32 PM, Alan Stern  wrote:
> On Wed, 24 Apr 2013, Sedat Dilek wrote:
>
>> > [ CC linux-pm and linux-usb (ehci) folks ]
>> >
>> > This happens with my external USB mouse after suspend/resume.
>> >
>> > Excerpt (full dmesg and kernel-config attached):
>> >
>> > $ dmesg | egrep -i 'usb|async' | grep 1-1.2
>> > [1.258602] usb 1-1.2: new low-speed USB device number 3 using ehci-pci
>> > [1.368649] usb 1-1.2: New USB device found, idVendor=046d, 
>> > idProduct=c00e
>> > [1.368661] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
>> > SerialNumber=0
>> > [1.368668] usb 1-1.2: Product: USB-PS/2 Optical Mouse
>> > [1.368672] usb 1-1.2: Manufacturer: Logitech
>> > [1.957999] input: Logitech USB-PS/2 Optical Mouse as
>> > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input4
>> > [   62.353997] usb 1-1.2: reset low-speed USB device number 3 using 
>> > ehci-pci
>> > [   62.636893] PM: Device 1-1.2 failed to resume async: error -32
>> > [   64.243543] usb 1-1.2: USB disconnect, device number 3
>> > [   64.380328] usb 1-1.2: new low-speed USB device number 5 using ehci-pci
>> > [   64.477612] usb 1-1.2: New USB device found, idVendor=046d, 
>> > idProduct=c00e
>> > [   64.477618] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
>> > SerialNumber=0
>> > [   64.477621] usb 1-1.2: Product: USB-PS/2 Optical Mouse
>> > [   64.477623] usb 1-1.2: Manufacturer: Logitech
>> > [   64.481934] input: Logitech USB-PS/2 Optical Mouse as
>> > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input11
>> >
>
> Did this work differently under earlier kernels?
>

Unfortunately, s/r did not work for several Linux-Next releases as
there is missing tglx's patch pendinging in tip.git/timers/core.

The last days I also use the touchpad, so the issue is new to me,
which says not that much :-).

[1] 
http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers/core&id=77c675ba18836802f6b73d2d773481d06ebc0f04

>> Thos 3 lines IIRC are important (one line missing above):
>>
>> [   62.353997] usb 1-1.2: reset low-speed USB device number 3 using ehci-pci
>> [   62.636877] dpm_run_callback(): usb_dev_resume+0x0/0x20 returns -32
>> [   62.636893] PM: Device 1-1.2 failed to resume async: error -32
>>
>> - Sedat -
>>
>> > Any help/hints/infos welcome :-)!
>
> This indicates that the optical mouse didn't survive the suspend/resume
> sequence and had to be reenumerated.  Without more information, there's
> no way to tell specifically what went wrong during the initial reset at
> timestamp 62.353997.
>
> If you want to pursue this farther, you could enable CONFIG_USB_DEBUG.
> You could also collect a usbmon trace for bus 1 showing what happens
> during the suspend and resume.
>

Hmm, I can try to enable CONFIG_USB_DEBUG and build a new kernel.

Can you give me more hints how to do a usbmon-trace?

> On the other hand, what difference does it really make if a mouse has
> to be reenumerated?
>

As a non-USB-expert it's hard to interprete such "bogus" lines in your logs.
I am curious enough to ask which is fair :-).
AFAICS in your eyes this is "harmless"?

Thanks for the fast as lightning reply!

- Sedat -

> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for Apr 24 [ PM: Device 1-1.2 failed to resume async: error -32 ]

[Sedat Dilek]

On Wed, Apr 24, 2013 at 10:00 PM, Sedat Dilek  wrote:
> On Wed, Apr 24, 2013 at 10:07 AM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> There will be no linux-next release tomorrow (April 25).
>>
>> Changes since 20130423:
>>
>> The net-next tree lost its build failure.
>>
>> The staging tree gained a build failure for which I disabled a driver.
>>
>> The arm-soc tree gained a conflict against the pm tree.
>>
>> 
>>
>
> [ CC linux-pm and linux-usb (ehci) folks ]
>
> This happens with my external USB mouse after suspend/resume.
>
> Excerpt (full dmesg and kernel-config attached):
>
> $ dmesg | egrep -i 'usb|async' | grep 1-1.2
> [1.258602] usb 1-1.2: new low-speed USB device number 3 using ehci-pci
> [1.368649] usb 1-1.2: New USB device found, idVendor=046d, idProduct=c00e
> [1.368661] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [1.368668] usb 1-1.2: Product: USB-PS/2 Optical Mouse
> [1.368672] usb 1-1.2: Manufacturer: Logitech
> [1.957999] input: Logitech USB-PS/2 Optical Mouse as
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input4
> [   62.353997] usb 1-1.2: reset low-speed USB device number 3 using ehci-pci
> [   62.636893] PM: Device 1-1.2 failed to resume async: error -32
> [   64.243543] usb 1-1.2: USB disconnect, device number 3
> [   64.380328] usb 1-1.2: new low-speed USB device number 5 using ehci-pci
> [   64.477612] usb 1-1.2: New USB device found, idVendor=046d, idProduct=c00e
> [   64.477618] usb 1-1.2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [   64.477621] usb 1-1.2: Product: USB-PS/2 Optical Mouse
> [   64.477623] usb 1-1.2: Manufacturer: Logitech
> [   64.481934] input: Logitech USB-PS/2 Optical Mouse as
> /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input11
>

Thos 3 lines IIRC are important (one line missing above):

[   62.353997] usb 1-1.2: reset low-speed USB device number 3 using ehci-pci
[   62.636877] dpm_run_callback(): usb_dev_resume+0x0/0x20 returns -32
[   62.636893] PM: Device 1-1.2 failed to resume async: error -32

- Sedat -

> Any help/hints/infos welcome :-)!
>
> Regards,
> - Sedat .-
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared

[Sedat Dilek]

On Mon, Feb 11, 2013 at 8:19 PM, Yinghai Lu  wrote:
> On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley  
> wrote:
>> On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote:
>>> On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu  wrote:
>>> > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley  
>>> > wrote:
>>> >> On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote:
>>> >>> On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote:
>>> >>> > On Tue, 5 Feb 2013, Peter Hurley wrote:
>>> >>> >
>>> >>> > > With -next-20130204:
>>> >>> > >
>>> >>> > > [   33.855570] irq 18: nobody cared (try booting with the "irqpoll" 
>>> >>> > > option)
>>> >>> > > [   33.855580] Pid: 0, comm: swapper/4 Not tainted 
>>> >>> > > 3.8.0-next-20130204-xeon #20130204
>>> >>> > > [   33.855582] Call Trace:
>>> >>> > > [   33.855585][] 
>>> >>> > > __report_bad_irq+0x36/0xe0
>>> >>> > > [   33.855600]  [] note_interrupt+0x1aa/0x200
>>> >>> > > [   33.855606]  [] ? mwait_idle+0x82/0x1b0
>>> >>> > > [   33.855610]  [] 
>>> >>> > > handle_irq_event_percpu+0xc9/0x260
>>> >>> > > [   33.855614]  [] handle_irq_event+0x48/0x70
>>> >>> > > [   33.855618]  [] handle_fasteoi_irq+0x5a/0x100
>>> >>> > > [   33.855624]  [] handle_irq+0x22/0x40
>>> >>> > > [   33.855630]  [] do_IRQ+0x5a/0xd0
>>> >>> > > [   33.855636]  [] common_interrupt+0x6d/0x6d
>>> >>> > > [   33.855638][] ? 
>>> >>> > > rcu_eqs_enter_common+0x4a/0x320
>>> >>> > > [   33.855646]  [] ? mwait_idle+0x82/0x1b0
>>> >>> > > [   33.855649]  [] ? mwait_idle+0x29/0x1b0
>>> >>> > > [   33.855653]  [] cpu_idle+0x116/0x130
>>> >>> > > [   33.855658]  [] start_secondary+0x251/0x258
>>> >>> > > [   33.855660] handlers:
>>> >>> > > [   33.855664] [] usb_hcd_irq
>>> >>> > > [   33.855667] Disabling IRQ #18
>>> >>> > >
>>> >> https://bugzilla.kernel.org/show_bug.cgi?id=53561
>>> >>
>>> >> Maybe this is some interaction with all the new ACPI code and fixes
>>> >> written in those 8 days.
>>> >
>>> > interrupt routing seems get changed:
>>> > next:
>>> >5:  0  0  0  0  0
>>> > 0  0  0   IO-APIC-fasteoi   snd_ctxfi
>>> >   18:  99970 13 16 20  99940
>>> > 13 13 16   IO-APIC-fasteoi   uhci_hcd:usb4
>>> > v3.8-rc7:
>>> >   18:424 15 11112420
>>> > 16 18105   IO-APIC-fasteoi   uhci_hcd:usb4, snd_ctxfi
>>> >
>>> > These messages in the bad dmesg log are interesting since PCI INT A is 
>>> > routed
>>> > on
>>> > irq 18 with the kernels that work.
>>> > [8.983246] pci :00:1e.0: can't derive routing for PCI INT A
>>> > [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5
>>> > ...
>>> >
>>> > acpi_pci_irq_add_prt() add wrong bus for that bridge, because that
>>> > that bridge is not scanned.
>>> >
>>> > Will check if I can produce one patch for it.
>>>
>>> Hi Peter,
>>>
>>> Can you try attached debug patch?
>>
>> Fixed, thanks.
>
> Bjorn, Rafael,
>
> acpi_pci_irq_add_prt need to be called after pci bridge get scanned,
> so we can not call it from pci_acpi_setup, after we move dev_register
> for pci_dev early.
>
> The attached debug patch move down that calling into
> pci_bus_add_devices and that will make prt works again.
>
> Can acpi provide another hook after bridge get scanned?
>

23: +   /* need to after bridge is scanned */
24: +   pcibios_irq_setup(&dev->dev);

... need to *be called* after...

Even this is a temporary workaround, can you send a separate patch for this?

- Sedat -

P.S.: Still wonder why people use "linux-2.6" as prefix in their patches.

> Thanks
>
> Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: Tree for July 17 (debugobjects: bt | btusb | usb related?)

[Sedat Dilek]

On Fri, Jul 20, 2012 at 11:47 AM, Stanislaw Gruszka  wrote:
> On Wed, Jul 18, 2012 at 08:06:17PM +0200, Sedat Dilek wrote:
>> On Tue, Jul 17, 2012 at 7:41 AM, Stephen Rothwell  
>> wrote:
>> > Hi all,
>> >
>> > Changes since 20120716:
>> >
>>
>> Not sure what the root cause of this issue is.
>>
>> I see the following call-trace in linux-next (next-20120717).
>>
>> [   23.431889] [ cut here ]
>> [   23.431896] WARNING: at lib/debugobjects.c:261 
>> debug_print_object+0x8e/0xb0()
>> [   23.431897] Hardware name: 
>> [   23.431901] ODEBUG: free active (active state 0) object type:
>> timer_list hint: delayed_work_timer_fn+0x0/0x40
> There are few delayed works on hci_dev structure, it's hard to say which
> one is not stopped before kfree.
>
>> # CONFIG_DEBUG_OBJECTS_WORK is not set
> If you enable that option, it should show which delayed work is causing 
> trouble.
>

OK, thanks for the explanations & hints!
I will activate that kconfig-option.

FYI: With yesterday's linux-next (next-20120719) I didn't trap into
this regression (same kernel-config + several bootups).

- Sedat -

> Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html