[Bug ??] 2.6.18-rc6-mm2 - PCI ethernet board does not seem to work

[Bug ??] 2.6.18-rc6-mm2 - PCI ethernet board does not seem to work

[Pierre Peiffer]

Hi,

My Ethernet board (Intel(R) PRO/1000) "doesn't seems" to work any more
with this kernel, but all is ok with kernel 2.6.18-rc6-mm1.

A bisection search show this patch:
gregkh-pci-pci-sort-device-lists-breadth-first.patch
as being the faulty one...

But after reading the content of this patch, I understood that the order
of the ethernet boards had changed. In fact,  I have four ethernet
boards and now, my eth0 does not point on the same card...
So all is now ok by changing my cable to the right board.

But is this really the expected behavior ?


-- 
Pierre Peiffer

Re: [Bug ??] 2.6.18-rc6-mm2 - PCI ethernet board does not seem to work

[Greg KH]

On Fri, Sep 15, 2006 at 12:21:57PM +0200, Pierre Peiffer wrote:
> Hi,
> 
> My Ethernet board (Intel(R) PRO/1000) "doesn't seems" to work any more
> with this kernel, but all is ok with kernel 2.6.18-rc6-mm1.
> 
> A bisection search show this patch:
> gregkh-pci-pci-sort-device-lists-breadth-first.patch
> as being the faulty one...
> 
> But after reading the content of this patch, I understood that the order
> of the ethernet boards had changed. In fact,  I have four ethernet
> boards and now, my eth0 does not point on the same card...
> So all is now ok by changing my cable to the right board.
> 
> But is this really the expected behavior ?

Yes.  You should use a persistent name for your network devices to
prevent this from happening.

That being said, I think we need to reverse the order of this patch,
keeping the current scheme as default, and allowing it to be overridden
on the command line for those few machines where it matters to be
compatible with the old, 2.4 ordering scheme.

Matt, care to rework the patch in this manner?

thanks,

greg k-h

Re: [Bug ??] 2.6.18-rc6-mm2 - PCI ethernet board does not seem to work

[Matt Domsch]

On Fri, Sep 15, 2006 at 12:21:57PM +0200, Pierre Peiffer wrote:
> Hi,
> 
> My Ethernet board (Intel(R) PRO/1000) "doesn't seems" to work any more
> with this kernel, but all is ok with kernel 2.6.18-rc6-mm1.
> 
> A bisection search show this patch:
> gregkh-pci-pci-sort-device-lists-breadth-first.patch
> as being the faulty one...
> 
> But after reading the content of this patch, I understood that the order
> of the ethernet boards had changed. In fact,  I have four ethernet
> boards and now, my eth0 does not point on the same card...
> So all is now ok by changing my cable to the right board.
> 
> But is this really the expected behavior ?

Yes, it's expected, but no, I agree it would be nice to not break
existing setups.

Care to send me an output of 'lspci -tv' and dmidecode (the first 80
or so lines)?

I think I'll redo this patch to keep the 2.6 depth-first sort order as
default, with command line options "pci=bfsort" and "pci=nobfsort" to
force it one way or the other, and DMI table entries for Dell's newest
systems that should default to bfsort.

Pierre, thank you for you report and your time to do the bisect.  I
apologize for any inconvenience this caused you.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: [Bug ??] 2.6.18-rc6-mm2 - PCI ethernet board does not seem to work

[Pierre Peiffer]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

Matt Domsch a écrit :
> 
> Yes, it's expected, but no, I agree it would be nice to not break
> existing setups.
> 
> Care to send me an output of 'lspci -tv' and dmidecode (the first 80
> or so lines)?

Yes, sure, both are joined in the attached files.

> 
> I think I'll redo this patch to keep the 2.6 depth-first sort order as
> default, with command line options "pci=bfsort" and "pci=nobfsort" to
> force it one way or the other, and DMI table entries for Dell's newest
> systems that should default to bfsort.
> 
> Pierre, thank you for you report and your time to do the bisect.  I
> apologize for any inconvenience this caused you.

Not a problem; I was just curious to understand why my network didn't 
work anymore without really showing any kind of problems...
Next time, I will start by changing my cables before looking at 
/var/log/messages ;-)

-- 
Pierre Peiffer

