lirc bug in kernel 4.10-rc3

[Wim Osterholt]

On Sat, Jan 07, 2017 at 05:11:38PM +0100, Wim Osterholt wrote:
> On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
> 
> L.S.,
> > 
> > after appearance of kernel-4.10-rc1 two days ago...
> 
> A quickly following release of 4.10-rc2 made sure that lirc_dev was loaded
> together with serial_ir. However, things still don't work.

Again no answer and another kernel release, but no fixes.


I just need to only send some codes.
I'm using (gentoo) lirc-0.9.0-rc6, which works fine up to kernel-4.9.2 .

In kernel-4.10-rc1/2/3 there are two bugs.

 1) With the same setup - only the kernel has changed from 4.9 to 4.10 -
irsend does not work anymore. I get these logs:
 
> Jan  7 01:55:23 localhost kernel: serial_ir: unknown parameter 'debug' ignored
> Jan  7 01:55:24 localhost kernel: serial_ir serial_ir.0: auto-detected active 
> high receiver
> Jan  7 01:55:24 localhost kernel: rc_core: IR keymap rc-rc6-mce not found
> Jan  7 01:55:24 localhost kernel: Registered IR keymap rc-empty
> Jan  7 01:55:24 localhost kernel: input: Serial IR type home-brew as 
> /devices/platform/serial_ir.0/rc/rc0/input10
> Jan  7 01:55:24 localhost kernel: rc rc0: Serial IR type home-brew as 
> /devices/platform/serial_ir.0/rc/rc0
> Jan  7 01:55:24 localhost kernel: input: MCE IR Keyboard/Mouse (serial_ir) as 
> /devices/virtual/input/input11
> Jan  7 01:55:24 localhost kernel: lirc_dev: IR Remote Control driver 
> registered, major 249
> Jan  7 01:55:24 localhost kernel: rc rc0: lirc_dev: driver ir-lirc-codec 
> (serial_ir) registered at minor = 0
> Jan  7 01:55:24 localhost kernel: IR LIRC bridge handler initialized
> Jan  7 01:55:56 localhost lircd-0.9.0[2171]: lircd(default) ready, using 
> /dev/lircd1
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: accepted new client on 
> /dev/lircd1
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: write failed
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: Invalid argument
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: error processing command: 
> SEND_ONCE bat KEY_1
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: transmission failed
> Jan  7 01:56:53 localhost lircd-0.9.0[2171]: removed client
 
 2) lirc-0.9.0 compiled with '--with-transmitter' delivers no transmitter in 
lirc_serial.ko



Regards, Wim.

lirc bug in kernel 4.10-rc3

[Wim Osterholt]

On Sat, Jan 07, 2017 at 05:11:38PM +0100, Wim Osterholt wrote:
> On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:
> 
> L.S.,
> > 
> > after appearance of kernel-4.10-rc1 two days ago...
> 
> A quickly following release of 4.10-rc2 made sure that lirc_dev was loaded
> together with serial_ir. However, things still don't work.

Again no answer and another kernel release, but no fixes.


I just need to only send some codes.
I'm using (gentoo) lirc-0.9.0-rc6, which works fine up to kernel-4.9.2 .

In kernel-4.10-rc1/2/3 there are two bugs.

 1) With the same setup - only the kernel has changed from 4.9 to 4.10 -
irsend does not work anymore. I get these logs:
 
> Jan  7 01:55:23 localhost kernel: serial_ir: unknown parameter 'debug' ignored
> Jan  7 01:55:24 localhost kernel: serial_ir serial_ir.0: auto-detected active 
> high receiver
> Jan  7 01:55:24 localhost kernel: rc_core: IR keymap rc-rc6-mce not found
> Jan  7 01:55:24 localhost kernel: Registered IR keymap rc-empty
> Jan  7 01:55:24 localhost kernel: input: Serial IR type home-brew as 
> /devices/platform/serial_ir.0/rc/rc0/input10
> Jan  7 01:55:24 localhost kernel: rc rc0: Serial IR type home-brew as 
> /devices/platform/serial_ir.0/rc/rc0
> Jan  7 01:55:24 localhost kernel: input: MCE IR Keyboard/Mouse (serial_ir) as 
> /devices/virtual/input/input11
> Jan  7 01:55:24 localhost kernel: lirc_dev: IR Remote Control driver 
> registered, major 249
> Jan  7 01:55:24 localhost kernel: rc rc0: lirc_dev: driver ir-lirc-codec 
> (serial_ir) registered at minor = 0
> Jan  7 01:55:24 localhost kernel: IR LIRC bridge handler initialized
> Jan  7 01:55:56 localhost lircd-0.9.0[2171]: lircd(default) ready, using 
> /dev/lircd1
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: accepted new client on 
> /dev/lircd1
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: write failed
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: Invalid argument
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: error processing command: 
> SEND_ONCE bat KEY_1
> Jan  7 01:56:52 localhost lircd-0.9.0[2171]: transmission failed
> Jan  7 01:56:53 localhost lircd-0.9.0[2171]: removed client
 
 2) lirc-0.9.0 compiled with '--with-transmitter' delivers no transmitter in 
lirc_serial.ko



Regards, Wim.

Re: lirc bug in kernel 4.10-rc2

[Wim Osterholt]

On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:

L.S.,
> 
> after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
> to find a question about lirc_serial in 'make oldconfig':
> 
> Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
>   Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y

A quickly following release of 4.10-rc2 made sure that lirc_dev was loaded
together with serial_ir. However, things still don't work.

I just need to send some codes.
I'm using lirc-0.9.0, which worked fine up to kernel-4.9.1 .

With kernel-4.10-rc1/2 there are two bugs.

1) With the same setup - only the kernel has changed from 4.9 to 4.10 -
   irsend does not work anymore. I get these logs:

Jan  7 01:55:23 localhost kernel: serial_ir: unknown parameter 'debug' ignored
Jan  7 01:55:24 localhost kernel: serial_ir serial_ir.0: auto-detected active 
high receiver
Jan  7 01:55:24 localhost kernel: rc_core: IR keymap rc-rc6-mce not found
Jan  7 01:55:24 localhost kernel: Registered IR keymap rc-empty
Jan  7 01:55:24 localhost kernel: input: Serial IR type home-brew as 
/devices/platform/serial_ir.0/rc/rc0/input10
Jan  7 01:55:24 localhost kernel: rc rc0: Serial IR type home-brew as 
/devices/platform/serial_ir.0/rc/rc0
Jan  7 01:55:24 localhost kernel: input: MCE IR Keyboard/Mouse (serial_ir) as 
/devices/virtual/input/input11
Jan  7 01:55:24 localhost kernel: lirc_dev: IR Remote Control driver 
registered, major 249
Jan  7 01:55:24 localhost kernel: rc rc0: lirc_dev: driver ir-lirc-codec 
(serial_ir) registered at minor = 0
Jan  7 01:55:24 localhost kernel: IR LIRC bridge handler initialized
Jan  7 01:55:56 localhost lircd-0.9.0[2171]: lircd(default) ready, using 
/dev/lircd1
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: accepted new client on /dev/lircd1
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: write failed
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: Invalid argument
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: error processing command: 
SEND_ONCE bat KEY_1
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: transmission failed
Jan  7 01:56:53 localhost lircd-0.9.0[2171]: removed client

   Where under kernel 4.9 things go well like:

Jan  7 02:25:08 localhost kernel: lirc_dev: IR Remote Control driver 
registered, major 250
Jan  7 02:25:08 localhost kernel: lirc_serial: module is from the staging 
directory, the quality is unknown, you have been warned.
Jan  7 02:25:08 localhost kernel: lirc_serial: unknown parameter 'debug' ignored
Jan  7 02:25:09 localhost kernel: lirc_serial lirc_serial.0: auto-detected 
active high receiver
Jan  7 02:25:09 localhost kernel: lirc_serial lirc_serial.0: lirc_dev: driver 
lirc_serial registered at minor = 0
Jan  7 02:25:19 localhost lircd-0.9.0[1970]: lircd(default) ready, using 
/dev/lircd1
Jan  7 02:25:33 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:33 localhost lircd-0.9.0[1970]: removed client
Jan  7 02:25:33 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: removed client
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: removed client
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: removed client


2) lirc-0.9.0 gives me the charming choice of using the lirc-made modules
   (lirc_serial, lirc_dev) or the kernel-made modules (lirc_serial,lirc_dev).
   Now kernel-4.10 ruined things, I should at least have the option of using
   the lirc-made modules instead of serial_ir and lirc_dev.
   However, the modules that lirc makes when using kernel-4.10 do not offer
   the possibily of transmission. (It has no variable txsense anywhere in it.)
   Although compiling says '--with-transmitter', there is something in the
   kernel source that prevents lirc from building that in. That is not
   derived from the .config file it finds in the source. I don't know what
   else it is looking for and doesn't find anymore.


Regards, Wim.

Re: lirc bug in kernel 4.10-rc2

[Wim Osterholt]

On Thu, Dec 29, 2016 at 05:53:58PM +0100, Wim Osterholt wrote:

L.S.,
> 
> after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
> to find a question about lirc_serial in 'make oldconfig':
> 
> Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
>   Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y

A quickly following release of 4.10-rc2 made sure that lirc_dev was loaded
together with serial_ir. However, things still don't work.

I just need to send some codes.
I'm using lirc-0.9.0, which worked fine up to kernel-4.9.1 .

With kernel-4.10-rc1/2 there are two bugs.

1) With the same setup - only the kernel has changed from 4.9 to 4.10 -
   irsend does not work anymore. I get these logs:

Jan  7 01:55:23 localhost kernel: serial_ir: unknown parameter 'debug' ignored
Jan  7 01:55:24 localhost kernel: serial_ir serial_ir.0: auto-detected active 
high receiver
Jan  7 01:55:24 localhost kernel: rc_core: IR keymap rc-rc6-mce not found
Jan  7 01:55:24 localhost kernel: Registered IR keymap rc-empty
Jan  7 01:55:24 localhost kernel: input: Serial IR type home-brew as 
/devices/platform/serial_ir.0/rc/rc0/input10
Jan  7 01:55:24 localhost kernel: rc rc0: Serial IR type home-brew as 
/devices/platform/serial_ir.0/rc/rc0
Jan  7 01:55:24 localhost kernel: input: MCE IR Keyboard/Mouse (serial_ir) as 
/devices/virtual/input/input11
Jan  7 01:55:24 localhost kernel: lirc_dev: IR Remote Control driver 
registered, major 249
Jan  7 01:55:24 localhost kernel: rc rc0: lirc_dev: driver ir-lirc-codec 
(serial_ir) registered at minor = 0
Jan  7 01:55:24 localhost kernel: IR LIRC bridge handler initialized
Jan  7 01:55:56 localhost lircd-0.9.0[2171]: lircd(default) ready, using 
/dev/lircd1
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: accepted new client on /dev/lircd1
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: write failed
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: Invalid argument
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: error processing command: 
SEND_ONCE bat KEY_1
Jan  7 01:56:52 localhost lircd-0.9.0[2171]: transmission failed
Jan  7 01:56:53 localhost lircd-0.9.0[2171]: removed client

   Where under kernel 4.9 things go well like:

Jan  7 02:25:08 localhost kernel: lirc_dev: IR Remote Control driver 
registered, major 250
Jan  7 02:25:08 localhost kernel: lirc_serial: module is from the staging 
directory, the quality is unknown, you have been warned.
Jan  7 02:25:08 localhost kernel: lirc_serial: unknown parameter 'debug' ignored
Jan  7 02:25:09 localhost kernel: lirc_serial lirc_serial.0: auto-detected 
active high receiver
Jan  7 02:25:09 localhost kernel: lirc_serial lirc_serial.0: lirc_dev: driver 
lirc_serial registered at minor = 0
Jan  7 02:25:19 localhost lircd-0.9.0[1970]: lircd(default) ready, using 
/dev/lircd1
Jan  7 02:25:33 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:33 localhost lircd-0.9.0[1970]: removed client
Jan  7 02:25:33 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: removed client
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: removed client
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: accepted new client on /dev/lircd1
Jan  7 02:25:34 localhost lircd-0.9.0[1970]: removed client


2) lirc-0.9.0 gives me the charming choice of using the lirc-made modules
   (lirc_serial, lirc_dev) or the kernel-made modules (lirc_serial,lirc_dev).
   Now kernel-4.10 ruined things, I should at least have the option of using
   the lirc-made modules instead of serial_ir and lirc_dev.
   However, the modules that lirc makes when using kernel-4.10 do not offer
   the possibily of transmission. (It has no variable txsense anywhere in it.)
   Although compiling says '--with-transmitter', there is something in the
   kernel source that prevents lirc from building that in. That is not
   derived from the .config file it finds in the source. I don't know what
   else it is looking for and doesn't find anymore.


Regards, Wim.

lirc bug in kernel 4.10-rc1

[Wim Osterholt]

L.S.,

after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
to find a question about lirc_serial in 'make oldconfig':

Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
  Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y

I was used to 'lirc_serial: module is from the staging directory, the quality
is unknown, you have been warned.'
This always worked perfectly fine with the last working version of lirc: 
0.9.0-rc6.
Would things finally get better now?  NO!

In kernel-4.10-rc1 lirc_serial has been removed from staging. It has vanished
completely. If it were only renamed to serial_ir there would be no problem.
I just change the modules parameters
   options lirc_serial irq=4 io=0x3f8 type=0 txsense=0 softcarrier=0 debug=1
to
   options  serial_ir  irq=4 io=0x3f8 type=0 txsense=0 softcarrier=0 debug=1
and it should work, isn't it?
(Oh, whell, the kernel stuff has no option 'debug'..)

Serial_ir loads without useful messages.
Lirc_dev does not get loaded with it. Loading it manually or not doesn't
make any difference.
Irsend will not work. 'hardware does not support sending'


There's another bug of which I don't know wether it is a kernel issue or a
lirc issue.
On kernel 4.9 (and below) lirc compiles modules lirc_serial and lirc_dev
which work equally well as the in-kernel modules lirc-serial and lirc_dev.
You may even exchange them independently. The only difference is that the
lirc version knows about the parameter 'debug'.

When I let /usr/src/linux point to 4.10-rc1, then the exact same source of
lirc does not compile the transmitter part and things don't work!
So using the lirc modules is not even an alternative anymore.
Did I miss something?

(For lirc-0.9.0 you'll need a missing patch for the vanished f_dentry stuff
 in the kernel source.)

Regards, Wim.

lirc bug in kernel 4.10-rc1

[Wim Osterholt]

L.S.,

after appearance of kernel-4.10-rc1 two days ago I was pleasantly surprised
to find a question about lirc_serial in 'make oldconfig':

Homebrew Serial Port Receiver (IR_SERIAL) [N/m/?] (NEW) m
  Serial Port Transmitter (IR_SERIAL_TRANSMITTER) [Y/n/?] y

I was used to 'lirc_serial: module is from the staging directory, the quality
is unknown, you have been warned.'
This always worked perfectly fine with the last working version of lirc: 
0.9.0-rc6.
Would things finally get better now?  NO!

In kernel-4.10-rc1 lirc_serial has been removed from staging. It has vanished
completely. If it were only renamed to serial_ir there would be no problem.
I just change the modules parameters
   options lirc_serial irq=4 io=0x3f8 type=0 txsense=0 softcarrier=0 debug=1
to
   options  serial_ir  irq=4 io=0x3f8 type=0 txsense=0 softcarrier=0 debug=1
and it should work, isn't it?
(Oh, whell, the kernel stuff has no option 'debug'..)

Serial_ir loads without useful messages.
Lirc_dev does not get loaded with it. Loading it manually or not doesn't
make any difference.
Irsend will not work. 'hardware does not support sending'


There's another bug of which I don't know wether it is a kernel issue or a
lirc issue.
On kernel 4.9 (and below) lirc compiles modules lirc_serial and lirc_dev
which work equally well as the in-kernel modules lirc-serial and lirc_dev.
You may even exchange them independently. The only difference is that the
lirc version knows about the parameter 'debug'.

When I let /usr/src/linux point to 4.10-rc1, then the exact same source of
lirc does not compile the transmitter part and things don't work!
So using the lirc modules is not even an alternative anymore.
Did I miss something?

(For lirc-0.9.0 you'll need a missing patch for the vanished f_dentry stuff
 in the kernel source.)

Regards, Wim.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

On Tue, Nov 22, 2016 at 06:50:28PM +0100, Bjørn Mork wrote:
> > iCountryCodeRelDate4 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.

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

[Wim Osterholt]

On Tue, Nov 22, 2016 at 06:50:28PM +0100, Bjørn Mork wrote:
> > iCountryCodeRelDate4 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.

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

