Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1522204 > unrolled thread

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-15 01:20 +0100
    Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Oliver Neukum <oneukum@suse.com> - 2016-11-15 12:20 +0100
    Re: crash by cdc_acm driver in kernels 4.8-rc1/5 poma <pomidorabelisima@gmail.com> - 2016-11-15 12:30 +0100
      Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-15 14:30 +0100
        Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Oliver Neukum <oneukum@suse.com> - 2016-11-16 13:50 +0100
          Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-16 16:10 +0100
            Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-17 03:00 +0100
              Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-17 10:20 +0100
                Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-17 18:20 +0100
                  Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Oliver Neukum <oneukum@suse.com> - 2016-11-21 14:30 +0100
                    Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-21 17:00 +0100
                      Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-21 21:30 +0100
                        Re: crash by cdc_acm driver in kernels 4.8-rc1/5 poma <pomidorabelisima@gmail.com> - 2016-11-22 01:00 +0100
                      Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Bjørn Mork <bjorn@mork.no> - 2016-11-22 19:00 +0100
                        Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-23 01:50 +0100
                    Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-22 16:40 +0100
                      Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Bjørn Mork <bjorn@mork.no> - 2016-11-22 19:10 +0100
                        Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Wim Osterholt <wim@djo.tudelft.nl> - 2016-11-23 02:00 +0100
                          Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Bjørn Mork <bjorn@mork.no> - 2016-11-23 09:00 +0100
                            Re: crash by cdc_acm driver in kernels 4.8-rc1/5 Alan Stern <stern@rowland.harvard.edu> - 2016-11-23 16:10 +0100

#1522204 — Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:

> It definitely does not crash and is probed and your .config is not
> extremely unusual.

Hmmm.

> ... Something odd is going on.

Whell, yes.
The only thing that appears you'll have to do is unset 'CONFIG_SMP'.

My machines didn't have the luxury of multicore processors (until recently),
so there never has been any reason to deliberately switch these options on!

In the process of searching, many options may have changed. The crash/OOPS
has now mitigated into just a WARNING with a call trace.
(Or it could be a totally different bug?)
After the call trace the device is working normally and a shutdown
completes to the end now.
That is with the config given here:
http://webserver.djo.tudelft.nl/.config-4.9-rc4.OK (CONFIG_SMP=y)
http://webserver.djo.tudelft.nl/WARNING-4.9-rc4    (call trace for C_S unset)

Tests on other machines with (slightly) different configs all seem to
confirm that the problems are gone when CONFIG_SMP is set.

Regards, Wim.

[toc] | [next] | [standalone]

#1522592

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-11-15 at 01:16 +0100, Wim Osterholt wrote:

Hi,

> Whell, yes.
> The only thing that appears you'll have to do is unset 'CONFIG_SMP'.

OK. I haven't tested that, nor would I ever considered it.
 
> My machines didn't have the luxury of multicore processors (until recently),
> so there never has been any reason to deliberately switch these options on!
> 
> In the process of searching, many options may have changed. The crash/OOPS
> has now mitigated into just a WARNING with a call trace.
> (Or it could be a totally different bug?)
> After the call trace the device is working normally and a shutdown
> completes to the end now.
> That is with the config given here:
> http://webserver.djo.tudelft.nl/.config-4.9-rc4.OK (CONFIG_SMP=y)
> http://webserver.djo.tudelft.nl/WARNING-4.9-rc4    (call trace for C_S unset)
> 
> Tests on other machines with (slightly) different configs all seem to
> confirm that the problems are gone when CONFIG_SMP is set.

OK, something extremely strange is going on. And I think it is time to get
the big hammer out. I made an extremely stupid debugging patch. Could
you test with it?

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1522597

On 15.11.2016 01:16, Wim Osterholt wrote:
> On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> 
>> It definitely does not crash and is probed and your .config is not
>> extremely unusual.
> 
> Hmmm.
> 
>> ... Something odd is going on.
> 
> Whell, yes.
> The only thing that appears you'll have to do is unset 'CONFIG_SMP'.
> 
> My machines didn't have the luxury of multicore processors (until recently),
> so there never has been any reason to deliberately switch these options on!
> 
> In the process of searching, many options may have changed. The crash/OOPS
> has now mitigated into just a WARNING with a call trace.
> (Or it could be a totally different bug?)
> After the call trace the device is working normally and a shutdown
> completes to the end now.
> That is with the config given here:
> http://webserver.djo.tudelft.nl/.config-4.9-rc4.OK (CONFIG_SMP=y)
> http://webserver.djo.tudelft.nl/WARNING-4.9-rc4    (call trace for C_S unset)
> 
> Tests on other machines with (slightly) different configs all seem to
> confirm that the problems are gone when CONFIG_SMP is set.
> 
> Regards, Wim.
> 
> 

