Alas, my laptop boots no more. I did leave it off and unplugged the night before yesterday (I think I noticed it needed a little bit more time to power off than usual, but this could be wrong). Yesterday morning it wouldn't boot. No POST, no CPU fan running, no nada. I've been unable to make it live again. I didn't invest much time in it, anyway. The hard disk works, so at least I lost no data. > -----Original Message----- > From: Bjorn Helgaas [mailto:bjorn.helgaas@xxxxxx] > Sent: Wednesday, November 19, 2008 20:09 > To: GARCIA DE SORIA LUCENA, JUAN JESUS > Cc: linux-pci@xxxxxxxxxxxxxxx; jbarnes@xxxxxxxxxxxxxxxx; Jiri > Slaby; Gary Hade; JIMENEZ SHAW, FRANCISCO JAVIER; Thomas Renninger > Subject: Re: PCI bus conflict hang: how to avoid the > allocation of an I/O range. > > ACPI is supposed to tell us enough about embedded things like > that so the OS can at least keep its mitts off. Maybe if you > attached the DSDT to the bugzilla > (http://bugzilla.kernel.org/show_bug.cgi?id=11054), > somebody smarter than I could figure something out. It's > quite possible that ACPI *is* telling us something, and we're > ignoring it. I've attached the disassembled DSDT to the bugzilla (I had it prepared somewhere else, so I have access to it). I could upload the Ubuntu booting dmesg. > BTW, I would assume Windows works fine on this box. You > don't have any information about how it configures that > bridge, do you? The laptop came very cheap with Windows XP Home. I think they were getting their stock away, because actually Windows Vista changes the way of handling transparent bridges which support positive decoding too. See the following link (Microsoft Word format): http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204 a672f11cf/PCIbridge-subtr.doc If that is actually true, (I think I looked at the device manager and confirmed it before the machine died) Windows XP doesn't configure any positive decoding ranges in the PCI-to-PCI bridge. That would explain it working correctly in Windows. I was explicitly looking for I/O resources in the 0x1000-0x1fff ranges, and I couldn't find any. I think the CardBus bridge, if any, had its ranges in some 0xF??? address block. I don't know if the activation of the positive decoding in the bridge is the thing responsible of the machine getting fried, although the coincidence seems likely. Perhaps decoding was working when changing the cardbus address, but some electrical decoding conflict still remained. I suspect the hardware had some serious bus design fiasco. If I can fix the hardware or I get any other new information I'll make you know. Regards, Juan Jesus. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