[Wim Osterholt]

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(, intf, buffer, buflen);
>   union_header = h.usb_cdc_union_desc;
> +
> + dev_dbg(>dev, "Parsed device header\n");
> + dev_dbg(>dev, "Union descriptor %p\n", h.usb_cdc_union_desc);
> + dev_dbg(>dev, "ACM descriptor %p\n", h.usb_cdc_acm_descriptor);
> + dev_dbg(>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 0249
[  161.397740] IP: [] acm_probe+0x580/0xd1e [cdc_acm]
[  161.397742] *pde =  
[  161.397745] Oops:  [#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:[] EFLAGS: 00010202 CPU: 0
[  161.397813] EIP is at acm_probe+0x580/0xd1e [cdc_acm]
[  161.397815] EAX: 0246 EBX: dc27b000 ECX: e086c934 EDX: 
[  161.397817] ESI: 0100 EDI:  EBP: df4dbc18 ESP: df4dbb80
[  161.397819]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  161.397821] CR0: 80050033 CR2: 0249 CR3: 1c45f000 CR4: 0690
[  161.397822] Stack:
[  161.397828]  3640 3662 000e df491d50   0010 
0040
[  161.397835]  0080 0246 dd1fc540 decf5a00 dc468c70 0001 df583a00 
df583a38
[  161.397841]  dc468c00 decf5800 decf5a00  dc452ab0 0004 0246 
df4dbc00
[  161.397842] Call Trace:
[  161.397853]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  161.397862]  [] ? usb_probe_interface+0x17b/0x1f6 [usbcore]
[  161.397870]  [] ? usb_probe_interface+0x17b/0x1f6 [usbcore]
[  161.397877]  [] ? driver_probe_device+0x17b/0x30e
[  161.397880]  [] ? driver_probe_device+0x17b/0x30e
[  161.397883]  [] ? bus_for_each_drv+0x59/0x68
[  161.397886]  [] ? bus_for_each_drv+0x59/0x68
[  161.397890]  [] ? __device_attach+0x91/0x105
[  161.397893]  [] ? driver_allows_async_probing+0x2f/0x2f
[  161.397896]  [] ? bus_probe_device+0x27/0x6b
[  161.397899]  [] ? bus_probe_device+0x27/0x6b
[  161.397902]  [] ? device_add+0x289/0x4be
[  161.397911]  [] ? usb_set_configuration+0x5a6/0x5e9 [usbcore]
[  161.397919]  [] ? usb_set_configuration+0x5a6/0x5e9 [usbcore]
[  161.397928]  [] ? generic_probe+0x3b/0x67 [usbcore]
[  161.397937]  [] ? generic_probe+0x3b/0x67 [usbcore]
[  161.397945]  [] ? usb_probe_device+0x49/0x62 [usbcore]
[  161.397953]  [] ? usb_suspend+0xcd/0xcd [usbcore]
[  161.397957]  [] ? driver_probe_device+0x17b/0x30e
[  161.397960]  [] ? driver_probe_device+0x17b/0x30e
[  161.397963]  [] ? bus_for_each_drv+0x59/0x68
[  161.397966]  [] ? bus_for_each_drv+0x59/0x68
[  161.397969]  [] ? __device_attach+0x91/0x105
[  161.397972]  [] ? driver_allows_async_probing+0x2f/0x2f
[  161.397976]  [] ? bus_probe_device+0x27/0x6b
[  161.397979]  [] ? bus_probe_device+0x27/0x6b
[  161.397982]  [] ? device_add+0x289/0x4be
[  161.397985]  [] ? add_device_randomness+0x84/0x9c
[  161.397993]  [] ? usb_new_device+0x29d/0x3b5 [usbcore]
[  161.398001]  [] ? usb_new_device+0x29d/0x3b5 [usbcore]

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

[Wim Osterholt]

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(, intf, buffer, buflen);
>   union_header = h.usb_cdc_union_desc;
> +
> + dev_dbg(>dev, "Parsed device header\n");
> + dev_dbg(>dev, "Union descriptor %p\n", h.usb_cdc_union_desc);
> + dev_dbg(>dev, "ACM descriptor %p\n", h.usb_cdc_acm_descriptor);
> + dev_dbg(>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 0249
[  161.397740] IP: [] acm_probe+0x580/0xd1e [cdc_acm]
[  161.397742] *pde =  
[  161.397745] Oops:  [#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:[] EFLAGS: 00010202 CPU: 0
[  161.397813] EIP is at acm_probe+0x580/0xd1e [cdc_acm]
[  161.397815] EAX: 0246 EBX: dc27b000 ECX: e086c934 EDX: 
[  161.397817] ESI: 0100 EDI:  EBP: df4dbc18 ESP: df4dbb80
[  161.397819]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  161.397821] CR0: 80050033 CR2: 0249 CR3: 1c45f000 CR4: 0690
[  161.397822] Stack:
[  161.397828]  3640 3662 000e df491d50   0010 
0040
[  161.397835]  0080 0246 dd1fc540 decf5a00 dc468c70 0001 df583a00 
df583a38
[  161.397841]  dc468c00 decf5800 decf5a00  dc452ab0 0004 0246 
df4dbc00
[  161.397842] Call Trace:
[  161.397853]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  161.397862]  [] ? usb_probe_interface+0x17b/0x1f6 [usbcore]
[  161.397870]  [] ? usb_probe_interface+0x17b/0x1f6 [usbcore]
[  161.397877]  [] ? driver_probe_device+0x17b/0x30e
[  161.397880]  [] ? driver_probe_device+0x17b/0x30e
[  161.397883]  [] ? bus_for_each_drv+0x59/0x68
[  161.397886]  [] ? bus_for_each_drv+0x59/0x68
[  161.397890]  [] ? __device_attach+0x91/0x105
[  161.397893]  [] ? driver_allows_async_probing+0x2f/0x2f
[  161.397896]  [] ? bus_probe_device+0x27/0x6b
[  161.397899]  [] ? bus_probe_device+0x27/0x6b
[  161.397902]  [] ? device_add+0x289/0x4be
[  161.397911]  [] ? usb_set_configuration+0x5a6/0x5e9 [usbcore]
[  161.397919]  [] ? usb_set_configuration+0x5a6/0x5e9 [usbcore]
[  161.397928]  [] ? generic_probe+0x3b/0x67 [usbcore]
[  161.397937]  [] ? generic_probe+0x3b/0x67 [usbcore]
[  161.397945]  [] ? usb_probe_device+0x49/0x62 [usbcore]
[  161.397953]  [] ? usb_suspend+0xcd/0xcd [usbcore]
[  161.397957]  [] ? driver_probe_device+0x17b/0x30e
[  161.397960]  [] ? driver_probe_device+0x17b/0x30e
[  161.397963]  [] ? bus_for_each_drv+0x59/0x68
[  161.397966]  [] ? bus_for_each_drv+0x59/0x68
[  161.397969]  [] ? __device_attach+0x91/0x105
[  161.397972]  [] ? driver_allows_async_probing+0x2f/0x2f
[  161.397976]  [] ? bus_probe_device+0x27/0x6b
[  161.397979]  [] ? bus_probe_device+0x27/0x6b
[  161.397982]  [] ? device_add+0x289/0x4be
[  161.397985]  [] ? add_device_randomness+0x84/0x9c
[  161.397993]  [] ? usb_new_device+0x29d/0x3b5 [usbcore]
[  161.398001]  [] ? usb_new_device+0x29d/0x3b5 [usbcore]

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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 0249
> > Nov 17 15:07:51 localhost kernel: IP: [] acm_probe+0x559/0xe53 
> > [cdc_acm]
> > Nov 17 15:07:51 localhost kernel: *pde =  
> > Nov 17 15:07:51 localhost kernel: Oops:  [#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:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0572 Conexant Systems (Rockwell), Inc.
  idProduct  0x1340 
  bcdDevice1.00
  iManufacturer   1 Conexant
  iProduct2 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
  bInterfaceNumber0
  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
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval 128
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  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:
bMasterInterface0
bSlaveInterface 1 
  Country Selection:
iCountryCodeRelDate4 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface  0 
  Endpoint

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

[Wim Osterholt]

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 0249
> > Nov 17 15:07:51 localhost kernel: IP: [] acm_probe+0x559/0xe53 
> > [cdc_acm]
> > Nov 17 15:07:51 localhost kernel: *pde =  
> > Nov 17 15:07:51 localhost kernel: Oops:  [#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:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0572 Conexant Systems (Rockwell), Inc.
  idProduct  0x1340 
  bcdDevice1.00
  iManufacturer   1 Conexant
  iProduct2 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
  bInterfaceNumber0
  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
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval 128
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  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:
bMasterInterface0
bSlaveInterface 1 
  Country Selection:
iCountryCodeRelDate4 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands (v.25ter)
  iInterface  0 
  Endpoint

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

[Wim Osterholt]

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/pci:00/: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 0249
Nov 17 15:07:51 localhost kernel: IP: [] acm_probe+0x559/0xe53 
[cdc_acm]
Nov 17 15:07:51 localhost kernel: *pde =  
Nov 17 15:07:51 localhost kernel: Oops:  [#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.

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

[Wim Osterholt]

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/pci:00/: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 0249
Nov 17 15:07:51 localhost kernel: IP: [] acm_probe+0x559/0xe53 
[cdc_acm]
Nov 17 15:07:51 localhost kernel: *pde =  
Nov 17 15:07:51 localhost kernel: Oops:  [#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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

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.

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

[Wim Osterholt]

On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> On Mon, 2016-10-17 at 17:20 +0200, Wim Osterholt wrote:
> > On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> > > Hi,
> > >
> > > I got one of those devices. However, I don't get a crash.
> > > Could you please give me instructions on how you trigger it?
> >   
> > That's not too hard, just plug it in. :-)

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

Hmmm.

> ... Something odd is going on.

You didn't try it on many machines, did you?
The latest install on a 'new' laptop (Dell latitude D610) did also crash.
For if it matters, they all have Intel chipset here.
Crashes now on five machines.

An worn-out Dell laptop (Inspiron 510m) suddenly got stuck in a reboot loop
for 4.7.10 and 4.9-rc3, but a 4.8-rc4 kept running. Even more miraculously,
it didn't crash on inserting the modem.
I could even compile a 4.9-rc3 that didn't crash on that machine.
The effect was even portable!

I now have a crashing and a non-crashing 4.9-rc3 kernel.
You can find the configs here:
http://webserver.djo.tudelft.nl/.config-4.9-rc3.notOK
http://webserver.djo.tudelft.nl/.config-4.9-rc3.OK

They are very different, so it will take a lot of time to eliminate the
options one by one.
So if you have an idea of which options, or combination of options are evil,
I'd like to hear.


Regards, Wim.

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

[Wim Osterholt]

On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> On Mon, 2016-10-17 at 17:20 +0200, Wim Osterholt wrote:
> > On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> > > Hi,
> > >
> > > I got one of those devices. However, I don't get a crash.
> > > Could you please give me instructions on how you trigger it?
> >   
> > That's not too hard, just plug it in. :-)

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

Hmmm.

> ... Something odd is going on.

You didn't try it on many machines, did you?
The latest install on a 'new' laptop (Dell latitude D610) did also crash.
For if it matters, they all have Intel chipset here.
Crashes now on five machines.

An worn-out Dell laptop (Inspiron 510m) suddenly got stuck in a reboot loop
for 4.7.10 and 4.9-rc3, but a 4.8-rc4 kept running. Even more miraculously,
it didn't crash on inserting the modem.
I could even compile a 4.9-rc3 that didn't crash on that machine.
The effect was even portable!

I now have a crashing and a non-crashing 4.9-rc3 kernel.
You can find the configs here:
http://webserver.djo.tudelft.nl/.config-4.9-rc3.notOK
http://webserver.djo.tudelft.nl/.config-4.9-rc3.OK

They are very different, so it will take a lot of time to eliminate the
options one by one.
So if you have an idea of which options, or combination of options are evil,
I'd like to hear.


Regards, Wim.

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

[Wim Osterholt]

On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: Manufacturer: Conexant
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: SerialNumber: 12345678

With that unique serial number it must be that very device. :-)

> It definitely does not crash and is probed and your .config is not
> extremely unusual.
> I am afraid unless you test the last patch I sent we will not make
> progress. Something odd is going on.

Whell, I DID test that patch and it already crashed before it could print
anything. That's why the output I sent you looked the same.

Once again, this time on 4.9-rc1.
Applied your patch 0001-CDC-ACM-more-paranoid-debugging to cdc_acm.c .

Did
> > dmesg -c
> > echo 9 > /proc/sysrq-trigger
> > modprobe cdc_acm
> > echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> >
> > [plug your device in]
> >
> > and provide the full output of dmesg after that.

Got
[  765.409057] sysrq: SysRq : Changing Loglevel
[  765.416465] sysrq: Loglevel set to 9
[  778.299271] usbcore: registered new interface driver cdc_acm
[  778.301921] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  833.204100] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  833.411088] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  833.412127] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  833.416129] usb 6-1: Product: USB Modem
[  833.420123] usb 6-1: Manufacturer: Conexant
[  833.420126] usb 6-1: SerialNumber: 12345678
[  833.473854] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  833.473876] BUG: unable to handle kernel NULL pointer dereference at 0249
[  833.473882] IP: [] acm_probe+0x540/0xd00 [cdc_acm]
[  833.473885] *pde =  
[  833.473887] Oops:  [#1] SMP
[  833.473925] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon 
bitblit softcursor font tileblit sr9700 dm9601 snd_hda_codec_generic usbnet 
usb_storage snd_hda_intel mii snd_hda_codec tg3 snd_hwdep snd_hda_core ptp 
pps_core snd_pcm libphy gpio_ich snd_timer firmware_class lpc_ich pcspkr ppdev 
snd ohci_pci mfd_core ohci_hcd floppy wmi uhci_hcd soundcore parport_pc 
acpi_cpufreq ehci_pci parport ehci_hcd processor button
[  833.473928] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G   O
4.9.0-rc1 #1
[  833.473930] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[  833.473935] Workqueue: usb_hub_wq hub_event
[  833.473937] task: df4e15c0 task.stack: df4f4000
[  833.473939] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[  833.473942] EIP is at acm_probe+0x540/0xd00 [cdc_acm]
[  833.473944] EAX: 0246 EBX: dc4b2800 ECX: e08fe594 EDX: 
[  833.473945] ESI: 0100 EDI:  EBP: df4f5c18 ESP: df4f5b80
[  833.473947]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  833.473949] CR0: 80050033 CR2: 0249 CR3: 1c8c4000 CR4: 0690
[  833.473950] Stack:
[  833.473956]  3a20 3de7 000f df4a9d50   0010 
0040
[  833.473960]  0080 0246 dee5f000 d9614d80 d960e070 0001 d2aee100 
d960e000
[  833.473965]  d2aee138 dee5f400 dee5f000  c82931b0 0004 0246 
df4f5c00
[  833.473966] Call Trace:
[  833.473975]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  833.473978]  [] ? usb_probe_interface+0x17b/0x1f6
[  833.473980]  [] ? usb_probe_interface+0x17b/0x1f6
[  833.473984]  [] ? driver_probe_device+0x17b/0x30e
[  833.473986]  [] ? driver_probe_device+0x17b/0x30e
[  833.473989]  [] ? bus_for_each_drv+0x59/0x68
[  833.473991]  [] ? bus_for_each_drv+0x59/0x68
[  833.473993]  [] ? __device_attach+0x91/0x105
[  833.473996]  [] ? driver_allows_async_probing+0x2f/0x2f
[  833.473998]  [] ? bus_probe_device+0x27/0x6b
[  833.474000]  [] ? bus_probe_device+0x27/0x6b
[  833.474002]  [] ? device_add+0x28d/0x4c0
[  833.474006]  [] ? usb_set_configuration+0x594/0x5d7
[  833.474008]  [] ? usb_set_configuration+0x594/0x5d7
[  833.474012]  [] ? generic_probe+0x3b/0x67
[  833.474014]  [] ? generic_probe+0x3b/0x67
[  833.474016]  [] ? usb_probe_device+0x49/0x62
[  833.474017]  [] ? usb_suspend+0xcd/0xcd
[  833.474020]  [] ? driver_probe_device+0x17b/0x30e
[  833.474022]  [] ? driver_probe_device+0x17b/0x30e
[  833.474024]  [] ? bus_for_each_drv+0x59/0x68
[  833.474026]  [] ? bus_for_each_drv+0x59/0x68
[  833.474028]  [] ? __device_attach+0x91/0x105
[  833.474031]  [] ? driver_allows_async_probing+0x2f/0x2f
[  833.474033]  [] ? bus_probe_device+0x27/0x6b
[  833.474035]  [] ? bus_probe_device+0x27/0x6b
[  833.474037]  [] ? device_add+0x28d/0x4c0
[  833.474041]  [] ? add_device_randomness+0x84/0x9c
[  833.474043]  [] ? usb_new_device+0x29d/0x3b5
[  833.474045]  [] ? usb_new_device+0x29d/0x3b5
[  833.474048]  [] ? hub_event+0xb32/0xed8
[  833.474050]  [] ? 

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

[Wim Osterholt]

On Tue, Oct 18, 2016 at 02:18:43PM +0200, Oliver Neukum wrote:
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: Manufacturer: Conexant
> Oct 18 14:05:07 linux-dtbq.site kernel: usb 1-9: SerialNumber: 12345678

With that unique serial number it must be that very device. :-)

> It definitely does not crash and is probed and your .config is not
> extremely unusual.
> I am afraid unless you test the last patch I sent we will not make
> progress. Something odd is going on.

Whell, I DID test that patch and it already crashed before it could print
anything. That's why the output I sent you looked the same.

