On Fri, 10 Jan 2003 20:00:31 +0100, Jochen Hein said:
> > - and I've seen a report it causes an OOPS
> > on 2.5.53. I've not tried it on post-52, but I had a -54 kernel OOPS
> > right around that point in bootup (right after IDE and somewhere in PCI
> > init). Haven't chased that one at all...
if it OOPSes without my patch, then it's somebody else's problem. If it
does so with my patch, but just gives the infamous "resource collisions"
message without it, then it's my fault ;)
> cs: cb_alloc(bus 1): vendor 0x115d, device 0x0003
OK.. we obviously made it *into* cb_alloc()..
> PCI: Enabling device 01:00.0 (0000 -> 0003)
This is coming out of pcibios_enable_resources() - the same function that
without my patch would have given the 'resource collisions' error and
returned.
> PCI: Setting latency timer of device 01:00.0 to 64
xircom_probe to pci_set_master to pcibios_set_master, and we've returned
from pci_enable_device. and thus we've gotten past where my patch is. Only
possibility is that my code has re-arraigned some pointers in an evil way.
Now, it's pretty obvious that *some* call to pci_assign_resource has to
happen before pci_enable_device() for these Xircom cards for things to work
at all (and note that they work just fine in 2.4 and pre-2.5.47).
I wonder if the *current* problem with the OOPs is due to this change in the
.53 patches to pci/setup_{bus,res}.c - as per the changelog:
<ink@jurassic.park.msu.ru>
[PATCH] PCI: setup-xx fixes
Don't disable PCI devices before changing the BARs, as discussed
recently. Disabling PCI_COMMAND_MASTER bit is an obvious bug.
Further, pdev_enable_device() is a leftover from very old (2.0, I guess)
alpha PCI code. It's used in pci_assign_unassigned_resources() to
enable *every* PCI device in the system. So, if we have two graphic
cards on the same bus, both with legacy VGA IO... oops.
Actually, only alpha relied on that due to the lack of
pcibios_enable_device (which has been already fixed).
After this patch, we no longer go into pdev_enable_device, which may have
been doing something that was in fact still needed by the Xircom code,
although I'm mostly guessing that it's the 'disable the ROM'. The other
possibility is that ink's patch exposes a problem with the way my patch
calls pci_alloc_resource() before pci_enable_device().
In any case, I've attached a new *UNTESTED* patch, that only tries to gratuitously
assign resources of MEM class, and disables the ROM once it does so.
No, I don't claim to fully understand this code. And if you're not brave
enough or can't test it yourself, I'll be taking the 2.5.56 plunge sometime
this weekend. ;) And all you other kernel hackers are welcome to jump right
in and tell me what I'm doing wrong.. ;)
/Valdis
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:35 EST