Most recent kernel where this bug did not occur: 2.6.12
Distribution: Gentoo 2006.1
Hardware Environment: Apple PowerBook G3 (Lombard)
Software Environment: Gentoo Linux 2006.1 (GCC 4.1.1)
Problem Description: Machine panics with "Oops: ...machine check..." message on insertion of (also if card
is already in slot on boot) any PCMCIA card with Yenta-socket driver, either as module, or compiled in.
Failure appears to be caused by pcmcia_read_cis_mem call according to stacktrace.
Steps to reproduce: Compile yenta-socket support either into kernel or as module and insert PCMCIA card.
Created attachment 9221 [details]
Image of stacktrace
Found workaround in the way of a "reserve=0xfd000000,0xffffff" parameter passed to the kernel using
yaboot. (BootX would apparently work on oldworld systems that exhibit this behavior)
I don't know how I missed these posts before filing this bug, but I did. Still, it seems that perhaps this
is still a bug that can be resolved? Maybe it's not in the PCMCIA code, necessarily, but perhaps in the
ppc32 platform code? Is there a way to mark this memory range reserved without requiring this
I will leave this bug deferred for now, until someone else can answer these questions.
Any update on this problem so far?
Closing the bug. Please reopen if still a problem and/or someone resumes the work on it.
I'm seeing this with kernel 188.8.131.52 (OpenSuSE 11.0) on a Lombard Powerbook. The fix given above still works but is annoying
Please can the bug be re-opened?
We had a similar problem a year ago with bcm43xx and b43legacy. In that case, it was attempted reads of memory that was only present for certain versions of the wireless adapter. On x86 platforms, the read returned all ones, but on ppc one got machine checks. Nasty to find as I only has x86.
what's the output of "lspcmcia -vvv" (without any card inserted), of "lspci -v" and of /proc/iomem (without the "reserved" boot option)?
Created attachment 16832 [details]
Results of lspcmcia etc. after booting without reserve=0x...
Created attachment 16833 [details]
Results of lspcmcia etc. after booting with reserve=0x...
These files don't look very different but were definitely created with / without the "reserve=0xfd000000,0xffffff" kernel boot option as hinted by the file names. Also the wireless LAN card (Netgear MA401) worked fine in the second case.
Oh. ppc doesn't have /proc/iomem output? (this _is_ a PPC box, right?) Also, this is a strange box as it doesn't define which iomem area to use for PCI devices. Therefore, pcmcia uses /etc/pcmcia/config.opts. So the proper fix would be to comment out the line in /etc/pcmcia/config.opts which reads
inclode memory 0xfd000000-0xfdffffff
Or what am I missing here?
I see what you're suggesting, but there's no relevant line in /etc/pcmcia/config.opts - file attached.
Created attachment 16856 [details]
file /etc/pcmcia/config.opts as discussed
And yes, it certainly _is_ a PPC box! More completely, it's an Apple Powerbook G3 (Lombard) with a PPC 740 running at 333 MHz
Strange. Could you post a full dmesg output (without the reserved option), please?
Created attachment 16858 [details]
dmesg straight after booting without "reserve=" etc.
Now this contains interesting information:
pcmcia: parent PCI bridge Memory window: 0xfd000000 - 0xfdffffff
means the PCI host bridge is configured to allow "downstream" devices to use this memory area. However, when the PCMCIA socket tries to do so, you get the machine check. So my question would be to the powerpc folks: why is the PCI host bridge configured this way, even if this memory area is not usable?
No response then from the PPC maintainers? Is anyone there following this thread?
I note this bug is still shown as CLOSED WILL_FIX_LATER too :-(
So I got paulus lombard here. I booted 2.6.27-rc1 (with a couple of totally unrelated fixes to make it build :-), with yenta built-in (couldn't be bothered netbooting with modules), orinoco built-in, prism54 (cardbus) built-in, 8250_cs built-in.
I tried 3 cards: orinoco card worked just fine. prism54 card worked just fine, 8250 modem didn't work because it apparently failed to match it to the 8250_cs driver, maybe it really wants modules there, I haven't looked too closely.
I'll try to investigate more tomorrow. It looks like yenta didn't pickup the fd000000 area on my machine and that worked, but I'll see if I can make it pick it up. It's possible that the firmware is lying and that this range hasn't actually been enabled on the bridge. I'll have a look.
Also make sure your config file doesn't try to feed ranges to the kernel driver, that's obsolete, it should be able to find free ones all by itself.
I think I see the problem. In your dmesg, one can see:
PCI host bridge /pci@80000000 (primary) ranges:
IO 0x00000000fe000000..0x00000000fe7fffff -> 0x0000000000000000
MEM 0x00000000fd000000..0x00000000fdffffff -> 0x0000000000000000
MEM 0x0000000080000000..0x00000000fcffffff -> 0x0000000080000000
That means that the region at 0xfd000000 is mapped to 0 ...
not 0xfd000000 on the PCI side. ie. It's not a 1:1 mapping, but rather
it's a way to access the ISA memory space on the PCI side.
As such it should -not- have been added to the PCI host bridge resources.
I'll see if I can find why the kernel is getting that wrong.
Created attachment 17035 [details]
Remove the ISA hole from the bridge resources
This patch should fix the problem. Please let me know.
OK will try as soon as I can, but the machine is at home and I'm now at work (for the next 9 hours or so ;=( )
I assume it's good for kernel 184.108.40.206 ? I'm not quite as bleeding-edge as you guys! Also not too experienced in kernel building either, but I have a friend who is. Will report back as soon as I can...
Ben - Looks good.
dmesg shows "Removing ISA hole at 0x00000000fd000000" otherwise very much as previously. BUT - no OOPS on PCMCIA card insertion, WiFi seems to be OK too.
Will test further over coming days but I think this fixes the problem, many thanks.
PS - It took over 8 hours to build (remember this is only a PPC 740 with 333 MHz clock and 384 M RAM) and I kept running out of HD space but eventually I got there.
Is this patch likely to make it into the next kernel release?
Yes, I'll also send it to -stable for .25 and .26 after I've fully convinced myself that it won't hurt anything.
Ouch, fixing the status...