The issue is not the PME interrupt, the issue is that the device is going into
a state that is not valid. A live system should never ASSERT PME# line. As long
as this functionality is enable on the chip the PME will be asserted.
To avoid this unwanted condition the driver should disable PME on
Marcelo Tosatti wrote:
On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
Scott Feldman wrote:
On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC
Can you do a simple test?
Connect the two box to the same switch. ( No other box should be on the
physical bus)
1. Send packets from BoxA --- BoxB ( Record the stats)
2. Send packets from BoxB --- BoxA(Record the stats)
3. Send packets simultaneously from BoxB-BoxA and
Bukie Mabayoje wrote:
Can you do a simple test?
Connect the two box to the same switch. ( No other box should be on the
physical bus)
1. Send packets from BoxA --- BoxB ( Record the stats)
2. Send packets from BoxB --- BoxA(Record the stats)
3. Send packets
Corey Minyard wrote:
BTW, I'm also working with the person who had the trouble with the I2C
non-blocking driver updates, but we haven't figured it out yet.
Hopefully soon. (Though that has nothing to do with this patch.)
Thanks,
-Corey
H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:Moore, Eric Dean [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
EBDA - Extended Bios Data Area
Does Linux and various boot loaders(lilo/grub/etc)
having any restrictions on where and how big
memory allocated in
I will be glad to work with on this, I have some exposure to the BMC. See
text below in blue.
bukie
Corey Minyard wrote:
Mark Studebaker wrote:
is there a way to do this solely in i2c-core without having to
add support to all the drivers?
Yes and no. In order to support this
Michael Gernoth wrote:
Hi,
we have about 70 P4 uniprocessor machines (some with Hyperthreading
capable CPUs) running linux 2.4.29, which are woken up on the weekdays
by sending a WOL packet to them. The machines all have a E100 nic with
WOL enabled in the bios. The E100 driver is compiled
Michael Gernoth wrote:
On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
Do you know the official NIC product name e.g Pro/100B. I need to identify
the LAN Controller. There are differences between 557 (not sure if 557 can
do WOL), 558 and 559 how they ASSERT the PME
Michael Gernoth wrote:
On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
Do you know the official NIC product name e.g Pro/100B. I need to identify
the LAN Controller. There are differences between 557 (not sure if 557 can
do WOL), 558 and 559 how they ASSERT the PME
Scott Feldman wrote:
On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
I experience the same problems as reported by Michael Gernoth when
sending a WOL-packet to computer with a e100 NIC which is already
powered on.
I didn't look at the 2.4 case, but for 2.6, it seems e100 was enabling
Linus Torvalds wrote:
On Fri, 28 Jan 2005, Jaco Kroon wrote:
ok, how would I try this? Where can I find an example to code it from?
Sorry, I should probably be grepping ...
If the udelay() didn't work, then this one isn't worth worryign about
either. Back to the drawing board.
Can you do a simple test?
Connect the two box to the same switch. ( No other box should be on the
physical bus)
1. Send packets from BoxA ---> BoxB ( Record the stats)
2. Send packets from BoxB ---> BoxA(Record the stats)
3. Send packets simultaneously from BoxB->BoxA and
Bukie Mabayoje wrote:
> Can you do a simple test?
> Connect the two box to the same switch. ( No other box should be on the
> physical bus)
> 1. Send packets from BoxA ---> BoxB ( Record the stats)
>
> 2. Send packets from BoxB ---> BoxA(Record the st
Corey Minyard wrote:
> BTW, I'm also working with the person who had the trouble with the I2C
> non-blocking driver updates, but we haven't figured it out yet.
> Hopefully soon. (Though that has nothing to do with this patch.)
>
> Thanks,
>
> -Corey
>
>
> I will be glad to work with on this, I have some exposure to the BMC. See
> text below in blue.
>
> bukie
>
> Corey Minyard wrote:
>
>> Mark Studebaker wrote:
>>
>> > is there a way to do this solely in i2c-core without having to
>> > add support to all the drivers?
>>
>> Yes and no. In order
Michael Gernoth wrote:
> Hi,
>
> we have about 70 P4 uniprocessor machines (some with Hyperthreading
> capable CPUs) running linux 2.4.29, which are woken up on the weekdays
> by sending a WOL packet to them. The machines all have a E100 nic with
> WOL enabled in the bios. The E100 driver is
Michael Gernoth wrote:
> On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
> > Do you know the official NIC product name e.g Pro/100B. I need to identify
> > the LAN Controller. There are differences between 557 (not sure if 557 can
> > do WOL), 558 an
Michael Gernoth wrote:
> On Fri, Jan 28, 2005 at 10:53:51AM -0800, Bukie Mabayoje wrote:
> > Do you know the official NIC product name e.g Pro/100B. I need to identify
> > the LAN Controller. There are differences between 557 (not sure if 557 can
> > do WOL), 558 an
David Härdeman wrote:
> Hi,
>
> (third question to LKML today =)
>
> I've recently bought an Intel SE7210TP1-E mainboard (specs here:
> http://www.intel.com/design/servers/boards/SE7210TP1-E/index.htm) and I
> now have most things working.
>
> There are however, two questionmarks left.
>
> 1)
Scott Feldman wrote:
> On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > I experience the same problems as reported by Michael Gernoth when
> > sending a WOL-packet to computer with a e100 NIC which is already
> > powered on.
>
> I didn't look at the 2.4 case, but for 2.6, it seems e100 was
Linus Torvalds wrote:
> On Fri, 28 Jan 2005, Jaco Kroon wrote:
> > >>
> > >>ok, how would I try this? Where can I find an example to code it from?
> > >> Sorry, I should probably be grepping ...
> > > If the udelay() didn't work, then this one isn't worth worryign about
> > > either. Back to
The issue is not the PME interrupt, the issue is that the device is going into
a state that is not valid. A live system should never ASSERT PME# line. As long
as this functionality is enable on the chip the PME will be asserted.
To avoid this unwanted condition the driver should disable PME on
Marcelo Tosatti wrote:
> On Sun, Jan 30, 2005 at 08:23:47PM -0800, Bukie Mabayoje wrote:
> >
> > Scott Feldman wrote:
> >
> > > On Sun, 2005-01-30 at 09:18, David Härdeman wrote:
> > > > I experience the same problems as reported by Michael Gernoth whe
"H. Peter Anvin" wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:"Moore, Eric Dean" <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > EBDA - Extended Bios Data Area
> >
> > Does Linux and various boot loaders(lilo/grub/etc)
> > having any restrictions on where and how big
25 matches
Mail list logo