I forgot to state we are on Kernel Version 2.6.20.11
--Michael
--
Michael Langford
www.TierOneDesign.com
Phone: 404-386-0495
Fax: 770-234-6899
> -----Original Message-----
> From: linux-serial-owner@xxxxxxxxxxxxxxx [mailto:linux-
> serial-owner@xxxxxxxxxxxxxxx] On Behalf Of Michael
> Langford
> Sent: Wednesday, October 03, 2007 3:53 PM
> To: Linux Serial Mailing List
> Subject: Call to tty_flip_buffer_push crashing system
>
> We're writing a custom driver for a 4 port usb-serial
> device we have
> made for a customer. We have issue with the recv of
> characters from the
> device. We have a snooper connected and see the data
> getting to linux.
>
> When drivers/usb/serial/generic.c calls
> tty_flip_buffer_push, in
> usb_serial_generic_read_bulk_callback, the system goes
> down hard. 100%
> frozen. I'm guessing I'm getting a kernel panic, but I
> can't even see
> that.
>
> This behavior happens with data I make up or what actually
> came from the
> usb endpoint.
>
> When I call this function (and tty_buffer_request_room and
> tty_insert_flip_string) in an ioctl command I've rigged
> up, all three
> functions work as expected, pushing the tty data to the
> awaiting program
> reading from the /dev/ttyUSB file.
>
> Any pointers on what may be going on here?
>
> We've verified that the tty is the same one from open. We
> do a small
> action in our port_open function on a separate endpoint on
> our device,
> then call the open function that's in generic.c.
>
> --Michael
>
> PS: If this is the incorrect list, I'd like to apologize
> for the OT, and
> ask for a pointer to one you think may have more answers.
>
> --
> Michael Langford
> www.TierOneDesign.com
> Phone: 404-386-0495
> Fax: 770-234-6899
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-serial" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-
> info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
