| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <AANLkTinyAoii-fBeN9fLKVqTTt81Y2IhHmRp1HllGFPF@mail.gmail.com>
Date: Tue, 29 Jun 2010 10:50:03 -0500
From: Xianghua Xiao <xiaoxianghua@...il.com>
To: "Zhang, Yongchao (GE Healthcare)" <Yongchao.Zhang@...com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: FW: Linux preempt policy serial port communication
On Tue, Jun 29, 2010 at 4:06 AM, Zhang, Yongchao (GE Healthcare)
<Yongchao.Zhang@...com> wrote:
> Hi,
> We have some problems about serial port. We need your expertise. The
> detail is like this:
>
> 1.Our Goal:
> We want to make test on serial port, and want to know whether the
> serial port communication is still OK under heavy system load.
>
> 2.Environment:
> 1). Two computer,one is as server,another is as client.
> The "Server" sends data to serial port. We use a serial port
> tool run on WINXP as server.
> The "Client" reads the data from serial port,and run on Linux.
>
> 3.The way access serial port for "client" program:
> During test procedure, we use two kinds of way to "read" data from
> serial port. One way is "select +none block read" ,another is "block
> read".
> The code slice is as the follwoing:
> (1).select+none block read. like this:
> ......
> while(num_of_bytes < len)
> {
> //wait till notified.
> while((select(m_fileDescriptor+1,&m_readSet,
> NULL, NULL, NULL)) == -1 && errno == EINTR)
> {
> usleep(1000);
> }
>
> //read data
> if((readBytes = ::read(m_fileDescriptor,
> (buff+num_of_bytes), (len-num_of_bytes))) == -1)
> {
> close();
>
> printf("CS_ERR_READ_SERIAL_PORT_FAIL");
> exit(0);
> }
> else
> {
> num_of_bytes += readBytes;
> }
> }
> ......
>
> (2).block read
> first set paramer c_cc as this during init.
> port_settings.c_cc[VMIN ] = 1 ;
> port_settings.c_cc[VTIME] = 0 ;
> second,read directly
> readBytes = ::read(m_fileDescriptor,
> (buff+num_of_bytes), (len-num_of_bytes))) == -1
>
> 4. The heavy load simulation program.
> Here we write a program to simulate heavy CPU load in linux
> system. This "heavy load program" create one thread and promote thread
> prority to 99, which is the top most in system. This thread did nothing
> but empty loop and never release CPU resource actively.The code slice as
> following:
>
> //create this thread
> ....
> pthread_create(&m_hThread[1],NULL,fifo_99_1 ,(void*)&trans)
> ....
>
> //thread proc
> void* fifo_99(void *para)
> {
> struct sched_param param;
>
> //adjust prority to FIFO 99.
> pthread_t thread_t = pthread_self();
> param.sched_priority = 99;
> pthread_setschedparam(thread_t,SCHED_FIFO,¶m);
>
> //only cost CPU resource
> while(1)
> {
> for (int z = 0; z < 10000; z++)
> {
> }
> }
> }
>
> 5. Test procedure
> (1).
> Procedure:
> Run serial port client program,the program is just waitting
> serial port data. The "client" program is run with normal priority.
> Run 99 FIFO emluator,so the CPU cost is 100% almost now.
> Run serial tool in WindowXP,and send data to client,total
> send several groups of data.
>
> Test result:
> Find the "client" program could not recevie the data during
> FIFO 99 emluator running. But if break the emluator , the "client"
> program could read out all the data
> immediately. We get know that it is "select" statement that always
> blocked without waken up if FIFO 99 running . So it seems the system
> could not notify the "serial port data received signal" to "select"
> statement in time.
>
> Analysis & Question:
> Why FIFO 99 could affect on serial port read? Could you
> please point out the detail code position(maybe in serial port driver)?
> And how to avoid this to let "serial port reading" could not be
> disturbed by any other thread or process even if FIFO 99?
>
> (2).
> Procedure
> The same procedure with (1). But this time we also promote
> the "client" program to FIFO 99.
> Test result:
> The same with (1).
> Analysis & Question:
> Once we doube that the thread priority of the "client"
> program is too low to get CPU resource, so we promote "client" program
> also to FIFO 99.
> But also could not read out the data until heavy load is
> over. Maybe even high priority for "client" program have no effect on
> this.
>
> (3).
> Procedure:
> The same with (1). But this time change FIFO 99 to FIFO 98,
> and also "client" program is run with normal priority.
> Test result:
> The "client" program could read the data in time,all is OK.
> Analysis & Question:
> FIFO 99,98 are both high prority in system. But 98 could not
> affect on the serial port,99 could. FIFO 99,98 are both high priority,
> why is it so much difference for serial port reading?
>
> (4).
> Procedure:
> The same with (3). But this time we run two heavy load
> programs i.e. two FIFO 98 in linux system.
> Test result:
> There is much difference with (1) and (3). We will find
> "client" program could receive the data but have some delay(about 2~4
> seconds delay)
> Analysis & Question:
> Two FIFO98 are also heavy load to system,but compared with
> FIFO 99,FIFO 98 is not so rigorous. So system maybe give "some running
> slice" to notify the "select" statement though could not be in time but
> still have opportunity to notify. Right?
>
>
> From our tests, we want to consult with you following questions:
>
> 1. Why FIFO 99 could affect on serial port read? Could you please
> point out the detail code position(maybe in serial port driver)? And
> how to avoid this to let "serial port reading" could not be disturbed by
> any other thread or process even if FIFO 99?
>
> 2. From procedure (2),To FIFO 99,98,why is there so much difference
> for serial port reading?
>
>
> Thanks!
>
> Best Regards!
>
> -------------------------
> Philip
> 2010.06.29
> -------------------------
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
which kernel/rt-patch are you using to do this test?
can you also list all the RT threads with their priorities, e.g.
softirqs etc, say: ps -e -o pid,rtprio,comm | grep sirq
Xianghua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists