Linux TCP impotency
Using 2.2.19 I discovered that running two simultaneous scp's (uses up whole capacity in TCP traffic) on a 115200bps full duplex serial port nullmodem cable causes the earlier started one to survive and the later to starve. Running bcp instead of the second (which uses UDP) at 11000 bytes per second caused the utilization in both directions to go up nearly to 100%. Is this a normal TCP stack behaviour? -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TCP stack misbehaviour?
On Sun, Apr 08, 2001 at 06:07:55PM +0200, Manfred Spraul wrote: > Could you add more details and post them to linux-kernel? > > * which kernel version 2.2.18 > * both sides linux, or one side linux, the other one something else both sides 2.2.18 linux > * a tcpdump that shows the problem, preferably 2 dumps, from both sides > of the cable > > -- > Manfred > -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
TCP stack misbehaviour?
The TCP stack in the linux kernel behaves this way: I have got a FULL-DUPLEX 28.800kbps channel with BER <= 1*10-9 a) I start a long TCP connection in one direction b) After 5 minutes I start another connection in the opposite direction The second connection rusn for about half a minute, then converges to 0 throughtput. After several minutes, another 30 seconds of transmission ocuur. The data path in the direction that should be used for this connection is empty, except for occasional ACKs. The utilization of the channel is about 4%. I would expect that both channels would be used for at least 95%. Instead, only one is used. Is this a bug of Linux kernel TCP stack, or a bug in the algorithm presented in the appropriate RFC? Isn't UDP more suitable for data transfers? -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The 53c400a
On Mon, Apr 02, 2001 at 10:15:28PM +0100, Alan Cox wrote: > Not in the near future. Never mind. I realized three things: a) my 53c400 card must be initialized first by DOS driver to be detected by Linux kernel b) The scanner initialization lasts about 4 minutes. And scanning is very slow even if I increase the kernel buffer to the max. as described in the SANE doc. c) Using an adaptec SCSI adapter works just fine: scanner initializes immediately, card is recognized even without DOS and the scanning is much faster. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SCSI interface chip NCE53c400a datasheet
If anybody found an electronic or paper copy of the %subj, please send it to me. Thanks in advance. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
g_NCR5380.o module removal bug
I realized that removing the module while in usage OOPSES the kernel and only the alt-sysrq-usb helps. I thought it should write some error message and do nothing. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
insmod message explanation
insmod g_NCR5380 ncr_addr=0xcc000 ncr_irq=255 ncr_53c400a=1 Using /lib/modules/2.2.19/scsi/g_NCR5380.o scsi : 0 hosts. /lib/modules/2.2.19/scsi/g_NCR5380.o: init_module: Device or resource busy Hint: this error can be caused by incorrect module parameters, including invalid IO or IRQ parameters Which device is busy? Or which resource is busy? Printer? hard drive? Or what? is init_module some kind of device or even maybe a resource? What stage did the process of inserting the module get into? Has the init_module been completed? Thanks in advance for answering these questions. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hanging process
I did cat /dev/zero >/dev/fd0 no space left on device (that's correct) ps ax | grep cat kill pid - nothing kill -9 pid - nothing then I repeatedly did the kill -9 , when after about half a minute it started working What's wrong? Why was the process unkillable? -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diskette change problems
I put a write-protected diskette into fd0 cat /dev/zero > /dev/fd0: readonly filesystem then removed dikette, switched the plastic nibble reinserted diskette cat /dev/zero > /dev/fd0 : readonly filesystem removed the diskette cat /dev/zero: a bunch of garbage, then kernel spasms about sectors not found and commands not performed reinserted the diskette cat /dev/zero > /dev/fd0: readonly filesystem rebooted the machine cat /dev/zero > /dev/fd0: run OK. morale: if you are not able to write on a write-permitted diskette, reboot the kernel -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
53c400a datasheet
Hello does anybody here have the datasheet for the 53c400a SCSI bus interface cotroller? I tried to find it on the Net but did not succeed. -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Inadmissible sound dropouts on 2.2.18
I found that 2.2.18 probably rudely drops samples (lets ocassionally one sample
be played several times) on the Gravis Ultrasound output device. I use 2.2.18
and the native kernel drivers. I wrote this program that should produce a clean
sine tone. Instead I hear a sine interspaced with crackling. The crackling
repeats at 100Hz I guess. There runs nothing CPU-consuming. The sound process
takes 5% CPU. It's funny Linux drops sound samples just at 5% of CPU load. I
got AMD K6-2 3D 400Mhz at 400Mhz, 4*100MHz, running stably between 20-35 deg C
of case temperature. I got PCI / AGP board FIC VA-503+. There are three serial
ports, none of them was transceiving at that time. There is one ISA NE2000 NIC
which was not sending any packets. There is a ISA Gravis Ultrasound PnP. Two
IDE disks, one of them sleeping, the second spinning but nod reading/writing.
64MB of 100MHz DIMM SDRAM, which runs for years without problems. 1MB L2 cache.
AGP video card ATI. No X server running, no SVGAlib application running. No
USB peripherals.
The crackling is not dependent on the buffer size you can set up in the C code.
The crackling is dependent on the frequency of the sine. It's clearly audible
(read: annoying) at 10kHz, audible at 1kHz, inaudible at 100Hz. So I think
they are sample dropouts - the card stops playing and repeats one sample until
kernel gets the breath and whips itself up to supply next audio data.
There are no custom changes in the drivers - no buffer tweaking, nothing. The
Gravis plays modules, midules and mp3 with nearly no problems (apart from when
Loreena Mc Kennith sings too high and too loud, I hear something that looks like
MP3 frames bounds, but I can't surely tell who's responsible for this - if the
Fraunhofer Institute or Linux Kernel)
root@ghost:/usr/src/linux# cat /proc/version
Linux version 2.2.18 (root@ghost) (gcc version 2.95.2.1 19991024 (release)) #14
Mon Jan 29 15:14:27 MET 2001
Clock
CFLAGS=-O3 -Wall -fomit-frame-pointer
LDFLAGS=-s -lm
all: syncro beat
syncro: syncro.c
beat: beat.c
clean:
rm -f *.o core syncro beat
#include
#include
#include
#include
#include
#include
#include
#include
#include
unsigned char errmsg[256];
int r;
int dsp;
int bits=16;
int channels;
int blocksize;
float left=1;
float right=1;
double left_angle=0;
double right_angle=0;
unsigned char buffer[65536];
void hum(void)
{
int a;
int val;
int remains;
unsigned char *ptr;
new_buffer:
ptr=buffer;
for (a=0;a>8;
val=32767*sin(right_angle);
*ptr++=val&255;
*ptr++=val>>8;
left_angle+=2*M_PI/44100*left;
if (left_angle>=2*M_PI) left_angle-=2*M_PI;
right_angle+=2*M_PI/44100*right;
if (right_angle>=2*M_PI) right_angle-=2*M_PI;
}
remains=sizeof(buffer);
ptr=buffer;
a2:
if (!remains) goto new_buffer;
val=write(dsp,ptr,remains);
if (val>=0){
remains-=val;
ptr+=val;
goto a2;
}
if (errno==EAGAIN||errno==EINTR) goto a2;
perror("beat");
exit(1);
}
/*---MAIN---*/
int main(int argc, char **argv)
{
int a;
again:
dsp=open("/dev/dsp",O_WRONLY);
if (dsp<0){
if (errno==EINTR||errno==EAGAIN) goto again;
}
if (r){
fprintf(stderr,"Can't open sound device.\n");
exit(1);
}
r=ioctl(dsp,SNDCTL_DSP_RESET,NULL);
if (r){
fprintf(stderr,"Can't reset sound device.\n");
exit(1);
}
a=44100;
r=ioctl(dsp,SNDCTL_DSP_SPEED,&a);
if (r){
fprintf(stderr,"Can't set 44100.\n");
exit(1);
}
a=1;
r=ioctl(dsp,SNDCTL_DSP_STEREO,&a);
if (r){
fprintf(stderr,"Can't set stereo.\n");
exit(1);
}
a=16;
r=ioctl(dsp,SOUND_PCM_WRITE_BITS,&a);
if (r){
fprintf(stderr,"Can't set 16bit.\n");
exit(1);
}
r=ioctl(dsp,SNDCTL_DSP_GETBLKSIZE,&blocksize);
if (r){
fprintf(stderr,"Can't get blocksize.\n");
exit(1);
}
r=ioctl(dsp,SNDCTL_DSP_SYNC,NULL);
if (r){
fprintf(stderr,"Can't sync device.\n");
exit(1);
}
hum();
return 0;
printf("Error setting up driver\n");
return 1;
}
CBQ simply doesn't work
I can't get the CBQ running on 2.2.17. Alexey look like he doesn't reply to his mails. I made one more man to check it over me. We both can't find a problem. The file with config info is attached. Eager for any idea Clock This is an excerpt from the kernel configuration: [*] QoS and/or fair queueing CBQ packet scheduler < > CSZ packet scheduler The simplest PRIO pseudoscheduler RED queue SFQ queue TEQL queue TBF queue [*] QoS support [*] Rate estimator [*] Packet classifier API Routing table based classifier Firewall based classifier U32 classifier Special RSVP classifier < > Special RSVP classifier for IPv6 [*] Ingres traffic policing ... [*] IP: multicasting [*] IP: advanced router This is a script that sets up the qos: #!/bin/bash /sbin/insmod cls_fw /sbin/insmod sch_prio /sbin/insmod sch_cbq /sbin/insmod cls__u32 /sbin/insmod cls_rsvp /sbin/insmod sch_red tc qdisc add dev ppp0 root handle 10: cbq bandwidth 28Kbit avpkt 1000 tc class add dev ppp0 parent 10:0 classid 10:1 cbq bandwidth 28Kbit rate 28Kbit allot 1514 weight 28Kbit prio 8 maxburst 20 avpkt 1000 tc class add dev ppp0 parent 10:1 classid 10:100 cbq bandwidth 28Kbit rate 16Kbit allot 1514 weight 16Kbit prio 5 maxburst 20 avpkt 1000 tc class add dev ppp0 parent 10:1 classid 10:200 cbq bandwidth 28Kbit rate 9Kbit allot 1514 weight 9Kbit prio 5 maxburst 20 avpkt 1000 tc class add dev ppp0 parent 10:1 classid 10:300 cbq bandwidth 28Kbit rate 3Kbit allot 1514 weight 3Kbit prio 5 maxburst 20 avpkt 1000 tc qdisc add dev ppp0 parent 10:100 sfq quantum 1514b perturb 15 tc qdisc add dev ppp0 parent 10:200 sfq quantum 1514b perturb 15 tc qdisc add dev ppp0 parent 10:300 sfq quantum 1514b perturb 15 This is what the script says when run just before testing: root@mspool:~# ./qos Using /lib/modules/2.2.17/misc/cls_fw.o insmod: a module named cls_fw already exists Using /lib/modules/2.2.17/misc/sch_prio.o insmod: a module named sch_prio already exists Using /lib/modules/2.2.17/misc/sch_cbq.o insmod: a module named sch_cbq already exists insmod: cls__u32: no module by that name found Using /lib/modules/2.2.17/misc/cls_rsvp.o insmod: a module named cls_rsvp already exists Using /lib/modules/2.2.17/misc/sch_red.o insmod: a module named sch_red already exists Config listings: root@mspool:~# tc qdisc show qdisc sfq 8036: dev ppp0 quantum 1514b perturb 15sec qdisc sfq 8035: dev ppp0 quantum 1514b perturb 15sec qdisc sfq 8034: dev ppp0 quantum 1514b perturb 15sec qdisc cbq 10: dev ppp0 rate 28Kbit (bounded,isolated) prio no-transmit root@mspool:~# tc class show dev ppp0 class cbq 10: root rate 28Kbit (bounded,isolated) prio no-transmit class cbq 10:100 parent 10:1 leaf 8034: rate 16Kbit prio 5 class cbq 10:1 parent 10: rate 28Kbit prio no-transmit class cbq 10:200 parent 10:1 leaf 8035: rate 9Kbit prio 5 class cbq 10:300 parent 10:1 leaf 8036: rate 3Kbit prio 5 root@mspool:~# tc filter show dev ppp0 filter parent 10: protocol ip pref 25 u32 filter parent 10: protocol ip pref 25 u32 fh 802: ht divisor 1 filter parent 10: protocol ip pref 25 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 10:300 match 3e50554d/ at 16 filter parent 10: protocol ip pref 25 u32 fh 801: ht divisor 1 filter parent 10: protocol ip pref 25 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 10:200 match 3e50554c/ at 16 filter parent 10: protocol ip pref 25 u32 fh 800: ht divisor 1 filter parent 10: protocol ip pref 25 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 10:100 match 3e50554a/ at 16 filter parent 10: protocol ip pref 50 u32 filter parent 10: protocol ip pref 50 u32 fh 802: ht divisor 1 filter parent 10: protocol ip pref 50 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 10:300 match 3e50554d/ at 16 filter parent 10: protocol ip pref 50 u32 fh 801: ht divisor 1 filter parent 10: protocol ip pref 50 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 10:200 match 3e50554c/ at 16 filter parent 10: protocol ip pref 50 u32 fh 800: ht divisor 1 filter parent 10: protocol ip pref 50 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 10:100 match 3e50554a/ at 16 filter parent 10: protocol ip pref 100 u32 filter parent 10: protocol ip pref 100 u32 fh 802: ht divisor 1 filter parent 10: protocol ip pref 100 u32 fh 802::800
Dropping chars on 16550
Hi folks What should I do, when I run cdda2wav | gogo (riping CD from a ATAPI CD thru mp3 encoder) and get a continuous dropping of characters, on a 16550- enhanced serial port, without handshake, with full-duplex load of 115200 bps? About 1 of 320 bytes is miscommunicated. The kernel is 2.2.12. Clock - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
