to
your FAMILY.
Regards
John William
to
your FAMILY.
Regards
John William
Is this a known bug in tmscsim.o (2.0f, included with 2.2.19):
I have the following devices (cat /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST15230N Rev: 0638
Type: Direct-AccessANSI SCSI revision: 02
Host:
Is this a known bug in tmscsim.o (2.0f, included with 2.2.19):
I have the following devices (cat /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST15230N Rev: 0638
Type: Direct-AccessANSI SCSI revision: 02
Host:
This is a follow up message to the original "Abysmal Receive Performance"
message. Thanks to everyone who e-mailed me with suggestions.
Well, after poking around, I eventually narrowed the problem down to the
fact that the system BIOS did not enable PCI->RAM write posting. After I
enabled
>Depends on what is driving it... An application I built can only push
>about
>80 Mbps bi-directional on PII 550Mhz machines. It is not the most
>efficient program in
>the world, but it isn't too bad either...
>
>I missed the rest of this thread, so maybe you already mentioned it, but
>what
>I've seen many reports like this where the NIC is invalidly in
>full-duplex more while the router is in half-duplex mode.
[root@copper diag]# ./tulip-diag eth1 -m
tulip-diag.c:v2.08 5/15/2001 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168
I've seen many reports like this where the NIC is invalidly in
full-duplex more while the router is in half-duplex mode.
[root@copper diag]# ./tulip-diag eth1 -m
tulip-diag.c:v2.08 5/15/2001 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168
Depends on what is driving it... An application I built can only push
about
80 Mbps bi-directional on PII 550Mhz machines. It is not the most
efficient program in
the world, but it isn't too bad either...
I missed the rest of this thread, so maybe you already mentioned it, but
what is the
>From: Nivedita Singhvi <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: [EMAIL PROTECTED]
>Subject: Re: Abysmal RECV network performance
>Date: Mon, 28 May 2001 23:45:28 -0700 (PDT)
>While we didnt use 2.2 kernels at all, we did similar tests
>on 2.4.0 through 2.4.4 kernels, on UP and SMP. I've
From: Nivedita Singhvi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Abysmal RECV network performance
Date: Mon, 28 May 2001 23:45:28 -0700 (PDT)
snip
While we didnt use 2.2 kernels at all, we did similar tests
on 2.4.0 through 2.4.4 kernels, on UP and SMP. I've used
Can someone please help me troubleshoot this problem - I am getting abysmal
(see numbers below) network performance on my system, but the poor
performance seems limited to receiving data. Transmission is OK.
The computer in question is a dual Pentium 90 machine. The machine has
RedHat 7.0
Can someone please help me troubleshoot this problem - I am getting abysmal
(see numbers below) network performance on my system, but the poor
performance seems limited to receiving data. Transmission is OK.
The computer in question is a dual Pentium 90 machine. The machine has
RedHat 7.0
On Tue, 3 Apr 2001, Harvey Fishman wrote:
>On Tue, 3 Apr 2001, Alan Cox wrote:
>
>> > I also tried it with 2.2.18 there it works but it seems to be >utterly
>> > slow. I'm using kernel 2.4.2(XFS version to be precise).
>>
>>M/O disks are slow. At a minimum make sure you are using a physical
I propose a patch of mpparse.c (patched against 2.4.2) to fix the Vectra XU
interrupt problem.
By the time we get to construct_default_ioirq_mptable(), we know we have an
ISA/PCI machine without any IRQ entries in the MP table. At this point the
kernel would just set up all the IRQ entries as
I propose a patch of mpparse.c (patched against 2.4.2) to fix the Vectra XU
interrupt problem.
By the time we get to construct_default_ioirq_mptable(), we know we have an
ISA/PCI machine without any IRQ entries in the MP table. At this point the
kernel would just set up all the IRQ entries as
>From: Alan Cox <[EMAIL PROTECTED]>
>
> > So PCI interrupts must always be level triggered? If so, then the kernel
> > should never program the IO APIC to use an edge triggered interrupt on a
>PCI
> > device. If that's true, then why not force the interrupt type to level
> > triggered for all
From: Alan Cox [EMAIL PROTECTED]
So PCI interrupts must always be level triggered? If so, then the kernel
should never program the IO APIC to use an edge triggered interrupt on a
PCI
device. If that's true, then why not force the interrupt type to level
triggered for all PCI devices (to
>From: "Dunlap, Randy" <[EMAIL PROTECTED]>
>
> > -Original Message-
> > From: John William [mailto:[EMAIL PROTECTED]]
> > If PCI interrupts are shared, force them to be level
> > triggered? Can shared
> > PCI interrupts be edge trig
I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU 5/90. This is
an old dual-pentium (Neptune chipset) machine.
The machine has an on-board SCSI and ethernet controller, and I have added a
Netgear FA310TX card. Due to the "unique" design of the motherboard, all the
PCI slots share
I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU 5/90. This is
an old dual-pentium (Neptune chipset) machine.
The machine has an on-board SCSI and ethernet controller, and I have added a
Netgear FA310TX card. Due to the "unique" design of the motherboard, all the
PCI slots share
From: "Dunlap, Randy" [EMAIL PROTECTED]
-Original Message-
From: John William [mailto:[EMAIL PROTECTED]]
snip
If PCI interrupts are shared, force them to be level
triggered? Can shared
PCI interrupts be edge triggered? If not, then wouldn't this
be the correct
22 matches
Mail list logo
