Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Apple16X50Serial] How to prevent HW buffer overflows?

My driver communicates with some special PC Cards which contain an UART. These are non-modem devices. Because our driver has to reside within the kernel (to subclass a kernel driver) and not to confuse the end user with an additional (unusable) serial port within his/her Network System Preferences, our driver uses Apple16X50UARTSync as provider and not the normal BSDSerialClient.

The driver tells Apple16X50UARTSync to activate hardware flow control (RTS/CTS). The communication of small "packets" (~20 bytes) works in both directions. Sending of large packets works, too. But if Apple16X50UARTSync receives a large packet (~255 bytes) Apple16X50UARTSync::dequeueData() is often cancelled because of a non-data event in the Apple16X50Queue. We tested that this event identifies itself as "hardware buffer overrun with data loss".

Unfortunately the protocol we are implementing does not allow ANY error on the UART line. There is no way to resent the request nor to do any other error checking - personally I think this wouldn't help either because receiving of large packets fails is quite regularly (not always but often). This is why RTS/CTS has to be used.

As far as we understand the internal receive Apple16X50Queue it is quite large (~2k) and we have increased its size to the maximum (~32k) without any better results. This is quite logical because we should get a software buffer overrun, if this queue would be the problem, shouldn't we?

I learned today that Linux UART drivers (from 2003) do not protect the FIFOs within a UART even if they allow own RTS/CTS. These drivers rely on fast calling of their interrupt routine.

One of our PC Cards has a 16 and the other a 128 FIFO. According to Apple16X50UARTSync::determineMasterClock() they have quite fast master clocks (>14MHz). We are working on Mac OS X v10.2.8 with Apple16X50Serial v1.0.6. For several difficulties with our superclass we are not using Mac OS X v10.3.1 and its Apple16X50Serial v1.3 yet.


Questions:
- Is it possible to increase the calling interval of the Apple16X50UARTSync::intervall() routine? Our knowledge of UARTs is quite zero to understand the deeper UART things within Apple16X50UARTSync.
- How do we install a DEBUG version of the Apple16X50Serial family? For some reason my machine got a kernel panic, while replacing the shipped Apple16X50Serial with the DEBUG version of the Darwin v6.8 Apple16X50Serial source. Sorry I know this is a newbee question and it is certainly written down somewhere but I was not able to find the procedure (yet).

or

- Are we totally wrong to look into the Apple16X50Serial for the bug? Is it possible we are producing the problem within our driver and get an UART hardware buffer overrun?


Your help is very appreciated. The final driver will get open source (even in current unusable state) after we have written its full documentation and perhaps it is even possible to make it public domain.

I am not sure if this could be an Apple "technical support incident" but because this project and my developer status have no budget for incidents, posting to this mailing list is my last opportunity.
_______________________________________________
darwin-drivers mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-drivers
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.