Try retest with mainline 4.9-rc5,
CONFIG_SMP was not crucial[1].

$ grep CONFIG_SMP /boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64*
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64:CONFIG_SMP=y
/boot/config-4.9.0-0.rc5.git0.1.fc26.x86_64+debug:CONFIG_SMP=y

[1] https://www.spinics.net/lists/linux-usb/msg148852.html

[toc] | [prev] | [next] | [standalone]

#1522717

On Tue, Nov 15, 2016 at 12:26:00PM +0100, poma wrote:
> > In the process of searching, many options may have changed. The crash/OOPS
> > has now mitigated into just a WARNING with a call trace.
> > (Or it could be a totally different bug?)
> > 
> > Tests on other machines with (slightly) different configs all seem to
> > confirm that the problems are gone when CONFIG_SMP is set.
> > 
> 
> Try retest with mainline 4.9-rc5,
> CONFIG_SMP was not crucial[1].

I did also test 4.9-rc5 and it behaves like all the rest (since 4.8).
My problem is gone when CONFIG_SMP is set.

That doesn't mean that there are no extra bugs here, dependant on the
presence or absence of other options.

> [1] https://www.spinics.net/lists/linux-usb/msg148852.html

I experience a sliding scale.
With debug it crashes immediately. It may crash later on (even at shutdown
time). It's not even an oops but a warning. In the end it happens to just
work.


Regards, Wim.

[toc] | [prev] | [next] | [standalone]

#1523444

On Tue, 2016-11-15 at 14:29 +0100, Wim Osterholt wrote:

> I experience a sliding scale.
> With debug it crashes immediately. It may crash later on (even at shutdown
> time). It's not even an oops but a warning. In the end it happens to just
> work.

This is very odd. We need to know where it crashes. Please try the
insane debug patch I posted.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1523559

On Wed, Nov 16, 2016 at 01:34:30PM +0100, Oliver Neukum wrote:
> 
> This is very odd. We need to know where it crashes. Please try the
> insane debug patch I posted.

A bit of patience please. Yesterday I hadn't the modem at hand.

Groeten, Wim.

[toc] | [prev] | [next] | [standalone]

#1524014

On Wed, Nov 16, 2016 at 04:07:57PM +0100, Wim Osterholt wrote:
> A bit of patience please. Yesterday I hadn't the modem at hand.

Whell, I lost track of what happens where with which config file..
Confusion about the bug not appearing an too many configs with SMP set
where I'm sure the machine(s) crashed on it.

The intention was to now use just one machine, to avoid confusion.
This is not going to work, due to problems with my video card.
(Crashes when it writes text beyond framebuffer space?)
VGA mode keeps working now.. We'll see..

Okay, a virgin start then.
A new 4.8.8 downloaded. A config from 4.7.9. Make oldconfig.
Accept all defaults for the new options.
CONFIG_SMP was set. Made two kernels, with and without SMP set.
Both kernels behaved the same: an OOPS at cdc_acm loading.
Fortunately the bug is still there.
In this very config the SMP setting does not seem to matter.

Now a retry of 4.9-rc5. I take the config of 4.8.8 and accept
the default for the new options.
SMP set.  No call trace appears.
For completeness I should also try with SMP unset. That is for tomorrow
then.

BTW, your latest patch was not yet applied here. At work where I had no oops
today, it gave an output count from 0 to 41, looping (30-39) through 16
buffers.  More tomorrow. Need urgent sleep now.

Regards, Wim.

[toc] | [prev] | [next] | [standalone]

#1524174

On Thu, Nov 17, 2016 at 02:57:33AM +0100, Wim Osterholt wrote:
> Now a retry of 4.9-rc5. I take the config of 4.8.8 and accept
> the default for the new options.
> SMP set.  No call trace appears.
> For completeness I should also try with SMP unset. That is for tomorrow
> then.

With CONFIG_SMP unset nothing goes wrong here either.
It looks like it has been fixed in 4.9-rc5, but I should also double check
several conbinations on my (slower) laptop.

Regards, Wim.

[toc] | [prev] | [next] | [standalone]

#1524532

On Thu, Nov 17, 2016 at 10:14:34AM +0100, Wim Osterholt wrote:
> > For completeness I should also try with SMP unset. That is for tomorrow
> > then.
> 
> With CONFIG_SMP unset nothing goes wrong here either.
> It looks like it has been fixed in 4.9-rc5, but I should also double check
> several conbinations on my (slower) laptop.