[-- Attachment #2: dmidecode.txt --]
[-- Type: text/plain, Size: 2468 bytes --]

# dmidecode 2.2
SMBIOS 2.3 present.
75 structures occupying 2773 bytes.
Table at 0x000F1260.
Handle 0x0000
	DMI type 0, 20 bytes.
	BIOS Information
		Vendor: NEC Corporation  
		Version: SBR20.86B.0071.P12.0307291340   
		Release Date: 07/29/2003
		Address: 0xF0000
		Runtime Size: 64 kB
		ROM Size: 1024 kB
		Characteristics:
			PCI is supported
			PNP is supported
			BIOS is upgradeable
			BIOS shadowing is allowed
			ESCD support is available
			Boot from CD is supported
			Selectable boot is supported
			EDD is supported
			Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
			Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
			5.25"/360 KB floppy services are supported (int 13h)
			5.25"/1.2 MB floppy services are supported (int 13h)
			3.5"/720 KB floppy services are supported (int 13h)
			3.5"/2.88 MB floppy services are supported (int 13h)
			Print screen service is supported (int 5h)
			8042 keyboard services are supported (int 9h)
			Serial services are supported (int 14h)
			Printer services are supported (int 17h)
			CGA/mono video services are supported (int 10h)
			ACPI is supported
			USB legacy is supported
			LS-120 boot is supported
			ATAPI Zip drive boot is supported
			BIOS boot specification is supported
			Function key-initiated network boot is supported
Handle 0x0001
	DMI type 1, 25 bytes.
	System Information
		Manufacturer: NEC                 
		Product Name: Express5800/120Lg [N8100-864E]          
		Version: FR0.1          
		Serial Number: 80003837009    
		UUID: DC6A4BC3-9F35-D811-0080-EFC03FE90700
		Wake-up Type: Power Switch
Handle 0x0002
	DMI type 2, 8 bytes.
	Base Board Information
		Manufacturer: NEC       
		Product Name: SE7501BR2 
		Version: FRU 0.01       
		Serial Number: KRB535200285   
Handle 0x0003
	DMI type 3, 17 bytes.
	Chassis Information
		Manufacturer: NEC Corporation                
		Type: Tower
		Lock: Not Present
		Version: 856-060342-102         
		Serial Number: 05                             
		Asset Tag: Manza                          
		Boot-up State: Unknown
		Power Supply State: Unknown
		Thermal State: Unknown
		Security Status: Unknown
		OEM Information: 0x00000000
Handle 0x0004
	DMI type 4, 35 bytes.
	Processor Information
		Socket Designation: CPU 1
		Type: Central Processor
		Family: Xeon
		Manufacturer: Intel Corporation
		ID: 29 0F 00 00 FF FB EB BF
		Signature: Type 0, Family F, Model 2, Stepping 9
		Flags:
			FPU (Floating-point unit on-chip)

[-- Attachment #3: lspci-tv.txt --]
[-- Type: text/plain, Size: 1278 bytes --]

-[0000:00]-+-00.0  Intel Corporation E7501 Memory Controller Hub
           +-00.1  Intel Corporation E7500/E7501 Host RASUM Controller
           +-03.0-[0000:02-04]--+-1c.0  Intel Corporation 82870P2 P64H2 I/OxAPIC
           |                    +-1d.0-[0000:04]----02.0  Intel Corporation 82544EI Gigabit Ethernet Controller (Copper)
           |                    +-1e.0  Intel Corporation 82870P2 P64H2 I/OxAPIC
           |                    \-1f.0-[0000:03]--+-02.0  Intel Corporation 82544EI Gigabit Ethernet Controller (Copper)
           |                                      \-03.0  Adaptec AIC-7901A U320
           +-03.1  Intel Corporation E7500/E7501 Hub Interface C RASUM Controller
           +-1d.0  Intel Corporation 82801CA/CAM USB (Hub #1)
           +-1d.1  Intel Corporation 82801CA/CAM USB (Hub #2)
           +-1e.0-[0000:01]--+-03.0  Intel Corporation 82557/8/9 [Ethernet Pro 100]
           |                 +-04.0  Intel Corporation 82540EM Gigabit Ethernet Controller
           |                 \-0c.0  ATI Technologies Inc Rage XL
           +-1f.0  Intel Corporation 82801CA LPC Interface Controller
           +-1f.1  Intel Corporation 82801CA Ultra ATA Storage Controller
           \-1f.3  Intel Corporation 82801CA/CAM SMBus Controller

Re: [Bug ??] 2.6.18-rc6-mm2 - PCI ethernet board does not seem to work

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

On Fri, Sep 15, 2006 at 03:29:54AM -0700, Greg KH wrote:
> That being said, I think we need to reverse the order of this patch,
> keeping the current scheme as default, and allowing it to be overridden
> on the command line for those few machines where it matters to be
> compatible with the old, 2.4 ordering scheme.
> 
> Matt, care to rework the patch in this manner?

Greg, Andrew,

I'd really like to rework this patch in a different direction.  As
such, please drop the patch:

gregkh-pci-pci-sort-device-lists-breadth-first.patch

from your trees, and I'll provide a new one next week.

Breadth-first vs depth-first is really only part of the problem.  More
fundamental is the expectation that embedded devices get discovered
before add-in devices in physical slots.  From there, breadth-first vs
depth-first is interesting again.  I'd like to sort the list to put
the embedded devices first, subsort those breadth-first, then list the
add-in devices in ascending slot number order, subsort breadth-first.
I'll default this sorting routine off, enabled/disabled via a command
line option, and enabled by default for some systems based on DMI
strings.

arch/i386/pci/irq.c already has the PCI IRQ Routing Table available,
from which we can get embedded vs slotN information.  It's not
currently being used in this manner, so I'm massaging that.

How does this sound?

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]