PROBLEM: PCI (?) trouble on Toshiba M400 notebook

PROBLEM: PCI (?) trouble on Toshiba M400 notebook

[Elias Holman]

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

PROBLEM: PCI/Intel 82945 trouble on Toshiba M400 notebook

[Elias Holman]

Hi all,
I submitted an email a week or so ago about a hang on boot due to a null
pointer dereference.  The problem started in 2.6.17-rc2 and continues
through 2.6.18-rc3.  I did some more digging on this problem hoping to
spark some interest.  I've narrowed the problem down to the following
code in pci_read_bases:

for(pos=0; pos<howmany; pos = next) {
.
.
.
pci_read_config_dword(dev, reg, &l);
//hang happens here on first attempt to write
pci_write_config_dword(dev, reg, ~0);

At that point, the device being accessed is the intel graphics hardware,
specifically, if you print out the vendor and device ID, you get:

vendor: 0x8086 = intel
device: 0x27A2 = PCI_DEVICE_ID_INTEL_82945GM_IG

I assume the issue is actually with this driver, but I don't understand
driver loading and the kernel architecture well enough to know where to
look next.  The device appears to be at two locations on the bus based
on my understanding of what lspci is telling me.  It appears to hang
when it is being accessed via 00:02.0; I'm basing this on some debug
messages I put in.

Following is the output of lspci -vvv for this device run on 2.6.17-rc1,
and the relevant text of my original email.  Any assistance or pointers
anyone can offer would be greatly appreciated.

00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated
Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: Toshiba America Info Systems Unknown device 0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 20
        Region 0: Memory at ffd80000 (32-bit, non-prefetchable)
[size=512K]
        Region 1: I/O ports at cff8 [size=8]
        Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at ffd40000 (32-bit, non-prefetchable)
[size=256K]
        Capabilities: [90] Message Signalled Interrupts: 64bit-
Queue=0/0 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics
Controller (rev 03)
        Subsystem: Toshiba America Info Systems Unknown device 0001
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Region 0: Memory at 55000000 (32-bit, non-prefetchable)
[disabled] [size=512K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-



On Tue, 2006-07-25 at 08:03 -0500, Elias Holman wrote:
> 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 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