On Fri, 25 Dec 2009, Andreas Mohr wrote:
> Hi,
>
> On Fri, Dec 25, 2009 at 06:54:43PM +0100, Guido Trentalancia wrote:
> > Hello !
> >
> > I get a kernel failure with the following backtrace during the initial
> > kernel load at startup. I am using an FTDI USB2serial converter.
> >
> > Any idea on how to avoid this ?
>
> I've seen the same thing _sometimes_ with the one FTDI adapter that I'm
> currently using (and strictly spoken that's a WARN_ON, not an OOPS),
> but not sure whether this still occurs after my recent Broadcom-specific
> USB host controller driver fix.
>
> > ------------[ cut here ]------------
> > WARNING: at drivers/usb/serial/usb-serial.c:406 serial_write_room
> > +0x70/0x80 [usbserial]()
> > Hardware name: S1730
> > Modules linked in: nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc
> > ipt_MASQUERADE iptable_nat nf_nat ip6t_REJECT nf_conntrack_ipv6
> > ip6table_filter ip6_tables ipv6 dm_multipath uinput arc4 ecb snd_cs4281
> > snd_rawmidi b43 snd_ac97_codec mac80211 cfg80211 ac97_bus snd_seq_dummy
> > rfkill snd_seq_oss snd_seq_midi_event ssb snd_seq mmc_core snd_pcm_oss
> > snd_mixer_oss ppdev snd_pcm snd_page_alloc snd_opl3_lib snd_seq_device
> > snd_timer snd_hwdep ftdi_sio snd parport_pc uvcvideo usbserial videodev
> > v4l1_compat parport i2c_piix4 pcspkr i2c_core yenta_socket rtl8150
> > rsrc_nonstatic soundcore ata_generic pata_acpi ehci_hcd [last unloaded:
> > freq_table]
> > Pid: 4, comm: events/0 Tainted: G W 2.6.32.2 #1
> > Call Trace:
> > [<c0439371>] warn_slowpath_common+0x71/0x100
> > [<ccede4b0>] ? serial_write_room+0x70/0x80 [usbserial]
> > [<ccede4b0>] ? serial_write_room+0x70/0x80 [usbserial]
> > [<c0439415>] warn_slowpath_null+0x15/0x20
> > [<ccede4b0>] serial_write_room+0x70/0x80 [usbserial]
> > [<c0612c4b>] ? tty_put_char+0x2b/0x30
> > [<c0619ea8>] tty_write_room+0x18/0x20
> > [<c06168c5>] process_echoes+0x45/0x2b0
>
> That's the one here in drivers/usb/serial/usb-serial.c:
> static int serial_write_room(struct tty_struct *tty)
> {
> struct usb_serial_port *port = tty->driver_data;
> dbg("%s - port %d", __func__, port->number);
> WARN_ON(!port->port.count);
> /* pass on to the driver specific version of this function */
> return port->serial->type->write_room(tty);
> }
>
> I'm really not at all certain what could have caused this problem,
> but did you try other USB configurations? Such as using self-powered
> external hubs etc.
> Also, do you get further USB-related error values in the dmesg log?
> This error could probably result from not entirely successful USB device
> enumeration etc.
This isn't related to the USB configuration, the device enumeration, or
anything else. Those WARN_ON() statements are simply obsolete. They
need to be removed -- port->port.count is no longer supposed to be used
for anything in the USB serial core, so the situation they warn about
is valid, not a problem at all.
So to answer Guido's question, the backtraces can be avoided by editing
the drivers/usb/serial/usb-serial.c source file and removing all the
lines that say:
WARN_ON(!port->port.count);
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
