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:
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 that
>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
>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
>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 u
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 (ker
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 >bloc
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 PCI
>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 a
12 matches
Mail list logo