Once again, this time on 4.9-rc1.
Applied your patch 0001-CDC-ACM-more-paranoid-debugging to cdc_acm.c .

Did
> > dmesg -c
> > echo 9 > /proc/sysrq-trigger
> > modprobe cdc_acm
> > echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> >
> > [plug your device in]
> >
> > and provide the full output of dmesg after that.

Got
[  765.409057] sysrq: SysRq : Changing Loglevel
[  765.416465] sysrq: Loglevel set to 9
[  778.299271] usbcore: registered new interface driver cdc_acm
[  778.301921] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  833.204100] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  833.411088] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  833.412127] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  833.416129] usb 6-1: Product: USB Modem
[  833.420123] usb 6-1: Manufacturer: Conexant
[  833.420126] usb 6-1: SerialNumber: 12345678
[  833.473854] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  833.473876] BUG: unable to handle kernel NULL pointer dereference at 0249
[  833.473882] IP: [] acm_probe+0x540/0xd00 [cdc_acm]
[  833.473885] *pde =  
[  833.473887] Oops:  [#1] SMP
[  833.473925] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon 
bitblit softcursor font tileblit sr9700 dm9601 snd_hda_codec_generic usbnet 
usb_storage snd_hda_intel mii snd_hda_codec tg3 snd_hwdep snd_hda_core ptp 
pps_core snd_pcm libphy gpio_ich snd_timer firmware_class lpc_ich pcspkr ppdev 
snd ohci_pci mfd_core ohci_hcd floppy wmi uhci_hcd soundcore parport_pc 
acpi_cpufreq ehci_pci parport ehci_hcd processor button
[  833.473928] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G   O
4.9.0-rc1 #1
[  833.473930] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[  833.473935] Workqueue: usb_hub_wq hub_event
[  833.473937] task: df4e15c0 task.stack: df4f4000
[  833.473939] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[  833.473942] EIP is at acm_probe+0x540/0xd00 [cdc_acm]
[  833.473944] EAX: 0246 EBX: dc4b2800 ECX: e08fe594 EDX: 
[  833.473945] ESI: 0100 EDI:  EBP: df4f5c18 ESP: df4f5b80
[  833.473947]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  833.473949] CR0: 80050033 CR2: 0249 CR3: 1c8c4000 CR4: 0690
[  833.473950] Stack:
[  833.473956]  3a20 3de7 000f df4a9d50   0010 
0040
[  833.473960]  0080 0246 dee5f000 d9614d80 d960e070 0001 d2aee100 
d960e000
[  833.473965]  d2aee138 dee5f400 dee5f000  c82931b0 0004 0246 
df4f5c00
[  833.473966] Call Trace:
[  833.473975]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  833.473978]  [] ? usb_probe_interface+0x17b/0x1f6
[  833.473980]  [] ? usb_probe_interface+0x17b/0x1f6
[  833.473984]  [] ? driver_probe_device+0x17b/0x30e
[  833.473986]  [] ? driver_probe_device+0x17b/0x30e
[  833.473989]  [] ? bus_for_each_drv+0x59/0x68
[  833.473991]  [] ? bus_for_each_drv+0x59/0x68
[  833.473993]  [] ? __device_attach+0x91/0x105
[  833.473996]  [] ? driver_allows_async_probing+0x2f/0x2f
[  833.473998]  [] ? bus_probe_device+0x27/0x6b
[  833.474000]  [] ? bus_probe_device+0x27/0x6b
[  833.474002]  [] ? device_add+0x28d/0x4c0
[  833.474006]  [] ? usb_set_configuration+0x594/0x5d7
[  833.474008]  [] ? usb_set_configuration+0x594/0x5d7
[  833.474012]  [] ? generic_probe+0x3b/0x67
[  833.474014]  [] ? generic_probe+0x3b/0x67
[  833.474016]  [] ? usb_probe_device+0x49/0x62
[  833.474017]  [] ? usb_suspend+0xcd/0xcd
[  833.474020]  [] ? driver_probe_device+0x17b/0x30e
[  833.474022]  [] ? driver_probe_device+0x17b/0x30e
[  833.474024]  [] ? bus_for_each_drv+0x59/0x68
[  833.474026]  [] ? bus_for_each_drv+0x59/0x68
[  833.474028]  [] ? __device_attach+0x91/0x105
[  833.474031]  [] ? driver_allows_async_probing+0x2f/0x2f
[  833.474033]  [] ? bus_probe_device+0x27/0x6b
[  833.474035]  [] ? bus_probe_device+0x27/0x6b
[  833.474037]  [] ? device_add+0x28d/0x4c0
[  833.474041]  [] ? add_device_randomness+0x84/0x9c
[  833.474043]  [] ? usb_new_device+0x29d/0x3b5
[  833.474045]  [] ? usb_new_device+0x29d/0x3b5
[  833.474048]  [] ? hub_event+0xb32/0xed8
[  833.474050]  [] ? 

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

[Wim Osterholt]

On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> Hi,
>
> I got one of those devices. However, I don't get a crash.
> Could you please give me instructions on how you trigger it?
  
That's not too hard, just plug it in. :-)
  
However you must have set cdc_acm in your kernel, or availabe as a module. 
It happens on all my machines on kernels 4.8 and 4.9.
Now, all my kernel configs will differ a bit, but must have something
peculiar in common. Or you've received a totally different device.
 
Here's one config at http://webserver.djo.tudelft.nl/.config-4.8.1
 
Many options are inherited by 'make oldconfig' from version to version,
without me knowing what it all means. So maybe it's just a weird combination
of options then?


Regards, Wim.

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

[Wim Osterholt]

On Mon, Oct 17, 2016 at 04:10:45PM +0200, Oliver Neukum wrote:
> Hi,
>
> I got one of those devices. However, I don't get a crash.
> Could you please give me instructions on how you trigger it?
  
That's not too hard, just plug it in. :-)
  
However you must have set cdc_acm in your kernel, or availabe as a module. 
It happens on all my machines on kernels 4.8 and 4.9.
Now, all my kernel configs will differ a bit, but must have something
peculiar in common. Or you've received a totally different device.
 
Here's one config at http://webserver.djo.tudelft.nl/.config-4.8.1
 
Many options are inherited by 'make oldconfig' from version to version,
without me knowing what it all means. So maybe it's just a weird combination
of options then?


Regards, Wim.

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

[Wim Osterholt]

On Wed, Sep 28, 2016 at 07:38:41PM -0400, Sinan Kaya wrote:
> 
> Can you try these patches on your machines please?

I applied the included patches on vanilla 4.8-rc8 and my machine booted
fine. (I saw a remark about SCSI interrupts, but I have no SCSI.)

Regards, Wim.

Re: 4.7 regression: ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off

[Wim Osterholt]

On Wed, Sep 28, 2016 at 07:38:41PM -0400, Sinan Kaya wrote:
> 
> Can you try these patches on your machines please?

I applied the included patches on vanilla 4.8-rc8 and my machine booted
fine. (I saw a remark about SCSI interrupts, but I have no SCSI.)

Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 28, 2016 at 05:23:30PM +0200, Oliver Neukum wrote:
> > 
> > HP src # sync
> > HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer 
> > dereference at 0249
> 
> The last view lines before that please with the debugging level ramped
> up to 9 please.

Recompiled again, double checked if it was really the new module.
That doesn't seem to make any difference at all.

