* [Bluez-users] lockup problem with larger packets @ 2004-10-22 21:21 Erwin Authried 2004-10-23 13:55 ` Marcel Holtmann 0 siblings, 1 reply; 5+ messages in thread From: Erwin Authried @ 2004-10-22 21:21 UTC (permalink / raw) To: bluez-users I have cross-compiled bluez for uClinux-2.4.20 for ARM7, with the bluez kernel patch applied, and bluez-utils 2.10. I'm using the Conceptronic CBT100C PCMCIA card on the system. The card is initialized with "hciattach ttyS2 bcsp". Basically, the system works fine, but I see occasional overrun errors on the UART, maybe because the ARM7 is running with 40MHz only. When I transmit larger packets (l2ping -s 300 ...), the number of overrun errors increases, and sometimes the system locks up. I'm getting an endless sequence of: bcsp_pkt_cull: Peer acked invalid packet bcsp_handle_le_pkt: Found a LE sync pkt, card has reset bcsp_pkt_cull: Peer acked invalid packet bcsp_handle_le_pkt: Found a LE sync pkt, card has reset bcsp_pkt_cull: Peer acked invalid packet ... Regards, Erwin ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bluez-users] lockup problem with larger packets 2004-10-22 21:21 [Bluez-users] lockup problem with larger packets Erwin Authried @ 2004-10-23 13:55 ` Marcel Holtmann [not found] ` <1098928778.23859.32.camel@kabel> 0 siblings, 1 reply; 5+ messages in thread From: Marcel Holtmann @ 2004-10-23 13:55 UTC (permalink / raw) To: Erwin Authried; +Cc: BlueZ Mailing List Hi Erwin, > I have cross-compiled bluez for uClinux-2.4.20 for ARM7, with the bluez > kernel patch applied, and bluez-utils 2.10. I'm using the Conceptronic > CBT100C PCMCIA card on the system. The card is initialized with > "hciattach ttyS2 bcsp". Basically, the system works fine, but I see > occasional overrun errors on the UART, maybe because the ARM7 is running > with 40MHz only. When I transmit larger packets (l2ping -s 300 ...), the > number of overrun errors increases, and sometimes the system locks up. > I'm getting an endless sequence of: > > bcsp_pkt_cull: Peer acked invalid packet > bcsp_handle_le_pkt: Found a LE sync pkt, card has reset > bcsp_pkt_cull: Peer acked invalid packet > bcsp_handle_le_pkt: Found a LE sync pkt, card has reset > bcsp_pkt_cull: Peer acked invalid packet > ... I am not a BCSP or uClinux expert so I think that I can't help you here, but from my testing with the BCSP part of the hci_uart driver I never saw any problems like this. Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <1098928778.23859.32.camel@kabel>]
* Re: [Bluez-users] lockup problem with larger packets [not found] ` <1098928778.23859.32.camel@kabel> @ 2004-10-28 11:47 ` Marcel Holtmann 2004-10-28 14:31 ` Erwin Authried 0 siblings, 1 reply; 5+ messages in thread From: Marcel Holtmann @ 2004-10-28 11:47 UTC (permalink / raw) To: Erwin Authried; +Cc: BlueZ Mailing List Hi Erwin, > > > I have cross-compiled bluez for uClinux-2.4.20 for ARM7, with the bluez > > > kernel patch applied, and bluez-utils 2.10. I'm using the Conceptronic > > > CBT100C PCMCIA card on the system. The card is initialized with > > > "hciattach ttyS2 bcsp". Basically, the system works fine, but I see > > > occasional overrun errors on the UART, maybe because the ARM7 is running > > > with 40MHz only. When I transmit larger packets (l2ping -s 300 ...), the > > > number of overrun errors increases, and sometimes the system locks up. > > > I'm getting an endless sequence of: > > > > > > bcsp_pkt_cull: Peer acked invalid packet > > > bcsp_handle_le_pkt: Found a LE sync pkt, card has reset > > > bcsp_pkt_cull: Peer acked invalid packet > > > bcsp_handle_le_pkt: Found a LE sync pkt, card has reset > > > bcsp_pkt_cull: Peer acked invalid packet > > > ... > > > > I am not a BCSP or uClinux expert so I think that I can't help you here, > > but from my testing with the BCSP part of the hci_uart driver I never > > saw any problems like this. > > > After a lot of debugging, I found out that the serial irq routine calls > tty_flip_buffer_push with the serial interrupt disabled. The processing > of the input buffer in bcsp_recv (hci_bcsp.c) was too slow so that the > characters that were buffered in the FIFO during that time caused an > overrun (There is no RTS/CTS flowcontrol). I have done modifiations to > hci_bcsp.c so that the processing is done much faster, and the problem > seems to have gone. please provide us a patch with your modifications. Regards Marcel ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bluez-users] lockup problem with larger packets 2004-10-28 11:47 ` Marcel Holtmann @ 2004-10-28 14:31 ` Erwin Authried 2004-10-28 17:30 ` Marcel Holtmann 0 siblings, 1 reply; 5+ messages in thread From: Erwin Authried @ 2004-10-28 14:31 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 2306 bytes --] Hi, here's a patch that reduces the execution time for "unslipping" the received data considerably. The patch does NOT support packets with CRC! This would require a little bit of additional work, I think that it would be better to rewrite the crc routine to calculate the whole packet checksum at once for better performance. I have not done that because the CBT100C doesn't use crc's. Please ignore the __fastram attribute, it's for uClinux on my specific board only. Functions with this attribute are placed into the cpu's internal 32-bit ram for faster execution. Regards, Erwin Am Don, den 28.10.2004 schrieb Marcel Holtmann um 13:47: > Hi Erwin, > > > > > I have cross-compiled bluez for uClinux-2.4.20 for ARM7, with the bluez > > > > kernel patch applied, and bluez-utils 2.10. I'm using the Conceptronic > > > > CBT100C PCMCIA card on the system. The card is initialized with > > > > "hciattach ttyS2 bcsp". Basically, the system works fine, but I see > > > > occasional overrun errors on the UART, maybe because the ARM7 is running > > > > with 40MHz only. When I transmit larger packets (l2ping -s 300 ...), the > > > > number of overrun errors increases, and sometimes the system locks up. > > > > I'm getting an endless sequence of: > > > > > > > > bcsp_pkt_cull: Peer acked invalid packet > > > > bcsp_handle_le_pkt: Found a LE sync pkt, card has reset > > > > bcsp_pkt_cull: Peer acked invalid packet > > > > bcsp_handle_le_pkt: Found a LE sync pkt, card has reset > > > > bcsp_pkt_cull: Peer acked invalid packet > > > > ... > > > > > > I am not a BCSP or uClinux expert so I think that I can't help you here, > > > but from my testing with the BCSP part of the hci_uart driver I never > > > saw any problems like this. > > > > > After a lot of debugging, I found out that the serial irq routine calls > > tty_flip_buffer_push with the serial interrupt disabled. The processing > > of the input buffer in bcsp_recv (hci_bcsp.c) was too slow so that the > > characters that were buffered in the FIFO during that time caused an > > overrun (There is no RTS/CTS flowcontrol). I have done modifiations to > > hci_bcsp.c so that the processing is done much faster, and the problem > > seems to have gone. > > please provide us a patch with your modifications. > > Regards > > Marcel [-- Attachment #2: unslip.patch --] [-- Type: text/x-patch, Size: 5404 bytes --] diff -u hci_bcsp.h.orig hci_bcsp.h --- hci_bcsp.h.orig Wed Oct 27 23:08:04 2004 +++ hci_bcsp.h Thu Oct 28 16:12:00 2004 @@ -42,6 +42,7 @@ struct sk_buff_head unrel; /* Unreliable packets queue */ unsigned long rx_count; + unsigned char *rx_ptr; struct sk_buff *rx_skb; u8 rxseq_txack; /* rxseq == txack. */ u8 rxack; /* Last packet sent by us that the peer ack'ed */ diff -u hci_bcsp.c.orig hci_bcsp.c --- hci_bcsp.c.orig Mon Oct 25 23:22:58 2004 +++ hci_bcsp.c Thu Oct 28 16:13:54 2004 @@ -53,6 +53,9 @@ #include <net/bluetooth/bluetooth.h> #include <net/bluetooth/hci_core.h> + +#include <linux/fastram.h> + #include "hci_uart.h" #include "hci_bcsp.h" @@ -401,53 +404,46 @@ } } -static inline void bcsp_unslip_one_byte(struct bcsp_struct *bcsp, unsigned char byte) +static int __fastram bcsp_unslip(struct bcsp_struct *bcsp, unsigned char **p_pdata, int *p_count) { - const u8 c0 = 0xc0, db = 0xdb; - - switch (bcsp->rx_esc_state) { - case BCSP_ESCSTATE_NOESC: - switch (byte) { - case 0xdb: - bcsp->rx_esc_state = BCSP_ESCSTATE_ESC; - break; - default: - memcpy(skb_put(bcsp->rx_skb, 1), &byte, 1); - if ((bcsp->rx_skb-> data[0] & 0x40) != 0 && - bcsp->rx_state != BCSP_W4_CRC) - bcsp_crc_update(&bcsp->message_crc, byte); - bcsp->rx_count--; - } - break; - - case BCSP_ESCSTATE_ESC: - switch (byte) { - case 0xdc: - memcpy(skb_put(bcsp->rx_skb, 1), &c0, 1); - if ((bcsp->rx_skb-> data[0] & 0x40) != 0 && - bcsp->rx_state != BCSP_W4_CRC) - bcsp_crc_update(&bcsp-> message_crc, 0xc0); - bcsp->rx_esc_state = BCSP_ESCSTATE_NOESC; - bcsp->rx_count--; - break; - - case 0xdd: - memcpy(skb_put(bcsp->rx_skb, 1), &db, 1); - if ((bcsp->rx_skb-> data[0] & 0x40) != 0 && - bcsp->rx_state != BCSP_W4_CRC) - bcsp_crc_update(&bcsp-> message_crc, 0xdb); - bcsp->rx_esc_state = BCSP_ESCSTATE_NOESC; - bcsp->rx_count--; - break; - - default: - BT_ERR ("Invalid byte %02x after esc byte", byte); - kfree_skb(bcsp->rx_skb); - bcsp->rx_skb = NULL; - bcsp->rx_state = BCSP_W4_PKT_DELIMITER; - bcsp->rx_count = 0; - } - } + unsigned char *pdata=*p_pdata; + int count=*p_count; + unsigned char c; + int ret=0; + + while(bcsp->rx_count && count){ + c=*pdata++; count--; + if (c==0xc0) {ret=-2; goto unslip_ret;} //unexpected end of slip pkt. + + switch(bcsp->rx_esc_state){ + case BCSP_ESCSTATE_NOESC: + if (c==0xdb){ + bcsp->rx_esc_state = BCSP_ESCSTATE_ESC; + } + else{ + *bcsp->rx_ptr++ = c; bcsp->rx_count--; + } + break; + case BCSP_ESCSTATE_ESC: + switch(c){ + case 0xdd: + *bcsp->rx_ptr++ = 0xdb; + break; + case 0xdc: + *bcsp->rx_ptr++ = 0xc0; + break; + default: + ret=-1; goto unslip_ret; // Illegal char after ESC + } + bcsp->rx_count--; + bcsp->rx_esc_state = BCSP_ESCSTATE_NOESC; + break; + } + } // while +unslip_ret: + *p_pdata = pdata; + *p_count = count; + return ret; } static inline void bcsp_complete_rx_pkt(struct hci_uart *hu) @@ -507,27 +503,32 @@ } /* Recv data */ -static int bcsp_recv(struct hci_uart *hu, void *data, int count) +static int __fastram bcsp_recv(struct hci_uart *hu, void *data, int count) { struct bcsp_struct *bcsp = hu->priv; - register unsigned char *ptr; - + unsigned char *ptr; BT_DBG("hu %p count %d rx_state %ld rx_count %ld", hu, count, bcsp->rx_state, bcsp->rx_count); - ptr = data; while (count) { - if (bcsp->rx_count) { - if (*ptr == 0xc0) { - BT_ERR("Short BCSP packet"); - kfree_skb(bcsp->rx_skb); - bcsp->rx_state = BCSP_W4_PKT_START; - bcsp->rx_count = 0; - } else - bcsp_unslip_one_byte(bcsp, *ptr); - - ptr++; count--; - continue; + // dest buf: bcsp->rx_ptr, rx_count + if (bcsp->rx_count){ + switch (bcsp_unslip(bcsp,&ptr,&count)){ + case -2: + BT_ERR("Short BCSP packet"); + kfree_skb(bcsp->rx_skb); + bcsp->rx_state = BCSP_W4_PKT_START; + bcsp->rx_count = 0; + break; + case -1: + BT_ERR("Illegal SLIP char"); + kfree_skb(bcsp->rx_skb); + bcsp->rx_skb=NULL; + bcsp->rx_state = BCSP_W4_PKT_DELIMITER; + bcsp->rx_count = 0; + break; + } + continue; } switch (bcsp->rx_state) { @@ -553,12 +554,14 @@ bcsp->rx_state = BCSP_W4_DATA; bcsp->rx_count = (bcsp->rx_skb->data[1] >> 4) + (bcsp->rx_skb->data[2] << 4); /* May be 0 */ + bcsp->rx_ptr=skb_put(bcsp->rx_skb,bcsp->rx_count); continue; case BCSP_W4_DATA: if (bcsp->rx_skb->data[0] & 0x40) { /* pkt with crc */ bcsp->rx_state = BCSP_W4_CRC; bcsp->rx_count = 2; + bcsp->rx_ptr=skb_put(bcsp->rx_skb,2); } else bcsp_complete_rx_pkt(hu); continue; @@ -609,7 +612,6 @@ /* Do not increment ptr or decrement count * Allocate packet. Max len of a BCSP pkt= * 0xFFF (payload) +4 (header) +2 (crc) */ - bcsp->rx_skb = bluez_skb_alloc(0x1005, GFP_ATOMIC); if (!bcsp->rx_skb) { BT_ERR("Can't allocate mem for new packet"); @@ -617,6 +619,8 @@ bcsp->rx_count = 0; return 0; } + bcsp->rx_ptr=skb_put(bcsp->rx_skb,bcsp->rx_count); + bcsp->rx_skb->dev = (void *) &hu->hdev; break; } ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bluez-users] lockup problem with larger packets 2004-10-28 14:31 ` Erwin Authried @ 2004-10-28 17:30 ` Marcel Holtmann 0 siblings, 0 replies; 5+ messages in thread From: Marcel Holtmann @ 2004-10-28 17:30 UTC (permalink / raw) To: Erwin Authried; +Cc: BlueZ Mailing List Hi Erwin, > here's a patch that reduces the execution time for "unslipping" the > received data considerably. The patch does NOT support packets with CRC! > This would require a little bit of additional work, I think that it > would be better to rewrite the crc routine to calculate the whole packet > checksum at once for better performance. I have not done that because > the CBT100C doesn't use crc's. > Please ignore the __fastram attribute, it's for uClinux on my specific > board only. Functions with this attribute are placed into the cpu's > internal 32-bit ram for faster execution. thanks for the patch, but I can't apply it. You don't follow the coding style and some parts are looking too hackish to me. However I don't have enough time to look at the performance problems of the BCSP driver, but it seems that this is necessary. So is anyone volunteering? Regards Marcel ------------------------------------------------------- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-10-28 17:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-22 21:21 [Bluez-users] lockup problem with larger packets Erwin Authried
2004-10-23 13:55 ` Marcel Holtmann
[not found] ` <1098928778.23859.32.camel@kabel>
2004-10-28 11:47 ` Marcel Holtmann
2004-10-28 14:31 ` Erwin Authried
2004-10-28 17:30 ` Marcel Holtmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox