On Sat, 4 Aug 2007, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
On Fri, 3 Aug 2007, Stefan Richter wrote:
There is a variety of possible naming schemes:
- Naming by order of discovery.
- Naming by vendor/model name strings.
- Naming by universally unique identifier.
- Naming by topolog
[EMAIL PROTECTED] wrote:
> On Fri, 3 Aug 2007, Stefan Richter wrote:
>> There is a variety of possible naming schemes:
>>
>> - Naming by order of discovery.
>> - Naming by vendor/model name strings.
>> - Naming by universally unique identifier.
>> - Naming by topology.
>> - ...
>>
>> Only the
On Fri, 3 Aug 2007, Stefan Richter wrote:
[EMAIL PROTECTED] wrote:
On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
It does not rename ethX to the "next free" one, but to a _persistent_ one.
If it were a "next free" thing, then removing
[EMAIL PROTECTED] wrote:
> On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
>> On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
>>> It does not rename ethX to the "next free" one, but to a _persistent_ one.
>>> If it were a "next free" thing, then removing a card would shuffle all
>>> your
On Aug 3 2007 00:49, Kay Sievers wrote:
>> I think it is helpful to integrate the suse patch rather than to patch udev
>> alone. This way, renames that do not involve udev also show up.
>
>But if you need to swap interface names, you will see the useless
>temporary device names. On SUSE, nothing e
On Thu, 2 Aug 2007, Ondrej Zajicek wrote:
On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
It does not rename ethX to the "next free" one, but to a _persistent_ one.
If it were a "next free" thing, then removing a card would shuffle all
your eth around again (and invalidate your
On Fri, 2007-08-03 at 00:39 +0200, Jan Engelhardt wrote:
> On Aug 3 2007 00:00, Kay Sievers wrote:
> >On 8/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >> I know I have seen my kernel outputting "A renamed to B". Since you two
> >> however wanted that information in the first place, I grepped
On Aug 3 2007 00:00, Kay Sievers wrote:
>On 8/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>> I know I have seen my kernel outputting "A renamed to B". Since you two
>> however wanted that information in the first place, I grepped a bit
>> around, and actually found, (drumroll), that the SUSE k
On 8/2/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> I know I have seen my kernel outputting "A renamed to B". Since you two
> however wanted that information in the first place, I grepped a bit
> around, and actually found, (drumroll), that the SUSE kernel has had a
> proper patch for [I can't r
Hey,
I know I have seen my kernel outputting "A renamed to B". Since you two
however wanted that information in the first place, I grepped a bit
around, and actually found, (drumroll), that the SUSE kernel has had a
proper patch for [I can't remember how long] quite some time. (At least
one d
On Thu, Aug 02, 2007 at 01:47:23PM +0200, Jan Engelhardt wrote:
> It does not rename ethX to the "next free" one, but to a _persistent_ one.
> If it were a "next free" thing, then removing a card would shuffle all
> your eth around again (and invalidate your iptables rules at the same
> time, to no
On Thu, Aug 02, 2007 at 05:36:45PM +0400, Michael Tokarev wrote:
> not become required (it is slowly becoming - for example, some
> packages on Debian (like xen for example) now explicitly depends
> on udev - but so far I managed to satisfy this dependency by
> other means).
udev is not problem -
> >And now tell me please how can I connect two messages from dmesg:
> >eth0: Tigon3 [partno(BCM95721) rev 4201 PHY(5750)] (PCI Express)
> >10/100/1000Base-T Ethernet 00:14:5e:5d:18:26
> >nic10: Link is up at 100 Mbps, full duplex.
>
> Generally, the "link is xyz" message comes directly after loa
On Aug 2 2007 17:07, Michael Tokarev wrote:
>Jan Engelhardt wrote:
>> On Aug 2 2007 12:56, Herbert Rosmanith wrote:
On Aug 2 2007 12:42, Herbert Rosmanith wrote:
There never *were* days when eth0 remained eth0 across such changes.
>>> but there *were* days when eth0 was eth0, if the kern
Jan Engelhardt wrote:
> On Aug 2 2007 16:56, Michael Tokarev wrote:
I already can see comments from udev/sysfs maintainers here: "naming
is a policy which does not belong to kernel". It's a bullshit, because
kernel too has to use SOME way to name things,
>>> (1) The kernel starts wi
On Aug 2 2007 16:56, Michael Tokarev wrote:
>>> I already can see comments from udev/sysfs maintainers here: "naming
>>> is a policy which does not belong to kernel". It's a bullshit, because
>>> kernel too has to use SOME way to name things,
>>
>> (1) The kernel starts with ethX
>> (2) udev ren
Jan Engelhardt wrote:
> On Aug 2 2007 12:56, Herbert Rosmanith wrote:
>>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>>> There never *were* days when eth0 remained eth0 across such changes.
>> but there *were* days when eth0 was eth0, if the kernel reports it as such.
>> now there is no eth0 at
Jan Engelhardt wrote:
> On Aug 2 2007 15:23, Michael Tokarev wrote:
>> Herbert Rosmanith wrote:
On Aug 2 2007 12:42, Herbert Rosmanith wrote:
There never *were* days when eth0 remained eth0 across such changes.
>> []
>>> of course, that's problem with gentoo, not with the kernel.
>> To me
On Aug 2 2007 14:00, Herbert Rosmanith wrote:
>> Wait, you forget that something may change the name. That dmesg message
>> from 1 second ago does not need to be valid anymore, just as anything
>> else in this world.
>
>there are many things in this world which are usually very persistent, and
>pe
> Wait, you forget that something may change the name. That dmesg message
> from 1 second ago does not need to be valid anymore, just as anything
> else in this world.
there are many things in this world which are usually very persistent, and
people rely on their persistence. e.g. in my office,
On Aug 2 2007 12:56, Herbert Rosmanith wrote:
>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>> There never *were* days when eth0 remained eth0 across such changes.
>
>but there *were* days when eth0 was eth0, if the kernel reports it as such.
>now there is no eth0 at all. if I see an "eth0" fro
On Aug 2 2007 15:23, Michael Tokarev wrote:
>Herbert Rosmanith wrote:
>>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>>> There never *were* days when eth0 remained eth0 across such changes.
>[]
>> of course, that's problem with gentoo, not with the kernel.
>
>To me it'd be a problem, but I don'
Herbert Rosmanith wrote:
>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>> There never *were* days when eth0 remained eth0 across such changes.
[]
> of course, that's problem with gentoo, not with the kernel.
Whenever it's a problem or not is questionable too. I mean,
ethX order depends on modu
> > cards around), eth0 would also suddenly become a different one. There never
> > *were* days when eth0 remained eth0 across such changes.
>
> but there *were* days when eth0 was eth0, if the kernel reports it as such.
> now there is no eth0 at all. if I see an "eth0" from dmesg, I expect
> it
>
> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
> There never *were* days when eth0 remained eth0 across such changes.
but there *were* days when eth0 was eth0, if the kernel reports it as such.
now there is no eth0 at all. if I see an "eth0" from dmesg, I expect
it to be present.
Instead, ude
On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>
>hu. where are the days when eth0 was eth0 ...
If you and/or your distribution accidentally or incidentally loaded modules in
the wrong order (which may happen in e.g. parallel-running boot scripts), you
suddenly have eth0 as eth1. Or, when you chan
On Aug 2 2007 12:20, Herbert Rosmanith wrote:
>
>I see a strange numbering of ethernet devices with a VIA EPIA EK
>board. This board has two ethernet connectors, you can see it
>here:
>http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=420
Maybe udev is configured to do
>
> Strange or not, correct or not - depends on the point of view.
>
> The key word here is "udev" - check your udev rules. Since some time
> ago udev on some distros comes with rules to give persistent device
> names for network interfaces. Some time ago you had eth0 and eth1
> with different
Herbert Rosmanith wrote:
> hi,
Hello.
[]
> When doing the module load, the kernel says:
> eth0: VIA Rhine III at 0x1d000, 00:40:63:ee:96:56, IRQ 17.
> eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link
> 45e1.
> eth1: VIA Rhine II at 0x1ec00, 00:40:63:ee:96:55, IRQ
hi,
I see a strange numbering of ethernet devices with a VIA EPIA EK
board. This board has two ethernet connectors, you can see it
here:
http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=420
I configured the system such that via-rhine is loaded as a module.
When doing
30 matches
Mail list logo