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