On Wed, Jun 18, 2008 at 12:18:30PM -0700, Brandeburg, Jesse wrote:
> > # cat /proc/interrupts
> > 10: 2296XT-PIC-XTata_piix, eth0, eth1
>
> whats wrong with your system that you can't use acpi and/or apic? It
> would probably orthoginally solve the problem by unsharing your
> in
IOCTLs to network interfaces are called under rtnl_lock(), so only one
IOCTL to any network interface in the system will be active at a time.
See dev_ioctl() in net/core/dev.c.
John's right, you most likely want a packet socket. See man packet.
- Chris
Ronciak, John wrote:
> An IOCTL to a driver
An IOCTL to a driver is going to block until satisfied. This means that
even with 4 interfaces running each IOCTL will be blocking in each
instance of the driver. You have not said how many processor you have
running. My guess is if you have each of the 4 interfaces running on a
separate proces
* Kok, Auke <[EMAIL PROTECTED]> wrote:
> You only complain and do not provide a single solution to your
> problem. [...]
i have reported the problem and even provided a fix.
I have triggered an e1000/e1000e related problem that got introduced in
the v2.6.25 merge window - one of my testboxes
Hi,
I am leaving the older message just for the sake of continuity in case you need
to know any of the history.
We're using Intel Pro/1000 VT with RHEL 5.2 and trying to use IOCTL to send and
receive data. We're
using the igb driver but there's some change we put in to get the packet right
aft
On Thursday 19 June 2008 01:05, Ingo Molnar wrote:
>
> ok, that looks much better! i have another box with e1000, ich7:
>
> 64 bytes from titan (10.0.1.14): icmp_seq=5 ttl=64 time=0.345 ms
> 64 bytes from titan (10.0.1.14): icmp_seq=6 ttl=64 time=1.03 ms
> 64 bytes from titan (10.0.1.14): icmp_se
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Wed, 18 Jun 2008 14:25:28 -0700
> You only complain and do not provide a single solution to your
> problem. Your continued screaming and whining is totally not
> productive nor constructive at all, and frankly is insulting since
> you completely ignore t
* Denys Fedoryshchenko <[EMAIL PROTECTED]> wrote:
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > with e1000e i get:
> >
> > 64 bytes from europe (10.0.1.15): icmp_seq=1 ttl=64 time=0.212 ms
> > 64 bytes from europe (10.0.1.15): icmp_seq=2 ttl=64 time=0.372 ms
> > 64 bytes from europe (10.0.
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> with e1000e i get:
>
> 64 bytes from europe (10.0.1.15): icmp_seq=1 ttl=64 time=0.212 ms
> 64 bytes from europe (10.0.1.15): icmp_seq=2 ttl=64 time=0.372 ms
> 64 bytes from europe (10.0.1.15): icmp_seq=3 ttl=64 time=0.815 ms
> 64 bytes from europe (
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Kok, Auke <[EMAIL PROTECTED]> wrote:
>
> > > Any ideas about what i should try next?
> >
> > have you tried e1000e?
>
> will try it.
ok, i tried it now, and there's good news: the latency problem seems
largely fixed by e1000e. (yay!)
with e1000 i
Ingo Molnar wrote:
> * Kok, Auke <[EMAIL PROTECTED]> wrote:
>
>>> Any ideas about what i should try next?
>> have you tried e1000e?
>
> will try it.
>
> But even it if solves the problem it's a nasty complication: given how
> many times i have to bisect back into the times when there was only
* Kok, Auke <[EMAIL PROTECTED]> wrote:
> > Any ideas about what i should try next?
>
> have you tried e1000e?
will try it.
But even it if solves the problem it's a nasty complication: given how
many times i have to bisect back into the times when there was only
e1000 around, how do i handle
Srivatsa Vaddagiri wrote:
> Hi,
> I happened to look at a system which was exhibiting poor ping
> performance with e1000 driver (in 2.6.25) and had some questions
> regarding that.
> ...
> Upon some investigation, I found that the interrupt count field in
> /proc/interrupts (associated with
Jeff, I think your patch got messed up when you pulled it into your
git branch. I'm attaching the patch again, Please update the patch and
make sure to compile it before sending it out
Thanks
-Malli
commit fc98f1631f62b68d70d4dd0db9b2b9b3fe19c5b5
Author: Malli <[EMAIL PROTECTED]>
Date: Wed Jun 1
Anders Grafström wrote:
David Acker wrote:
> What is the status of this patch?
Jeff merged it in netdev-2.6#upstream so it is queued for 2.6.25.
>
> The e100 driver broke in 2.6.25 on the ixp4xx based platform I'm using.
> This patch seems to be the cause.
>
> It appears to wor
Ingo Molnar wrote:
> * David Miller <[EMAIL PROTECTED]> wrote:
>
>> From: Ingo Molnar <[EMAIL PROTECTED]>
>> Date: Tue, 17 Jun 2008 11:27:06 +0200
>>
>>> when i originally reported it i debugged it back to missing e1000 TX
>>> completion IRQs. I tried various versions of the driver to figure
>>>
>>> David Acker wrote:
What is the status of this patch?
>>>
>>> Jeff merged it in netdev-2.6#upstream so it is queued for 2.6.25.
The e100 driver broke in 2.6.25 on the ixp4xx based platform I'm using.
This patch seems to be the cause.
It appears to work again with pci_dma_sync_single_for_d
Hello:
We are specialized in new network products, including switch, firewall,
router, GBIC,SFP,WIC,cables etc... We provide high quality products and the
most reasonable price with professional services to our customers. So if you
are interested in any of our products, please contact with
Hi,
I happened to look at a system which was exhibiting poor ping
performance with e1000 driver (in 2.6.25) and had some questions regarding that.
Ping test was done between the system and a laptop, which were connected
using a straight ethernet cable. Ping reported round trip times runnin
19 matches
Mail list logo