On Mon, Sep 17, 2007 at 07:03:29PM +0200, Peter Stuge wrote:
Hi,
Thank you for your excellent reply!
On Mon, Sep 17, 2007 at 10:43:35AM +0300, Markus Tornqvist wrote:
I've been reading dmesg and tested sda, I should have mentioned that, but that didn't help...
Please send us your dmesg output.
I actually have a mount now!! :)
I will explain details further below, but here's what I hope is relevant:
pcmcia: request for exclusive IRQ could not be fulfilled. pcmcia: the driver needs updating to supported shared IRQ lines. Probing IDE interface ide2... hde: ELITE PRO CF CARD 1GB, CFA DISK drive usbcore: registered new driver hiddev input: USB Multimedia Keyboard as /class/input/input0 input: USB HID v1.00 Keyboard [ USB Multimedia Keyboard ] on usb-0000:00:10.0-2 ide2 at 0x100-0x107,0x10e on irq 5 hde: max request size: 128KiB hde: 2031120 sectors (1039 MB) w/1KiB Cache, CHS=2015/16/63 hde: hde1 ide-cs: hde: Vpp = 0.0
The entirety is attached.
So the driver is broken wrt irq handling?
It appears to be abstracted behind a cardbus whatever interface and therefore it would probably need something extra to work, right?
The CF slot is PCMCIA slot #1 in the Ricoh RL5c476 controller, which by the way appears to be quite a crappy piece of hardware. (There are known, unfixed, hard-to-fix bugs with it specifically mentioned on the Linux PCMCIA page.)
http://pcmcia-cs.sf.net/%27s mail archives speak of irq problems at least.
I will definitely look into this further later.
But I couldn't get it running..
First of all, make sure you build your own kernel so you have control of things.
This I am doing, fortunately.
Then; are you using new PATA or old ATAPI/IDE drivers? Make sure you
I'm on the new one, CONFIG_IDE
have PCMCIA PATA support or PCMCIA IDE support enabled, respectively.
Here I made a stupid mistake, didn't notice it under the pcmcia menus so I searched for PCMCIA, so I missed it, as it's under the IDE menu with the name CONFIG_BLK_DEV_IDECS so my bad there :(
I recompiled my FAI installer kernel with that on and it Just Worked :)
So that was the faulty point.
Either way, the particular flash card you are using needs to be recognized by the kernel driver in order for things to work automagically. Run pccardctl info with the card inserted to get the PRODID_* strings you need - then calculate the CRC32 hash that needs to go into the kernel - see /usr/src/linux/Documentation/pcmcia/crc32hash.c and add the hashes to both drivers. Please send a patch to the linux-pcmcia mailing list with them as well.
I'm not sure I understand this part, at least completely, sorry.
This is not handleable by udev, to have the rules there for creating nodes? Or do I need to patch the drivers to have udev play along?
Documentation/pcmcia/devicetable.txt isn't really clear either on where I'm supposed to put those crc32 hashes...
Anyway, seems my card is supported anyway but it would be interesting to know this stuff :>
When using LB there are at least two tricky problems with what you (and I) want to accomplish:
- If FILO is to load the kernel from the Ricoh slot #1, the Ricoh
chip seems to need to be configured in a way which later causes Linux to not be able to pick it up as a PCMCIA controller. This is surely a problem with how LB initializes the Ricoh, combined with, ehm, "design decisions" in the FILO IDE driver.
I'm actually thinking about skipping FILO if possible, so I have the kernel and and a small-enough initrd as the payload.
Have to admit I haven't really checked sizes yet, but the via spec said the bios is 2/4Mbit, so 4Mbit should fit pretty much...
Any thoughts on this?
It is still always sad when hardware doesn't really work or is very hard to fix :/
- Pluggable device events are handled in a separate kernel thread,
which means that the root device may not be available by the time Linux wants to mount root even though the card is physically plugged in - because the coldplug event has not been processed and the device has not yet been added to the kernel-internal device tree.
This may turn out to be a severe problem.
Anyway, my roadmap is pretty much that next up I'll set up a local debian repository so I can install a kernel.
Then I'll have FAI install on the cf.
After that (because seems it's now supported) I'll test boot with the factory bios and grub.
.. And then there will be linuxbios, finally :)
1 needs further investigation. I gave up on it because I did not understand 2 completely when I first looked at this. If you search the LB archives for September 2006 you'll find some posts by me babbling about the CF situation on the EPIA-MII.
After I get this message out.
IBM has an article on this from early 2.4 kernel times. The suggested workaround was to add a few seconds delay to the kernel before it tries to mount root, so that the coldplug event is handled first. That's crazy ugly of course, but it works. Unfortunately the patch for the ancient kernels is no longer available so it will have to be re-invented. :(
Even if it were available I doubt it would patch in very cleanly, so something needs to be figured out.
It's also possible to configure the Ricoh slot #1 as a static IDE device - ie. not hot-pluggable and using the plain PATA/IDE drivers, not the PCMCIA ones. Then it works fine in FILO, and it almost worked with 2.6.18. A lot has happened in the kernel since so I think
What is "almost worked", please? :)
chances are good for it to work perfectly now. The problem with this is that the slot IS hot-pluggable so I do not want to be dumbing it down with a non-hotplug-aware driver. You may be fine with that.
That's almost the same type of defeat-admission as using a separate cf-ide adapter, which I'd rather pass up on.
Finally, if you haven't gotten to booting with LB yet and are still working with the factory BIOS you are just having some silly driver issue in your kernel. Get that fixed (possibly you need to add your card CRC32 hashes to the drivers) and you'll be on your way.
Would seem to be limited to whatever bad mojo's still coming wrt the ricoh.
Thank you once again!