Ok, that's fine then.
Thanks for your note.
Guido
On Sat, 2009-12-26 at 14:23 -0500, Alan Stern wrote:
> 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