Nov 17 15:07:49 localhost kernel: usb 4-1: new full-speed USB device number 2 using uhci_hcd
Nov 17 15:07:49 localhost kernel: usb 4-1: New USB device found, idVendor=0572, idProduct=1340
Nov 17 15:07:49 localhost kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 17 15:07:49 localhost kernel: usb 4-1: Product: USB Modem
Nov 17 15:07:49 localhost kernel: usb 4-1: Manufacturer: Conexant
Nov 17 15:07:49 localhost kernel: usb 4-1: SerialNumber: 12345678
Nov 17 15:07:50 localhost mtp-probe[12956]: checking bus 4, device 2: "/sys/devices/pci0000:00/0000:00:1d.2/usb4/4-1"
Nov 17 15:07:50 localhost mtp-probe[12956]: bus: 4, device: 2 was not an MTP device
Nov 17 15:07:51 localhost kernel: Check point  1
Nov 17 15:07:51 localhost kernel: Check point  2
Nov 17 15:07:51 localhost kernel: Check point  3
Nov 17 15:07:51 localhost kernel: Check point  4
Nov 17 15:07:51 localhost kernel: Check point  5
Nov 17 15:07:51 localhost kernel: Check point  6
Nov 17 15:07:51 localhost kernel: Check point  7
Nov 17 15:07:51 localhost kernel: Check point  8
Nov 17 15:07:51 localhost kernel: Check point  9
Nov 17 15:07:51 localhost kernel: Check point  10
Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 00000249
Nov 17 15:07:51 localhost kernel: IP: [<e186ece2>] acm_probe+0x559/0xe53 [cdc_acm]
Nov 17 15:07:51 localhost kernel: *pde = 00000000 
Nov 17 15:07:51 localhost kernel: Oops: 0000 [#1] SMP
...


You can get a few logs concatenated at
http://webserver.djo.tudelft.nl/insane488.logs

Usually the oops follows immediately after inserting the modem, but in one case
it took a few seconds extra before the oops. I think that is the one that
printed the full range of checkpoints.

On another 3 machines running 4.9-rc5 here  everything went fine on insertion.
Switching back to 4.8.8 produced the bug with outputs similar to the above.

Now back to the laptops to see if I can get confirmation of having seen the
oops at 4.9-rc5 in some way. I'm not sure now. 


Regards, Wim.

[toc] | [prev] | [next] | [standalone]

#1526674

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:

> Nov 17 15:07:51 localhost kernel: Check point  10
> Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 00000249
> Nov 17 15:07:51 localhost kernel: IP: [<e186ece2>] acm_probe+0x559/0xe53 [cdc_acm]
> Nov 17 15:07:51 localhost kernel: *pde = 00000000 
> Nov 17 15:07:51 localhost kernel: Oops: 0000 [#1] SMP

I don't understand it, bit please test the attached patch
with dynamic debugging for cdc-acm and the kernel log level
at maximum. And please repost "lsusb -v" for your device.

	Regards
		Oliver

[toc] | [prev] | [next] | [standalone]

#1526840

On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
> On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:
> 
> > Nov 17 15:07:51 localhost kernel: Check point  10
> > Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 00000249
> > Nov 17 15:07:51 localhost kernel: IP: [<e186ece2>] acm_probe+0x559/0xe53 [cdc_acm]
> > Nov 17 15:07:51 localhost kernel: *pde = 00000000 
> > Nov 17 15:07:51 localhost kernel: Oops: 0000 [#1] SMP
> 
> I don't understand it, bit please test the attached patch
> with dynamic debugging for cdc-acm and the kernel log level
> at maximum. And please repost "lsusb -v" for your device.

I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.

I assume you want this on a crashing kernel, but I already removed the
sources. (Lack of space).
4.8.10 is now compiling, that was the fastest option. If that one doesn't
crash anymore I'll dig up 4.8.8 again.

lsusb -v:

Bus 004 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0572 Conexant Systems (Rockwell), Inc.
  idProduct          0x1340 
  bcdDevice            1.00
  iManufacturer           1 Conexant
  iProduct                2 USB Modem
  iSerial                 3 12345678
  bNumConfigurations      2
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           73
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             128
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x07
          sends break
          line coding and serial state
          get/set/clear comm features
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Country Selection:
        iCountryCodeRelDate        4 04052004
        wCountryCode          0x4803
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           96
    bNumInterfaces          3
    bConfigurationValue     2
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval             128
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x07
          sends break
          line coding and serial state
          get/set/clear comm features
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Country Selection:
        iCountryCodeRelDate        4 04052004
        wCountryCode          0x4803
Device Status:     0x0000
  (Bus Powered)

[toc] | [prev] | [next] | [standalone]

#1527028

On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
> 
> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.

Neither 4.8.10, nor 4.8.9 show the bug.
It must be a bug ouside cdc_acm that they have fixed. (a late propagation of
the IRQ-penalty-bug-fix maybe?)

I'm rebuilding 4.8.8 now.

Groeten, Wim.

[toc] | [prev] | [next] | [standalone]

#1527133

On 21.11.2016 21:23, Wim Osterholt wrote:
> On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote:
>>
>> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
>> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
> 
> Neither 4.8.10, nor 4.8.9 show the bug.
> It must be a bug ouside cdc_acm that they have fixed. (a late propagation of
> the IRQ-penalty-bug-fix maybe?)
> 
> I'm rebuilding 4.8.8 now.
> 
> Groeten, Wim.
> 


After all the patching and testing I concluded the same, 
breakage came and is gone outside drivers/usb/class/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/diff/?id=v4.9-rc5&id2=v4.9-rc4

[toc] | [prev] | [next] | [standalone]

#1527793

Wim Osterholt <wim@djo.tudelft.nl> writes:

> On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
>> On Thu, 2016-11-17 at 17:11 +0100, Wim Osterholt wrote:
>> 
>> > Nov 17 15:07:51 localhost kernel: Check point  10
>> > Nov 17 15:07:51 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at 00000249
>> > Nov 17 15:07:51 localhost kernel: IP: [<e186ece2>] acm_probe+0x559/0xe53 [cdc_acm]
>> > Nov 17 15:07:51 localhost kernel: *pde = 00000000 
>> > Nov 17 15:07:51 localhost kernel: Oops: 0000 [#1] SMP
>> 
>> I don't understand it, bit please test the attached patch
>> with dynamic debugging for cdc-acm and the kernel log level
>> at maximum. And please repost "lsusb -v" for your device.
>
> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I
> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now.
>
> I assume you want this on a crashing kernel, but I already removed the
> sources. (Lack of space).
> 4.8.10 is now compiling, that was the fastest option. If that one doesn't
> crash anymore I'll dig up 4.8.8 again.
>
> lsusb -v:
>
> Bus 004 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. 
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               1.10
>   bDeviceClass            2 Communications
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0        64
>   idVendor           0x0572 Conexant Systems (Rockwell), Inc.
>   idProduct          0x1340 
>   bcdDevice            1.00
>   iManufacturer           1 Conexant
>   iProduct                2 USB Modem
>   iSerial                 3 12345678
>   bNumConfigurations      2
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           73
>     bNumInterfaces          2
>     bConfigurationValue     1
>     iConfiguration          0 
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         2 Communications
>       bInterfaceSubClass      2 Abstract (modem)
>       bInterfaceProtocol      1 AT-commands (v.25ter)
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval             128
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass        10 CDC Data
>       bInterfaceSubClass      0 Unused
>       bInterfaceProtocol      0 
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               1
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               1
>       CDC Header:
>         bcdCDC               1.10
>       CDC Call Management:
>         bmCapabilities       0x03
>           call management
>           use DataInterface
>         bDataInterface          1
>       CDC ACM:
>         bmCapabilities       0x07
>           sends break
>           line coding and serial state
>           get/set/clear comm features
>       CDC Union:
>         bMasterInterface        0
>         bSlaveInterface         1 
>       Country Selection:
>         iCountryCodeRelDate        4 04052004
>         wCountryCode          0x4803
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           96
>     bNumInterfaces          3
>     bConfigurationValue     2
>     iConfiguration          0 
>     bmAttributes         0x80
>       (Bus Powered)
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         2 Communications
>       bInterfaceSubClass      2 Abstract (modem)
>       bInterfaceProtocol      1 AT-commands (v.25ter)
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval             128
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass        10 CDC Data
>       bInterfaceSubClass      0 Unused
>       bInterfaceProtocol      0 
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval              10
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval              10
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        2
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass        10 CDC Data
>       bInterfaceSubClass      0 Unused
>       bInterfaceProtocol      0 
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               1
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x03  EP 3 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               1
>       CDC Header:
>         bcdCDC               1.10
>       CDC Call Management:
>         bmCapabilities       0x03
>           call management
>           use DataInterface
>         bDataInterface          1
>       CDC ACM:
>         bmCapabilities       0x07
>           sends break
>           line coding and serial state
>           get/set/clear comm features
>       CDC Union:
>         bMasterInterface        0
>         bSlaveInterface         1 
>       Country Selection:
>         iCountryCodeRelDate        4 04052004
>         wCountryCode          0x4803

No excuse for crashing of course, but that's one of the sickets
descriptor sets I've seen today. Who got the bright idea to put the
communication class functional descriptors on the data class interfaces?
And what's with the second data interface?  How is the host supposed to
make any use of that when both(!) the CDC Union descriptors refer to
interface 0 and 1 only?  Not that we can use those union descriptors for
much anyway since we have to guess the relationship between control and
data interface before we can get to it...

So I'm not surprised that this is unexpected by the driver.  We just
need to figure out how to ignore the noise and carry on.

But looking at the driver, it looks like that is exactly what it should
do.  This device has the  NO_UNION_NORMAL quirk so normal probing is
skipped and we will just use interfaces 0 and 1.  Which is the only sane
thing to do given the above mess...

Don't understand how it could crash.



Bjørn

[toc] | [prev] | [next] | [standalone]

#1528049

On Tue, Nov 22, 2016 at 06:50:28PM +0100, Bjørn Mork wrote:
> >         iCountryCodeRelDate        4 04052004
> >         wCountryCode          0x4803
> 
> No excuse for crashing of course, but that's one of the sickets
> descriptor sets I've seen today. Who got the bright idea to put the
> communication class functional descriptors on the data class interfaces?

Whell, the chinese of coarse. It's all chinese to me. But maybe they made 
this time an exact copy of their example from Conexant. Not that they are
that careful usually.

>...
> Don't understand how it could crash.

The oops does normally not immediately lead to a crash. Only with debugging
on it will halt immediately and the log will tell you that a reboot will
be necessairy. 

Wim.

[toc] | [prev] | [next] | [standalone]

#1527603

On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:

> I don't understand it, bit please test the attached patch
> with dynamic debugging for cdc-acm and the kernel log level
> at maximum.

> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 6895f9e..f03b5db 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -1188,6 +1188,12 @@ static int acm_probe(struct usb_interface *intf,
>  
>  	cdc_parse_cdc_header(&h, intf, buffer, buflen);
>  	union_header = h.usb_cdc_union_desc;
> +
> +	dev_dbg(&intf->dev, "Parsed device header\n");
> +	dev_dbg(&intf->dev, "Union descriptor %p\n", h.usb_cdc_union_desc);
> +	dev_dbg(&intf->dev, "ACM descriptor %p\n", h.usb_cdc_acm_descriptor);
> +	dev_dbg(&intf->dev, "Country descriptor %p\n", h.usb_cdc_country_functional_desc);
> +
>  	cmgmd = h.usb_cdc_call_mgmt_descriptor;
>  	if (cmgmd)
>  		call_intf_num = cmgmd->bDataInterface;


On kernel 4.8.8  this crashes hard and produces over a serial link:

[  156.842106] sysrq: SysRq : Changing Loglevel
[  156.842110] sysrq: Loglevel set to 9
[  156.947852] usbcore: registered new interface driver cdc_acm
[  156.947854] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[  161.176701] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[  161.383608] usb 4-1: New USB device found, idVendor=0572, idProduct=1340
[  161.384707] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  161.388722] usb 4-1: Product: USB Modem
[  161.392711] usb 4-1: Manufacturer: Conexant
[  161.392714] usb 4-1: SerialNumber: 12345678
[  161.397703] cdc_acm:acm_probe: cdc_acm 4-1:1.0: interfaces are valid
[  161.397731] BUG: unable to handle kernel NULL pointer dereference at 00000249
[  161.397740] IP: [<e086ad09>] acm_probe+0x580/0xd1e [cdc_acm]
[  161.397742] *pde = 00000000 
[  161.397745] Oops: 0000 [#1] SMP
[  161.397786] Modules linked in: cdc_acm radeon drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit fbcon bitblit softcursor font tileblit binfmt_misc snd_pcm_oss snd_mixer_oss usb_storage usbhid ipw2200 libipw lib80211 snd_intel8x0 cfg80211 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_pci snd_timer snd ehci_hcd rfkill usbcore soundcore via_rhine firmware_class ppdev pcspkr parport_pc mii lpc_ich parport fan usb_common acpi_cpufreq thermal mfd_core floppy button processor
[  161.397790] CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.8.8 #2
[  161.397792] Hardware name: MEDIONPC MS-7048/MS-7048, BIOS 6.00 PG 02/12/2004
[  161.397805] Workqueue: usb_hub_wq hub_event [usbcore]
[  161.397807] task: df4c9500 task.stack: df4da000
[  161.397810] EIP: 0060:[<e086ad09>] EFLAGS: 00010202 CPU: 0
[  161.397813] EIP is at acm_probe+0x580/0xd1e [cdc_acm]
[  161.397815] EAX: 00000246 EBX: dc27b000 ECX: e086c934 EDX: 00000000
[  161.397817] ESI: 00000100 EDI: 00000000 EBP: df4dbc18 ESP: df4dbb80
[  161.397819]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  161.397821] CR0: 80050033 CR2: 00000249 CR3: 1c45f000 CR4: 00000690
[  161.397822] Stack:
[  161.397828]  00003640 00003662 0000000e df491d50 00000000 00000000 00000010 00000040
[  161.397835]  00000080 00000246 dd1fc540 decf5a00 dc468c70 00000001 df583a00 df583a38
[  161.397841]  dc468c00 decf5800 decf5a00 00000000 dc452ab0 00000004 00000246 df4dbc00
[  161.397842] Call Trace:
[  161.397853]  [<c04bce4d>] ? __mutex_unlock_slowpath+0xf4/0xfc
[  161.397862]  [<e1e2e50d>] ? usb_probe_interface+0x17b/0x1f6 [usbcore]
[  161.397870]  [<e1e2e50d>] ? usb_probe_interface+0x17b/0x1f6 [usbcore]
[  161.397877]  [<c0366fe8>] ? driver_probe_device+0x17b/0x30e
[  161.397880]  [<c0366fe8>] ? driver_probe_device+0x17b/0x30e
[  161.397883]  [<c03656e2>] ? bus_for_each_drv+0x59/0x68
[  161.397886]  [<c03656e2>] ? bus_for_each_drv+0x59/0x68
[  161.397890]  [<c0366d96>] ? __device_attach+0x91/0x105
[  161.397893]  [<c036727c>] ? driver_allows_async_probing+0x2f/0x2f
[  161.397896]  [<c036636a>] ? bus_probe_device+0x27/0x6b
[  161.397899]  [<c036636a>] ? bus_probe_device+0x27/0x6b
[  161.397902]  [<c0364af0>] ? device_add+0x289/0x4be
[  161.397911]  [<e1e2ce72>] ? usb_set_configuration+0x5a6/0x5e9 [usbcore]
[  161.397919]  [<e1e2ce72>] ? usb_set_configuration+0x5a6/0x5e9 [usbcore]
[  161.397928]  [<e1e34664>] ? generic_probe+0x3b/0x67 [usbcore]
[  161.397937]  [<e1e34664>] ? generic_probe+0x3b/0x67 [usbcore]
[  161.397945]  [<e1e2e379>] ? usb_probe_device+0x49/0x62 [usbcore]
[  161.397953]  [<e1e2e330>] ? usb_suspend+0xcd/0xcd [usbcore]
[  161.397957]  [<c0366fe8>] ? driver_probe_device+0x17b/0x30e
[  161.397960]  [<c0366fe8>] ? driver_probe_device+0x17b/0x30e
[  161.397963]  [<c03656e2>] ? bus_for_each_drv+0x59/0x68
[  161.397966]  [<c03656e2>] ? bus_for_each_drv+0x59/0x68
[  161.397969]  [<c0366d96>] ? __device_attach+0x91/0x105
[  161.397972]  [<c036727c>] ? driver_allows_async_probing+0x2f/0x2f
[  161.397976]  [<c036636a>] ? bus_probe_device+0x27/0x6b
[  161.397979]  [<c036636a>] ? bus_probe_device+0x27/0x6b
[  161.397982]  [<c0364af0>] ? device_add+0x289/0x4be
[  161.397985]  [<c035f7e9>] ? add_device_randomness+0x84/0x9c
[  161.397993]  [<e1e2521a>] ? usb_new_device+0x29d/0x3b5 [usbcore]
[  161.398001]  [<e1e2521a>] ? usb_new_device+0x29d/0x3b5 [usbcore]
[  161.398010]  [<e1e26949>] ? hub_event+0xb32/0xed8 [usbcore]
[  161.398017]  [<e1e26949>] ? hub_event+0xb32/0xed8 [usbcore]
[  161.398026]  [<e1e25d06>] ? usb_remote_wakeup+0x6f/0x7d [usbcore]
[  161.398031]  [<c01484b7>] ? process_one_work+0x174/0x2bc
[  161.398034]  [<c01484b7>] ? process_one_work+0x174/0x2bc
[  161.398037]  [<c0148a93>] ? worker_thread+0x22c/0x2f6
[  161.398040]  [<c0148867>] ? rescuer_thread+0x23f/0x23f
[  161.398043]  [<c014be62>] ? kthread+0xa4/0xa9
[  161.398046]  [<c04be662>] ? ret_from_kernel_thread+0xe/0x24
[  161.398049]  [<c014bdbe>] ? kthread_create_on_node+0x101/0x101
[  161.398085] Code: 14 89 83 b4 04 00 00 8b 45 94 89 43 04 8b 45 ac 89 43 08 8b 85 7c ff ff ff 89 83 c0 04 00 00 8b 45 a8 89 03 8b 45 c0 85 c0 74 0a <0f> b6 40 03 89 83 c8 04 00 00 f6 45 9c 04 74 07 83 a3 c8 04 00
[  161.398091] EIP: [<e086ad09>] acm_probe+0x580/0xd1e [cdc_acm] SS:ESP 0068:df4dbb80
[  161.398092] CR2: 0000000000000249
[  161.398096] ---[ end trace da016e6d3520a331 ]---
[  161.398152] BUG: unable to handle kernel paging request at ffffffec
[  161.398156] IP: [<c014c304>] kthread_data+0xf/0x13
[  161.398159] *pde = 00735067 *pte = 00000000 
[  161.398161] Oops: 0000 [#2] SMP
[  161.398197] Modules linked in: cdc_acm radeon drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit fbcon bitblit softcursor font tileblit binfmt_misc snd_pcm_oss snd_mixer_oss usb_storage usbhid ipw2200 libipw lib80211 snd_intel8x0 cfg80211 snd_ac97_codec ac97_bus uhci_hcd snd_pcm ehci_pci snd_timer snd ehci_hcd rfkill usbcore soundcore via_rhine firmware_class ppdev pcspkr parport_pc mii lpc_ich parport fan usb_common acpi_cpufreq thermal mfd_core floppy button processor
[  161.398200] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G      D         4.8.8 #2
[  161.398202] Hardware name: MEDIONPC MS-7048/MS-7048, BIOS 6.00 PG 02/12/2004
[  161.398217] task: df4c9500 task.stack: df4da000
[  161.398219] EIP: 0060:[<c014c304>] EFLAGS: 00010002 CPU: 0
[  161.398221] EIP is at kthread_data+0xf/0x13
[  161.398223] EAX: 00000000 EBX: df4dc000 ECX: dec92374 EDX: df4c9500
[  161.398225] ESI: df4c97b4 EDI: dfbd0960 EBP: df4dbf48 ESP: df4dbf44
[  161.398227]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  161.398229] CR0: 80050033 CR2: 00000014 CR3: 1c45f000 CR4: 00000690
[  161.398231] Stack:
[  161.398237]  c0148bbb df4dbf6c c04bb2a4 df401d80 c01e2b00 df4c9500 00000001 df4dc000
[  161.398244]  df4dbd50 df4dbf98 df4dbf78 c04bb669 df4c9500 df4dbfac c0139827 df4c9888
[  161.398250]  01000000 df4c972c df4c8000 00000001 00000000 df4dbf98 df4dbf98 00000009
[  161.398251] Call Trace:
[  161.398254]  [<c0148bbb>] ? wq_worker_sleeping+0xd/0x75
[  161.398259]  [<c04bb2a4>] ? __schedule+0xcc/0x424
[  161.398263]  [<c01e2b00>] ? __slab_free+0x266/0x270
[  161.398266]  [<c04bb669>] ? schedule+0x6d/0x7a
[  161.398270]  [<c0139827>] ? do_exit+0x74d/0x775
[  161.398274]  [<c04bf679>] ? rewind_stack_do_exit+0x11/0x13
[  161.398277]  [<c014bdbe>] ? kthread_create_on_node+0x101/0x101
[  161.398312] Code: 8d 44 90 4c c0 8d 0c 95 00 00 00 00 29 cb b9 02 00 00 00 89 da 5b 5d e9 f5 fd ff ff 55 89 e5 3e 8d 74 26 00 8b 80 84 02 00 00 5d <8b> 40 ec c3 55 89 e5 52 3e 8d 74 26 00 b9 04 00 00 00 8b 90 84
[  161.398316] EIP: [<c014c304>] kthread_data+0xf/0x13 SS:ESP 0068:df4dbf44
[  161.398318] CR2: 00000000ffffffec
[  161.398320] ---[ end trace da016e6d3520a332 ]---
[  161.398321] Fixing recursive fault but reboot is needed!


Regards, Wim.

[toc] | [prev] | [next] | [standalone]

#1527802

Wim Osterholt <wim@djo.tudelft.nl> writes:

> On Mon, Nov 21, 2016 at 02:19:32PM +0100, Oliver Neukum wrote:
>
>> I don't understand it, bit please test the attached patch
>> with dynamic debugging for cdc-acm and the kernel log level
>> at maximum.
>
>> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
>> index 6895f9e..f03b5db 100644
>> --- a/drivers/usb/class/cdc-acm.c
>> +++ b/drivers/usb/class/cdc-acm.c
>> @@ -1188,6 +1188,12 @@ static int acm_probe(struct usb_interface *intf,
>>  
>>  	cdc_parse_cdc_header(&h, intf, buffer, buflen);
>>  	union_header = h.usb_cdc_union_desc;
>> +
>> +	dev_dbg(&intf->dev, "Parsed device header\n");
>> +	dev_dbg(&intf->dev, "Union descriptor %p\n", h.usb_cdc_union_desc);
>> +	dev_dbg(&intf->dev, "ACM descriptor %p\n", h.usb_cdc_acm_descriptor);
>> +	dev_dbg(&intf->dev, "Country descriptor %p\n", h.usb_cdc_country_functional_desc);
>> +
>>  	cmgmd = h.usb_cdc_call_mgmt_descriptor;
>>  	if (cmgmd)
>>  		call_intf_num = cmgmd->bDataInterface;
>
>
> On kernel 4.8.8  this crashes hard and produces over a serial link:

Huh?  That device shouldn't ever enter that code path AFAICS.
Unless.... you wouldn't happen to add a dynamic entry for this device,
would you?  What's the output of

 cat /sys/bus/usb/drivers/cdc_acm/new_id

?

We should probably survive it, but I think the current acm_probe() is
going to barf hard on the last data interface, if probed without the
default NO_UNION_NORMAL quirk.  cdc_parse_cdc_header() will happily
parse all the functional descriptors, including the union pointing to
interfaces 0 and 1.  I might be missing it, but I cannot see any sanity
check verifying that the currently probed interface is actually part of
the set of interfaces pointed to by the union.  There is a sanity check
for the availability of the data interface, but there is none for the
control interface (the assumption of course that that's the interface
we're probing).

I think we need a bit more sanity checking of the union.  This is likely
a generic problem for any CDC driver, so it is worth considering adding
a shared function for that.

And all this fails to explain anything if you didn't add the device
dynamically, of course...



Bjørn

[toc] | [prev] | [next] | [standalone]

#1528051

On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote:
> > On kernel 4.8.8  this crashes hard and produces over a serial link:
> 
> Huh?  That device shouldn't ever enter that code path AFAICS.
> Unless.... you wouldn't happen to add a dynamic entry for this device,

No idea of what you mean here.

> would you?  What's the output of
> 
>  cat /sys/bus/usb/drivers/cdc_acm/new_id

Just empty.

Wim.

[toc] | [prev] | [next] | [standalone]

#1528168

On November 23, 2016 1:54:57 AM CET, Wim Osterholt <wim@djo.tudelft.nl> wrote:
>On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote:
>> > On kernel 4.8.8  this crashes hard and produces over a serial link:
>> 
>> Huh?  That device shouldn't ever enter that code path AFAICS.
>> Unless.... you wouldn't happen to add a dynamic entry for this
>device,
>
>No idea of what you mean here.
>
>> would you?  What's the output of
>> 
>>  cat /sys/bus/usb/drivers/cdc_acm/new_id
>
>Just empty.

Shit. Back to not understanding how you could possibly enter the debugging code at all.

Bjørn

[toc] | [prev] | [next] | [standalone]

#1528487

On Wed, 23 Nov 2016, [ISO-8859-1] Bj�rn Mork wrote:

> On November 23, 2016 1:54:57 AM CET, Wim Osterholt <wim@djo.tudelft.nl> wrote:
> >On Tue, Nov 22, 2016 at 07:08:30PM +0100, Bjørn Mork wrote:
> >> > On kernel 4.8.8  this crashes hard and produces over a serial link:
> >> 
> >> Huh?  That device shouldn't ever enter that code path AFAICS.
> >> Unless.... you wouldn't happen to add a dynamic entry for this
> >device,
> >
> >No idea of what you mean here.
> >
> >> would you?  What's the output of
> >> 
> >>  cat /sys/bus/usb/drivers/cdc_acm/new_id
> >
> >Just empty.
> 
> Shit. Back to not understanding how you could possibly enter the debugging code at all.

You're in the lucky position of having an engaged and responsive bug
reporter who is willing to apply patches and run tests.  Just write a
simple diagnostic patch that will reveal exactly what pathway is being
followed.

Alan Stern

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web