PROBLEM: PCI (?) trouble on Toshiba M400 notebook

[Elias Holman <eholman@holtones.com>]

I have a Toshiba Portege M400 tablet notebook that will not boot due to
a null pointer dereference.  This problem appears to have been
introduced between 2.6.17-rc1 and rc2.  I have tried many kernels since
then with no better luck, up to 2.6.18-rc2.  I apologize if this issue
has been addressed via a patch or otherwise and I have not seen it, but
a search of the mailing list archives turned up nothing except that this
problem was informally reported on June 21st by Herbert Rosmanith, but
he chose not to submit a full report for whatever reason.  From his
email:

"I just had to examine
a notebook which had problems with our software: a
"toshiba portege m400". 2.4 seems to work so far, as does 2.6.16.
I also tried 2.6.17, but get a strange problem: it simply hangs
after writing "PCI: probing hardware" (or similar). A closer look
reveals that it hangs in drivers/pci/probe.c, in pci_read_bases. What's
exactly going on, I don't know..."

I have more or less confirmed that it stops in pci_read_bases by putting
printk statements at different points in the code (I am really not a
kernel hacker and so it was the only thing I knew to do).  It appears
that the problem is in this block:

for(pos=0; pos<howmany; pos = next) {
.
.
.
pci_read_config_dword(dev, reg, &l);
pci_write_config_dword(dev, reg, ~0);
pci_read_config_dword(dev, reg, &sz);
pci_write_config_dword(dev, reg, l);

It stops somewhere in the reading and writing block, although I haven't
narrowed it down further.  It appears that the value of howmany is 6, so
I assume this is being called from inside of pci_setup_device in the
PCI_HEADER_TYPE_NORMAL case, where a call to pci_read_bases has a
constant 6 passed in.  It appears to hang on the 3rd time through the
loop, i.e. device number 2.  I don't really know how the output of lspci
relates to that device number, but I am happy to provide the full
verbose lspci output for an interested party.  It also appears to be the
second call to pci_read_bases, with it being called from inside the
PCI_HEADER_TYPE_BRIDGE case with no issue (I am basing this again on the
value of howmany, which is 2 in that case).

I can get further into the boot process by specifying pci=off, although
then acpi has trouble.  If I specify pci=off and acpi=off, then it gets
even further, but eventually has trouble mounting the root filesystem.

I am currently running what appears to be a stable configuration on
2.6.17-rc1 with no issue.  I am happy to provide any more debugging
information that someone might need.
-- 
Eli


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/