Hi Jesse,
Brandeburg, Jesse wrote:
>> 05:02.0 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet
>> Controller (rev 03)
>> 05:02.1 Ethernet controller: Intel Corporation 82546GB Gigabit Ethernet
>> Controller (rev 03)
>
> This chip is connected over PCI-X and should be significantly
hat's the only one I found so far: http://lkml.org/lkml/2005/3/10/213
--
Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics
Callinstrasse 38, 30167 Hannover, Germany
Phone/Fax: +49 511 762-17185 / -17193
http://www.top500.org/system/9234 | http://www.top
Hi Auke,
Kok, Auke wrote:
>
> if you have udev installed and running you can just edit:
>
> /etc/udev/rules.d/70-persistent-net.rules
>
> to rename the devices persistently. No ugly firmware hacks needed.
That's too far down the road as the kernel needs to make the inquieries
already and udev
Bummer.
I guess I was too focused to get the 'ordering' right, i.e. to have eth0
and eth1 on the motherboard and then eth2 and eth3 on the PCIe card,
that I totally oversaw this part of my 'kernel line':
ip=:eth0:dhcp
Probably i just need to put eth2 here.
If that's the cure, sorry for the
Hi all,
Brandeburg, Jesse wrote:
>
> if your add-in nics are e1000 server adapters they can be configured to PXE
> boot too. You have to enable option rom support in the BISO and the option
> rom itself.
I don't see these cards in the BIOS right now only the onboard ones.
I've enabled everyth
Hi Roman,
Roman Chertov wrote:
> I frequently use this on CentOS as I have some machines with 10 NICs.
> You can try to see how CentOS/RH do it so that you can use it on your
> own distribution. In /etc/sysconfig/network-scripts there are files
> like ifcfg-ethX. There you can specify the MAC an
Carsten Aulbert wrote:
ions during installation, but that's really hacky.
>
> If you know of a tool to activate PXE on the add-on NICs please let me
> know. I'll try to find out the IDs now.
>
OK, I suspect the NICs are just too new for the 2.6.23 kernel (and also
for t
Carsten Aulbert wrote:
> I'm currently looking through the device IDs which module to use for these.
OK, found the igb kernel driver for that one. I'll try what will happen
if this is included.
Thanks for listening and suggesti
Hi all,
I hope e1000e questions are on topic here as well:
We are currently in transition from 2.6.25.9 to 2.6.27.10 (vanilla) and
hit quite a few problems with our NICs.
0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet
Controller (Copper) (rev 03)
0e:00.0 Ethernet controll
Hi John,
Ronciak, John wrote:
> For the 2.6.27 kernel you should be only using the e1000e driver. This is
> the driver needed going forward that will support the 82573 devices.
Tried (as written before) and it failed in the same manner.
>
> Have you been using jumbo frames in your previous ins
Hi again,
Carsten Aulbert wrote:
> Next thing I do is I could
> o set the MTU to 1500
> o power the system down
> o reboot into the new kernel with e1000e
> o see what happens
>
> Anything else I should/could try?
OK, did that, i.e. switched MTU manually to 1500, shutdown -
And another hi from me
I think I've found the problem.
We are using netconsole for remote logging and this one is loaded via
/etc/modules (obviously *before* DHCP is running. netconsole tries to
force its way through and in 2.6.25.9 that does not seem to be an issue,
however with the 2.6.27.10 ke
Hi Jesse,
Brandeburg, Jesse wrote:
> Carsten Aulbert wrote:
>> And another hi from me
>>
>> I think I've found the problem.
>>
>> We are using netconsole for remote logging and this one is loaded via
>> /etc/modules (obviously *before* DHCP is running.
Hi again,
Carsten Aulbert wrote:
>> you're welcome to try the attached patch (against 2.6.29-rc1 but should
>> apply)
>> but it is more a shot in the dark than an actual fix for your issue.
>
> Well, let's see. I will try it remotely now, if it fails and
Hi Jesse,
sorry for the late reply, too much other work to rank this question high
enough.
I was able to work around the problem by adding netconsole module
loading to a dhclient hook.
Brandeburg, Jesse schrieb:
>>
>> 0d:00.0 0200: 8086:108c (rev 03)
>> 0e:00.0 0200: 8086:109a
>
> ah, our good
uot;eth0", ifr_flags=IFF_BROADCAST|
IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|
IFF_RUNNING|IFF_MULTICAST}) = 0
Could this be the problem?
thanks for any suggestion!
Cheers
Carsten
--
Dr. Carsten Aulbert - Max Planck Institute for Gra
Hi Jesse
On Thursday 29 September 2011 01:12:19 Jesse Brandeburg wrote:
> This is probably the driver touching a register that prevents IPMI
> traffic from flowing to the bmc. It may be a patch that Debian made
> that broke it, I don't generally track debian's forks of the kernel. :-)
>
At leas
w to fix it.
This error seemed to be popping up here and there on this list and elsewhere,
but so far I've yet to find a definite answer ...
Cheers && TIA
Carsten
--
Dr. Carsten Aulbert - Max Planck Institute for Gravitational Physics
Callinstrasse 38, 30167 Hannover, Germany
Phone/
Hi
On Thursday 26 January 2012 18:10:57 Allan, Bruce W wrote:
> Please file a bug with this same information (plus exact kernel versions)
> at http://sourceforge.net/tracker/?atid=447449&group_id=42302
Done
https://sourceforge.net/tracker/?func=detail&aid=3480447&group_id=42302&atid=447449
ID:
Hi
On Friday 27 January 2012 08:31:06 Jesse Brandeburg wrote:
> Hi Carsten, it sounds to me like this might be related to ASPM, can you
> try the boot option pcie_aspm=off
Sorry no change :(
>
> before you do that please capture the output of lspci -vvv and attach it
> to the bug (or send it he
Hi
as this email is not showing up in the SF list archive, I'm resending it
(sorry Jesse for you receiving it again)
On Friday 27 January 2012 13:43:54 Carsten Aulbert wrote:
> Hi
>
> On Friday 27 January 2012 08:31:06 Jesse Brandeburg wrote:
> > Hi Carsten, it sounds to m
Hi
after filing https://sourceforge.net/p/e1000/bugs/496/ I thought it may
help to subscribe here (again) to help out quickly if a question arises.
If not, please feel free to scare me away with pitch forks ;)
Cheers
Carsten
--
Dr. Carsten Aulbert, Atlas cluster administration
Max Planck
Hi,
is there anything I could do about this (other than moving back to an
ancient kernel to try to work around the problem)?
These constant errors lead to all sort of NFS problems and I'm a bit
reluctant to just switch off more than 1000 servers at the moment.
Cheers
Carsten
--
Dr. Ca
move back to version
3.2 and hope that our cgroups related constraints are still satisfied.
Thanks a lot for the reply
Cheers
Carsten
--
Dr. Carsten Aulbert, Atlas cluster administration
Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
Callinstraße
24 matches
Mail list logo