[  549.238494] sysrq: SysRq : Changing Loglevel
[  549.265916] sysrq: Loglevel set to 9
[  549.363794] usbcore: registered new interface driver cdc_acm
[  549.429906] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  550.941964] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  551.148944] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  551.149975] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  551.153974] usb 6-1: Product: USB Modem
[  551.157969] usb 6-1: Manufacturer: Conexant
[  551.161969] usb 6-1: SerialNumber: 12345678
[  551.171006] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  551.173997] BUG: unable to handle kernel NULL pointer dereference at 0249
[  551.177957] IP: [] acm_probe+0x52d/0xced [cdc_acm]
[  551.177957] *pde =  
[  551.177957] Oops:  [#1] SMP
[  551.177957] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon 
bitblit softcursor font tileblit sr9700 snd_hda_codec_generic dm9601 
snd_hda_intel usbnet usb_storage mii snd_hda_codec snd_hwdep tg3 snd_hda_core 
ptp pps_core snd_pcm gpio_ich libphy snd_timer lpc_ich ppdev firmware_class 
pcspkr mfd_core snd ohci_pci ohci_hcd uhci_hcd wmi floppy parport_pc soundcore 
ehci_pci parport acpi_cpufreq ehci_hcd button processor
[  551.177957] CPU: 0 PID: 725 Comm: kworker/0:2 Tainted: G   O
4.8.0-rc8 #1


Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 28, 2016 at 05:23:30PM +0200, Oliver Neukum wrote:
> > 
> > HP src # sync
> > HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer 
> > dereference at 0249
> 
> The last view lines before that please with the debugging level ramped
> up to 9 please.

Recompiled again, double checked if it was really the new module.
That doesn't seem to make any difference at all.

[  549.238494] sysrq: SysRq : Changing Loglevel
[  549.265916] sysrq: Loglevel set to 9
[  549.363794] usbcore: registered new interface driver cdc_acm
[  549.429906] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  550.941964] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  551.148944] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  551.149975] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  551.153974] usb 6-1: Product: USB Modem
[  551.157969] usb 6-1: Manufacturer: Conexant
[  551.161969] usb 6-1: SerialNumber: 12345678
[  551.171006] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  551.173997] BUG: unable to handle kernel NULL pointer dereference at 0249
[  551.177957] IP: [] acm_probe+0x52d/0xced [cdc_acm]
[  551.177957] *pde =  
[  551.177957] Oops:  [#1] SMP
[  551.177957] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon 
bitblit softcursor font tileblit sr9700 snd_hda_codec_generic dm9601 
snd_hda_intel usbnet usb_storage mii snd_hda_codec snd_hwdep tg3 snd_hda_core 
ptp pps_core snd_pcm gpio_ich libphy snd_timer lpc_ich ppdev firmware_class 
pcspkr mfd_core snd ohci_pci ohci_hcd uhci_hcd wmi floppy parport_pc soundcore 
ehci_pci parport acpi_cpufreq ehci_hcd button processor
[  551.177957] CPU: 0 PID: 725 Comm: kworker/0:2 Tainted: G   O
4.8.0-rc8 #1


Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
> this should show you where it crashes. In addition I've attached
> a patch with paranoid debugging. Could you compile and test a kernel
> with it?
> 
>   Regards
>   Oliver

If you mean
  echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
etc, then it will take some time because I don't have the cabling not
available now for a serial dump.

Just 4.8-rc8 with the patched modules gave an oops of less than one screen
while the machine stayed responsive long enough to grab it with the mouse
and put it in a file:

HP src # sync
HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer dereference 
at 0249
[ 3744.914538] IP: [] acm_probe+0x52d/0xced [cdc_acm]
[ 3744.914850] *pde = 
[ 3744.915133] Oops:  [#1] SMP
[ 3744.915446] Modules linked in: cdc_acm(+) nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon 
bitblit softcursor font tileblit sr9700 dm9601 snd_hda_codec_generic 
usb_storage usbnet snd_hda_intel mii snd_hda_codec tg3 snd_hwdep snd_hda_core 
ptp pps_core snd_pcm libphy gpio_ich firmware_class snd_timer lpc_ich pcspkr 
ppdev ohci_pci snd ohci_hcd wmi mfd_core uhci_hcd floppy parport_pc soundcore 
ehci_pci parport acpi_cpufreq ehci_hcd button processor
[ 3744.918142] CPU: 1 PID: 24530 Comm: udevd Tainted: G   O
4.8.0-rc8 #1
[ 3744.918142] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[ 3744.918142] task: df7b4d00 task.stack: d3d56000
[ 3744.918142] EIP: 0060:[] EFLAGS: 00010202 CPU: 1
[ 3744.918142] EIP is at acm_probe+0x52d/0xced [cdc_acm]
[ 3744.918142] EAX: 0246 EBX: cf9a7800 ECX: e09318d4 EDX: 
[ 3744.918142] ESI: 0100 EDI:  EBP: d3d57cc8 ESP: d3d57c30
[ 3744.918142]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 3744.918142] CR0: 80050033 CR2: 0249 CR3: 1ac9a000 CR4: 0690
[ 3744.918142] Stack:
[ 3744.918142]  3a20 3d7b 000f df4a9d50   0010 
0040
[ 3744.918142]  0080 0246 dedeb200 dac90740 cfa40870 0001 ceb37180 
cfa40800
[ 3744.918142]  ceb371b8 dedeaa00 dedeb200  cabfe3f0 0004 0246 
d3d57cb0
[ 3744.918142] Call Trace:
[ 3744.918142]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[ 3744.918142]  [] ? usb_probe_interface+0x17b/0x1f6
[ 3744.918142]  [] ? usb_probe_interface+0x17b/0x1f6
[ 3744.918142]  [] ? driver_probe_device+0x17b/0x30e
[ 3744.918142]  [] ? driver_probe_device+0x17b/0x30e
[ 3744.918142]  [] ? __driver_attach+0xaf/0xd2
[ 3744.918142]  [] ? __driver_attach+0xaf/0xd2
[ 3744.918142]  [] ? klist_next+0x2a/0xad
[ 3744.918142]  [] ? bus_for_each_dev+0x50/0x6c
[ 3744.918142]  [] ? bus_for_each_dev+0x50/0x6c
[ 3744.918142]  [] ? driver_attach+0x19/0x1b
[ 3744.918142]  [] ? driver_probe_device+0x30e/0x30e
[ 3744.918142]  [] ? bus_add_driver+0x10a/0x1ee
[ 3744.918142]  [] ? kset_find_obj+0x2b/0x5f
[ 3744.918142]  [] ? driver_register+0x74/0xa9
[ 3744.918142]  [] ? driver_register+0x74/0xa9
[ 3744.918142]  [] ? usb_register_driver+0x67/0xf8
[ 3744.918142]  [] ? acm_init+0xac/0xdf [cdc_acm]
[ 3744.918142]  [] ? 0xe0934000
[ 3744.918142]  [] ? do_one_initcall+0x90/0x113
[ 3744.918142]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[ 3744.918142]  [] ? kmem_cache_alloc_trace+0x72/0xe3
[ 3744.918142]  [] ? do_init_module+0x21/0x1a7
[ 3744.918142]  [] ? do_init_module+0x50/0x1a7
[ 3744.918142]  [] ? load_module+0x190e/0x1d33
[ 3744.918142]  [] ? SyS_finit_module+0x9c/0xa8
[ 3744.918142]  [] ? SyS_finit_module+0x9c/0xa8
[ 3744.918142]  [] ? do_int80_syscall_32+0x47/0x7f
[ 3744.918142]  [] ? do_int80_syscall_32+0x47/0x7f
[ 3744.918142]  [] ? entry_INT80_32+0x31/0x31
[ 3744.918142] Code: 14 89 83 b4 04 00 00 8b 45 90 89 43 04 8b 45 ac 89 43 08 
8b 85 7c ff ff ff 89 83 c0 04 00 00 8b 45 a4 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
[ 3744.918142] EIP: [] acm_probe+0x52d/0xced [cdc_acm] SS:ESP 
0068:d3d57c30
[ 3744.918142] CR2: 0249
[ 3745.49] ---[ end trace e6bc96526d51607e ]---
[ 3745.006322] udevd[945]: worker [24530] terminated by signal 9 (Killed)
[ 3745.008927] udevd[945]: worker [24530] failed while handling 
'/devices/pci:00/:00:1d.3/usb6/6-1/6-1:1.0'


Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
> this should show you where it crashes. In addition I've attached
> a patch with paranoid debugging. Could you compile and test a kernel
> with it?
> 
>   Regards
>   Oliver

If you mean
  echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
etc, then it will take some time because I don't have the cabling not
available now for a serial dump.

Just 4.8-rc8 with the patched modules gave an oops of less than one screen
while the machine stayed responsive long enough to grab it with the mouse
and put it in a file:

HP src # sync
HP src # [ 3744.914184] BUG: unable to handle kernel NULL pointer dereference 
at 0249
[ 3744.914538] IP: [] acm_probe+0x52d/0xced [cdc_acm]
[ 3744.914850] *pde = 
[ 3744.915133] Oops:  [#1] SMP
[ 3744.915446] Modules linked in: cdc_acm(+) nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon 
bitblit softcursor font tileblit sr9700 dm9601 snd_hda_codec_generic 
usb_storage usbnet snd_hda_intel mii snd_hda_codec tg3 snd_hwdep snd_hda_core 
ptp pps_core snd_pcm libphy gpio_ich firmware_class snd_timer lpc_ich pcspkr 
ppdev ohci_pci snd ohci_hcd wmi mfd_core uhci_hcd floppy parport_pc soundcore 
ehci_pci parport acpi_cpufreq ehci_hcd button processor
[ 3744.918142] CPU: 1 PID: 24530 Comm: udevd Tainted: G   O
4.8.0-rc8 #1
[ 3744.918142] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[ 3744.918142] task: df7b4d00 task.stack: d3d56000
[ 3744.918142] EIP: 0060:[] EFLAGS: 00010202 CPU: 1
[ 3744.918142] EIP is at acm_probe+0x52d/0xced [cdc_acm]
[ 3744.918142] EAX: 0246 EBX: cf9a7800 ECX: e09318d4 EDX: 
[ 3744.918142] ESI: 0100 EDI:  EBP: d3d57cc8 ESP: d3d57c30
[ 3744.918142]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 3744.918142] CR0: 80050033 CR2: 0249 CR3: 1ac9a000 CR4: 0690
[ 3744.918142] Stack:
[ 3744.918142]  3a20 3d7b 000f df4a9d50   0010 
0040
[ 3744.918142]  0080 0246 dedeb200 dac90740 cfa40870 0001 ceb37180 
cfa40800
[ 3744.918142]  ceb371b8 dedeaa00 dedeb200  cabfe3f0 0004 0246 
d3d57cb0
[ 3744.918142] Call Trace:
[ 3744.918142]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[ 3744.918142]  [] ? usb_probe_interface+0x17b/0x1f6
[ 3744.918142]  [] ? usb_probe_interface+0x17b/0x1f6
[ 3744.918142]  [] ? driver_probe_device+0x17b/0x30e
[ 3744.918142]  [] ? driver_probe_device+0x17b/0x30e
[ 3744.918142]  [] ? __driver_attach+0xaf/0xd2
[ 3744.918142]  [] ? __driver_attach+0xaf/0xd2
[ 3744.918142]  [] ? klist_next+0x2a/0xad
[ 3744.918142]  [] ? bus_for_each_dev+0x50/0x6c
[ 3744.918142]  [] ? bus_for_each_dev+0x50/0x6c
[ 3744.918142]  [] ? driver_attach+0x19/0x1b
[ 3744.918142]  [] ? driver_probe_device+0x30e/0x30e
[ 3744.918142]  [] ? bus_add_driver+0x10a/0x1ee
[ 3744.918142]  [] ? kset_find_obj+0x2b/0x5f
[ 3744.918142]  [] ? driver_register+0x74/0xa9
[ 3744.918142]  [] ? driver_register+0x74/0xa9
[ 3744.918142]  [] ? usb_register_driver+0x67/0xf8
[ 3744.918142]  [] ? acm_init+0xac/0xdf [cdc_acm]
[ 3744.918142]  [] ? 0xe0934000
[ 3744.918142]  [] ? do_one_initcall+0x90/0x113
[ 3744.918142]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[ 3744.918142]  [] ? kmem_cache_alloc_trace+0x72/0xe3
[ 3744.918142]  [] ? do_init_module+0x21/0x1a7
[ 3744.918142]  [] ? do_init_module+0x50/0x1a7
[ 3744.918142]  [] ? load_module+0x190e/0x1d33
[ 3744.918142]  [] ? SyS_finit_module+0x9c/0xa8
[ 3744.918142]  [] ? SyS_finit_module+0x9c/0xa8
[ 3744.918142]  [] ? do_int80_syscall_32+0x47/0x7f
[ 3744.918142]  [] ? do_int80_syscall_32+0x47/0x7f
[ 3744.918142]  [] ? entry_INT80_32+0x31/0x31
[ 3744.918142] Code: 14 89 83 b4 04 00 00 8b 45 90 89 43 04 8b 45 ac 89 43 08 
8b 85 7c ff ff ff 89 83 c0 04 00 00 8b 45 a4 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
[ 3744.918142] EIP: [] acm_probe+0x52d/0xced [cdc_acm] SS:ESP 
0068:d3d57c30
[ 3744.918142] CR2: 0249
[ 3745.49] ---[ end trace e6bc96526d51607e ]---
[ 3745.006322] udevd[945]: worker [24530] terminated by signal 9 (Killed)
[ 3745.008927] udevd[945]: worker [24530] failed while handling 
'/devices/pci:00/:00:1d.3/usb6/6-1/6-1:1.0'


Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
> 
> Very good. This is a valid oops. We can do two things. When I
> decode it, seems to crash in acm_alloc_minor() which does not make
> sense. It is likely that our kernels or compilers are a bit different.
> Could you please call gdb on your kernel module cdc-acm.ko
> and do:
> 
> list *(acm_probe+0x4ee)
> 
> this should show you where it crashes.

Currently gcc-4.9.3-rc3.
This is from vanilla kernel 4.8-rc8

# gdb ./cdc-acm.ko
GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see: .
Find the GDB manual and other documentation resources online at: 
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./cdc-acm.ko...done.
(gdb) list *(acm_probe+0x4ee)
0x1c9b is in acm_probe (drivers/usb/class/cdc-acm.c:1346).
1341acm->control = control_interface;
1342acm->data = data_interface;
1343acm->minor = minor;
1344acm->dev = usb_dev;
1345if (h.usb_cdc_acm_descriptor)
1346acm->ctrl_caps = 
h.usb_cdc_acm_descriptor->bmCapabilities;
1347if (quirks & NO_CAP_LINE)
1348acm->ctrl_caps &= ~USB_CDC_CAP_LINE;
1349acm->ctrlsize = ctrlsize;
1350acm->readsize = readsize;
(gdb) quit

A new kernel is compiling now.

Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 28, 2016 at 11:16:04AM +0200, Oliver Neukum wrote:
> 
> Very good. This is a valid oops. We can do two things. When I
> decode it, seems to crash in acm_alloc_minor() which does not make
> sense. It is likely that our kernels or compilers are a bit different.
> Could you please call gdb on your kernel module cdc-acm.ko
> and do:
> 
> list *(acm_probe+0x4ee)
> 
> this should show you where it crashes.

Currently gcc-4.9.3-rc3.
This is from vanilla kernel 4.8-rc8

# gdb ./cdc-acm.ko
GNU gdb (Gentoo 7.10.1 vanilla) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see: .
Find the GDB manual and other documentation resources online at: 
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./cdc-acm.ko...done.
(gdb) list *(acm_probe+0x4ee)
0x1c9b is in acm_probe (drivers/usb/class/cdc-acm.c:1346).
1341acm->control = control_interface;
1342acm->data = data_interface;
1343acm->minor = minor;
1344acm->dev = usb_dev;
1345if (h.usb_cdc_acm_descriptor)
1346acm->ctrl_caps = 
h.usb_cdc_acm_descriptor->bmCapabilities;
1347if (quirks & NO_CAP_LINE)
1348acm->ctrl_caps &= ~USB_CDC_CAP_LINE;
1349acm->ctrlsize = ctrlsize;
1350acm->readsize = readsize;
(gdb) quit

A new kernel is compiling now.

Regards, Wim.

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

[Wim Osterholt]

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

After some experimenting I succeeded in grabbing it over the serial port.
The console was immedately frozen, but the serial port kept working:

[  407.859834] sysrq: SysRq : Changing Loglevel
[  407.908433] sysrq: Loglevel set to 9
[  407.980538] usbcore: registered new interface driver cdc_acm
[  408.044439] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  410.480711] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  410.696717] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  410.700739] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  410.704738] usb 6-1: Product: USB Modem
[  410.708735] usb 6-1: Manufacturer: Conexant
[  410.708738] usb 6-1: SerialNumber: 12345678
[  410.763492] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  410.763515] BUG: unable to handle kernel NULL pointer dereference at 0249
[  410.763522] IP: [] acm_probe+0x4ee/0xc8c [cdc_acm]
[  410.763524] *pde =  
[  410.763526] Oops:  [#1] SMP
[  410.763562] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc snd_pcm_oss snd_mixer_oss fbcon bitblit softcursor 
font tileblit sr9700 dm9601 usb_storage usbnet snd_hda_codec_generic mii 
snd_hda_intel snd_hda_codec tg3 snd_hwdep ptp snd_hda_core pps_core snd_pcm 
gpio_ich libphy firmware_class pcspkr ohci_pci lpc_ich ppdev snd_timer mfd_core 
ohci_hcd snd uhci_hcd wmi parport_pc floppy ehci_pci soundcore parport ehci_hcd 
acpi_cpufreq button processor
[  410.763565] CPU: 0 PID: 429 Comm: kworker/0:1 Not tainted 4.8.0-rc8 #1
[  410.763567] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[  410.763572] Workqueue: usb_hub_wq hub_event
[  410.763574] task: df523f00 task.stack: dec3
[  410.763576] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[  410.763579] EIP is at acm_probe+0x4ee/0xc8c [cdc_acm]
[  410.763581] EAX: 0246 EBX: decff000 ECX: e08e1854 EDX: 
[  410.763582] ESI: 0100 EDI:  EBP: dec31c18 ESP: dec31b80
[  410.763584]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  410.763586] CR0: 80050033 CR2: 0249 CR3: 13edd000 CR4: 0690
[  410.763587] Stack:
[  410.763592]  3a20 3d01 000f df4a9d50   0010 
0040
[  410.763597]  0080 0246 df650ec0 dee42800 da86f470 0001 df7d2e80 
df7d2eb8
[  410.763601]  da86f400 dee42600 dee42800  da95f000 0004 0246 
dec31c00
[  410.763602] Call Trace:
[  410.763609]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  410.763614]  [] ? usb_probe_interface+0x17b/0x1f6
[  410.763616]  [] ? usb_probe_interface+0x17b/0x1f6
[  410.763620]  [] ? driver_probe_device+0x17b/0x30e
[  410.763622]  [] ? driver_probe_device+0x17b/0x30e
[  410.763625]  [] ? bus_for_each_drv+0x59/0x68
[  410.763627]  [] ? bus_for_each_drv+0x59/0x68
[  410.763629]  [] ? __device_attach+0x91/0x105
[  410.763631]  [] ? driver_allows_async_probing+0x2f/0x2f
[  410.763634]  [] ? bus_probe_device+0x27/0x6b
[  410.763636]  [] ? bus_probe_device+0x27/0x6b
[  410.763638]  [] ? device_add+0x289/0x4be
[  410.763641]  [] ? usb_set_configuration+0x5a6/0x5e9
[  410.763643]  [] ? usb_set_configuration+0x5a6/0x5e9
[  410.763647]  [] ? generic_probe+0x3b/0x67
[  410.763649]  [] ? generic_probe+0x3b/0x67
[  410.763652]  [] ? usb_probe_device+0x49/0x62
[  410.763654]  [] ? usb_suspend+0xcd/0xcd
[  410.763656]  [] ? driver_probe_device+0x17b/0x30e
[  410.763658]  [] ? driver_probe_device+0x17b/0x30e
[  410.763661]  [] ? bus_for_each_drv+0x59/0x68
[  410.763663]  [] ? bus_for_each_drv+0x59/0x68
[  410.763665]  [] ? __device_attach+0x91/0x105
[  410.763667]  [] ? driver_allows_async_probing+0x2f/0x2f
[  410.763670]  [] ? bus_probe_device+0x27/0x6b
[  410.763672]  [] ? bus_probe_device+0x27/0x6b
[  410.763674]  [] ? device_add+0x289/0x4be
[  410.763677]  [] ? add_device_randomness+0x84/0x9c
[  410.763680]  [] ? usb_new_device+0x29d/0x3b5
[  410.763681]  [] ? usb_new_device+0x29d/0x3b5
[  410.763684]  [] ? hub_event+0xb32/0xed8
[  410.763686]  [] ? hub_event+0xb32/0xed8
[  410.763689]  [] ? usb_remote_wakeup+0x6f/0x7d
[  410.763693]  [] ? process_one_work+0x174/0x2bc
[  410.763695]  [] ? process_one_work+0x174/0x2bc
[  410.763698]  [] ? worker_thread+0x22c/0x2f6
[  410.763700]  [] ? rescuer_thread+0x23f/0x23f
[  410.763703]  [] ? kthread+0xa4/0xa9
[  410.763706]  [] ? ret_from_kernel_thread+0xe/0x24
[  410.763708]  [] ? kthread_create_on_node+0x101/0x101
[  410.763734] 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 

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

[Wim Osterholt]

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

After some experimenting I succeeded in grabbing it over the serial port.
The console was immedately frozen, but the serial port kept working:

[  407.859834] sysrq: SysRq : Changing Loglevel
[  407.908433] sysrq: Loglevel set to 9
[  407.980538] usbcore: registered new interface driver cdc_acm
[  408.044439] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  410.480711] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  410.696717] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  410.700739] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  410.704738] usb 6-1: Product: USB Modem
[  410.708735] usb 6-1: Manufacturer: Conexant
[  410.708738] usb 6-1: SerialNumber: 12345678
[  410.763492] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  410.763515] BUG: unable to handle kernel NULL pointer dereference at 0249
[  410.763522] IP: [] acm_probe+0x4ee/0xc8c [cdc_acm]
[  410.763524] *pde =  
[  410.763526] Oops:  [#1] SMP
[  410.763562] Modules linked in: cdc_acm nouveau video drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart i2c_algo_bit 
cfg80211 rfkill binfmt_misc snd_pcm_oss snd_mixer_oss fbcon bitblit softcursor 
font tileblit sr9700 dm9601 usb_storage usbnet snd_hda_codec_generic mii 
snd_hda_intel snd_hda_codec tg3 snd_hwdep ptp snd_hda_core pps_core snd_pcm 
gpio_ich libphy firmware_class pcspkr ohci_pci lpc_ich ppdev snd_timer mfd_core 
ohci_hcd snd uhci_hcd wmi parport_pc floppy ehci_pci soundcore parport ehci_hcd 
acpi_cpufreq button processor
[  410.763565] CPU: 0 PID: 429 Comm: kworker/0:1 Not tainted 4.8.0-rc8 #1
[  410.763567] Hardware name: Hewlett-Packard HP xw4300 Workstation/0A00h, BIOS 
786D3 v01.08 03/10/2006
[  410.763572] Workqueue: usb_hub_wq hub_event
[  410.763574] task: df523f00 task.stack: dec3
[  410.763576] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[  410.763579] EIP is at acm_probe+0x4ee/0xc8c [cdc_acm]
[  410.763581] EAX: 0246 EBX: decff000 ECX: e08e1854 EDX: 
[  410.763582] ESI: 0100 EDI:  EBP: dec31c18 ESP: dec31b80
[  410.763584]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  410.763586] CR0: 80050033 CR2: 0249 CR3: 13edd000 CR4: 0690
[  410.763587] Stack:
[  410.763592]  3a20 3d01 000f df4a9d50   0010 
0040
[  410.763597]  0080 0246 df650ec0 dee42800 da86f470 0001 df7d2e80 
df7d2eb8
[  410.763601]  da86f400 dee42600 dee42800  da95f000 0004 0246 
dec31c00
[  410.763602] Call Trace:
[  410.763609]  [] ? __mutex_unlock_slowpath+0xf4/0xfc
[  410.763614]  [] ? usb_probe_interface+0x17b/0x1f6
[  410.763616]  [] ? usb_probe_interface+0x17b/0x1f6
[  410.763620]  [] ? driver_probe_device+0x17b/0x30e
[  410.763622]  [] ? driver_probe_device+0x17b/0x30e
[  410.763625]  [] ? bus_for_each_drv+0x59/0x68
[  410.763627]  [] ? bus_for_each_drv+0x59/0x68
[  410.763629]  [] ? __device_attach+0x91/0x105
[  410.763631]  [] ? driver_allows_async_probing+0x2f/0x2f
[  410.763634]  [] ? bus_probe_device+0x27/0x6b
[  410.763636]  [] ? bus_probe_device+0x27/0x6b
[  410.763638]  [] ? device_add+0x289/0x4be
[  410.763641]  [] ? usb_set_configuration+0x5a6/0x5e9
[  410.763643]  [] ? usb_set_configuration+0x5a6/0x5e9
[  410.763647]  [] ? generic_probe+0x3b/0x67
[  410.763649]  [] ? generic_probe+0x3b/0x67
[  410.763652]  [] ? usb_probe_device+0x49/0x62
[  410.763654]  [] ? usb_suspend+0xcd/0xcd
[  410.763656]  [] ? driver_probe_device+0x17b/0x30e
[  410.763658]  [] ? driver_probe_device+0x17b/0x30e
[  410.763661]  [] ? bus_for_each_drv+0x59/0x68
[  410.763663]  [] ? bus_for_each_drv+0x59/0x68
[  410.763665]  [] ? __device_attach+0x91/0x105
[  410.763667]  [] ? driver_allows_async_probing+0x2f/0x2f
[  410.763670]  [] ? bus_probe_device+0x27/0x6b
[  410.763672]  [] ? bus_probe_device+0x27/0x6b
[  410.763674]  [] ? device_add+0x289/0x4be
[  410.763677]  [] ? add_device_randomness+0x84/0x9c
[  410.763680]  [] ? usb_new_device+0x29d/0x3b5
[  410.763681]  [] ? usb_new_device+0x29d/0x3b5
[  410.763684]  [] ? hub_event+0xb32/0xed8
[  410.763686]  [] ? hub_event+0xb32/0xed8
[  410.763689]  [] ? usb_remote_wakeup+0x6f/0x7d
[  410.763693]  [] ? process_one_work+0x174/0x2bc
[  410.763695]  [] ? process_one_work+0x174/0x2bc
[  410.763698]  [] ? worker_thread+0x22c/0x2f6
[  410.763700]  [] ? rescuer_thread+0x23f/0x23f
[  410.763703]  [] ? kthread+0xa4/0xa9
[  410.763706]  [] ? ret_from_kernel_thread+0xe/0x24
[  410.763708]  [] ? kthread_create_on_node+0x101/0x101
[  410.763734] 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 

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

