kernel fault when booting with dual link network card

Hi,

Kernel 2.6.24 causes the machine to fault when a dual-link network card is installed right after loading the tulip module. Output of SER PIM attached.

Sjoerd

What the world *really* needs is a good Automatic Bicycle Sharpener.

I'm afraid just the hex dump isn't really any use. To be possibly useful, we need at least the symbolic addresses of IAOQ and %r2. That's:

%r2: 0x10245748
IAOQ[0]: 0x10252bdc
IAOQ[1]: 0x10252be0

the I/O module error seems to indicate an incorrect GSC DMA read.

James

I don't think it's going to tell us anything useful. I believe that we've not set up the cardmode Dino correctly to respond to iomem space and as a result the first access to iomem space will fault.

Of course, this is a machine with CCIO, so it could be something going wrong with the CCIO programming too. But I think it's Dino.

Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Yes specially if the system low in RAM (e.g. when I have to reduce ram of my c110 from 512M to 64M, it became impossible to boot it ;-( .)
After longly thought it was a pb of coherency, I am now convince that's the key pb: my d380 boot fine with 256M but I resurrect 'ccio_mem_ratio' which reduce artificially iova_space_size and if I can still boot it, disk's issues occur more quickly (a simple tar -xvf of a big file is enough now). Right now, I reach to put in place many trace_mark() in this driver and thanks to Mathieu Desnoyers's patch and his help, it's now possible to me to collect a lot of info without degrading too much system perf. Just need more time to collect relevant info and analyze it ;-)

But I think it's Dino.

hypothesis easy to verify: just remove this card.

hth,

	J.

Without the card the machine seems to work fine indeed.

Sjoerd

"There are three principal ways to lose money: wine, women, and engineers.
While the first two are more pleasant, the third is by far the more certain."
		-- Baron Rothschild, ca. 1800

tx for feedback.

btw, sorry if I miss it but what kind system is: a C, D or a K model?

Tx,

	J.

This is a D9000 machine with a D220 processor

Sjoerd

All science is either physics or stamp collecting.
		-- Ernest Rutherford

On Sun, Jun 29, 2008 at 10:22:21AM -0600, Matthew Wilcox wrote:
...

It depends on if the first access is a read or a write. If it's a read (and odds are good that's true), we will get the exact IP that faulted and get something about "CPU timeout" in the PIM dump.

I doubt it too. I agree it's much more likely something with Dino.

thanks,
grant

BTW, once you've captured a PIM, it needs to be cleared with "ser clearpim" before it will record the next one.

And thanks - this confirmed what several had suspected:

Timestamp = Sun Jun 29 14:45:18 GMT 2008 (20:08:06:29:14:45:18)

Bus HPA Module Type Path Slt Md Sev Estat Requestor Responder
----- ---------- ---------------- -------- -- -- --- ---- ---------- ----------
GSC 0x0000006d A DMA I/O 8/8 2 0 fe 0x03 0x00000000 0x00000000

Type "io info" will dump all the IO devices and you can match the "8/8" path to the offending device. I suspect it's the card-mode Dino as well.

We probably need to enable "PCI_DEBUG" which depends on "DEBUG_KERNEL". Enable both of those, then capture the console output when booting that kernel. We can then walk through the Dino and PCI code to see what didn't get setup correctly.

thanks,
grant