PROBLEM: sym53c8xx is broken on HP LH 4 after Linux 2.2

On the HP NetServer LH4, the sym53c8xx driver only works in 2.2 kernels, and fails with a "CACHE INCORRECTLY CONFIGURED" error on 2.4 and 2.6. This also applies to the sym53c8xx_2 driver.

I searched through the 2.4 and 2.3 series, and finally found that it broke after the pre4-1 patch from the 2.3.99 era. I split that patch up into little parts and found the one piece that exposed the problem - it's a small pair of changes to pci-i386.c. Backing that patch out of 2.4.22 with patch -R makes the sym driver work again.

I've captured lspci dumps before and after the change, along with the output from the driver on a stock kernel vs. a kernel that has this patch backed out. There's a lot of it, so I've put it out on my web server at this URL:

http://www.exploits.org/~rkroll/sym/

I am not suggesting that the patch be reverted, since it's obviously a bug fix. My guess is that the fix exposed a problem in the driver.

Some background on the hardware: the LH4 seems to have two 53c895 interfaces on board. In 2.2, you can't see the primary interface in lspci, perhaps due to the bug that was fixed by the pre4-1 patch. This is generally not a problem, since the NetRAID/MegaRAID typically covers that interface.

On 2.4, both interfaces are visible, and the driver can't seem to latch onto the second one. I don't care if the first one doesn't work, since I don't intend to talk to the disks that way. All I need is the second one, since that's where my tape drive is connected.

This system happens to be a dual Pentium III, but I've whittled the kernel builds down to generic UP/Pentium settings without any positive effect. I even threw out just about everything except what I need to boot at one point. I've tried using "sym53c8xx=excl:0x1400", but it doesn't help. It's not something in userspace which causes this, since it still happens when I boot with 'init=/bin/sh'.

I intend to run 2.4.22 on this system, but tried 2.6.0-test9 in case the problem had been discovered and fixed in that tree. Unfortunately, it also failed. I haven't tried mangling 2.6's PCI code to duplicate the effects of backing out that patch yet.

This box is not in production, so I can run tests and try different things. My own attempts at making the driver work were not successful.

I'm stuck. Any advice or pointers would be appreciated.

Hi Russell. I'm really interested in fixing this for the sym2 driver in 2.6. Given this bit of the lspci log:

01:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895 (rev 01)

	Subsystem: Hewlett-Packard Company: Unknown device 1000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 247 (7500ns min, 16000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 1400 [size=256]
	Region 1: Memory at 40000000 (32-bit, non-prefetchable) [size=256]
	Region 2: Memory at 40001000 (32-bit, non-prefetchable) [size=4K]

01:07.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895 (rev 01)

	Subsystem: Hewlett-Packard Company: Unknown device 1000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 247 (7500ns min, 16000ns max), cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at a000 [size=256]
	Region 1: Memory at e8101000 (32-bit, non-prefetchable) [size=256]
	Region 2: Memory at e8100000 (32-bit, non-prefetchable) [size=4K]

I would say that this is a PCI problem, not a sym2 problem. I'm only trying to pass the buck to another of my personalities though, since I also hack PCI stuff. I really don't think we should have two devices with the same domain:bus:slot.function since there's no way to do pci config cycles to one or the other.

Hmm.. is this what's meant by the comment:

/*
* Ignore Symbios chips controlled by various RAID controllers.
* These controllers set value 0x52414944 at RAM end - 16. */

#if defined(__i386__)
        if (base_2_c) {
		...
                        ram_val = readl_raw(ram_ptr + ram_size - 16);
                        iounmap(ram_ptr);
                        if (ram_val == 0x52414944) {
                                printf_info("%s: not initializing, "
                                            "driven by RAID controller.\n",
                                            sym_name(device));
                                return -1;
                        }

I have a couple of suggestions.

First, I have a strong suspicion that updating your firmware will fix this problem. But once we do that, we lose this opportunity for debugging the pci code. So after we're done robustifying the pci code, you can go to http://welcome.hp.com/country/us/en/support.html select "Download drivers and software", enter 'lh 4' in the box, submit, then select "Cross operating system (BIOS, Firmware, etc)".

Second, I want to see what the PCI code is up to. So, can you change the #undef DEBUG to #define DEBUG in linux-2.6.0-test9/drivers/pci/probe.c then boot that kernel and send me the dmesg output.

Thanks.

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

I can tell you what's going on here. This is a 450NX based motherboard. The 450NX chipset from Intel was the first chipset to have peer PCI busses. For backwards compatibility, some machine makers hacked their PCI BIOS to have a fake bridge device on PCI bus 0 that points to the same bus number as the peer bus. This way if the OS didn't know about the peer bus registers it would still find the devices by scanning behind the bridge. In this case we are scanning behind this fake bridge and then also scanning based upon the peer bus registers in the chipset, and as a result we are finding the device twice. In order to fix this problem you need to change the peer bus quirk code for the 450NX chipset to scan the list of bus 0 devices looking for a bridge that has the same config as the peer bus registers and if so delete the bridge from the list. That will avoid double scanning and will avoid having the PCI code try and configure sub busses via a fake bridge when it should do all configurations via the 450NX peer bus registers.

  Doug Ledford <[email protected]>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606