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(a)yahoo.com>
wrote:
> From: amruth <amruth_pv(a)yahoo.com>
> Subject: 2.6.26 kernel crashes after hotplugging 2nd
device of same type
> To: linux-usb(a)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(a)yahoo.com>
> wrote:
>
> > From: amruth <amruth_pv(a)yahoo.com>
> > Subject: kernel crashes after connecting multiple
> serial devices
> > To: "Alan Stern"
> <stern(a)rowland.harvard.edu>, "Oliver
Neukum"
> <oliver(a)neukum.org>
> > Cc: linux-usb(a)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(a)neukum.org> wrote:
> >
> > > From: Oliver Neukum
<oliver(a)neukum.org>
> > > Subject: Re: usb_reset_device causes probe
to
> fail on
> > USB serial device
> > > To: "Alan Stern"
> > <stern(a)rowland.harvard.edu>
> > > Cc: amruth_pv(a)yahoo.com,
> linux-usb(a)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(a)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(a)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(a)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(a)vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html