[Wim Osterholt]

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

That is not possible under a 4.8 kernel.

'Fixing recursive fault but reboot is needed!' and frozen it is.


Regards, Wim.

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

[Wim Osterholt]

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

That is not possible under a 4.8 kernel.

'Fixing recursive fault but reboot is needed!' and frozen it is.


Regards, Wim.

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

[Wim Osterholt]

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> OK. Strange. Please do
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

On kernel-4.7.4 this gives this little output:

[  135.279989] sysrq: SysRq : Changing Loglevel
[  135.280489] sysrq: Loglevel set to 9
[  146.712004] usbcore: registered new interface driver cdc_acm
[  146.712537] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  173.257346] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  173.450326] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  173.450879] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  173.451374] usb 6-1: Product: USB Modem
[  173.451867] usb 6-1: Manufacturer: Conexant
[  173.452360] usb 6-1: SerialNumber: 12345678
[  173.455415] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  173.455995] cdc_acm 6-1:1.0: ttyACM0: USB ACM device
[  173.562316] cdc_acm:acm_ctrl_msg: cdc_acm 6-1:1.0: acm_ctrl_msg - rq 0x20, 
val 0x0, len 0x7, result 7


4.8-rc7 is compiling now..


Regards, Wim.

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

[Wim Osterholt]

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> OK. Strange. Please do
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

On kernel-4.7.4 this gives this little output:

[  135.279989] sysrq: SysRq : Changing Loglevel
[  135.280489] sysrq: Loglevel set to 9
[  146.712004] usbcore: registered new interface driver cdc_acm
[  146.712537] cdc_acm: USB Abstract Control Model driver for USB modems and 
ISDN adapters
[  173.257346] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[  173.450326] usb 6-1: New USB device found, idVendor=0572, idProduct=1340
[  173.450879] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  173.451374] usb 6-1: Product: USB Modem
[  173.451867] usb 6-1: Manufacturer: Conexant
[  173.452360] usb 6-1: SerialNumber: 12345678
[  173.455415] cdc_acm:acm_probe: cdc_acm 6-1:1.0: interfaces are valid
[  173.455995] cdc_acm 6-1:1.0: ttyACM0: USB ACM device
[  173.562316] cdc_acm:acm_ctrl_msg: cdc_acm 6-1:1.0: acm_ctrl_msg - rq 0x20, 
val 0x0, len 0x7, result 7


4.8-rc7 is compiling now..


Regards, Wim.

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

[Wim Osterholt]

> >Please look up the bConfigurationValue for your device
> >in sysfs.

I didn't explicitly say that this was done under kernel-4.7.4, otherwise
it may have been impossible under 4.8 .

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> OK. Strange. Please do
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

You don't state if this must be done in a safe 4.7.4 or a crashable 4.8.
(if I get that far to retrieve dmesg to a file).

Anyway, echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
results in 'No such file or directory' because there is no 'dynamic_debug'.

The kernel option DYNAMIC_DEBUG was not set.
A new kernel is compiling now..



Groeten, Wim.

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

[Wim Osterholt]

> >Please look up the bConfigurationValue for your device
> >in sysfs.

I didn't explicitly say that this was done under kernel-4.7.4, otherwise
it may have been impossible under 4.8 .

On Thu, Sep 22, 2016 at 04:40:50PM +0200, Oliver Neukum wrote:
> 
> OK. Strange. Please do
> 
> dmesg -c
> echo 9 > /proc/sysrq-trigger
> modprobe cdc_acm
> echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
> 
> [plug your device in]
> 
> and provide the full output of dmesg after that.

You don't state if this must be done in a safe 4.7.4 or a crashable 4.8.
(if I get that far to retrieve dmesg to a file).

Anyway, echo "module cdc_acm +mpf" > /sys/kernel/debug/dynamic_debug/control
results in 'No such file or directory' because there is no 'dynamic_debug'.

The kernel option DYNAMIC_DEBUG was not set.
A new kernel is compiling now..



Groeten, Wim.

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

[Wim Osterholt]

On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> in sysfs.

