Sergei:
 > Naranjo Manuel Francisco <[EMAIL PROTECTED]> writes:
 >> My problems start when I recieve more than 300 bytes. The system crashes. I 
 >> have
 >> tried to delay the output of data in order to give the hardware time to push
 >> the recived data out, but could get to anything.
 >> I'm not sending this as a patch because it is not the final release.
 >> If anyone can help me a bit, It will be great.
 >
 > Not that it's the reason of the problem you have, but here are a few
 > random comments.
I can't understand what you want to tell me. Do you mean the reason of my 
problem
is the 300 bytes limit of the hardware? If it were that should not hang up the 
system.

 >
 > You don't handle throttle in your driver, and according to recent
 > discussion this is a bug even though it's very unlikely it will bite
 > you.
I will check for throttle in the forum archive and see what I can get from it.

 >
 > [...]
 >> static void aircable_send(struct usb_serial_port *port)
 >> {
 > [...]
 >>     spin_lock_irqsave(&priv->lock, flags);
 > [...]
 >>     buf = kzalloc(count + HCI_HEADER_LENGTH, GFP_KERNEL);
 > [...]
 >>     serial_buf_get(priv->buf, buf + HCI_HEADER_LENGTH, MAX_HCI_FRAMESIZE);
 >>
 >>     memcpy(port->write_urb->transfer_buffer, buf, count + 
 >> HCI_HEADER_LENGTH);
 >>     kfree(buf);
 >>     port->write_urb_busy = 1;
 >>
 >>     spin_unlock_irqrestore(&priv->lock, flags);
 >
 > Doesn't seem to be a good idea to do that much at interrupts
 > disabled.
I will try to not force interrupts disabled.
 > Is it OK to call kzalloc(..., GFP_KERNEL) at all?
Do you think GFP_ATOMIC will be better?

 >
 > [...]
 >>             tty_buffer_request_room(tty,package_length - HCI_HEADER_LENGTH);
 >>             tty_insert_flip_string(tty, urb->transfer_buffer +
 >>                 HCI_HEADER_LENGTH + (HCI_COMPLETE_FRAME) * (i),
 >>                 package_length - HCI_HEADER_LENGTH);
 >>             tty_flip_buffer_push(tty);
 >
 > You don't need to call tty_buffer_request_room() at all as
 > tty_insert_flip_string() does it for you anyway.
Ok I did not know that ;)
 >
 > Also, I'd try to move tty_flip_buffer_push() out of the loop.
Ok I will try that. May that consume much processor?

 > And I think you can optimize it even further by pre-calculating of the
 > memory required by the whole transfer_buffer, then getting memory from
 > the tty using tty_prepare_flip_string(), filling it in a loop, then
 > calling tty_flip_buffer_push() after the loop.
tty_prepare_flip_string() works likes tty_buffer_request_room then not?
I will try your suggestion, I think that could work for me.

Regards,
Manuel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to