Wim Osterholt <wim@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