Google pointed me to /sys/bus/usb/drivers/usb/*
where I find all kinds of 'bConfigurationValue'.
Now is the problem to find which one you could mean.

Under /sys/bus/usb/drivers/usb/7-1  I find
manufacturer  which reads 'Conexant'  and
bConfigurationValue  which reads '1'


Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> in sysfs.

Google pointed me to /sys/bus/usb/drivers/usb/*
where I find all kinds of 'bConfigurationValue'.
Now is the problem to find which one you could mean.

Under /sys/bus/usb/drivers/usb/7-1  I find
manufacturer  which reads 'Conexant'  and
bConfigurationValue  which reads '1'


Regards, Wim.

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

[Wim Osterholt]

On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> On Tue, 2016-09-20 at 17:45 +0200, Wim Osterholt wrote:
> 
> Anyway, which of its configurations is used?
> Please look up the bConfigurationValue for your device
> in sysfs.

And what might that be?
'locate sysfs' gives one hit at /etc/init.d/sysfs
When I say 'sysfs stop' it stops udev.
When I say 'sysfs start' it says nothing.
Again 'sysfs start' says sysfs already started.
That doesn't have changed anything.

There's a /sys/fs/ext4/* with nothing that you seem to mean.

There's a /proc/sys/fs with nothing that you seem to mean.

There's one mention of acm in /proc/tty/drivers and nowhere I see anything
that might be of any interest somehow.


Regards, Wim.


- w...@djo.tudelft.nl -

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

[Wim Osterholt]

On Wed, Sep 21, 2016 at 02:21:17PM +0200, Oliver Neukum wrote:
> On Tue, 2016-09-20 at 17:45 +0200, Wim Osterholt wrote:
> 
> Anyway, which of its configurations is used?
> Please look up the bConfigurationValue for your device
> in sysfs.

And what might that be?
'locate sysfs' gives one hit at /etc/init.d/sysfs
When I say 'sysfs stop' it stops udev.
When I say 'sysfs start' it says nothing.
Again 'sysfs start' says sysfs already started.
That doesn't have changed anything.

There's a /sys/fs/ext4/* with nothing that you seem to mean.

There's a /proc/sys/fs with nothing that you seem to mean.

There's one mention of acm in /proc/tty/drivers and nowhere I see anything
that might be of any interest somehow.


Regards, Wim.


- w...@djo.tudelft.nl -

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

[Wim Osterholt]

On Tue, Sep 20, 2016 at 03:05:14PM +0200, Oliver Neukum wrote:
> 
> I cannot replicate it. Could you please provide "lsusb -v"?
> 
>   Regards
>   Oliver

It concerns these type of modems:
http://www.ebay.nl/itm/191933738340
http://www.ebay.nl/itm/121590899044

lsusb:
Bus 002 Device 002: ID 0bda:0111 Realtek Semiconductor Corp. RTS5111 Card 
Reader Controller
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. 
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS 
Advent) DM9601 Fast Ethernet Adapter
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Since the output is quite lengthy, I've cut out everything but Bus 007 Device 
002
lsusb -v:

Bus 007 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0572 Conexant Systems (Rockwell), Inc.
  idProduct  0x1340 
  bcdDevice1.00
  iManufacturer   1 Conexant
  iProduct2 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
  bInterfaceNumber0
  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
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval 128
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  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:
bMasterInterface0
bSlaveInterface 1 
  Country Selection:
iCountryCodeRelDate4 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands 

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

[Wim Osterholt]

On Tue, Sep 20, 2016 at 03:05:14PM +0200, Oliver Neukum wrote:
> 
> I cannot replicate it. Could you please provide "lsusb -v"?
> 
>   Regards
>   Oliver

It concerns these type of modems:
http://www.ebay.nl/itm/191933738340
http://www.ebay.nl/itm/121590899044

lsusb:
Bus 002 Device 002: ID 0bda:0111 Realtek Semiconductor Corp. RTS5111 Card 
Reader Controller
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. 
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0fe6:9700 Kontron (Industrial Computer Source / ICS 
Advent) DM9601 Fast Ethernet Adapter
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Since the output is quite lengthy, I've cut out everything but Bus 007 Device 
002
lsusb -v:

Bus 007 Device 002: ID 0572:1340 Conexant Systems (Rockwell), Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass2 Communications
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0572 Conexant Systems (Rockwell), Inc.
  idProduct  0x1340 
  bcdDevice1.00
  iManufacturer   1 Conexant
  iProduct2 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
  bInterfaceNumber0
  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
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval 128
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 CDC Data
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  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:
bMasterInterface0
bSlaveInterface 1 
  Country Selection:
iCountryCodeRelDate4 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 2 Communications
  bInterfaceSubClass  2 Abstract (modem)
  bInterfaceProtocol  1 AT-commands 

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> 
> your stack trace is broken. Did you fail to install the System.map file?
> 
>   Regards
>   Oliver

A laptop, more broken than the rest, does not output anything after
inserting. Later on it crashes. No system.map file in /boot.
After booting with the dongle inserted it spits out:

[   17.204261] fbcon: radeondrmfb (fb0) is primary device
[   17.276234] BUG: unable to handle kernel NULL pointer dereference at 0007
[   17.276266] IP: [] acm_probe+0x450/0xed0 [cdc_acm]
[   17.276272] *pde =  
[   17.276278] Oops:  [#1] PREEMPT SMP
[   17.276362] Modules linked in: cdc_acm(+) radeon(+) fbcon i2c_algo_bit 
bitblit softcursor font drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm snd_intel8x0m snd_intel8x0 
pcmcia snd_ac97_codec drm dell_smm_hwmon hwmon ipw2200 fb uhci_hcd fbdev 
ehci_pci yenta_socket ehci_hcd ac97_bus snd_pcm dcdbas libipw usbcore 
pcmcia_rsrc pcmcia_core snd_timer lib80211 cfg80211 3c59x snd serio_raw 
intel_agp soundcore usb_common 8250_pci mii video intel_gtt agpgart 8250 
8250_base parport_pc parport serial_core
[   17.276371] CPU: 0 PID: 1311 Comm: udevd Not tainted 4.8.0-rc5 #1
[   17.276375] Hardware name: Dell Computer Corporation Inspiron 4100   
/Inspiron 4100, BIOS A13 05/16/2003
[   17.276379] task: cf9667c0 task.stack: cf10a000
[   17.276385] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[   17.276400] EIP is at acm_probe+0x450/0xed0 [cdc_acm]
[   17.276404] EAX: 0004 EBX: cbb62800 ECX: 0040 EDX: 0040
[   17.276409] ESI:  EDI:  EBP: cf10bd00 ESP: cf10bc60
[   17.276413]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   17.276418] CR0: 80050033 CR2: 0007 CR3: 0f07f000 CR4: 06d0
[   17.276420] Stack:
[   17.276435]   0082 0012  46dd cf29ac80 cf9e6238 
cf90cb84
[   17.276448]  cf801c08 0012 45c0 0080 cf9e6200 cf88d960 0010 
cc884470
[   17.276462]  cc884400 0001 cf194a00 cf193000 cf194a00 c14f00ff cc8844f8 
cf9667c0
[   17.276464] Call Trace:
[   17.276486]  [] ? _raw_spin_unlock_irqrestore+0xf/0x30
[   17.276498]  [] ? preempt_count_add+0x89/0x90
[   17.276505]  [] ? preempt_count_add+0x89/0x90
[   17.276512]  [] ? _raw_spin_lock_irqsave+0x11/0x40
[   17.276611]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276657]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276675]  [] ? driver_probe_device+0x1ff/0x400
[   17.276682]  [] ? driver_probe_device+0x1ff/0x400
[   17.276691]  [] ? __driver_attach+0xd9/0x100
[   17.276698]  [] ? __driver_attach+0xd9/0x100
[   17.276706]  [] ? _raw_spin_lock+0xd/0x30
[   17.276712]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276720]  [] ? driver_probe_device+0x400/0x400
[   17.276728]  [] ? bus_for_each_dev+0x47/0x80
[   17.276735]  [] ? bus_for_each_dev+0x47/0x80
[   17.276743]  [] ? driver_attach+0x11/0x20
[   17.276750]  [] ? driver_probe_device+0x400/0x400
[   17.276757]  [] ? bus_add_driver+0x1df/0x270
[   17.276764]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276777]  [] ? kset_find_obj+0x44/0x90
[   17.276785]  [] ? driver_register+0x4e/0xc0
[   17.276791]  [] ? driver_register+0x4e/0xc0
[   17.276837]  [] ? usb_register_driver+0x5a/0x110 [usbcore]
[   17.276852]  [] ? acm_init+0xa7/0xd6 [cdc_acm]
[   17.276857]  [] ? 0xd07f9000
[   17.276864]  [] ? do_one_initcall+0x2d/0x130
[   17.276880]  [] ? do_init_module+0x19/0x1a0
[   17.276889]  [] ? do_init_module+0x48/0x1a0
[   17.276900]  [] ? load_module+0x19c7/0x2150
[   17.276913]  [] ? kernel_read_file+0x103/0x200
[   17.276922]  [] ? SyS_finit_module+0x90/0xd0
[   17.276929]  [] ? SyS_finit_module+0x90/0xd0
[   17.276940]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276946]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276954]  [] ? entry_INT80_32+0x2a/0x2a
[   17.277046] Code: 04 89 b3 c0 04 00 00 8d 04 80 c1 e0 02 89 83 b4 04 00 00 
8b 45 a8 89 43 04 8b 45 ac 89 43 08 8b 45 a0 89 03 8b 45 c0 85 c0 74 0a <0f> b6 
40 03 89 83 c8 04 00 00 f6 45 a4 04 74 07 83 a3 c8 04 00
[   17.277065] EIP: [] acm_probe+0x450/0xed0 [cdc_acm] SS:ESP 
0068:cf10bc60
[   17.277068] CR2: 0007
[   17.277360] ---[ end trace 5847748dfb454f14 ]---
[   17.280317] udevd[1295]: worker [1311] terminated by signal 9 (Killed)
[   17.280333] udevd[1295]: worker [1311] failed while handling 
'/devices/pci:00/:00:1d.0/usb1/1-1/1-1:1.0'

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> 
> your stack trace is broken. Did you fail to install the System.map file?
> 
>   Regards
>   Oliver

A laptop, more broken than the rest, does not output anything after
inserting. Later on it crashes. No system.map file in /boot.
After booting with the dongle inserted it spits out:

[   17.204261] fbcon: radeondrmfb (fb0) is primary device
[   17.276234] BUG: unable to handle kernel NULL pointer dereference at 0007
[   17.276266] IP: [] acm_probe+0x450/0xed0 [cdc_acm]
[   17.276272] *pde =  
[   17.276278] Oops:  [#1] PREEMPT SMP
[   17.276362] Modules linked in: cdc_acm(+) radeon(+) fbcon i2c_algo_bit 
bitblit softcursor font drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm snd_intel8x0m snd_intel8x0 
pcmcia snd_ac97_codec drm dell_smm_hwmon hwmon ipw2200 fb uhci_hcd fbdev 
ehci_pci yenta_socket ehci_hcd ac97_bus snd_pcm dcdbas libipw usbcore 
pcmcia_rsrc pcmcia_core snd_timer lib80211 cfg80211 3c59x snd serio_raw 
intel_agp soundcore usb_common 8250_pci mii video intel_gtt agpgart 8250 
8250_base parport_pc parport serial_core
[   17.276371] CPU: 0 PID: 1311 Comm: udevd Not tainted 4.8.0-rc5 #1
[   17.276375] Hardware name: Dell Computer Corporation Inspiron 4100   
/Inspiron 4100, BIOS A13 05/16/2003
[   17.276379] task: cf9667c0 task.stack: cf10a000
[   17.276385] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[   17.276400] EIP is at acm_probe+0x450/0xed0 [cdc_acm]
[   17.276404] EAX: 0004 EBX: cbb62800 ECX: 0040 EDX: 0040
[   17.276409] ESI:  EDI:  EBP: cf10bd00 ESP: cf10bc60
[   17.276413]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   17.276418] CR0: 80050033 CR2: 0007 CR3: 0f07f000 CR4: 06d0
[   17.276420] Stack:
[   17.276435]   0082 0012  46dd cf29ac80 cf9e6238 
cf90cb84
[   17.276448]  cf801c08 0012 45c0 0080 cf9e6200 cf88d960 0010 
cc884470
[   17.276462]  cc884400 0001 cf194a00 cf193000 cf194a00 c14f00ff cc8844f8 
cf9667c0
[   17.276464] Call Trace:
[   17.276486]  [] ? _raw_spin_unlock_irqrestore+0xf/0x30
[   17.276498]  [] ? preempt_count_add+0x89/0x90
[   17.276505]  [] ? preempt_count_add+0x89/0x90
[   17.276512]  [] ? _raw_spin_lock_irqsave+0x11/0x40
[   17.276611]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276657]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276675]  [] ? driver_probe_device+0x1ff/0x400
[   17.276682]  [] ? driver_probe_device+0x1ff/0x400
[   17.276691]  [] ? __driver_attach+0xd9/0x100
[   17.276698]  [] ? __driver_attach+0xd9/0x100
[   17.276706]  [] ? _raw_spin_lock+0xd/0x30
[   17.276712]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276720]  [] ? driver_probe_device+0x400/0x400
[   17.276728]  [] ? bus_for_each_dev+0x47/0x80
[   17.276735]  [] ? bus_for_each_dev+0x47/0x80
[   17.276743]  [] ? driver_attach+0x11/0x20
[   17.276750]  [] ? driver_probe_device+0x400/0x400
[   17.276757]  [] ? bus_add_driver+0x1df/0x270
[   17.276764]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276777]  [] ? kset_find_obj+0x44/0x90
[   17.276785]  [] ? driver_register+0x4e/0xc0
[   17.276791]  [] ? driver_register+0x4e/0xc0
[   17.276837]  [] ? usb_register_driver+0x5a/0x110 [usbcore]
[   17.276852]  [] ? acm_init+0xa7/0xd6 [cdc_acm]
[   17.276857]  [] ? 0xd07f9000
[   17.276864]  [] ? do_one_initcall+0x2d/0x130
[   17.276880]  [] ? do_init_module+0x19/0x1a0
[   17.276889]  [] ? do_init_module+0x48/0x1a0
[   17.276900]  [] ? load_module+0x19c7/0x2150
[   17.276913]  [] ? kernel_read_file+0x103/0x200
[   17.276922]  [] ? SyS_finit_module+0x90/0xd0
[   17.276929]  [] ? SyS_finit_module+0x90/0xd0
[   17.276940]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276946]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276954]  [] ? entry_INT80_32+0x2a/0x2a
[   17.277046] Code: 04 89 b3 c0 04 00 00 8d 04 80 c1 e0 02 89 83 b4 04 00 00 
8b 45 a8 89 43 04 8b 45 ac 89 43 08 8b 45 a0 89 03 8b 45 c0 85 c0 74 0a <0f> b6 
40 03 89 83 c8 04 00 00 f6 45 a4 04 74 07 83 a3 c8 04 00
[   17.277065] EIP: [] acm_probe+0x450/0xed0 [cdc_acm] SS:ESP 
0068:cf10bc60
[   17.277068] CR2: 0007
[   17.277360] ---[ end trace 5847748dfb454f14 ]---
[   17.280317] udevd[1295]: worker [1311] terminated by signal 9 (Killed)
[   17.280333] udevd[1295]: worker [1311] failed while handling 
'/devices/pci:00/:00:1d.0/usb1/1-1/1-1:1.0'

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

[Wim Osterholt]

> your stack trace is broken. Did you fail to install the System.map file?
> 
>   Regards
>   Oliver

>Finally found something.
>CONFIG_DEBUG_INFO was not set.

Doesn't make any difference either.
Compiled cdc_acm in the kernel, not as a module. Doesn't make any
difference, except for that it says 'a reboot is necessairy' en then it
freezes. Still no symbols.

Google didn't tell me anything useful, nor did you.
This took me days already.
I told you all you need: plug in a modem that needs cdc_acm.


Wim.


- w...@djo.tudelft.nl -

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

[Wim Osterholt]

> your stack trace is broken. Did you fail to install the System.map file?
> 
>   Regards
>   Oliver

>Finally found something.
>CONFIG_DEBUG_INFO was not set.

Doesn't make any difference either.
Compiled cdc_acm in the kernel, not as a module. Doesn't make any
difference, except for that it says 'a reboot is necessairy' en then it
freezes. Still no symbols.

Google didn't tell me anything useful, nor did you.
This took me days already.
I told you all you need: plug in a modem that needs cdc_acm.


Wim.


- w...@djo.tudelft.nl -

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep  6 19:12:38 localhost kernel: Call Trace:
> > Sep  6 19:12:38 localhost kernel:  [] ? 0xc01f4347
> 
> Hi,
> 
> your stack trace is broken. Did you fail to install the System.map file?

Source is available under /usr/src/linux --> /usr/src/linux-4.8-rc5
System.map is available there, also as System.map-4.8-rc5.
System.map and System.map-4.8-rc5 is also available in /boot.
But the call trace still shows no symbols.
>From reading I understood that symbols from modules will not be available in
System.map. So what else  should I do?



[   46.133212] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[   46.334136] usb 4-1: New USB device found, idVendor=0572, idProduct=1340
[   46.334140] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   46.334142] usb 4-1: Product: USB Modem
[   46.334145] usb 4-1: Manufacturer: Conexant
[   46.334147] usb 4-1: SerialNumber: 12345678
[   46.388110] BUG: unable to handle kernel NULL pointer dereference at 0246
[   46.391243] IP: [] 0xe12d0a35
[   46.391243] *pde =  
[   46.391243] Oops:  [#1] SMP
[   46.391243] 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 lirc_serial(C) lirc_dev(O) binfmt_misc 
svgalib_helper(O) snd_pcm_oss snd_mixer_oss usbhid usb_storage ipw2200 
snd_intel8x0 snd_ac97_codec libipw lib80211 ac97_bus cfg80211 snd_pcm snd_timer 
rfkill firmware_class snd via_rhine ppdev soundcore pcspkr uhci_hcd mii 
ehci_pci ehci_hcd usbcore floppy parport_pc lpc_ich usb_common fan parport 
acpi_cpufreq thermal mfd_core processor button
[   46.391243] CPU: 1 PID: 1868 Comm: udevd Tainted: G C O4.8.0-rc5 
#1
[   46.391243] Hardware name: MEDIONPC MS-7048/MS-7048, BIOS 6.00 PG 02/12/2004
[   46.391243] task: df6adb00 task.stack: dc74
[   46.391243] EIP: 0060:[] EFLAGS: 00010202 CPU: 1
[   46.391243] EAX:  EBX: dec6f000 ECX:  EDX: 0124
[   46.391243] ESI: dec6f27c EDI: dc7a5800 EBP: 0246 ESP: dc741ce8
[   46.391243]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   46.391243] CR0: 80050033 CR2: 0246 CR3: 1c714000 CR4: 0690
[   46.391243] Stack:
[   46.391243]  df788000 df788000 df788400 dc7a5800 df4b5780 df4b57b8 0001 
dc7a5870
[   46.391243]  dc4409c0 df78801c 0040 0010  dec6f00c dec6f27c 

[   46.391243]  dc79e800  df6adb00 da4a5f30 c01f5243 0246 0246 
da4a5f30
[   46.391243] Call Trace:
[   46.391243]  [] ? 0xc01f5243
[   46.391243]  [] ? 0xc043c68a
[   46.391243]  [] ? 0xe09fc22f
[   46.391243]  [] ? 0xc03087a8
[   46.391243]  [] ? 0xc0308907
[   46.391243]  [] ? 0xc0307444
[   46.391243]  [] ? 0xc03083c3
[   46.391243]  [] ? 0xc03088b2
[   46.391243]  [] ? 0xc0308097
[   46.391243]  [] ? 0xc0308ebe
[   46.391243]  [] ? 0xe09fb525
[   46.391243]  [] ? 0xe12d30a9
[   46.391243]  [] ? 0xe12d3000
[   46.391243]  [] ? 0xc01003eb
[   46.391243]  [] ? 0xc043c68a
[   46.391243]  [] ? 0xc027d355
[   46.391243]  [] ? 0xc01af013
[   46.391243]  [] ? 0xc0184275
[   46.391243]  [] ? 0xc01842a4
[   46.391243]  [] ? 0xc017546b
[   46.391243]  [] ? 0xc01756c3
[   46.391243]  [] ? 0xc0100ed1
[   46.391243]  [] ? 0xc043dd25
[   46.391243] Code: 44 24 04 ba 20 1c 2d e1 89 58 74 83 c0 1c 89 44 24 24 e8 
35 4e 03 df 85 c0 0f 88 ed fe ff ff 8b 6c 24 54 85 ed 0f 84 91 00 00 00 <0f> b6 
45 00 ba c0 00 40 02 83 e8 04 e8 b4 e4 ed de 85 c0 89 83
[   46.391243] EIP: []  SS:ESP 0068:dc741ce8
[   46.391243] CR2: 0246
[   46.802809] ---[ end trace 3cd7f784cc67fa66 ]---
[   46.811156] udevd[884]: worker [1868] terminated by signal 9 (Killed)
[   46.811164] udevd[884]: worker [1868] failed while handling 
'/devices/pci:00/:00:1d.2/usb4/4-1/4-1:1.1'


Regards, Wim.
y

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep  6 19:12:38 localhost kernel: Call Trace:
> > Sep  6 19:12:38 localhost kernel:  [] ? 0xc01f4347
> 
> Hi,
> 
> your stack trace is broken. Did you fail to install the System.map file?

Source is available under /usr/src/linux --> /usr/src/linux-4.8-rc5
System.map is available there, also as System.map-4.8-rc5.
System.map and System.map-4.8-rc5 is also available in /boot.
But the call trace still shows no symbols.
>From reading I understood that symbols from modules will not be available in
System.map. So what else  should I do?



[   46.133212] usb 4-1: new full-speed USB device number 2 using uhci_hcd
[   46.334136] usb 4-1: New USB device found, idVendor=0572, idProduct=1340
[   46.334140] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   46.334142] usb 4-1: Product: USB Modem
[   46.334145] usb 4-1: Manufacturer: Conexant
[   46.334147] usb 4-1: SerialNumber: 12345678
[   46.388110] BUG: unable to handle kernel NULL pointer dereference at 0246
[   46.391243] IP: [] 0xe12d0a35
[   46.391243] *pde =  
[   46.391243] Oops:  [#1] SMP
[   46.391243] 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 lirc_serial(C) lirc_dev(O) binfmt_misc 
svgalib_helper(O) snd_pcm_oss snd_mixer_oss usbhid usb_storage ipw2200 
snd_intel8x0 snd_ac97_codec libipw lib80211 ac97_bus cfg80211 snd_pcm snd_timer 
rfkill firmware_class snd via_rhine ppdev soundcore pcspkr uhci_hcd mii 
ehci_pci ehci_hcd usbcore floppy parport_pc lpc_ich usb_common fan parport 
acpi_cpufreq thermal mfd_core processor button
[   46.391243] CPU: 1 PID: 1868 Comm: udevd Tainted: G C O4.8.0-rc5 
#1
[   46.391243] Hardware name: MEDIONPC MS-7048/MS-7048, BIOS 6.00 PG 02/12/2004
[   46.391243] task: df6adb00 task.stack: dc74
[   46.391243] EIP: 0060:[] EFLAGS: 00010202 CPU: 1
[   46.391243] EAX:  EBX: dec6f000 ECX:  EDX: 0124
[   46.391243] ESI: dec6f27c EDI: dc7a5800 EBP: 0246 ESP: dc741ce8
[   46.391243]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[   46.391243] CR0: 80050033 CR2: 0246 CR3: 1c714000 CR4: 0690
[   46.391243] Stack:
[   46.391243]  df788000 df788000 df788400 dc7a5800 df4b5780 df4b57b8 0001 
dc7a5870
[   46.391243]  dc4409c0 df78801c 0040 0010  dec6f00c dec6f27c 

[   46.391243]  dc79e800  df6adb00 da4a5f30 c01f5243 0246 0246 
da4a5f30
[   46.391243] Call Trace:
[   46.391243]  [] ? 0xc01f5243
[   46.391243]  [] ? 0xc043c68a
[   46.391243]  [] ? 0xe09fc22f
[   46.391243]  [] ? 0xc03087a8
[   46.391243]  [] ? 0xc0308907
[   46.391243]  [] ? 0xc0307444
[   46.391243]  [] ? 0xc03083c3
[   46.391243]  [] ? 0xc03088b2
[   46.391243]  [] ? 0xc0308097
[   46.391243]  [] ? 0xc0308ebe
[   46.391243]  [] ? 0xe09fb525
[   46.391243]  [] ? 0xe12d30a9
[   46.391243]  [] ? 0xe12d3000
[   46.391243]  [] ? 0xc01003eb
[   46.391243]  [] ? 0xc043c68a
[   46.391243]  [] ? 0xc027d355
[   46.391243]  [] ? 0xc01af013
[   46.391243]  [] ? 0xc0184275
[   46.391243]  [] ? 0xc01842a4
[   46.391243]  [] ? 0xc017546b
[   46.391243]  [] ? 0xc01756c3
[   46.391243]  [] ? 0xc0100ed1
[   46.391243]  [] ? 0xc043dd25
[   46.391243] Code: 44 24 04 ba 20 1c 2d e1 89 58 74 83 c0 1c 89 44 24 24 e8 
35 4e 03 df 85 c0 0f 88 ed fe ff ff 8b 6c 24 54 85 ed 0f 84 91 00 00 00 <0f> b6 
45 00 ba c0 00 40 02 83 e8 04 e8 b4 e4 ed de 85 c0 89 83
[   46.391243] EIP: []  SS:ESP 0068:dc741ce8
[   46.391243] CR2: 0246
[   46.802809] ---[ end trace 3cd7f784cc67fa66 ]---
[   46.811156] udevd[884]: worker [1868] terminated by signal 9 (Killed)
[   46.811164] udevd[884]: worker [1868] failed while handling 
'/devices/pci:00/:00:1d.2/usb4/4-1/4-1:1.1'


Regards, Wim.
y

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep  6 19:12:38 localhost kernel: Call Trace:
> > Sep  6 19:12:38 localhost kernel:  [] ? 0xc01f4347
> 
> Hi,
> 
> your stack trace is broken. Did you fail to install the System.map file?

Never needed that for anything the last 20 years or so.
I don't have the device at hand here, so new logs will be available
tomorrow.

Regards, Wim.

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> > Sep  6 19:12:38 localhost kernel: Call Trace:
> > Sep  6 19:12:38 localhost kernel:  [] ? 0xc01f4347
> 
> Hi,
> 
> your stack trace is broken. Did you fail to install the System.map file?

Never needed that for anything the last 20 years or so.
I don't have the device at hand here, so new logs will be available
tomorrow.

Regards, Wim.

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> > 
> > The oops tells things that I didn't all write down, but it says
> > null pointer dereference at 0246
> 
> That is the important part. I am sorry, but without the oops
> nobody can help you. Please capture it

Sep  6 19:12:37 localhost kernel: usb 7-1: new full-speed USB device number 2 
using uhci_hcd
Sep  6 19:12:37 localhost kernel: usb 7-1: New USB device found, idVendor=0572, 
idProduct=1340
Sep  6 19:12:37 localhost kernel: usb 7-1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
Sep  6 19:12:37 localhost kernel: usb 7-1: Product: USB Modem
Sep  6 19:12:37 localhost kernel: usb 7-1: Manufacturer: Conexant
Sep  6 19:12:37 localhost kernel: usb 7-1: SerialNumber: 12345678
Sep  6 19:12:38 localhost mtp-probe[13126]: checking bus 7, device 2: 
"/sys/devices/pci:00/:00:1d.3/usb7/7-1"
Sep  6 19:12:38 localhost mtp-probe[13126]: bus: 7, device: 2 was not an MTP 
device
Sep  6 19:12:38 localhost kernel: BUG: unable to handle kernel NULL pointer 
dereference at 0246
Sep  6 19:12:38 localhost kernel: IP: [] 0xe0a81a35
Sep  6 19:12:38 localhost kernel: *pde =  
Sep  6 19:12:38 localhost kernel: Oops:  [#1] SMP
Sep  6 19:12:38 localhost kernel: Modules linked in: cdc_acm(+) nouveau video 
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart 
i2c_algo_bit lirc_serial(C) lirc_dev(O) cfg80211 rfkill binfmt_misc 
svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon bitblit softcursor font 
tileblit sr9700 dm9601 usbnet usb_storage mii snd_hda_codec_generic tg3 
snd_hda_intel snd_hda_codec ptp snd_hwdep pps_core gpio_ich snd_hda_core libphy 
ppdev firmware_class uhci_hcd pcspkr snd_pcm ohci_pci ohci_hcd lpc_ich ehci_pci 
snd_timer ehci_hcd mfd_core snd usbcore floppy soundcore wmi parport_pc 
usb_common parport acpi_cpufreq processor button
Sep  6 19:12:38 localhost kernel: CPU: 0 PID: 13127 Comm: udevd Tainted: G  
   C O4.8.0-rc5 #1
Sep  6 19:12:38 localhost kernel: Hardware name: Hewlett-Packard HP xw4300 
Workstation/0A00h, BIOS 786D3 v01.08 03/10/2006
Sep  6 19:12:38 localhost kernel: task: df639c00 task.stack: df4d6000
Sep  6 19:12:38 localhost kernel: EIP: 0060:[] EFLAGS: 00010202 CPU: 0
Sep  6 19:12:38 localhost kernel: EAX:  EBX: def22000 ECX:  
EDX: 0124
Sep  6 19:12:38 localhost kernel: ESI: def2227c EDI: dee04000 EBP: 0246 
ESP: df4d7ce8
Sep  6 19:12:38 localhost kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Sep  6 19:12:38 localhost kernel: CR0: 80050033 CR2: 0246 CR3: 19b4d000 
CR4: 0690
Sep  6 19:12:38 localhost kernel: Stack:
Sep  6 19:12:38 localhost kernel:  dee8ba00 dee8ba00 dee8b400 dee04000 df4b6380 
df4b63b8 0001 dee04070
Sep  6 19:12:38 localhost kernel:  daca2ec0 dee8ba1c 0040 0010  
def2200c def2227c 
Sep  6 19:12:38 localhost kernel:  dee20800  df639c00 dcdc37e0 c01f4347 
0246 0246 dcdc37e0
Sep  6 19:12:38 localhost kernel: Call Trace:
Sep  6 19:12:38 localhost kernel:  [] ? 0xc01f4347
Sep  6 19:12:38 localhost kernel:  [] ? 0xc04357ca
Sep  6 19:12:38 localhost kernel:  [] ? 0xe0ac422f
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030276f
Sep  6 19:12:38 localhost kernel:  [] ? 0xc03028ce
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030140b
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030238a
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0302879
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030205e
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0302e85
Sep  6 19:12:38 localhost kernel:  [] ? 0xe0ac3525
Sep  6 19:12:38 localhost kernel:  [] ? 0xe08620a9
Sep  6 19:12:38 localhost kernel:  [] ? 0xe0862000
Sep  6 19:12:38 localhost kernel:  [] ? 0xc01003eb
Sep  6 19:12:38 localhost kernel:  [] ? 0xc04357ca
Sep  6 19:12:38 localhost kernel:  [] ? 0xc027c45c
Sep  6 19:12:38 localhost kernel:  [] ? 0xc01ae14a
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0183bf5
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0183c24
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0174deb
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0175043
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0100ed1
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0436e65
Sep  6 19:12:38 localhost kernel: Code: 44 24 04 ba 20 2c a8 e0 89 58 74 83 c0 
1c 89 44 24 24 e8 0f de 87 df 85 c0 0f 88 ed fe ff ff 8b 6c 24 54 85 ed 0f 84 
91 00 00 00 <0f> b6 45 00 ba c0 00 40 02 83 e8 04 e8 eb c5 72 df 85 c0 89 83
Sep  6 19:12:38 localhost kernel: EIP: []  SS:ESP 0068:df4d7ce8
Sep  6 19:12:38 localhost kernel: CR2: 0246
Sep  6 19:12:38 localhost kernel: ---[ end trace 64919c4014c0aa1d ]---
Sep  6 19:12:38 localhost kernel: udevd[919]: worker [13127] terminated by 
signal 9 (Killed)
Sep  6 19:12:38 localhost kernel: udevd[919]: worker [13127] failed while 
handling '/devices/pci:00/:00:1d.3/usb7/7-1/7-1:1.1'
Sep  6 19:12:38 localhost kernel: clocksource: timekeeping watchdog on CPU1: 
Marking clocksource 'tsc' as unstable because the skew is too 

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

[Wim Osterholt]

On Thu, Sep 08, 2016 at 02:20:38PM +0200, Oliver Neukum wrote:
> > 
> > The oops tells things that I didn't all write down, but it says
> > null pointer dereference at 0246
> 
> That is the important part. I am sorry, but without the oops
> nobody can help you. Please capture it

Sep  6 19:12:37 localhost kernel: usb 7-1: new full-speed USB device number 2 
using uhci_hcd
Sep  6 19:12:37 localhost kernel: usb 7-1: New USB device found, idVendor=0572, 
idProduct=1340
Sep  6 19:12:37 localhost kernel: usb 7-1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
Sep  6 19:12:37 localhost kernel: usb 7-1: Product: USB Modem
Sep  6 19:12:37 localhost kernel: usb 7-1: Manufacturer: Conexant
Sep  6 19:12:37 localhost kernel: usb 7-1: SerialNumber: 12345678
Sep  6 19:12:38 localhost mtp-probe[13126]: checking bus 7, device 2: 
"/sys/devices/pci:00/:00:1d.3/usb7/7-1"
Sep  6 19:12:38 localhost mtp-probe[13126]: bus: 7, device: 2 was not an MTP 
device
Sep  6 19:12:38 localhost kernel: BUG: unable to handle kernel NULL pointer 
dereference at 0246
Sep  6 19:12:38 localhost kernel: IP: [] 0xe0a81a35
Sep  6 19:12:38 localhost kernel: *pde =  
Sep  6 19:12:38 localhost kernel: Oops:  [#1] SMP
Sep  6 19:12:38 localhost kernel: Modules linked in: cdc_acm(+) nouveau video 
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm agpgart 
i2c_algo_bit lirc_serial(C) lirc_dev(O) cfg80211 rfkill binfmt_misc 
svgalib_helper(O) snd_pcm_oss snd_mixer_oss fbcon bitblit softcursor font 
tileblit sr9700 dm9601 usbnet usb_storage mii snd_hda_codec_generic tg3 
snd_hda_intel snd_hda_codec ptp snd_hwdep pps_core gpio_ich snd_hda_core libphy 
ppdev firmware_class uhci_hcd pcspkr snd_pcm ohci_pci ohci_hcd lpc_ich ehci_pci 
snd_timer ehci_hcd mfd_core snd usbcore floppy soundcore wmi parport_pc 
usb_common parport acpi_cpufreq processor button
Sep  6 19:12:38 localhost kernel: CPU: 0 PID: 13127 Comm: udevd Tainted: G  
   C O4.8.0-rc5 #1
Sep  6 19:12:38 localhost kernel: Hardware name: Hewlett-Packard HP xw4300 
Workstation/0A00h, BIOS 786D3 v01.08 03/10/2006
Sep  6 19:12:38 localhost kernel: task: df639c00 task.stack: df4d6000
Sep  6 19:12:38 localhost kernel: EIP: 0060:[] EFLAGS: 00010202 CPU: 0
Sep  6 19:12:38 localhost kernel: EAX:  EBX: def22000 ECX:  
EDX: 0124
Sep  6 19:12:38 localhost kernel: ESI: def2227c EDI: dee04000 EBP: 0246 
ESP: df4d7ce8
Sep  6 19:12:38 localhost kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Sep  6 19:12:38 localhost kernel: CR0: 80050033 CR2: 0246 CR3: 19b4d000 
CR4: 0690
Sep  6 19:12:38 localhost kernel: Stack:
Sep  6 19:12:38 localhost kernel:  dee8ba00 dee8ba00 dee8b400 dee04000 df4b6380 
df4b63b8 0001 dee04070
Sep  6 19:12:38 localhost kernel:  daca2ec0 dee8ba1c 0040 0010  
def2200c def2227c 
Sep  6 19:12:38 localhost kernel:  dee20800  df639c00 dcdc37e0 c01f4347 
0246 0246 dcdc37e0
Sep  6 19:12:38 localhost kernel: Call Trace:
Sep  6 19:12:38 localhost kernel:  [] ? 0xc01f4347
Sep  6 19:12:38 localhost kernel:  [] ? 0xc04357ca
Sep  6 19:12:38 localhost kernel:  [] ? 0xe0ac422f
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030276f
Sep  6 19:12:38 localhost kernel:  [] ? 0xc03028ce
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030140b
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030238a
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0302879
Sep  6 19:12:38 localhost kernel:  [] ? 0xc030205e
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0302e85
Sep  6 19:12:38 localhost kernel:  [] ? 0xe0ac3525
Sep  6 19:12:38 localhost kernel:  [] ? 0xe08620a9
Sep  6 19:12:38 localhost kernel:  [] ? 0xe0862000
Sep  6 19:12:38 localhost kernel:  [] ? 0xc01003eb
Sep  6 19:12:38 localhost kernel:  [] ? 0xc04357ca
Sep  6 19:12:38 localhost kernel:  [] ? 0xc027c45c
Sep  6 19:12:38 localhost kernel:  [] ? 0xc01ae14a
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0183bf5
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0183c24
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0174deb
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0175043
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0100ed1
Sep  6 19:12:38 localhost kernel:  [] ? 0xc0436e65
Sep  6 19:12:38 localhost kernel: Code: 44 24 04 ba 20 2c a8 e0 89 58 74 83 c0 
1c 89 44 24 24 e8 0f de 87 df 85 c0 0f 88 ed fe ff ff 8b 6c 24 54 85 ed 0f 84 
91 00 00 00 <0f> b6 45 00 ba c0 00 40 02 83 e8 04 e8 eb c5 72 df 85 c0 89 83
Sep  6 19:12:38 localhost kernel: EIP: []  SS:ESP 0068:df4d7ce8
Sep  6 19:12:38 localhost kernel: CR2: 0246
Sep  6 19:12:38 localhost kernel: ---[ end trace 64919c4014c0aa1d ]---
Sep  6 19:12:38 localhost kernel: udevd[919]: worker [13127] terminated by 
signal 9 (Killed)
Sep  6 19:12:38 localhost kernel: udevd[919]: worker [13127] failed while 
handling '/devices/pci:00/:00:1d.3/usb7/7-1/7-1:1.1'
Sep  6 19:12:38 localhost kernel: clocksource: timekeeping watchdog on CPU1: 
Marking clocksource 'tsc' as unstable because the skew is too 

crash by cdc_acm driver in kernels 4.8-rc1/5

[Wim Osterholt]

L.S.

up to vanilla kernel 4.7.3 I've seen no problems.
On two different dekstops running vanilla kernel-4.8 I can force a crash by
inserting an USB-modem that requires module cdc_acm.ko .
(Strangely enough that doesn't happen on my laptop.)

The moment that cdc_acm loads (manually or automatically - the hardware needs
to be present) a kernel oops occurs.
The system remains responsive for a while, but a reboot is necessairy.
If you try a neat shutdown, the system will hang forever after 'remounting fs
read-only'. You'll need a power-down.

The oops tells things that I didn't all write down, but it says
null pointer dereference at 0246
...
failed while handling devices/pci:00/:00:1d.3/usb7/7-1/7-1:1d  etc.
...
udevd .. is taking too long..

Could someone please explain and repair the magic that is happening here?

Thanks in advance, Wim Osterholt.


- w...@djo.tudelft.nl -

crash by cdc_acm driver in kernels 4.8-rc1/5

[Wim Osterholt]

L.S.

up to vanilla kernel 4.7.3 I've seen no problems.
On two different dekstops running vanilla kernel-4.8 I can force a crash by
inserting an USB-modem that requires module cdc_acm.ko .
(Strangely enough that doesn't happen on my laptop.)

The moment that cdc_acm loads (manually or automatically - the hardware needs
to be present) a kernel oops occurs.
The system remains responsive for a while, but a reboot is necessairy.
If you try a neat shutdown, the system will hang forever after 'remounting fs
read-only'. You'll need a power-down.

The oops tells things that I didn't all write down, but it says
null pointer dereference at 0246
...
failed while handling devices/pci:00/:00:1d.3/usb7/7-1/7-1:1d  etc.
...
udevd .. is taking too long..

Could someone please explain and repair the magic that is happening here?

Thanks in advance, Wim Osterholt.


- w...@djo.tudelft.nl -

Re: [PATCH RESEND] floppy: fix open(O_ACCMODE) for ioctl-only open

[Wim Osterholt]

On Thu, Jun 30, 2016 at 01:18:00PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina <jkos...@suse.cz>
> 
> Commit 09954bad4 ("floppy: refactor open() flags handling"), as a 
> side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that 
> this is being used setfdprm userspace for ioctl-only open().
> 
> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) 
> modes, while still keeping the original O_NDELAY bug fixed.
> 
> Cc: sta...@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt <w...@djo.tudelft.nl>
> Tested-by: Wim Osterholt <w...@djo.tudelft.nl>
> Signed-off-by: Jiri Kosina <jkos...@suse.cz>
> ---
> 
> Jens, this should preferably go into 4.7-rcX and to -stable as well.
> 

How come this patch is still not in the recent release of 4.7 ?



Regards, Wim.

Re: [PATCH RESEND] floppy: fix open(O_ACCMODE) for ioctl-only open

[Wim Osterholt]

On Thu, Jun 30, 2016 at 01:18:00PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina 
> 
> Commit 09954bad4 ("floppy: refactor open() flags handling"), as a 
> side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that 
> this is being used setfdprm userspace for ioctl-only open().
> 
> Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE) 
> modes, while still keeping the original O_NDELAY bug fixed.
> 
> Cc: sta...@vger.kernel.org # v4.5+
> Reported-by: Wim Osterholt 
> Tested-by: Wim Osterholt 
> Signed-off-by: Jiri Kosina 
> ---
> 
> Jens, this should preferably go into 4.7-rcX and to -stable as well.
> 

How come this patch is still not in the recent release of 4.7 ?



Regards, Wim.

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Wed, Jun 29, 2016 at 04:34:14AM -0400, Sinan Kaya wrote:
> > 
> 
> I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation
> 
> Can you test this and give me a tested-by?


Kernel-4.7-rc5 plus this patch works like a charm on my Inspiron 4100.
Dmesg output is quite similar to the one from kernel-4.6 .

Tested-by: Wim Osterholt. <w...@djo.tudelft.nl>

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Wed, Jun 29, 2016 at 04:34:14AM -0400, Sinan Kaya wrote:
> > 
> 
> I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation
> 
> Can you test this and give me a tested-by?


Kernel-4.7-rc5 plus this patch works like a charm on my Inspiron 4100.
Dmesg output is quite similar to the one from kernel-4.6 .

Tested-by: Wim Osterholt. 

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote:
> > However, an earlier try on my Inspiron 510m did not work.
> > I'll do a clean retry later today, just to make sure.
> 
> 
> Ok, let me know. I can post a clean patch series. I was trying to get 
> you something to test before posting the official version.

The 510m just finished compiling and now it works fine too.
Thanks.



Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Mon, Jun 27, 2016 at 04:22:18AM -0400, ok...@codeaurora.org wrote:
> > However, an earlier try on my Inspiron 510m did not work.
> > I'll do a clean retry later today, just to make sure.
> 
> 
> Ok, let me know. I can post a clean patch series. I was trying to get 
> you something to test before posting the official version.

The 510m just finished compiling and now it works fine too.
Thanks.



Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Sat, Jun 25, 2016 at 04:51:03AM -0400, ok...@codeaurora.org wrote:
> On 2016-06-24 21:39, Wim Osterholt wrote:
> 
> Please apply the patches on top of clean 4.7-rc4 tree and apply them in 
> order with
> 
> git am 0001...
> git am 0002...

It doesn't work that way.
Beginners problems with git.
Tried all kinds of things, including a new git clone to no avail.
Took a long time to discover that in the above example these were the names
of the 'attachments'.
It didn't work. Error 'could not find out the kind of patch' or some such.
Took much longer to find out that in that mail and in the saved attachments
there were lines beginning with '>From' that were the culprit.

Still not found out how to make patch work without errors.
Anyway, by doing it with more manual intervention om a stock kernel-4.7-rc4
on my (very slow) Inspiron 4100 it seems to work like before. Hooray.
However, an earlier try on my Inspiron 510m did not work.
I'll do a clean retry later today, just to make sure.

regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Sat, Jun 25, 2016 at 04:51:03AM -0400, ok...@codeaurora.org wrote:
> On 2016-06-24 21:39, Wim Osterholt wrote:
> 
> Please apply the patches on top of clean 4.7-rc4 tree and apply them in 
> order with
> 
> git am 0001...
> git am 0002...

It doesn't work that way.
Beginners problems with git.
Tried all kinds of things, including a new git clone to no avail.
Took a long time to discover that in the above example these were the names
of the 'attachments'.
It didn't work. Error 'could not find out the kind of patch' or some such.
Took much longer to find out that in that mail and in the saved attachments
there were lines beginning with '>From' that were the culprit.

Still not found out how to make patch work without errors.
Anyway, by doing it with more manual intervention om a stock kernel-4.7-rc4
on my (very slow) Inspiron 4100 it seems to work like before. Hooray.
However, an earlier try on my Inspiron 510m did not work.
I'll do a clean retry later today, just to make sure.

regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote:
> 
> Can you give it a try?

Whell, I tried to no avail.

Wether it is on 4.6 or 4.7, with or without your previous patch,
I keep getting rejected hunks.
For example, here the line to be deleted is nowhere to be found:

> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 714ba4d..c2f22c9 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq)
>   int penalty = 0;
>  
>   if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> + return acpi_isa_irq_penalty[irq];
>  
>   /*
>   * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict


Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote:
> 
> Can you give it a try?

Whell, I tried to no avail.

Wether it is on 4.6 or 4.7, with or without your previous patch,
I keep getting rejected hunks.
For example, here the line to be deleted is nowhere to be found:

> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 714ba4d..c2f22c9 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq)
>   int penalty = 0;
>  
>   if (irq < ACPI_MAX_ISA_IRQS)
> - penalty += acpi_isa_irq_penalty[irq];
> + return acpi_isa_irq_penalty[irq];
>  
>   /*
>   * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict


Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
> > 
> > Sure, let me get a patch for you.
> 
> Here it is

http://webserver.djo.tudelft.nl/dmesg460+printpatch2


> I am trying to find a system with similar characteristics for debug

All from the same laptop, Dell Inspiron 4100.
The same problem arises at a Dell Inspiron 510m.
I've not seen it on a workstation Dell XW4300.



Groeten, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote:
> > 
> > Sure, let me get a patch for you.
> 
> Here it is

http://webserver.djo.tudelft.nl/dmesg460+printpatch2


> I am trying to find a system with similar characteristics for debug

All from the same laptop, Dell Inspiron 4100.
The same problem arises at a Dell Inspiron 510m.
I've not seen it on a workstation Dell XW4300.



Groeten, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> On 2016-06-21 18:13, Wim Osterholt wrote:
> >> 
> >>pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> >>penalty);
> >> 
> > 
> > This produced some 60 lines extra
> 
> Thanks, let's go back to 4.6 and add a very similar printf to every 
> single place where the array is modified and also right before the 
> enabled message.
> 

I don't get this right.
Assuming that you're still talking about the same file, I find a few
instances of 'enabled', most of them in if-statements and one where it might
be set, so it looks. However, that's already in a printk statement.
I don't know about arrays and even less where these are set. Even worse, I
don't know what to put in a 'similar' line if you don't mean 'exactly the
same'.
So please state file and line numbers and the line to be inserted.



Groeten, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Wed, Jun 22, 2016 at 11:54:39PM -0400, ok...@codeaurora.org wrote:
> On 2016-06-21 18:13, Wim Osterholt wrote:
> >> 
> >>pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
> >>penalty);
> >> 
> > 
> > This produced some 60 lines extra
> 
> Thanks, let's go back to 4.6 and add a very similar printf to every 
> single place where the array is modified and also right before the 
> enabled message.
> 

I don't get this right.
Assuming that you're still talking about the same file, I find a few
instances of 'enabled', most of them in if-statements and one where it might
be set, so it looks. However, that's already in a printk statement.
I don't know about arrays and even less where these are set. Even worse, I
don't know what to put in a 'similar' line if you don't mean 'exactly the
same'.
So please state file and line numbers and the line to be inserted.



Groeten, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote:
> 
> Thanks, It was a guess with no proof.
> 
> Let's undo the change above and start adding some print statements to collect
> data from your system.
> 
> Can you add this to the end of acpi_irq_get_penalty function and then send
> the output?
> 
>   pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
>   penalty);
>  

This produced some 60 lines extra. Too much to include here.
The entire dmesg file is here:
http://webserver.djo.tudelft.nl/dmesg474+printpenalty


Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote:
> 
> Thanks, It was a guess with no proof.
> 
> Let's undo the change above and start adding some print statements to collect
> data from your system.
> 
> Can you add this to the end of acpi_irq_get_penalty function and then send
> the output?
> 
>   pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq,
>   penalty);
>  

This produced some 60 lines extra. Too much to include here.
The entire dmesg file is here:
http://webserver.djo.tudelft.nl/dmesg474+printpenalty


Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

> Can you try the following and see if it makes any difference?
> 
> 
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
> int penalty = 0;
> 
> if (irq < ACPI_MAX_ISA_IRQS)
> -   penalty += acpi_isa_irq_penalty[irq];
> +   return acpi_isa_irq_penalty[irq];
> 
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link 
> *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> +   if (irq < ACPI_MAX_ISA_IRQS)
> +   acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) 
> +
> +   
> PIRQ_PENALTY_PCI_USING;
> +
> 
> 
> 
> > Bjorn


I tried this on kernel 4.7.0-rc4, but that didn't help. It still tried to
grab irq7.


Regards, Wim.


- w...@djo.tudelft.nl -

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

> Can you try the following and see if it makes any difference?
> 
> 
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq)
> int penalty = 0;
> 
> if (irq < ACPI_MAX_ISA_IRQS)
> -   penalty += acpi_isa_irq_penalty[irq];
> +   return acpi_isa_irq_penalty[irq];
> 
> /*
> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link 
> *link)
> acpi_device_bid(link->device));
> return -ENODEV;
> } else {
> +   if (irq < ACPI_MAX_ISA_IRQS)
> +   acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) 
> +
> +   
> PIRQ_PENALTY_PCI_USING;
> +
> 
> 
> 
> > Bjorn


I tried this on kernel 4.7.0-rc4, but that didn't help. It still tried to
grab irq7.


Regards, Wim.


- w...@djo.tudelft.nl -

kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

L.S.
up to vanilla kernel-4.6.2 sound was working fine.
Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc.
There appears to be a bug in the Intel sound driver and/or ACPI driver.
Dmesg shows interesting lines like:
[   11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
[   11.498605] PCI: setting IRQ 7 as level-triggered
[   11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[   12.757735] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0m) vs. 
 (parport0)
[   12.757751] snd_intel8x0m :00:1f.6: unable to grab IRQ 7
[   12.757875] snd_intel8x0m: probe of :00:1f.6 failed with error -16
[   12.900171] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0) vs. 
 (parport0)
[   12.900189] snd_intel8x0 :00:1f.5: unable to grab IRQ 7
[   12.900389] snd_intel8x0: probe of :00:1f.5 failed with error -16
[   12.922554] genirq: Flags mismatch irq 7. 0080 (ipw2200) vs.  
(parport0)
[   12.922559] ipw2200: Error allocating IRQ 7

If I boot kernel-4.7.0-rc3 with acpi=off  then sound is back!

If you need the full dmesg outputs then please get them here:
http://webserver.djo.tudelft.nl/dmesg460+ACPI
http://webserver.djo.tudelft.nl/dmesg473+ACPI
http://webserver.djo.tudelft.nl/dmesg473noACPI
(with excuses for the silly hostname which is out of our control)

Regards, Wim.


- w...@djo.tudelft.nl -

kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

L.S.
up to vanilla kernel-4.6.2 sound was working fine.
Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc.
There appears to be a bug in the Intel sound driver and/or ACPI driver.
Dmesg shows interesting lines like:
[   11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7
[   11.498605] PCI: setting IRQ 7 as level-triggered
[   11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[   12.757735] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0m) vs. 
 (parport0)
[   12.757751] snd_intel8x0m :00:1f.6: unable to grab IRQ 7
[   12.757875] snd_intel8x0m: probe of :00:1f.6 failed with error -16
[   12.900171] genirq: Flags mismatch irq 7. 0080 (snd_intel8x0) vs. 
 (parport0)
[   12.900189] snd_intel8x0 :00:1f.5: unable to grab IRQ 7
[   12.900389] snd_intel8x0: probe of :00:1f.5 failed with error -16
[   12.922554] genirq: Flags mismatch irq 7. 0080 (ipw2200) vs.  
(parport0)
[   12.922559] ipw2200: Error allocating IRQ 7

If I boot kernel-4.7.0-rc3 with acpi=off  then sound is back!

If you need the full dmesg outputs then please get them here:
http://webserver.djo.tudelft.nl/dmesg460+ACPI
http://webserver.djo.tudelft.nl/dmesg473+ACPI
http://webserver.djo.tudelft.nl/dmesg473noACPI
(with excuses for the silly hostname which is out of our control)

Regards, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On my first message I stated:

 It looks to me that the code in floppy.c is quite old; no changes here.
 So the bug is elsewhere in the kernel.
 
That was because the changelog at the beginning of floppy.c ended in 2003.
Wouln't it be wise to keep these items updated?

Groeten, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On my first message I stated:

 It looks to me that the code in floppy.c is quite old; no changes here.
 So the bug is elsewhere in the kernel.
 
That was because the changelog at the beginning of floppy.c ended in 2003.
Wouln't it be wise to keep these items updated?

Groeten, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Wed, Jun 15, 2016 at 04:13:53PM +0200, Jiri Kosina wrote:
> 
> Wim, could you please test whether the patch below, applied on top of 
> vanilla kernel (i.e. drop the revert), everything you are using still 
> works as expected?
> 

Applied on kernel-4.7-rc3 it looks like it's working. (Strace setfdprm looks
good.) That is on a remote machine. An actual test on floppies must wait
until tomorrow when I get there.

Regards, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Wed, Jun 15, 2016 at 04:13:53PM +0200, Jiri Kosina wrote:
> 
> Wim, could you please test whether the patch below, applied on top of 
> vanilla kernel (i.e. drop the revert), everything you are using still 
> works as expected?
> 

Applied on kernel-4.7-rc3 it looks like it's working. (Strace setfdprm looks
good.) That is on a remote machine. An actual test on floppies must wait
until tomorrow when I get there.

Regards, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Wed, Jun 15, 2016 at 09:09:13AM +0200, Jiri Kosina wrote:
> > Surprising or not, the thusly compiled kernel ran fine and I could 
> > handle floppies like before! (open(/dev/fd0,O_ACCMODE) succeeds.)
> 
> Thanks for testing.
> 
> Now next question -- what do you actually want to achieve with passing 
> O_ACCMODE to open()?
> 
> O_ACCMODE should primarily be used as a mask to use when extracting access 
> mode bits from fcntl(F_GETFL) call.

It happens in setfdprm from fdutils. What they wanted to achieve with it
I don't know. Setting parameters or some such.
Problem is that fdutils is probably unmaintained for ten years or so.

Regards, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Wed, Jun 15, 2016 at 09:09:13AM +0200, Jiri Kosina wrote:
> > Surprising or not, the thusly compiled kernel ran fine and I could 
> > handle floppies like before! (open(/dev/fd0,O_ACCMODE) succeeds.)
> 
> Thanks for testing.
> 
> Now next question -- what do you actually want to achieve with passing 
> O_ACCMODE to open()?
> 
> O_ACCMODE should primarily be used as a mask to use when extracting access 
> mode bits from fcntl(F_GETFL) call.

It happens in setfdprm from fdutils. What they wanted to achieve with it
I don't know. Setting parameters or some such.
Problem is that fdutils is probably unmaintained for ten years or so.

Regards, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Mon, Jun 13, 2016 at 02:15:15PM +0200, Jiri Kosina wrote:
> > up to vanilla kernel 4.4.13 floppy functionality performs like it should.
> > (On an x86 PC that is. With a 1.44MB diskette drive.)
> > >From kernel 4.5* and up it changed to barely usable.
> > 
> > After a virgin start (cold or warm boot) with an empty diskette drive and
> > then loaded with a standard 720K diskette you may run 'mdir' (from mtools)
> > and it shows the directory fine.
> > The first time you load a standard 1.44MB diskette (wether it is a virgin
> > start or after a 720K disktette) and you run mdir, it says literally:
> > 
> >  plain_io: Input/output error
> >  init A: could not read boot sector
> >  Cannot initialize 'A:'
> > 
> > After this, all subsequent runs of mdir will do fine on both floppies.
> > However, most of my floppies are in a different format. (1.6MB)
> > I rely on 'setfdprm' (from fdutils) to set the correct parameters.
> > 
> > setfdprm /dev/fd0 1600/1440
> > /dev/fd0: Invalid argument
> > 
> > Strace shows me:
> > ...
> > open(/dev/fd0, O_ACCMODE) = -1
> > 
> > So this actually means that 'invalid argument' refers to O_ACCMODE.
> 
> Hmm, could you please test with 09954bad448 reverted? (although I don't 
> really have a good explanation currently how it'd be causing what you are 
> observing).
> 
> Thanks,
> 
> -- 
> Jiri Kosina

Hmm. Now I need a crash course git.
After reading at www.kernel.org/pub/software/scm/git/docs/user-manual.html
I now tried:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git checkout -b new v4.5  (assuming that the first 'wrong' kernel would be best)
git revert 09954bad448(that did something, which I assume te be good)
copied the .config file from 4.5 I had lying around  and ran make.

Surprising or not, the thusly compiled kernel ran fine and I could handle
floppies like before!
(open(/dev/fd0,O_ACCMODE) succeeds.)


Regards, Wim.


- w...@djo.tudelft.nl -

Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Mon, Jun 13, 2016 at 02:15:15PM +0200, Jiri Kosina wrote:
> > up to vanilla kernel 4.4.13 floppy functionality performs like it should.
> > (On an x86 PC that is. With a 1.44MB diskette drive.)
> > >From kernel 4.5* and up it changed to barely usable.
> > 
> > After a virgin start (cold or warm boot) with an empty diskette drive and
> > then loaded with a standard 720K diskette you may run 'mdir' (from mtools)
> > and it shows the directory fine.
> > The first time you load a standard 1.44MB diskette (wether it is a virgin
> > start or after a 720K disktette) and you run mdir, it says literally:
> > 
> >  plain_io: Input/output error
> >  init A: could not read boot sector
> >  Cannot initialize 'A:'
> > 
> > After this, all subsequent runs of mdir will do fine on both floppies.
> > However, most of my floppies are in a different format. (1.6MB)
> > I rely on 'setfdprm' (from fdutils) to set the correct parameters.
> > 
> > setfdprm /dev/fd0 1600/1440
> > /dev/fd0: Invalid argument
> > 
> > Strace shows me:
> > ...
> > open(/dev/fd0, O_ACCMODE) = -1
> > 
> > So this actually means that 'invalid argument' refers to O_ACCMODE.
> 
> Hmm, could you please test with 09954bad448 reverted? (although I don't 
> really have a good explanation currently how it'd be causing what you are 
> observing).
> 
> Thanks,
> 
> -- 
> Jiri Kosina

Hmm. Now I need a crash course git.
After reading at www.kernel.org/pub/software/scm/git/docs/user-manual.html
I now tried:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git checkout -b new v4.5  (assuming that the first 'wrong' kernel would be best)
git revert 09954bad448(that did something, which I assume te be good)
copied the .config file from 4.5 I had lying around  and ran make.

Surprising or not, the thusly compiled kernel ran fine and I could handle
floppies like before!
(open(/dev/fd0,O_ACCMODE) succeeds.)


Regards, Wim.


- w...@djo.tudelft.nl -

Re: VFS regression ? Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Sat, Jun 11, 2016 at 02:15:01PM +0100, One Thousand Gnomes wrote:

> > open(/dev/fd0, O_ACCMODE) = -1

> If you do 
> 
> touch foo
> 
> then compile and run the following program does it error on the newer
> kernel ?
> 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
>   if (open("foo", 3) == -1)
> perror("foo");
>   return 0;
> }

No errors get printed for kernel 4.4 to 4.7 .

Regards, Wim.


- w...@djo.tudelft.nl -

Re: VFS regression ? Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

On Sat, Jun 11, 2016 at 02:15:01PM +0100, One Thousand Gnomes wrote:

> > open(/dev/fd0, O_ACCMODE) = -1

> If you do 
> 
> touch foo
> 
> then compile and run the following program does it error on the newer
> kernel ?
> 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
>   if (open("foo", 3) == -1)
> perror("foo");
>   return 0;
> }

No errors get printed for kernel 4.4 to 4.7 .

Regards, Wim.


- w...@djo.tudelft.nl -

disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

L.S.

up to vanilla kernel 4.4.13 floppy functionality performs like it should.
(On an x86 PC that is. With a 1.44MB diskette drive.)
>From kernel 4.5* and up it changed to barely usable.

After a virgin start (cold or warm boot) with an empty diskette drive and
then loaded with a standard 720K diskette you may run 'mdir' (from mtools)
and it shows the directory fine.
The first time you load a standard 1.44MB diskette (wether it is a virgin
start or after a 720K disktette) and you run mdir, it says literally:

 plain_io: Input/output error
 init A: could not read boot sector
 Cannot initialize 'A:'

After this, all subsequent runs of mdir will do fine on both floppies.
However, most of my floppies are in a different format. (1.6MB)
I rely on 'setfdprm' (from fdutils) to set the correct parameters.

setfdprm /dev/fd0 1600/1440
/dev/fd0: Invalid argument

Strace shows me:
...
open(/dev/fd0, O_ACCMODE) = -1

So this actually means that 'invalid argument' refers to O_ACCMODE.

At all kernels I see no changed rights in:
ls -al /dev/fd0
 brw-rw 1 root disk 2, 0 May 13 16:43 /dev/fd0

It looks to me that the code in floppy.c is quite old; no changes here.
So the bug is elsewhere in the kernel.

Could someone please explain and repair the magic that is happening here?

Thanks in advance, Wim Osterholt.


- w...@djo.tudelft.nl -

disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

[Wim Osterholt]

L.S.

up to vanilla kernel 4.4.13 floppy functionality performs like it should.
(On an x86 PC that is. With a 1.44MB diskette drive.)
>From kernel 4.5* and up it changed to barely usable.

After a virgin start (cold or warm boot) with an empty diskette drive and
then loaded with a standard 720K diskette you may run 'mdir' (from mtools)
and it shows the directory fine.
The first time you load a standard 1.44MB diskette (wether it is a virgin
start or after a 720K disktette) and you run mdir, it says literally:

 plain_io: Input/output error
 init A: could not read boot sector
 Cannot initialize 'A:'

After this, all subsequent runs of mdir will do fine on both floppies.
However, most of my floppies are in a different format. (1.6MB)
I rely on 'setfdprm' (from fdutils) to set the correct parameters.

setfdprm /dev/fd0 1600/1440
/dev/fd0: Invalid argument

Strace shows me:
...
open(/dev/fd0, O_ACCMODE) = -1

So this actually means that 'invalid argument' refers to O_ACCMODE.

At all kernels I see no changed rights in:
ls -al /dev/fd0
 brw-rw 1 root disk 2, 0 May 13 16:43 /dev/fd0

It looks to me that the code in floppy.c is quite old; no changes here.
So the bug is elsewhere in the kernel.

Could someone please explain and repair the magic that is happening here?

Thanks in advance, Wim Osterholt.


- w...@djo.tudelft.nl -