Re: PCI Internal Modems
Date: Mon, 06 Mar 2000 15:43:13 -0600 From: Brice Ruth [EMAIL PROTECTED] Just a quick note: the US Robotics (3com) Sportster internal PCI modems work just fine under Linux. I had to use 'setserial' to set the line discipline (it shows up as a 'Serial Controller' in /proc/pci) - but no problems thereafter. Just make sure ya don't get a WinModem. The USR models #5610, #5611, #5612 and #5613 are *not* winmodems. Most if not all of the other USR modems are winmodems, though. Be careful befure you purchase a PCI modem. USR is pretty careful about listing Windows as a requirement on the outside of the box. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
Re: Serial dongle does not work since kernel 2.1.132
Date: Fri, 07 Jan 2000 23:51:14 +0100 From: Carlo Scarfoglio [EMAIL PROTECTED] Now I am running kernel 2.3.36 SMP , Suse 6.1 standard on a dual Celeron Abit BP6 mobo. The serial dongle is connected to /dev/ttyS3 on an ISA multiport card. I ran the app through strace on K 2.3.36 and after a write to the serial port the result was an endless series of read(4, 0x...,84) that failed wit error -1. From time to time some characters are returned, but the app probably does not receive enough data to perform its check. Interestingly, when run under strace, the app finds and checks OK the dongle, it won't when run alone (no strace). But yesterday I found that I can fix the problem by setting "low_latency" to the port with setserial. This seems to be the cure so far. It sounds like the Dongle protocol is extremely fragile, and is highly timing dependent. For what it's worth, old Linux kernels (Linue 2.0) had basically the same behaviour as newer kernels by default. The low_latency flag turns on new behaviour, which increases CPU utilization, but shortens the time before incoming characters are processed. If using low_latency fixes it, as well as running the app under strace (which slows the application), then it's probably a very fragile application or hardware, and it's not a kernel problem. Your app vendor is going to have to deal with this. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
Re: TTY Flip buffers
Date: Tue, 23 Nov 1999 08:57:41 -0800 (PST) From: Linux Lists [EMAIL PROTECTED] Note that the char_buf buffer size is 2*TTY_FLIPBUF_SIZE. However, all serial drivers check the value TTY_FLIPBUF_SIZE in order to know whether the buffer is full or not. Is this correct?? Shouldn't the serial drivers be checking for 2*TTY_FLIPBUF_SIZE?? Aren't the serial drivers subutilizing the flip buffers in this way?? The existing code is correct. The reason why the buffer is 2*TTY_FLIPBUF_SIZE is that we're doing double buffering; first one half of the buffer is filled, while the other half is being processed by the line discpline, and then the two (half) buffers are flipped --- this the name "flip buffers". It really is double buffering by another name; I wasn't familiar with the more commonly used name when I reinvented the technique for Linux. :-) Another question: if I want to use a larger flip buffer, can I just allocate the required memory amount and set the pointers char_buf_ptr and flag_buf_ptr?? If not, I don't see the reason for the existence of these pointers ... You have to change the routines that set and reset those pointers when the flip buffers are flipped. There is a patch outstanding to allow bigger flip buffers, and I'll hopefully have a chance to look at it over Thanksgiving weekend. (My apologies Pavel for my delay in looking over your patch; I've been swamped lately.) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
Re: serial insertion bug in 2.2.*
Date: Sat, 30 Oct 1999 19:35:54 +0200 (MEST) From: Marc SCHAEFER [EMAIL PROTECTED] You are right. However, the main issue is not that, it's why does it not fail with a good error message, such as: minor/major already allocated, there is already a char device with name `serial', or the IRQ 3 is already used ? I understand that serial devices now support IRQ sharing, and that's maybe the reason why ``IRQ already used'' doesn't fail anymore. FYI, This has been fixed in the 4.91 version of the serial driver (which is also folded into the 2.3.29-pre2 kernel). http://web.mit.edu/tytso/www/linux/serial/ - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
Re: HELP: Boca multiport(BB1008) board configuration
From: Qingyue Shirley Wang [EMAIL PROTECTED] Date: Thu, 14 Oct 1999 13:47:42 -0700 I recently installed a Boca 8-port board with Redhat linux 2.2.5. .All 8 ports were recognized at start up, and seem to be configured correctly, but somehow only the first port (ttyS16) works (I'm attaching it to a remote power control device), but all others have no response when I try to read/write to it. And here is the configuration for the multiports sharing one IRQ: # setserial ttyS16 get_multiport Multiport config for irq 4: Port monitor = 0x107 Port1 = 0x107, mask=0xff, match=0x0 Port2 = 0x10f, mask=0xff, match=0x0 Port3 = 0x117, mask=0xff, match=0x0 Port4 = 0x11f, mask=0xff, match=0x0 (The Boca manual says that the port status register appears at the end of the eight-address block for each port) First of all, I suspect what happens is that your multiport configuration is wrong, so that the serial ports work if there's only one port on that irq open, but once you have more than one port open, they stop working. Secondly, for a 8-port boca, you only need to sample a single port, since the bits on one port will cover all eight ports. So try simply using this configuration: Port1 = 0x107, mask=0xff, match=0x0 (Don't set port monitor except when you're trying to figure out how the multiport registers work, since it causes a huge amount of prink traffic. It's for debugging purposes only.) The first I would try is to avoid using the multiport configuration altogether. On an eight port card, with fast CPU's you can get away without needing to use the multiport registers. So see if things work without multiport, and only then try to configure the multiport registers. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
Re: Serial ports not detected
Date: Tue, 12 Oct 1999 10:18:42 +0200 (MET DST) From: Jean-Paul Le Fevre [EMAIL PROTECTED] After having spent a lot of time trying to figure out the cause of the problem, it turns out that it is likely a BIOS setup problem. At boot time, the serial driver (version 4.27) just declares that no options are enabled but does not print anything else. At work, on a Dell OptiPlex, the driver detects as expected 2 ports ttyS01 and ttyS00. At home, these ports remain invisible. Someone told me that it has something to do with the BIOS. Unfortunately, I didn't see anything related to the serial ports in the BIOS menus. The BIOS config information is usually on a menu labelled "peripherals"; sometimes it's on a secondary menu accessed off the advanced configuration page. There wasn't anything labelled "COM1" or "COM2" there? - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
Re: Serial port as a Midi port?
The problem is Midi runs at 31250 baud (I have read that this should be bps, but the Midi specs say 31.25 kBaud) which is not a standard rate (to my knowledge) . Using 'setserial /dev/cua0 baud_base 31250' I can set it to this rate, but I don't trust it as I can also set it to '1' which dose not sound right to me. (31250 is not a factor of 115200, the normal (?) high speed that is then divided by integers to get the requested rate) In general, you shouldn't try to touch baud_base. Baud_base needs to be clock frequency on the serial board (almost always 1.8432 MHz) expressed in Hertz divided by 16. Hence, the baud_base must always been 115200 unless you are using a non-standard clock crystal installed on your serial board. There is very few hardware with a non-standard clock crystal since that hardware isn't compatible with Dos/Windows systems without custom device drivers. Linux is one of the few OS's that supports non-standard serial clock crystals. The way you program that UART to use a specific baud rate is to divide the baud_base by the baud rate and program the resulting divisor into the UART. The problem with 31250 is (as you point out), it's will not evenly divide 115200 bps. What this means is that the hardware physically cannot support that baud rate, at least not without using a custom clock crystal. Changing baud_base without changing the clock crystal will only cause the UART to use an incorrect baud rate. The serial port is an asynchronous port, which means that when the line is idle, there's nothing on it. So the start bit is used to alert and synchronize the UART that there's an incoming data word coming in. The stop bit is used to end the data word. High speed serial lines, especially dedicated ones, use synchronous serial setup, which doesn't have start bits and stop bits, and is therefore more efficient. The tradeoff is that a synchronous link must always be transmitting/receiving data, even if it is all zero's. So with a UART, there's always one start bit, and it's different from the parity bit. I hope this helps you out. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to [EMAIL PROTECTED]
