Here's a summary of the current state of the Linux PCI subsystem, as of
2.6.18-rc6.
If the information in here is incorrect, or anyone knows of any
outstanding issues not listed here, please let me know.
List of outstanding regressions from 2.6.17:
- none known.
List of outstanding regressions from older kernel versions:
- none known.
If interested, the list of all currently open PCI bugs can be seen at:
http://bugzilla.kernel.org/showdependencytree.cgi?id=5829&hide_resolved=1
Future patches that are currently in my quilt tree (as found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
) for the PCI subsystem are as follows. All of these will be submitted
for inclusion into 2.6.19, except as noted:
- MSI rework currently being tested out in the -mm tree.
- PCI Express AER implementation.
- few minor PCI Hotplug driver fixes and cleanups.
- resource minor tweak.
- PCI sort device lists in breadth-first to fix the regression
of PCI device order from the 2.4 kernel tree. This can be
disabled by a command line option if anyone is wed to the old
2.6 buggy way.
Note that there are some PCI API changes that happen in my driver tree.
See that status report for details on those changes (nothing was done to
break anything, only new stuff was added.)
No other new PCI driver API changes are pending that I am aware of. The
PCI sort order change will affect some people's userspace ordering of
network devices, restoring it to the proper 2.4 ordering. It was never
intended that this be broken, and since no one has noticed this for the
past 3 years, it was not broken in a severe way.
thanks,
greg k-h
Hi Greg!
> No other new PCI driver API changes are pending that I am aware of. The
> PCI sort order change will affect some people's userspace ordering of
> network devices, restoring it to the proper 2.4 ordering. It was never
> intended that this be broken, and since no one has noticed this for the
> past 3 years, it was not broken in a severe way.
Changing the device order in the middle of the 2.6 cycle doesn't sound
like a sane idea to me. Many people have changed their systems' configuration
to adapt to the 2.6 ordering and this patch would break their setups.
I have seen many such examples in my vicinity.
I believe that not breaking existing 2.6 setups is much more important
than keeping compatibility with 2.4 kernels, especially when the problem
is discovered after more than 2 years after release of the first 2.6.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
How do I type 'for i in *.dvi ; do xdvi $i ; done' in a GUI?
On Sat, Sep 09, 2006 at 10:39:32AM +0200, Martin Mares wrote:
> Hi Greg!
>
> > No other new PCI driver API changes are pending that I am aware of. The
> > PCI sort order change will affect some people's userspace ordering of
> > network devices, restoring it to the proper 2.4 ordering. It was never
> > intended that this be broken, and since no one has noticed this for the
> > past 3 years, it was not broken in a severe way.
>
> Changing the device order in the middle of the 2.6 cycle doesn't sound
> like a sane idea to me. Many people have changed their systems' configuration
> to adapt to the 2.6 ordering and this patch would break their setups.
> I have seen many such examples in my vicinity.
>
> I believe that not breaking existing 2.6 setups is much more important
> than keeping compatibility with 2.4 kernels, especially when the problem
> is discovered after more than 2 years after release of the first 2.6.
Respectfully, With the current 2.6 development model (i.e. the lack of
a 2.7), how are we to address this kind of thing? I'd like to see it
fixed in all new distro releases that base on 2.6.18-2.6.19, and it'll be an
individual distro decision to apply to existing releases (somewhat
unlikely). I'm open to suggestions. Udev rules like what opensuse
use would keep the existing names constant, as would the Red Hat
ifcfg-eth* method, so at least those distro users are OK. We really
need this at install time to get the naming right in the first place.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Hello!
> Respectfully, With the current 2.6 development model (i.e. the lack of
> a 2.7), how are we to address this kind of thing? I'd like to see it
> fixed in all new distro releases that base on 2.6.18-2.6.19, and it'll be an
> individual distro decision to apply to existing releases (somewhat
> unlikely). I'm open to suggestions. Udev rules like what opensuse
> use would keep the existing names constant, as would the Red Hat
> ifcfg-eth* method, so at least those distro users are OK. We really
> need this at install time to get the naming right in the first place.
The problem is that there is nothing as a single "right". There exists no
consistent definition of how should the ordering look like and the fact
that 2.4 and 2.6 differ are just a consequence of that.
>From the point of view of 2.4 users, the "right" definition is the one used
by 2.4 kernels.
>From the point of view of 2.6 users, the only right definition is the current one.
For people installing Linux from scratch, it doesn't matter because neither
definition has any advantage, both give unstable results when new devices
are plugged in.
Moreover, the depth-first order is probably a little bit more stable,
because on-board buses usually have lower numbers than buses where hotpluggable
devices live (e.g., cardbus), so newly plugged devices are nicely ordered
after all built-in ones.
If you want to have stable names, use udev, relying on any order is wrong
as new devices can always appear anywhere.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
How an engineer writes a program: Start by debugging an empty file...
On Sat, Sep 09, 2006 at 01:18:16AM -0700, Greg KH wrote:
> No other new PCI driver API changes are pending that I am aware of. The
You said you were going to do the s/hotplug_slot/pci_slot/ change for
submission in the next round of patches.
On Sat, Sep 09, 2006 at 07:25:38AM -0600, Matthew Wilcox wrote:
> On Sat, Sep 09, 2006 at 01:18:16AM -0700, Greg KH wrote:
> > No other new PCI driver API changes are pending that I am aware of. The
>
> You said you were going to do the s/hotplug_slot/pci_slot/ change for
> submission in the next round of patches.
Ah yeah, sorry, that's in my queue, forgot to mention it.
greg k-h