USB serial device trying to register wrong tty device after usb_reset_device
amruth
amruth_pv at yahoo.com
Sun Jul 27 19:37:25 UTC 2008
Hi
All
> I connected 2 serial devices based on TI 3410 chipset,
> which downloads firmware and the system resets using
> usb_reset_device. The problem is after the adding the second
> device, the system downloads firmware, usb_reset_device is
> called similar to first one, but now the USB reenumerates.
> Does the first device which has been allocated ttyUSB0
> disappear. I have seen that the first device ttyUSB0 does
> not disappear.
> The system is trying to re register the 2nd device with
> ttyUSB0 which is not correct.Why does the kernel detect that
> ttyUSB0 is already claimed by 1st device. The code snippet
> from usb-serial.c is below.
>
> if (get_free_serial (serial, num_ports, &minor) ==
> NULL) {
> dev_err(&interface->dev, "No
> more free serial devices\n");
> goto probe_error;
> }
> serial->minor = minor;
>
> Why does not get_free_serial return 1 instead of 0 because
> 0 is climed by 1st device.
>
> snprintf (&port->dev.bus_id[0],
> sizeof(port->dev.bus_id), "ttyUSB%d",
> port->number);
> dbg ("%s - registering %s",
> __FUNCTION__, port->dev.bus_id);
> retval =
> device_register(&port->dev);
> if (retval)
> dev_err(&port->dev,
> "Error registering port device, "
>
> "continuing\n");
>
>
>
> Is there any workaround to find that the 1st device is
> already claimed, so that register try to register with 2nd
> device and create ttyUSB1.
> Please let me know if anybody encountered this issue.
> Thanks
> Amruth p.v
>
>
> --- On Sat, 7/26/08, amruth <amruth_pv at yahoo.com>
> wrote:
>
> > From: amruth <amruth_pv at yahoo.com>
> > Subject: 2.6.26 kernel crashes after hotplugging 2nd
> device of same type
> > To: linux-usb at vger.kernel.org
> > Date: Saturday, July 26, 2008, 1:23 AM
> > Hi
> > All
> > The system crashes after connecting multiple serial
> devices
> > based on ti usb 3410 chipset of same type.
> >
> > The detailed log is below. The kernel is 2.6.26.
> >
> > Please suggest any ideas what is going on.Do we have
> any
> > workaround for this issue.
> >
> > Do the kernel allow multiple devie to register.
> >
> > If the first device was assigned ttyUSB0, then why
> does the
> > 2nd device try to register with same ttyUSB0. How does
> > ttyUSB ids assigned in the kernel.
> >
> >
> > usb 2-2: reset full speed USB device using uhci_hcd
> and
> > address 5
> > usb 2-2: device firmware changed
> > usb 2-2: USB disconnect, address 5
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > ti_shutdown
> > ti_usb_3410_5052 2-2:1.0: device disconnected
> > usb 2-2: new full speed USB device using uhci_hcd and
> > address 6
> > usb 2-2: configuration #1 chosen from 2 choices
> > ti_usb_3410_5052 2-2:1.0: TI USB 3410 1 port adapter
> > converter detected
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > ti_startup - product 0x 8, num configurations 2,
> > configuration value 1
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > ti_startup - device type is 3410
> > ti_usb_3410_5052: probe of 2-2:1.0 failed with error
> -5
> > ti_usb_3410_5052 2-2:2.0: TI USB 3410 1 port adapter
> > converter detected
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > ti_startup - product 0x 8, num configurations 2,
> > configuration value 2
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > ti_startup - device type is 3410
> > usb-serial ttyUSB0: Error registering port device,
> > continuing
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > ti_shutdown
> > BUG: unable to handle kernel NULL pointer dereference
> at
> > 00000018
> > IP: [<c04a2215>] sysfs_find_dirent+0x4/0x23
> > *pde = 0e975067 *pte = 00000000
> > Oops: 0000 [#1] SMP
> > Modules linked in: ti_usb_3410_5052 usbserial autofs4
> hidp
> > rfcomm l2cap bluetooth sunrpc iptable_filter ip_tables
> > ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables
> x_tables
> > dm_multipath sbs sbshc battery ac ipv6 parport_pc lp
> parport
> > dcdbas floppy snd_intel8x0 snd_ac97_codec ac97_bus
> > snd_seq_dummy ide_cd_mod cdrom snd_seq_oss
> > snd_seq_midi_event button snd_seq e1000 snd_seq_device
> > snd_pcm_oss snd_mixer_oss snd_pcm serio_raw rtc_cmos
> > rtc_core i2c_i801 snd_timer rtc_lib i2c_core snd
> edac_core
> > pcspkr soundcore snd_page_alloc dm_snapshot dm_zero
> > dm_mirror dm_log dm_mod ata_piix libata sd_mod
> scsi_mod ext3
> > jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded:
> microcode]
> >
> > Pid: 4035, comm: sh Not tainted (2.6.26 #1)
> > EIP: 0060:[<c04a2215>] EFLAGS: 00010246 CPU: 0
> > EIP is at sysfs_find_dirent+0x4/0x23
> > EAX: 00000000 EBX: c067ea13 ECX: df801080 EDX:
> c067ea13
> > ESI: c067ea13 EDI: c06ec794 EBP: ce8dc6fc ESP:
> cebafe30
> > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > Process sh (pid: 4035, ti=cebaf000 task=df1dedc0
> > task.ti=cebaf000)
> > Stack: c067ea13 00000000 c04a2b01 ce8dc684 00000000
> > c04a32ce ce8dc684 00000001
> > ce896c1c d0c88438 c054ca37 ce8dc684 c0548e33
> > ce8dc684 00000001 00000000
> > c0548f3f d0c88400 e0af9907 d0c88434 e0af9862
> > 00000001 c04ddc02 d0c88434
> > Call Trace:
> > [<c04a2b01>] sysfs_get_dirent+0x19/0x45
> > [<c04a32ce>] sysfs_remove_group+0x18/0x96
> > [<c054ca37>] device_pm_remove+0x14/0x3c
> > [<c0548e33>] device_del+0xd/0x111
> > [<c0548f3f>] device_unregister+0x8/0x10
> > [<e0af9907>] destroy_serial+0xa5/0xeb
> [usbserial]
> > [<e0af9862>] destroy_serial+0x0/0xeb [usbserial]
> > [<c04ddc02>] kref_put+0x36/0x40
> > [<e0af9796>] usb_serial_put+0x1c/0x27
> [usbserial]
> > [<e0af9bea>] usb_serial_disconnect+0x83/0xa8
> > [usbserial]
> > [<c056e321>] usb_unbind_interface+0x2d/0x5f
> > [<c054a699>] __device_release_driver+0x58/0x76
> > [<c054a6cf>] device_release_driver+0x18/0x21
> > [<c0549de2>] bus_remove_device+0x6b/0x7b
> > [<c0548ee6>] device_del+0xc0/0x111
> > [<c056c3f7>] usb_disable_device+0x55/0xbb
> > [<c056cddf>] usb_set_configuration+0x1bd/0x414
> > [<c04e0505>] sscanf+0x17/0x19
> > [<c056fbfd>] set_bConfigurationValue+0x44/0x62
> > [<c056fbb9>] set_bConfigurationValue+0x0/0x62
> > [<c054856a>] dev_attr_store+0x19/0x1d
> > [<c04a1b50>] sysfs_write_file+0xa4/0xd8
> > [<c04a1aac>] sysfs_write_file+0x0/0xd8
> > [<c0469cbd>] vfs_write+0x83/0xf6
> > [<c046a20f>] sys_write+0x3c/0x63
> > [<c040389a>] syscall_call+0x7/0xb
> > [<c0610000>] migration_call+0x314/0x3b6
> > =======================
> > Code: 40 08 83 79 0c 00 8d 58 18 74 0f 0f 0b eb fe 8b
> 41 20
> > 3b 42 20 72 09 8d 5a 0c 8b 13 85 d2 75 ef 89 51 0c 89
> 0b 5b
> > c3 56 89 d6 53 <8b> 58 18 eb 11 8b 43 10 89 f2
> e8 df
> > ed 03 00 85 c0 74 07 8b 5b
> > EIP: [<c04a2215>] sysfs_find_dirent+0x4/0x23
> SS:ESP
> > 0068:cebafe30
> > ---[ end trace e53c213592aca5ba ]---
> >
> >
> > Thanks
> > Amruth p.v
> >
> >
> > Thanks
> > Amruth p.v
> >
> >
> > --- On Fri, 7/25/08, amruth
> <amruth_pv at yahoo.com>
> > wrote:
> >
> > > From: amruth <amruth_pv at yahoo.com>
> > > Subject: kernel crashes after connecting multiple
> > serial devices
> > > To: "Alan Stern"
> > <stern at rowland.harvard.edu>, "Oliver
> Neukum"
> > <oliver at neukum.org>
> > > Cc: linux-usb at vger.kernel.org
> > > Date: Friday, July 25, 2008, 1:10 PM
> > > Hi
> > > The system crashes after connecting multiple
> serial
> > devices
> > > based on ti usb 3410 chipset. The detailed log is
> > below. The
> > > kernel is 2.6.26. Please suggest any ideas what
> is
> > going on.
> > >
> > > usb 2-2: reset full speed USB device using
> uhci_hcd
> > and
> > > address 5
> > > usb 2-2: device firmware changed
> > > usb 2-2: USB disconnect, address 5
> > >
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > > ti_shutdown
> > > ti_usb_3410_5052 2-2:1.0: device disconnected
> > > usb 2-2: new full speed USB device using uhci_hcd
> and
> > > address 6
> > > usb 2-2: configuration #1 chosen from 2 choices
> > > ti_usb_3410_5052 2-2:1.0: TI USB 3410 1 port
> adapter
> > > converter detected
> > >
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > > ti_startup - product 0x 8, num configurations
> 2,
> > > configuration value 1
> > >
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > > ti_startup - device type is 3410
> > > ti_usb_3410_5052: probe of 2-2:1.0 failed with
> error
> > -5
> > > ti_usb_3410_5052 2-2:2.0: TI USB 3410 1 port
> adapter
> > > converter detected
> > >
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > > ti_startup - product 0x 8, num configurations
> 2,
> > > configuration value 2
> > >
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > > ti_startup - device type is 3410
> > > usb-serial ttyUSB0: Error registering port
> device,
> > > continuing
> > >
> >
> /usr/src/linux-2.6.26/drivers/usb/serial/ti_usb_3410_5052.c:
> > > ti_shutdown
> > > BUG: unable to handle kernel NULL pointer
> dereference
> > at
> > > 00000018
> > > IP: [<c04a2215>] sysfs_find_dirent+0x4/0x23
> > > *pde = 0e975067 *pte = 00000000
> > > Oops: 0000 [#1] SMP
> > > Modules linked in: ti_usb_3410_5052 usbserial
> autofs4
> > hidp
> > > rfcomm l2cap bluetooth sunrpc iptable_filter
> ip_tables
> > > ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables
> > x_tables
> > > dm_multipath sbs sbshc battery ac ipv6 parport_pc
> lp
> > parport
> > > dcdbas floppy snd_intel8x0 snd_ac97_codec
> ac97_bus
> > > snd_seq_dummy ide_cd_mod cdrom snd_seq_oss
> > > snd_seq_midi_event button snd_seq e1000
> snd_seq_device
> > > snd_pcm_oss snd_mixer_oss snd_pcm serio_raw
> rtc_cmos
> > > rtc_core i2c_i801 snd_timer rtc_lib i2c_core snd
> > edac_core
> > > pcspkr soundcore snd_page_alloc dm_snapshot
> dm_zero
> > > dm_mirror dm_log dm_mod ata_piix libata sd_mod
> > scsi_mod ext3
> > > jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded:
> > microcode]
> > >
> > > Pid: 4035, comm: sh Not tainted (2.6.26 #1)
> > > EIP: 0060:[<c04a2215>] EFLAGS: 00010246
> CPU: 0
> > > EIP is at sysfs_find_dirent+0x4/0x23
> > > EAX: 00000000 EBX: c067ea13 ECX: df801080 EDX:
> > c067ea13
> > > ESI: c067ea13 EDI: c06ec794 EBP: ce8dc6fc ESP:
> > cebafe30
> > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > > Process sh (pid: 4035, ti=cebaf000 task=df1dedc0
> > > task.ti=cebaf000)
> > > Stack: c067ea13 00000000 c04a2b01 ce8dc684
> 00000000
> > > c04a32ce ce8dc684 00000001
> > > ce896c1c d0c88438 c054ca37 ce8dc684
> c0548e33
> > > ce8dc684 00000001 00000000
> > > c0548f3f d0c88400 e0af9907 d0c88434
> e0af9862
> > > 00000001 c04ddc02 d0c88434
> > > Call Trace:
> > > [<c04a2b01>] sysfs_get_dirent+0x19/0x45
> > > [<c04a32ce>] sysfs_remove_group+0x18/0x96
> > > [<c054ca37>] device_pm_remove+0x14/0x3c
> > > [<c0548e33>] device_del+0xd/0x111
> > > [<c0548f3f>] device_unregister+0x8/0x10
> > > [<e0af9907>] destroy_serial+0xa5/0xeb
> > [usbserial]
> > > [<e0af9862>] destroy_serial+0x0/0xeb
> > [usbserial]
> > > [<c04ddc02>] kref_put+0x36/0x40
> > > [<e0af9796>] usb_serial_put+0x1c/0x27
> > [usbserial]
> > > [<e0af9bea>]
> usb_serial_disconnect+0x83/0xa8
> > > [usbserial]
> > > [<c056e321>]
> usb_unbind_interface+0x2d/0x5f
> > > [<c054a699>]
> __device_release_driver+0x58/0x76
> > > [<c054a6cf>]
> device_release_driver+0x18/0x21
> > > [<c0549de2>] bus_remove_device+0x6b/0x7b
> > > [<c0548ee6>] device_del+0xc0/0x111
> > > [<c056c3f7>] usb_disable_device+0x55/0xbb
> > > [<c056cddf>]
> usb_set_configuration+0x1bd/0x414
> > > [<c04e0505>] sscanf+0x17/0x19
> > > [<c056fbfd>]
> set_bConfigurationValue+0x44/0x62
> > > [<c056fbb9>]
> set_bConfigurationValue+0x0/0x62
> > > [<c054856a>] dev_attr_store+0x19/0x1d
> > > [<c04a1b50>] sysfs_write_file+0xa4/0xd8
> > > [<c04a1aac>] sysfs_write_file+0x0/0xd8
> > > [<c0469cbd>] vfs_write+0x83/0xf6
> > > [<c046a20f>] sys_write+0x3c/0x63
> > > [<c040389a>] syscall_call+0x7/0xb
> > > [<c0610000>] migration_call+0x314/0x3b6
> > > =======================
> > > Code: 40 08 83 79 0c 00 8d 58 18 74 0f 0f 0b eb
> fe 8b
> > 41 20
> > > 3b 42 20 72 09 8d 5a 0c 8b 13 85 d2 75 ef 89 51
> 0c 89
> > 0b 5b
> > > c3 56 89 d6 53 <8b> 58 18 eb 11 8b 43 10 89
> f2
> > e8 df
> > > ed 03 00 85 c0 74 07 8b 5b
> > > EIP: [<c04a2215>]
> sysfs_find_dirent+0x4/0x23
> > SS:ESP
> > > 0068:cebafe30
> > > ---[ end trace e53c213592aca5ba ]---
> > >
> > >
> > > Thanks
> > > Amruth p.v
> > >
> > >
> > > --- On Fri, 7/25/08, Oliver Neukum
> > > <oliver at neukum.org> wrote:
> > >
> > > > From: Oliver Neukum
> <oliver at neukum.org>
> > > > Subject: Re: usb_reset_device causes probe
> to
> > fail on
> > > USB serial device
> > > > To: "Alan Stern"
> > > <stern at rowland.harvard.edu>
> > > > Cc: amruth_pv at yahoo.com,
> > linux-usb at vger.kernel.org
> > > > Date: Friday, July 25, 2008, 10:44 AM
> > > > Am Freitag 25 Juli 2008 15:42:14 schrieb
> Alan
> > Stern:
> > > > > On Fri, 25 Jul 2008, Oliver Neukum
> wrote:
> > > > >
> > > > > > > What about situations where
> the
> > > firmware
> > > > loading or mode switching was
> > > > > > > done by a userspace task?
> > > > > >
> > > > > > They will have to go into kernel
> space.
> > > > >
> > > > > This does not sound practical.
> You're
> > > talking
> > > > about putting
> > > > > potentially unbounded amounts of new
> code
> > and
> > > data
> > > > into the kernel.
> > > >
> > > > True. But the kernel is already open to
> > potentially
> > > > unbounded amounts
> > > > of new code. We are adding drivers faster
> than
> > > removing
> > > > them.
> > > >
> > > > > > > I'm not at all convinced
> that
> > the
> > > > actions needed to return a wiped-out
> > > > > > > device to normal operation
> can be
> > > carried
> > > > out in the relatively
> > > > > > > delicate environment of
> > > > resume-from-hibernation.
> > > > > >
> > > > > > Why?
> > > > >
> > > > > Because there's no restriction on
> what
> > may be
> > > > needed. Arbitrary
> > > > > sequences of packets, arbitrarily long
> data
> > > sets,...
> > > > And all with no
> > > > > support from userspace.
> > > >
> > > > But the amount of work an implementation of
> > resume()
> > > may
> > > > have to
> > > > do. uvc needs to submit hundreds of URBs in
> the
> > worst
> > > case.
> > > >
> > > > > The whole USB-Persist thing was sort of
> a
> > hack to
> > > > begin with. Trying
> > > > > to shoehorn all this extra stuff into
> it is
> > just
> > > > impractical. It makes
> > > > > much more sense to say that a device
> which
> > loses
> > > too
> > > > much state as a
> > > > > result of a power interruption must be
> > logically
> > > > disconnected and
> > > > > reinitialized.
> > > >
> > > > But why let it stay a sort of hack? The idea
> has
> > > potential.
> > > >
> > > > Regards
> > > > Oliver
> > > > --
> > > > To unsubscribe from this list: send the line
> > > > "unsubscribe linux-usb" in
> > > > the body of a message to
> > majordomo at vger.kernel.org
> > > > More majordomo info at
> > > > http://vger.kernel.org/majordomo-info.html
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line
> > > "unsubscribe linux-usb" in
> > > the body of a message to
> majordomo at vger.kernel.org
> > > More majordomo info at
> > > http://vger.kernel.org/majordomo-info.html
> >
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-usb" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
>
>
>
>
> --
> To unsubscribe from this list: send the line
> "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
More information about the kernel
mailing list