On Sat, 8 Jan 2011, Kevin D. Kissell wrote: > > With the Bonito I'd have assumed it was some low-level PCI code rewrite > > -- that seem to keep happening over and over again -- that missed a bit in > > the Bonito driver or the driver altogether. With the Bonito core cards > > limited to the MIPS 20Kc core and some exotic (for the Malta) QED CPU > > options that would be no surprise at all to me. > I don't think it's a "classic" Bonito, YAMON calls out: > > MIPS SOC-it 101 OCP / 1.3 SDR-FW-1:1 If it doesn't say "Bonito", then it's not a Bonito. ;) I've had a peek at the driver and I bet it's related to the "PCI iomap" thing. The PCNet32 driver doesn't use it and goes for the traditional direct inw()/outw()/etc. approach. I haven't been following the relevant discussions, so I can't say offhand whether PCI iomap has become mandatory now or not, but what I think is happening is that inw()/outw()/etc. no longer reach the PCI port I/O space from the driver on your system by default. Now the other driver presumably does use PCI iomap and when it initialises, it maps a piece of PCI port I/O space somewhere in the virtual address space (or initialises a KSEG/XKPHYS mapping in kernel's structures) making inw()/outw()/etc. see it. And given due to PC/AT legacy PCI port I/O space ranges requested are typically small (256 contiguous bytes are the guaranteed maximum on PC/AT-compatible systems), one MMU page spans more than one (as does obviously a kernel segment) making the other driver's mapping inadvertently valid for this driver too. This in turn magically makes it work. Note, while a plausible explanation, this is a pure guess on my side. If it is indeed valid, then where the bug lies will depend on whether PCI iomap has become mandatory or not. Maciej
