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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
