Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote: > On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: > > On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: > > > On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: > > > > The challenge here is that because struct netdev is initialized to all > > > > zeros, code that consumes dev_id can't tell the difference between a > > > > driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a > > > > default (unset) value of 0. I think the only solution here is to make > > > > sure the kernel drivers, if they need to set it, always set this > > > > non-zero, so udev, seeing a non-zero value, knows it's a valid value > > > > to use. > > > > > > These seem to be the 4 drivers currently setting dev_id: > > > > > > drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: > > > adap->port[i]->dev_id = j; > > > drivers/net/ethernet/freescale/fec.c: fep->dev_id = dev_id++; > > > > Look up a few lines: > > > > /* setup board info structure */ > > fep = netdev_priv(ndev); > > > > fep is not a pointer to the net_device, but to the private device > > structure. This is why I didn't include it in the list. > > Good catch. > > > > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id = port - 1; > > > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = > > > EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; > > > > > > of these, both the mlx4 and siena drivers set them starting at 0. I > > > think the fec driver might be doing so as well, but it's not as > > > obvious. I'm pretty sure cxgb4 starts numbering at 1 just from > > > reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be > > > comfortable relying on the value of dev_id. > > > > I agree it looks like some cleanup is needed due to the inconsistency. > > > > This is still only an issue when a single function supports multiple > > ethernet devices, right? > > I believe so, yes. > Ok, good. I did like your idea to possibly set this to something other than 0 in the default case and then make sure that any driver that needs to set it can do so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: > On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: > > On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: > > > On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: > > > > Matt Domsch (matt_dom...@dell.com) said: > > > > > On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: > > > > > > > If we can solve the installtime naming convention choice to not > > > > > > > eliminate biosdevname, be able to disable systemd/udevd naming, > > > > > > > and > > > > > > > have the default be possible on a per-system-vendor basis, and > > > > > > > solve > > > > > > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this > > > > > > > proposal. Without fixing these shortcomings though, my customers > > > > > > > will > > > > > > > have a fit at me. > > > > > > > > > > > > If you're agreeing that biosdevname should be limited to > > > > > > type9/type41 > > > > > > (if I'm reading you right), and if the systemd/udev names still use > > > > > > those > > > > > > fields, what parts of biosdevname are you still requiring? The > > > > > > actual > > > > > > namespace used, or something else? > > > > > > > > > > I'd prefer if we didn't force users through another namespace change. > > > > > I took a lot of flack for changing the namespace once. From their > > > > > perspective, it's still udev doing the renaming, only now the code > > > > > moved from a udev helper into udev itself. > > > > > > > > True; the users likely don't care other than how they enable/disable it. > > > > > > > > > I'd like to see the SR-IOV & NPAR devices handled. Those aren't > > > > > represented in type9/type41, and their commonplace on Dell systems. > > > > > > > > > > I'd like to see the Dell-specific PCI VPD-R code from biosdevname > > > > > included in udev, as that's used to map multi-port devices to port > > > > > numbers. Those aren't represented in type9/type41, and they're > > > > > commonplace on Dell systems. > > > > > > > > OK. > > > > > > > > > I'd like to see kernel driver work to be sure every multi-port driver > > > > > with the same PCI b/d/b/f sets dev_id. That isn't necessarily true > > > > > today, which makes it hard to trust. biosdevname needs this too, > > > > > until such a time as it's dead. > > > > > > > > Do we have a list of these, or is it a matter of doing a driver audit? > > > > CC'ing gospo. > > > > > > (Thanks, Bill, though I've been following this thread as I am on the > > > list). > > > > > > Right now almost no drivers actually set dev_id. In fact mlx4_en, > > > cxgb4, and sfc seem to be the only ones right now. If we feel like this > > > a requirement there will be work on the kernel side to add this. > > > > The challenge here is that because struct netdev is initialized to all > > zeros, code that consumes dev_id can't tell the difference between a > > driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a > > default (unset) value of 0. I think the only solution here is to make > > sure the kernel drivers, if they need to set it, always set this > > non-zero, so udev, seeing a non-zero value, knows it's a valid value > > to use. > > These seem to be the 4 drivers currently setting dev_id: > > drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap->port[i]->dev_id > = j; > drivers/net/ethernet/freescale/fec.c: fep->dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id = port - 1; > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = > EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; > > of these, both the mlx4 and siena drivers set them starting at 0. I > think the fec driver might be doing so as well, but it's not as > obvious. I'm pretty sure cxgb4 starts numbering at 1 just from > reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be > comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: > Matt Domsch (matt_dom...@dell.com) said: > > On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: > > > > If we can solve the installtime naming convention choice to not > > > > eliminate biosdevname, be able to disable systemd/udevd naming, and > > > > have the default be possible on a per-system-vendor basis, and solve > > > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this > > > > proposal. Without fixing these shortcomings though, my customers will > > > > have a fit at me. > > > > > > If you're agreeing that biosdevname should be limited to type9/type41 > > > (if I'm reading you right), and if the systemd/udev names still use those > > > fields, what parts of biosdevname are you still requiring? The actual > > > namespace used, or something else? > > > > I'd prefer if we didn't force users through another namespace change. > > I took a lot of flack for changing the namespace once. From their > > perspective, it's still udev doing the renaming, only now the code > > moved from a udev helper into udev itself. > > True; the users likely don't care other than how they enable/disable it. > > > I'd like to see the SR-IOV & NPAR devices handled. Those aren't > > represented in type9/type41, and their commonplace on Dell systems. > > > > I'd like to see the Dell-specific PCI VPD-R code from biosdevname > > included in udev, as that's used to map multi-port devices to port > > numbers. Those aren't represented in type9/type41, and they're > > commonplace on Dell systems. > > OK. > > > I'd like to see kernel driver work to be sure every multi-port driver > > with the same PCI b/d/b/f sets dev_id. That isn't necessarily true > > today, which makes it hard to trust. biosdevname needs this too, > > until such a time as it's dead. > > Do we have a list of these, or is it a matter of doing a driver audit? > CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. > > So, aside from the naming convention change (which, hey, if someone > > else takes the pain for making that change again, not me or my company > > - go nuts!), the rest is straightforward technical and code can be > > cribbed if desired from biosdevname or just rewritten. > > OK, thanks. Let's see what we can do here. My concern is the conflict > between trying to cover all of the cases, and trying to avoid writing > documentation that is a lot of "if your device is , then your > name is Y or Z depending on which commandline you booted with when you > installed.' > > Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ixgbe/udev mystery
On Fri, Mar 25, 2011 at 07:01:02PM +0100, Thomas Bendler wrote: > 2011/3/25 Thomas Bendler > > > [...] > > > One remark, the error occured with the standard ixgbe module (2.0.62-k2), so > > I upgraded the module to the latest version (3.2.10-NAPI) but still have the > > same error. > > > > And another remark, the network card work without problems when using Ubuntu > 11.04.2 instead of Fedora (ixgbe driver version 2.0.44-k2). > So like the older Ubuntu driver works fine, but newer drivers in Fedora or the Intel SourceForge driver are problematic. It sounds like you must be either failing an additional check that was added or hitting some sort of regression that was introduced between driver version 2.0.44-k2 and 2.0.62-k2. I don't have any great suggestions about why this is broken, but I would suggest you open a bug at bugzilla.redhat.com with the full details of this failure. If you let me know what the bug # is (email is fine) after you open it, I'll make sure the right folks take a look. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ixgbe/udev mystery
On Fri, Mar 25, 2011 at 01:46:28PM +0100, Thomas Bendler wrote:
> Hi @all,
>
> I've setup a F14 box (minimal install) on a Supermicro server. So far, so
> good. After some configuration (mainly automtic stuff done by puppet) and a
> reboot I noticed that only the 1Gb network cards where configured but not
> the 10Gb cards. I didn't even see eth2 and eth3 using ifonfig -a. A look
> into /etc/udev/rules.d/70-persistent-net.rules shows only entries for the
> 1Gb cards:
>
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single
> # line, and change only the value of the NAME= key.
>
> # PCI device 0x8086:0x1096 (e1000e) (custom name provided by external tool)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:30:48:d7:1c:9e", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth0"
>
> # PCI device 0x8086:0x1096 (e1000e) (custom name provided by external tool)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:30:48:d7:1c:9f", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth1"
>
> So I've added the 10Gb cards manually (from an Ubuntu installation on an
> equal box):
>
> # PCI device 0x8086:0x10ec (ixgbe)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:1b:21:3b:6c:19", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth2"
>
> # PCI device 0x8086:0x10ec (ixgbe)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:1b:21:3b:6c:18", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="eth3"
>
> So I also added ifcfg-eth2 and ifcfg-eth3 to /etc/sysconfig/network-scripts
> with something like this (real IP configuration will be done later):
>
> DEVICE="eth2"
> HWADDR="00:1b:21:3b:6c:19"
> NM_CONTROLLED="yes"
> ONBOOT="no"
>
> Now the funny stuff starts, after the first reboot the devices eth2 and eth3
> shown up typing ifconfig -a. After the second reboot the eth2 and eth3
> interface disappeared again and I now see in dmesg:
>
> [6.159363] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
> version 2.0.62-k2
> [6.159367] ixgbe: Copyright (c) 1999-2010 Intel Corporation.
> [6.159425] ixgbe :0c:00.0: enabling device ( -> 0002)
> [6.159435] ixgbe :0c:00.0: PCI->APIC IRQ transform: INT B -> IRQ 17
> [6.159449] ixgbe :0c:00.0: setting latency timer to 64
> [...]
> [7.039039] ixgbe :0c:00.0: HW Init failed: -15
> [7.039077] ixgbe: probe of :0c:00.0 failed with error -15
> [7.039099] ixgbe :0c:00.1: enabling device ( -> 0002)
> [7.039108] ixgbe :0c:00.1: PCI->APIC IRQ transform: INT A -> IRQ 16
> [7.039119] ixgbe :0c:00.1: setting latency timer to 64
> [7.895037] ixgbe :0c:00.1: HW Init failed: -15
> [7.895056] ixgbe: probe of :0c:00.1 failed with error -15
>
> Any ideas?
>
Your devices are not showing up because the driver is failing to load.
Erroe -15 is IXGBE_ERR_RESET_FAILED, so it seems there is either
something wrong with your cards of you are hitting a driver bug.
You should probably turn on dynamic debugging for the ixgbe module and
see if you can figure out what might be going wrong. A guide for using
dynamic debugging can be found in Documentation/dynamic-debug-howto.txt.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bnx2 driver fails to load on Fedora Rawhide
On Tue, Jan 18, 2011 at 10:56:22PM +, David Woodhouse wrote: > On Tue, 2011-01-18 at 15:07 -0500, Andy Gospodarek wrote: > > and that explains how we missed the bnx2 firmware changes. Does this > > mean you will not be merging from Linus going forward? > > We'll be *removing* the legacy firmware/ directory from Linus' tree. > > I didn't intend to merge from there at all, after the linux-firmware.git > tree started. It was evidently a *mistake* to do it the last time; it > only served to mask the issue and Michael didn't realise there was a > problem. > Fair enough. Thanks, -andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bnx2 driver fails to load on Fedora Rawhide
On Tue, Jan 18, 2011 at 12:00:57PM +, David Woodhouse wrote: > On Mon, 2011-01-17 at 15:04 +0000, Andy Gospodarek wrote: > > > > It looks like that firmware is in Linus' tree, but somehow it is not in > > Woodhouse's linux-firmware tree. That seems odd. > > Yeah, that's just broken. If the driver/firmware ABI changes > incompatibly and the kernel gets updated so that it can no longer use > the older firmware, then driver maintainers *need* to put the new > firmware into the firmware tree so that it actually gets to users. > > In this case it looks like they only updated the legacy firmware/ > directory in the kernel source itself, that people don't really use any > more and that is going to be going away real soon now. That's not very > useful. > > Michael? Did you submit the new firmware for linux-firmware.git and I > just missed it? If so, I apologise; please could you resend? > David, I seemed to recall that you were initially pulling (just copying with a cronjob, iirc) files from firmware/ in Linus' tree to your linux-firmware git tree. That was why I was a bit confused that these were out of sync. I see now that the last time you did this was here: commit 72cf26d513496edfaaf6be7c605dd57f7b44e073 Merge: 2d07c7d 7936fd8 Author: David Woodhouse Date: Fri Aug 6 08:20:09 2010 +0100 Merge legacy kernel source firmware/ directory from 2.6.35 and that explains how we missed the bnx2 firmware changes. Does this mean you will not be merging from Linus going forward? Thanks, -andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bnx2 driver fails to load on Fedora Rawhide
On Mon, Jan 17, 2011 at 01:41:41AM -0800, narendr...@dell.com wrote: > Hello, > > On Fedora Rawhide bnx2 driver failed to load with the following messages on > PowerEdge R710 with BCM5709 devices.( Bugzilla Bug 670121- bnx2 driver fails > to load on rawhide). > > I observed this failure while I was setting up the box for biosdevname > related experiments. > > [ 12.680616] bnx2: Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 > v2.0.18 (Oct 7, 2010) > [ 12.681213] bnx2 :01:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36 > [ 12.681502] bnx2 :01:00.0: setting latency timer to 64 > [ 12.682141] bnx2 :01:00.0: pci_enable_pcie_error_reporting failed > 0xfffb > [ 12.830923] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.0.17.fw" > [ 12.831263] bnx2 :01:00.0: PCI INT A disabled > [ 12.831614] bnx2: probe of :01:00.0 failed with error -2 > [ 12.832099] bnx2 :01:00.1: PCI INT B -> GSI 48 (level, low) -> IRQ 48 > [ 12.832375] bnx2 :01:00.1: setting latency timer to 64 > [ 12.833126] bnx2 :01:00.1: pci_enable_pcie_error_reporting failed > 0xfffb > [ 13.115474] bnx2: Can't load firmware file "bnx2/bnx2-mips-09-6.0.17.fw" > [ 13.115804] bnx2 :01:00.1: PCI INT B disabled > [ 13.116652] bnx2: probe of :01:00.1 failed with error -2 > > > [root@fedora-14-r710 ~]# uname -r > 2.6.37-0.rc7.git0.1.fc15.x86_64 > [root@fedora-14-r710 ~]# modinfo -F version bnx2 > 2.0.18 > > With regards, > Narendra K > > It looks like that firmware is in Linus' tree, but somehow it is not in Woodhouse's linux-firmware tree. That seems odd. Copying Woodhouse to see if he has any thoughts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
On Fri, Aug 13, 2010 at 05:49:31PM +0200, Kevin Kofler wrote: > > You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla > is one of those), you can only get your poorly-written code merged if you > know the right > people. :-( > FTFY http://people.redhat.com/agospoda/pics/hackbar.jpg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: web-m and Fedora 14
On Fri, May 21, 2010 at 11:21:01AM +0200, Kevin Kofler wrote: > Peter Robinson wrote: > > I don't see when the support lands in F-13 there couldn't be press > > statements about it, just because it appears after the release doesn't > > mean its not significant and isn't worth making a statement about. > > In fact this is a big failure of our feature process, but whenever I have > brung this up in FESCo, the reaction of the other folks there was to > threaten banning that kind of updates entirely. :-/ > > Yeah, wonderful idea, let's allow everyone else to advertise WebM > support months before us just because the upstream release date > happened to be at the worst possible point of our release cycle. :-/ > > Adding features in updates is needed. Our feature process needs to > accomodate this. The current process is broken. > > Kevin Kofler > I'm not sure we need to push it all the way into F13, but a special WebM repo would be nice so this can be easily tested by any user on F13 systems in preparation for full 'support' in F14. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Realtek 8192se on F12/F13
On Mon, May 10, 2010 at 12:38:15PM +0200, Jos Vos wrote: > Hi, > > What is the status of support for the Realtek 8192se WiFi > controller in F12 and F13? > > I see in some wiki page a reference to the Realtek website, > at least for (stock) F12. > > Is this chipset in the meantime supported in the F12 kernel > and/or will it be supported in F13? https://bugzilla.redhat.com/show_bug.cgi?id=558337 Short answer, not supported yet. I build the wireless driver on my netbook whenever updating the vendor driver with the patch attached here: https://bugzilla.redhat.com/show_bug.cgi?id=558337#c4 It's a bit of a pain, but once built it works great. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
