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: 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 +, 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 david.woodho...@intel.com 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 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: 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: ixgbe/udev mystery
On Fri, Mar 25, 2011 at 07:01:02PM +0100, Thomas Bendler wrote: 2011/3/25 Thomas Bendler m...@bendler-net.de [...] 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: 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
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 hereh, 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: 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 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
